Hello,

Am 01.01.2013 um 18:25 schrieb NicoEchániz:

On 12/30/2012 10:16 PM, Jan Lühr wrote:

...

Hello,

I started using batman-adv's gateway mode. Sadly, I ran into some trouble - A client is connected to two gateways via vpn (fastd): # batctl gw_mode client (selection class: 1)

# batctl gwl Gateway (#/255) Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/f6:ec:38:e9:72:35 (bat0)] 6a:4b:93:de:00:84 (255) 6a:4b:93:de:00:84 [ mesh-vpn]: 207 - 48MBit/48MBit => aa:31:0e:4a:0f:1d (254) aa:31:0e:4a:0f:1d [ mesh-vpn]: 39 - 1024KBit/1024KBit

# batctl o [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/f6:ec:38:e9:72:35 (bat0)] Originator last-seen (#/255) Nexthop [outgoingIF]: Potential nexthops ... aa:31:0e:4a:0f:1d 0.500s (255) aa:31:0e:4a:0f:1d [ mesh-vpn]: aa:31:0e:4a:0f:1d (255) 6a:4b:93:de:00:84 0.940s (255) 6a:4b:93:de:00:84 [ mesh-vpn]: 6a:4b:93:de:00:84 (255)

The client should use 6a:4b:93:de:00:84 as a gatway, since it provides much higher data rates - however, it is stuck at aa:31:0e:4a:0f:1d.

I have observed the same behavior.

That's quite frustrating. Can I debug, when and why batman-adv actually chooses as specific gateway?

Thanks, Keep smiling yanosz

Hello,

Am 03.01.2013 um 02:57 schrieb Marek Lindner:

On Thursday, January 03, 2013 07:28:02 Jan Lühr wrote:

...

...

...

The client should use 6a:4b:93:de:00:84 as a gatway, since it provides much higher data rates - however, it is stuck at aa:31:0e:4a:0f:1d.

I have observed the same behavior.

That's quite frustrating. Can I debug, when and why batman-adv actually chooses as specific gateway?

Yes, you can. Enable the batman-adv debug log at compile and runtime. While retrieving the 'batman' log messages you should see something like: Adding route to gateway .. Changing route to gateway .. Found new gateway .. etc

Maybe you can post the result here ?

Ok, Let's give it a try:

=== Command Log a) Situation on node at beginng - just one gateway, the right one. Freifunk-b0487acb2d58:~# batctl gwl Gateway (#/255) Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/b2:48:7a:cb:2d:59 (bat0)] => 72:8b:06:40:61:2e (248) 72:8b:06:40:61:2e [ mesh-vpn]: 215 - 96MBit/96MBit

b) Enable gateway mode on the backup gateway root@fastd3:~# /usr/local/sbin/batctl gw server 1Mbit/1Mbit

Gateway-List is: Freifunk-b0487acb2d58:~# batctl gwl Gateway (#/255) Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/b2:48:7a:cb:2d:59 (bat0)] => 72:8b:06:40:61:2e (255) 72:8b:06:40:61:2e [ mesh-vpn]: 215 - 96MBit/96MBit aa:31:0e:4a:0f:1d (255) aa:31:0e:4a:0f:1d [ mesh-vpn]: 39 - 1024KBit/1024KBit

c) Disable regular gateway, force node to switch to backup kif:~# batctl gw_mode client

Gateway-List is: reifunk-b0487acb2d58:~# batctl gwl Gateway (#/255) Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/b2:48:7a:cb:2d:59 (bat0)] => aa:31:0e:4a:0f:1d (255) aa:31:0e:4a:0f:1d [ mesh-vpn]: 39 - 1024KBit/1024KBit

d) Re-enable regular gateway root@kif:~# /usr/local/sbin/batctl gw server 100Mbit/100Mbit

Gateway-List is Freifunk-b0487acb2d58:~# batctl gwl Gateway (#/255) Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/b2:48:7a:cb:2d:59 (bat0)] 72:8b:06:40:61:2e (254) 72:8b:06:40:61:2e [ mesh-vpn]: 215 - 96MBit/96MBit => aa:31:0e:4a:0f:1d (255) aa:31:0e:4a:0f:1d [ mesh-vpn]: 39 - 1024KBit/1024KBit

e) Wait some time

f) Stop Logging

=== End of command Log

=== Node log of that hour http://jluehr.de/batman-adv.log.gz

zgrep -i gateway batman-adv.log.gz [ 1022240] Gateway class of originator aa:31:0e:4a:0f:1d changed from 0 to 39 [ 1035100] Gateway class of originator 72:8b:06:40:61:2e changed from 215 to 0 [ 1035100] Gateway 72:8b:06:40:61:2e removed from gateway list [ 1035830] Changing route to gateway aa:31:0e:4a:0f:1d (gw_flags: 39, tq: 255) [ 1046020] Gateway class of originator 72:8b:06:40:61:2e changed from 0 to 215

Hello,

Am 03.01.2013 um 15:58 schrieb Marek Lindner:

On Thursday, January 03, 2013 19:03:11 Jan Lühr wrote:

...

c) Disable regular gateway, force node to switch to backup kif:~# batctl gw_mode client

Gateway-List is: reifunk-b0487acb2d58:~# batctl gwl Gateway (#/255) Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2012.4.0, MainIF/MAC: wlan0-1/b2:48:7a:cb:2d:59 (bat0)] => aa:31:0e:4a:0f:1d (255) aa:31:0e:4a:0f:1d [ mesh-vpn]: 39 - 1024KBit/1024KBit

d) Re-enable regular gateway root@kif:~# /usr/local/sbin/batctl gw server 100Mbit/100Mbit

Ah! You failed to mention this part in your initial email.

The behavior is easily explained: batman-adv does not switch gateway whenever a new gateway is found (even if it is a better gateway) unless the selection class is on fast or late switching.

It is. - Sorry, forgot to mention: Freifunk-b0487acb2d58:~# batctl gw_mode client (selection class: 1)

=> 1 -> fast connection consider the gateway's advertised throughput as well as the link quality towards the gateway

Keep smiling yanosz

On 01/03/2013 12:14 PM, Marek Lindner wrote:

On Thursday, January 03, 2013 23:01:07 Jan Lühr wrote:

...

...

Ah! You failed to mention this part in your initial email.

The behavior is easily explained: batman-adv does not switch gateway whenever a new gateway is found (even if it is a better gateway) unless the selection class is on fast or late switching.

It is. - Sorry, forgot to mention: Freifunk-b0487acb2d58:~# batctl gw_mode client (selection class: 1)

=> 1 -> fast connection consider the gateway's advertised throughput as well as the link quality towards the gateway

You did mention you were using selection class 1. I was referring to your test in which you turn on/off your best gateway. As I explained in my previous mail: batman-adv does not switch the gateway once it has chosen a gateway unless you select fast or late switching as selection class. Selection class 1 does not fall into this category which means a gateway reselection only happens if the currently selected gateway disappears.

Marek, could you please clarify this?

From the man page I don't see an option that would behave as Jan (and I) seem to be expecting it to work. That is: switch to a better gateway - with more bandwidth and comparable link quality - when it's available.

gw_mode|gw [off|client|server] [sel_class|bandwidth] [...] If the node is a gateway client the parameter will decide which criterias to consider when the batman-adv module has to choose between different internet connections announced by the afore- mentioned servers. default: 20 -> late switch (TQ 20) examples: 1 -> fast connection consider the gateway's advertised throughput as well as the link quality towards the gateway 2 -> stable connection chooses the gateway with the best link quality and stick with it (ignore the advertised throughput) 3 -> fast switch connection chooses the gateway with the best link quality but switches to another gateway as soon as a better one is found XX -> late switch connection chooses the gateway with the best link quality but switches to another gateway as soon as a better one is found which is at least XX TQ better than the cur- rently selected gateway (XX has to be a number between 3 and 256).

Would mode 3 accomplish this fast switching? It doesn't mention if this mode will consider advertised throughput or not; only selection class 1 mentions throughput.

-- NicoEchániz

On 01/03/2013 09:39 PM, Marek Lindner wrote:

On Friday, January 04, 2013 08:06:17 NicoEchániz wrote:

...

Would mode 3 accomplish this fast switching? It doesn't mention if this mode will consider advertised throughput or not; only selection class 1 mentions throughput.

Selection class 3 and beyond do change the gateway when a better one becomes available. But as you correctly pointed out these selection classes don't consider the announced bandwidth for the simple reason that nobody cared. In most wireless scenarios (the main playground for batman-adv) the path towards the gateway turned out to be more critical than the gateway's pipe to the internet.

Feel free to propose something if you care about having this option. The necessary code shouldn't be too hard to add. Backward compatibility will be more difficult to achieve.

I believe that those of us who chose to use selection class 1 would prefer if it were "dynamic". So if a new gateway appears, then the client would evaluate with the same previous criteria if it is better or not (considering "the gateway's advertised throughput as well as the link quality") and switch accordingly. I see no reason why when someone chooses selection class 1 she would be expecting to choose the best available gw once and not ever check again.

If a network is stable, when a new better gw appears in some area it won't be selected until nodes are restarted, and that might be a long time.

In my town, where partial energy outages are frequent, I've had to manually switch off gw_mode and play around with this from time to time because clients would be stuck with the wrong gw after an energy shortage in the main gw.

One other change that might be interesting would be the addition of a setting for how much the advertised throughput affects gw selection. I've seen Jan uses 96/96Mbit as advertised throughput on one router; I do the same on our "main gateway", but maybe it would be better if we could actually advertise the real throughput and have a setting to control how much the bandwidth difference affects the selection.

By the way, I posted a patch to improve the man page explanation a couple of hours ago.

good, it reads better now :)

Cheers, NicoEchániz

Hello,

Am 04.01.2013 um 18:41 schrieb Marek Lindner:

On Friday, January 04, 2013 23:12:59 NicoEchániz wrote:

...

...

Selection class 3 and beyond do change the gateway when a better one becomes available. But as you correctly pointed out these selection classes don't consider the announced bandwidth for the simple reason that nobody cared. In most wireless scenarios (the main playground for batman-adv) the path towards the gateway turned out to be more critical than the gateway's pipe to the internet.

Feel free to propose something if you care about having this option. The necessary code shouldn't be too hard to add. Backward compatibility will be more difficult to achieve.

I believe that those of us who chose to use selection class 1 would prefer if it were "dynamic". So if a new gateway appears, then the client would evaluate with the same previous criteria if it is better or not (considering "the gateway's advertised throughput as well as the link quality") and switch accordingly. I see no reason why when someone chooses selection class 1 she would be expecting to choose the best available gw once and not ever check again.

If a network is stable, when a new better gw appears in some area it won't be selected until nodes are restarted, and that might be a long time.

You misread my statement. Nobody needs to be convinced of the usefulness of such a feature (at least for what concerns myself). Somebody needs to come up with a solid proposal which then needs to be implemented. That is what I meant by saying "Feel free to propose something [..]".

Note that switching immediately as soon as a better gateway comes around isn't the best solution. Imagine a case in which a gateway announcing the highest bandwidth in your network barely is visible for your gateway client. It will keep switching between gateways, thereby breaking all your stateful connections such as: ssh, vpns, video & music streams, etc

Thanks for being open minded. Imho there are a few "tweaks" for doing so.

For our networks, it's not important, that all clients choose the gateway with the highest data rate. Basically, we have 3 gateway-types -> Regular Gateways, that should be used if they are reachable (above a certain TQ threshold) -> Backup Gateways - Gateways, that should be used if no regular Gateway is available. -> Test Gateways - Just for testing purpose - should be used if no Backup-Gateway is available.

Imho others may have more / or less classes. basically what is needed here is a positive gateway ("route priority") - imho the already existing gateway-class may be used for doing so.

In order to prevent "switching immediately as soon as a better gateway comes around", we may can go this way: gw_mode client may have three parameters: 1st: Switching threshold based on TQ (Like today, eg 20: late switching) 2nd: Switching threshold based on Gateway Class). GC-Thresh 3rd: LQ-Threshold for GW-class-switch GC-TQ-Thresh

Meaning: Switch gateway to same / better class, if there is a Gateway having TQ xx-Times bigger (traditional late switching with xx) Switch gateway to a better class, if a Class is GC-Thresh times better, and LQ is above TQ-GC-Thresh Switch gateway to a worse class, if all existing gateway of same or better class have LQ < GC-TQ-Thresh

However, this is quite complex and I don't know if everybody will be happy with this - However, I'll be so.

For backwards compatibility, old configurations can be detected by counting the number of parameters and react according old defaults.

If you like thinks to be more complex - Different thresholds for blocking DHCPDISCOVER / DHCPREQUEST ;-)

Thanks, Keep smiling yanosz

On 01/04/2013 02:41 PM, Marek Lindner wrote:

On Friday, January 04, 2013 23:12:59 NicoEchániz wrote:

...

...

Selection class 3 and beyond do change the gateway when a better one becomes available. But as you correctly pointed out these selection classes don't consider the announced bandwidth for the simple reason that nobody cared. In most wireless scenarios (the main playground for batman-adv) the path towards the gateway turned out to be more critical than the gateway's pipe to the internet.

Feel free to propose something if you care about having this option. The necessary code shouldn't be too hard to add. Backward compatibility will be more difficult to achieve.

I believe that those of us who chose to use selection class 1 would prefer if it were "dynamic". So if a new gateway appears, then the client would evaluate with the same previous criteria if it is better or not (considering "the gateway's advertised throughput as well as the link quality") and switch accordingly. I see no reason why when someone chooses selection class 1 she would be expecting to choose the best available gw once and not ever check again.

If a network is stable, when a new better gw appears in some area it won't be selected until nodes are restarted, and that might be a long time.

You misread my statement. Nobody needs to be convinced of the usefulness of such a feature (at least for what concerns myself). Somebody needs to come up with a solid proposal which then needs to be implemented. That is what I meant by saying "Feel free to propose something [..]".

Note that switching immediately as soon as a better gateway comes around isn't the best solution. Imagine a case in which a gateway announcing the highest bandwidth in your network barely is visible for your gateway client. It will keep switching between gateways, thereby breaking all your stateful connections such as: ssh, vpns, video & music streams, etc

Yeah, I agree. The gateway switching should be regulated by a threshold, so that it won't be switching like crazy when a client has similar ranking values from more than one gw. See the proposal below...

...

One other change that might be interesting would be the addition of a setting for how much the advertised throughput affects gw selection. I've seen Jan uses 96/96Mbit as advertised throughput on one router; I do the same on our "main gateway", but maybe it would be better if we could actually advertise the real throughput and have a setting to control how much the bandwidth difference affects the selection.

Again, feel free to propose something which can be discussed.

It could just be implemented as a new setting like: gw_bw_weight

which would regulate how much gw bandwidth/throughput affects best gw calculation.

I don't know what's the current algorithm but I guess there would be no problem with backwards compatibility here; if the value is not set, the default should produce the same result we get now.

So to make the proposal clear:

I'd change options for gw_mode client to something like this:

gw_sel_class [1|2] (1 considers TQ and bw, 2 only considers TQ)

gw_tq_threshold [3...256] the minimum TQ delta to switch to a better gw, defaults to 20.

gw_bw_weight [value from 0 to 1] how much does advertised gw bandwidth affect the selection. 0 does not affect selection, 1 has most effect. Defaults to 1 but has no effect if gw_sel_class is 2.

For backwards compatibility, if gw_sel_class > 2, it should behave as the proposed option 2 with gw_tq_threshold set to the actual value. So, for example gw_sel_class 20 would be "translated" to: gw_sel_class 2, gw_tq_threshold 20, al least until it's deprecated.

The advantage of this proposal is that we can have a tq_threshold that can still be used in the mode that considers gw throughput.

I like this better than gateway classes that Jan proposed, as it is less implementation specific.

Please let me know if anything in this proposal is not sufficiently clear.

cheers, NicoEchániz

PS: Marek, there are mismatched parenthesis in the new man page text in this paragraph:

The second (optional) argument specifies the selection class (if 'client' was the first argument) or the gateway bandwidth (if this node's internet connection bandwidth. Just enter any number (optionally followed by "kbit" or "mbit") and the batman-adv module will guess your appropriate gateway class.

Hello,

Am 05.01.2013 um 00:28 schrieb NicoEchániz:

On 01/04/2013 02:41 PM, Marek Lindner wrote:

...

On Friday, January 04, 2013 23:12:59 NicoEchániz wrote:

...

...

Selection class 3 and beyond do change the gateway when a better one becomes available. But as you correctly pointed out these selection classes don't consider the announced bandwidth for the simple reason that nobody cared. In most wireless scenarios (the main playground for batman-adv) the path towards the gateway turned out to be more critical than the gateway's pipe to the internet.

Feel free to propose something if you care about having this option. The necessary code shouldn't be too hard to add. Backward compatibility will be more difficult to achieve.

I believe that those of us who chose to use selection class 1 would prefer if it were "dynamic". So if a new gateway appears, then the client would evaluate with the same previous criteria if it is better or not (considering "the gateway's advertised throughput as well as the link quality") and switch accordingly. I see no reason why when someone chooses selection class 1 she would be expecting to choose the best available gw once and not ever check again.

If a network is stable, when a new better gw appears in some area it won't be selected until nodes are restarted, and that might be a long time.

You misread my statement. Nobody needs to be convinced of the usefulness of such a feature (at least for what concerns myself). Somebody needs to come up with a solid proposal which then needs to be implemented. That is what I meant by saying "Feel free to propose something [..]".

...

...

One other change that might be interesting would be the addition of a setting for how much the advertised throughput affects gw selection. I've seen Jan uses 96/96Mbit as advertised throughput on one router; I do the same on our "main gateway", but maybe it would be better if we could actually advertise the real throughput and have a setting to control how much the bandwidth difference affects the selection.

Again, feel free to propose something which can be discussed.

It could just be implemented as a new setting like: gw_bw_weight

which would regulate how much gw bandwidth/throughput affects best gw calculation.

I don't know what's the current algorithm but I guess there would be no problem with backwards compatibility here; if the value is not set, the default should produce the same result we get now.

So to make the proposal clear:

I'd change options for gw_mode client to something like this:

gw_sel_class [1|2] (1 considers TQ and bw, 2 only considers TQ)

gw_tq_threshold [3...256] the minimum TQ delta to switch to a better gw, defaults to 20.

gw_bw_weight [value from 0 to 1] how much does advertised gw bandwidth affect the selection. 0 does not affect selection, 1 has most effect. Defaults to 1 but has no effect if gw_sel_class is 2.

For backwards compatibility, if gw_sel_class > 2, it should behave as the proposed option 2 with gw_tq_threshold set to the actual value. So, for example gw_sel_class 20 would be "translated" to: gw_sel_class 2, gw_tq_threshold 20, al least until it's deprecated.

I guess, we'll be fine with this. However, it's not clear to me, in what way (formula) gw_bw_weight will actually influence the selection process. Do you have any proposals?

Thanks Keep smiling yanosz

On Monday, January 07, 2013 23:26:10 Jan Lühr wrote:

Ok, I make one - for Link-Usability (or attractiveness, or whatever you like) LU, Gateway-Class GC and TQ: LU = (1 - gw_bw_weight) * TQ + gw_bw_weight * GC

gw_tq_threshold should then be renamed to gw_lu_threshold.

However, that implies, that TQ and GC should are linear in LU and that min( TQ ) = min ( GC ) as well as max ( TQ ) = max( GC ). I'll be fine with the assuming that TQ and GC should be linear in LU - GC can be scaled such that the min / max condition holds LU = (1 - gw_bw_weight) * TQ + gw_bw_weight * ( c1 * GC + c2) (for contants c1, c2)

@Marek, Nico : What Do you think?

May I propose that we schedule an IRC discussion for this topic ? I lost track of what you are actually trying to achieve and I see things getting more and more complicated. Whatever idea you come up with keep in mind that somebody has to do the following before this solution can be merged:

* batman-adv code has to be written, tested & debugged * batman-adv kernel doc has to be written * batctl code has to be written, tested & debugged * man page has to be updated * user documentation for $your_new_mechanism has to be written

Unless you manage to convince somebody else to do the work for you that somebody who has to do all work will be you. In other words: It is in your best interest to keep things as simple as possible. :-)

Cheers, Marek

On Wednesday, January 09, 2013 00:35:17 NicoEchániz wrote:

On 01/08/2013 03:15 AM, Marek Lindner wrote:

...

May I propose that we schedule an IRC discussion for this topic ? I lost track of what you are actually trying to achieve and I see things getting more and more complicated. Whatever idea you come up with keep in mind that somebody has to do the

following before this solution can be merged:

• batman-adv code has to be written, tested & debugged
• batman-adv kernel doc has to be written
• batctl code has to be written, tested & debugged
• man page has to be updated
• user documentation for $your_new_mechanism has to be written

Unless you manage to convince somebody else to do the work for you that somebody who has to do all work will be you. In other words: It is in your best interest to keep things as simple as possible. :-)

agreed. When would it be a good time for an IRC discussion on this matter?

I am idling on IRC most of the time. Depends on you guys.

Cheers, Marek

On 01/09/2013 08:49 AM, Jan Lühr wrote:

Hello,

Am 09.01.2013 um 07:30 schrieb Marek Lindner:

...

On Wednesday, January 09, 2013 00:35:17 NicoEchániz wrote:

...

On 01/08/2013 03:15 AM, Marek Lindner wrote:

...

May I propose that we schedule an IRC discussion for this topic ? I lost track of what you are actually trying to achieve and I see things getting more and more complicated. Whatever idea you come up with keep in mind that somebody has to do the

following before this solution can be merged:

• batman-adv code has to be written, tested & debugged
• batman-adv kernel doc has to be written
• batctl code has to be written, tested & debugged
• man page has to be updated
• user documentation for $your_new_mechanism has to be written

Unless you manage to convince somebody else to do the work for you that somebody who has to do all work will be you. In other words: It is in your best interest to keep things as simple as possible. :-)

agreed. When would it be a good time for an IRC discussion on this matter?

I am idling on IRC most of the time. Depends on you guys.

Sorry for answering late. We'll have our freifunk community-meeting tomorrow evening and we're going to talk about that. For our IRC-meeting, I'd prefer some day next week - If it's ok for you.

I'm also idling on IRC usually; next week is ok; Jan what about monday or twesday?.

Hi all,

I wanted to share this proposal we arrived at after discussion with some AlterMundi hackers, so we can discuss it during our future IRC session. I've previously shared it with yanosz, who had some observations that he can better explain, but agreed on this initial assumption which triggered the proposal:

The scenario we see in our networks is that over a certain link quality which is considered acceptable, we want the clients to choose the gw with better bandwidth. So if for example this quality floor is TQ 100, then if a gw has 6Mbit/s advertised b/w and another has 3Mbit/s, the clients that see this gateways with a TQ above 100 will choose the faster one between them.

We observed that in the current implementation, advertized gateway throughput is used to modify the final gw selection by publishing unrealistic bandwidth. The proposal tries to fix this, as well as the "dynamic switching" for selection class 1. Looking at the current code involved we also believe it would allow to make the implementation simpler.

This would be the proposed options:

gw_sel_class [1,2] 1 will consider gw throughput, 2 will only consider TQ. When using selection class 1, clients will switch gateways if one with better throughput becomes available and reachable with a TQ above gw_tq_floor (see below). Defaults to 2.

gw_tq_floor Only relevant for gw_sel_class 1. Above this TQ floor, the gw with the best advertised throughput will be chosen.* Defaults to 100(?)

gw_tq_threshold TQ delta that triggers a gw switch in the client. If gw_sel_class is 1, the tq_threshold will only be considered to choose between two or more gateways advertising the same winning throughput on the net. Defaults to 20.

The old config options would be deprecated but to maintain backwards compatibility, if gw_sel_class is set to... say 20, it would be internally translated as: gw_sel_class 2 gw_tq_threshold 20

I believe this proposal maintains current behavior for sel_class>1 while IMHO it better handles sel_class 1.

Cheers, NicoEchániz

* if no gw can be reached with TQ over the tq_floor, the client should choose one anyway, probably the one with better TQ; this should be discussed further. Another option would be to choose no gateway and the network admins should fix the net :) or lower the tq_floor values.