> 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.
It seems I have an error in my routing, it seems the packtes go out on the
right path but with the wrong src address, and after they come back from
the other path.
What would be the way to force the src to change on each path? I dont find
a option for that with nexthop
These are my settings right now
172.26.240.4
nexthop via 172.26.247.248 dev bond1 weight 1
nexthop via 172.26.31.248 dev bond0 weight 1
172.26.240.0/21 dev bond1 proto kernel scope link src 172.26.244.216
172.26.16.0/20 dev bond0 proto kernel scope link src 172.26.18.33
default via 172.26.31.248 dev bond0 src 172.26.18.33
>
> 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
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
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
