Hi,
If multiple default gateways are set, which one will be chosen? And if
the chosen one is down, will others take over?
It works sometime, but not most of the time. (example below) The
behavior is inconsistent.
How the case is handled? On what condition another default gateway is
chosen? Thank you!
=======================
~ # ip r
10.65.30.0/24 dev bond0 src 10.65.30.71
default via 10.65.30.221 dev bond0 (this one is down!)
default via 10.65.30.1 dev bond0
~ # ip r get 8.8.8.8
8.8.8.8 via 10.65.30.221 dev bond0 src 10.65.30.71
~ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
// after a while
~ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=56 time=5.0 ms
~ # ip r get 8.8.8.8
8.8.8.8 via 10.65.30.1 dev bond0 src 10.65.30.71
// after two while
~ # ip r get 8.8.8.8
8.8.8.8 via 10.65.30.221 dev bond0 src 10.65.30.71
~ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
==================================
Best regards,
Wei
From: Wei Huang <redacted>
Date: Thu, 23 Aug 2012 14:31:26 +0800
If multiple default gateways are set, which one will be chosen? And if
the chosen one is down, will others take over?
Yes.
It works sometime, but not most of the time. (example below) The
behavior is inconsistent.
The problem is that when a nexthop becomes unresponsive we need
to wait for an event to timeout the routing cache entry.
In 3.6.0-rc1 and later, this inconsistent behavior will happen less
often, because the routing cache has been removed so we will do the
full default route resolution on every route lookup. The only problem
at that point is socket cached routes, those will still need to wait
for a timeout before the next default gateway will be tried.
On Thu, Aug 23, 2012 at 2:38 PM, David Miller [off-list ref] wrote:
The problem is that when a nexthop becomes unresponsive we need
to wait for an event to timeout the routing cache entry.
In 3.6.0-rc1 and later, this inconsistent behavior will happen less
often, because the routing cache has been removed so we will do the
full default route resolution on every route lookup. The only problem
at that point is socket cached routes, those will still need to wait
for a timeout before the next default gateway will be tried.
Thanks a lot, David!
I'm using 2.6.16. Could you tell me where the code is, that detects
nexthop unresponsive, sends an event, and timeout the cache? Or are
there procs or sysctl to adjust the timer values?
Another thing I found is that the route looking-up seems to update the
routing cache entry. Is that true? In my example in the first mail,
after a while, the default gateway should have been switched to the
second one. If I ping 8.8.8.8 then, the second active gateway should
be used. But instead, if I look for the route first with "ip r get
8.8.8.8", the first inactive gateway will be the result, and it will
be used if I ping now.
Will the route looking-up even influence the behavior? Will there be a
work around way for this?
Thanks,
Wei