Re: [LARTC] Question re: multi-homed access

[Thomas Vander Stichele <thomas@urgent.rug.ac.be>]

Hello Julian,

> > So you're saying it looks like it works right, but it doesn't ? Hm, ok.
> > So are the times when it doesn't work totally random, or is there some
> > logic in it ?
> 
> 	Nothing is random :) The problem comes when the cached
> route entry expires (/proc/sys/net/ipv4/route/gc_timeout) or the
> cache is flushed as result of a user command such as adding/deleting
> IP address or flushing the routes explicitly with "ip route cache flush".
> The result is clear: the routing cache forgets the path and the NAT
> code does not care.

Hm, OK.  I checked the value on my system and it's set to 300, which IIRC 
would mean 5 minutes (it's in seconds, right ?).  The ssh connection set 
up takes only about 2 seconds.  Isn't it highly unlikely that the cache 
would have a timeout in that interval, *reliably*, every time ?

> > > 	I hope there will be effect
> >
> > On first inspection, no.  Is there some way I can debug incoming packets ?
> > What else can I give as feedback ?
> 
> 	You have to be able to analyze with tcpdump what is going on.

OK, I used both iptraf and tcpdump to check what is going on, and I find 
something very odd.  Traffic does indeed go out on two interfaces, as 
traceroutes and output of last on the boxes I ssh to show.  But using both 
tcpdump and iptraf, I only see non-tcp data going over eth2.  None of the 
tcp-connections show up on eth2.  They do on eth1.

The only difference I can see is that ifconfig shows eth2 to be
"UP BROADCAST NOTRAILERS RUNNING", while eth1 is "UP BROADCAST RUNNING 
MULTICAST".  Other than that, the total received traffic is roughly the 
same on both interfaces (which is weird, since I still cannot connect from 
the outside over eth2), while the transmitted data for eth1 is 10 times 
larger than for eth2.  I'm not sure if this is because somehow traffic 
going out over eth2 is not "registered" right (as seen by tcpdump and 
iptraf) or because of something else.  I'm not that experienced using 
tcpdump, so I can't tell.  Also, I don't know enough about the lesser-used 
output from ifconfig since I never needed it before ;)

Is there something that could explain this weird behaviour ? Or are there 
some hints or guides to use tcpdump correctly in debugging this particular 
problem ?

All of this, btw, is done with my patched kernel including your patches 
(just to make sure ;) )

Thanks in advance,
Thomas

 -- 

The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*-                      -*->
"You don't need a girlfriend, you need a maid !"
"Isn't that the same thing ?"
"Uh uh, baby, you're in the wrong century."
<-*- thomas@apestaart.org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/