On 06/22/07 13:57, Grant Taylor wrote:
I'm now going to test where the two routes are different MAC
addresses to see if the traffic does indeed start using the proper
rout again.
Ok, I have done it and it is working.
The short answer is all you need to have backup routes is to enter them
in reverse order. You do not need to do any special kernel options,
patch the kernel or any thing else, or any special ip rules. All you
need to do is to enter the routes in the reverse of the order that you
want them to be used.
For example, if I have two different internet connections, each with
their own default gateway. Obviously the two default gateways have to
not be on the same subnet.
GW1: A.B.C.D
GW2: Z.Y.X.W
GW3: K.L.M.N
route add default gw K.L.M.N
route add default gw Z.Y.X.W
route add default gw A.B.C.D
Note: All the above routes are the same metric (default of 0).
I do not know why you have to add the routes in reverse. I have just
noticed that route adds the routes as the highest priority to the
routing table. Filled from the top, not the bottom type thing. So,
conversely add them in the reverse order.
In my current test environment I have two identical VMWare virtual
machines (literal copy from one to the other) that I have modified the
configuration and tested. I'll try to depict it below:
( ISP 1 ) --- ... --- ( ISP 1) --- ( Internet )
( ) |
(DMZ) --- ( Router ) ( Peering Link)
( ) |
( ISP 2 ) --- ... --- ( ISP 2) --- ( Internet )
In this scenario, the DMZ IP address space is from ISP 1. ISP 1 has a
route to the DMZ via the ISP 1 IP address on my local Linux router. ISP
1 has a secondary route to the DMZ via the IP address on ISP 2s router
over the peering link. ISP 2 has a route to the DMZ via the ISP 2 IP
address on my local Linux router.
The link between my local Linux router and ISP 1 is a high speed
wireless link. The link between my local Linux router and ISP 2 is a
lower speed ADSL link.
The ADSL link from ISP 2 is *ONLY* used for backup access in case my
local Linux router is unable to communicate with ISP 1s router. Thus if
for some reason traffic does come in to my ISP 2 IP address it is to go
back out the ISP 1 link, thus asymmetric routing.
I appreciate all the suggestions that everyone submitted while trying to
help resolve this issue. In the end it turned out that everything that
was needed is already in the stock / vanilla kernel.org kernel. All I
had to do was be smart enough to use it.
Some points to help others with this issue if they ever need it:
- Equal Cost Multi Path (a.k.a. E.C.M.P.) routing is NOT needed.
- NO ip rule(s) were needed to pull this off.
- NO additional routing tables were needed to pull this off.
- NO patches (i.e. Julian's Dead Gateway Detection patch) were needed
to make this off.
- NO special scripts were needed to monitor and / or modify the
routing table(s). (Note: This is applicable to my scenario, see below.)
With regards to the monitoring of routing tables, I did not need to do
any thing special, i.e. no ping or arping was needed. I think this was
because when my primary route went down I would start using the
secondary route and the returning traffic would always try to use the
primary and fail back to the secondary route. When the primary route
did come back up the inbound traffic would come in the primary interface
/ route thus incrementing the counters in my kernel thus making the
kernel aware that the primary route was indeed back up so it could
switch back to it.
Note: In my test, I was manually taking the interface down on one VM
and subsequently bring it back up and restoring the route(s) across it.
In my opinion, this interface fiddling on the upstream end is not
automatic, but is out side of the scope of the client end failing back
to a backup route. If I were trying to do this between two systems
where the link in the middle (between intermediary switches) went down,
I believe I would have to do some sort of heart beat across the link.
In this case, I would probably use (read: try) arping first and then
switch to something else if that did not work.
Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
