Re: [LARTC] Redundant internet connections. !!!SOLVED!!!

Re: [LARTC] Redundant internet connections. !!!SOLVED!!!

[Grant Taylor]

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@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc