<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: Routing: redunancy interface issues
From: Keith Smith <keith,AT,ksmith,DOT,com>
Date: Thu, 7 Feb 2002 07:11:35 +0100
In-reply-to: <OFE5D1E49C.DC458517-ONC1256B56.0053012C@medisearch-int.com>

Nils Lichtenfeld wrote:

> Ok, thats impressive.... So is 192.168.64.128 at the same time your ethx 
>IP? Or would that be a bad idea?

In the particular case above this is a VPN hub on bonded T's, and there 
is no internal interface.

However several of the machines that are spokes do just exactly that, 
they use the same IP on the internal eth as the tunnel. In fact they ALL 
do just exactly that.

And they are in a rather large VPN web, in particular the 25.128 machine 
connects to 12 boxes via CIPE 4 of which overlap this box.

I wrote a "poor mans gated" type program, that sweeps and reads the 
route table looking for point-to-point links and sets up routes based on 
what it can and can't see.  For example from this machine:

#
# ppproutes
#
# DESTINATION    GATEWAY         MASK            UNLESS         FLAGS
#-------------- --------------- --------------- --------------- -----
# oops - This is the cable modem ...
192.168.100.0   192.168.64.1    255.255.255.0   *               net
# mail.ksmith.com may as well be direct
206.139.101.4   192.168.64.1    255.255.255.255 *               net
# casafiesta is the tunnel target
206.139.101.16  192.168.64.1    255.255.255.255 *               net
# jmartin
192.168.4.0     192.168.4.1     255.255.255.0
# VPN to Pittsgrove
192.168.7.0     192.168.7.1     255.255.255.0
# WARREN
192.168.9.0     192.168.9.128   255.255.255.0
# TPS
192.168.42.0    192.168.42.1    255.255.255.0
192.168.43.0    192.168.43.1    255.255.255.0
# VPN to Ksmith
192.168.0.0     192.168.64.128  255.255.0.0
206.139.100.0   192.168.64.128  255.255.254.0
# b0201 / Terminix-Triad  24.0-31.255
192.168.24.0    192.168.25.128  255.255.248.0
192.168.32.0    192.168.25.128  255.255.248.0

Note that 192.168.0.0/16 is routed to .64.128 but there are other more 
specific routes that can come up.  In the event say my .4.1 tunnel here 
went down the packet would get sent via .64.128.

Unfortunately, ... this appears to be a bit of a problem with CIPE, 
because the interface shows up whether you are talking or not.  With 
ppptcp the underlying daemon would lose connectivity and the interface 
would shut down (ie pppd was killed), and would stay down until the two 
machines could talk again when the ppptcp code would again fire up the 
interface.  With CIPE the interface is up as long as the ciped daemon is 
running.

This is not good.

I wish it were not true, but I can't tell you how many times I haven't 
been able to get from here to say the .4.1 hosts real address direct but 
I'll be darned if I can't bounce it off of 64.128 and have it arrive no 
problem. (Albeit with a bit more latency :)

I'm thinking in terms of wrappering ciped in a perl script, that 
monitors the host links, and then killing the ciped daemon when I can't 
get a ping across, or something along those lines.

I hate hacking code like this, but ideally ciped-cb would not bring the 
interface up unless the link was actually working.  If I get REALLY 
motivated I may do a source hack for this, but the last time I fixed an 
SCO tty ioctl problem under iBCS I posted a patch and pissed off the 
maintainer, who then refused to acknowledge it was a problem.  To this 
day iBCS is broken if you run a terminal on a serial line over 38.4K. 
Dunno about abi.

> to go through network B... Would not a triagle be better?

Teach your mailer to wrap, keep your stuff within 80 columns, and that 
will work alot better for visibility.  Outlook sucks unless the other 
guy is using outlook too.  I actually often use a text terminal or 
console window for mail.  You should look at your messages on one 
sometime with 'mail' or another 'simple' client.  Your diagram was WAY 
over to the right, the sentence prior to the quoted line ended at column 
131.  That way what YOU see is what I'LL get :)!  But I digress...

Yes, as in the above example.  I duplicate many of the same tunnels as 
64.128, so we all talk to each other.  The idea is to set up a web of 
VPN'd machines that talk to each other.  Unfortunately now, I'm having 
problems with the route redundancy aspect.

Setting up metrics may also be a viable alternative, but my experience 
is that is slows things down tremendously, and complicates the crap out 
of maintaining it.  After all the interface is *UP* even if it can't 
send any packets.  I'm not sure that would even work.

-- 
Keith Smith                 keith,AT,ksmith,DOT,com
655 W Fremont Dr
Tempe AZ 85282              it's hot





<< | Thread Index | >> ]    [ << | Date Index | >> ]