jose nuno neto writes:
Im using RedHat 2.6.18-164.2.1.el5 without any patch
The way Im using to test failed gateway is with iptables blocking the
traffic, probably not the best simulation.
What I want to test is a switch/router fail that wont forward my
connection properly.
In that case iptables is a proper simulation IMHO, but I'm not sure the
kernel can switch routes the way you expect.
As far as I know, if both routers are reachable and one of them will not
forward your traffic, using routing like this will not help you. Whenever a
route lookup is performed, randomly one of the two provided routes will be
taken (whether that router will forward your traffic or not).
Julian Anastasov's patches make this a bit smarter, so that, if your
*router* is unreachable, that route will not be selected. But still, if the
router is fine but it won't forward your traffic, you'll have bad luck half
the time.
Personally I use a similar setup (only I'm not using bonding). I have solved
it this way (with much help from http://www.ssi.bg/~ja/dgd-usage.txt ):
I have a separate route table for each router:
ip route add 172.26.240.4 via 172.26.247.248 dev bond1 table 200
ip route add 172.26.240.4 via 172.26.31.248 dev bond0 table 201
and an ip rule:
ip rule add to 172.26.240.4 lookup 200
or
ip rule add to 172.26.240.4 lookup 201
And then I use ping or a TCP/UDP connection to see via which router the
critical IP is reachable, and I adjust the ip rule as necessary. Maybe that
gives you some more ideas.
Everything is pretty ok, but since I have this critical IP and have to
paths to get to it, though I could add extra redundancy with iproute tools
Right now I did a test with your input, failing one path, and after
putting it up again, doing ping to the gateway ip
But no change happens....
Do you have any extra clues?
Just to be sure: what route is the kernel using for your critical IP, before
you begin, after failing one path, and after putting it up again? (ip route
get 172.26.240.4)
What happens if you flush the route cache? (ip route flush cache)
Regards,
roel
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
