I'm using ip route to create a load-balanced use of 2 internet
connections, in most respects it works correctly - i.e. traffic gets
routed over both connections. However, one 'feature' of the load
balancing is that routes get cached and don't change if they're in
more or less continuous use - this is exactly the behaviour I need.
Unfortunately some routes don't seem to behave like this and it seems
to be the ones with an 'expires' time. For example I have:
atom3:~# ip -s route show cache 209.85.229.99
209.85.229.99 from 192.168.0.165 via 192.168.0.200 dev eth0
cache users 1 age 16sec mtu 1500 advmss 1460 hoplimit 64
209.85.229.99 via 192.168.0.200 dev eth0 src 192.168.0.165
cache users 1 used 2 age 15sec mtu 1500 advmss 1460 hoplimit 64
With no expires on and from my experiments if I keep up a simple ping
then the route is retained.
However the following route:
atom3:~# ip -s route show cache 92.63.131.67
92.63.131.67 from 10.50.0.1 via 10.50.0.2 dev tun0
cache users 1 used 103 age 1sec mtu 1500 advmss 1460 hoplimit 64
92.63.131.67 via 10.50.0.2 dev tun0 src 10.50.0.1
cache expires 79sec users 1 used 209 age 1sec mtu 1480 advmss
1460 hoplimit 64
has an expires time and when it expires it can get thrown over to the
other connection (which would disconnect any open sessions that check
IP consistency...)
This seems to be the case depending on which gateway is being used.
You'll notice that the second link is via a tunnel.
Firstly, am I correct in thinking that the 'expires' time is what
causes the cache to get cleared regardless of ages and secondly, if
so, is there any way of controlling the expires behaviour or even
finding out why it gets set so I can find a mitigating measure? I can
post more details about the network as it is purely a test bed at this
point - its fairly complex so I didn't want to post a load of
irrelevant information....
I did some searching through the kernel code and am pretty confident
that the expires is the dst_entry struct expires, I have then found
http://books.google.co.uk/books?id=yy7tihZLgGYC&pg=PA892 on Expiration
criteria and this confirms the effect I am seeing and a number of
possible causes.
My suspicion is that because one of the ISP connections I am using to
test the set-up is a bluetooth/mobile phone connection that the PMTU
discovery sets the expires flag on this route. This means that on the
live set-up with only standard ADSL providers I should simply be able
to match the MTU's in the default route and eliminate the problem _IF_
my guess is correct.
Posting this back to the list in case anyone has any further thoughts
on confirming my theory, or alternate theories, and also so anyone
with the same problem can at least get as far as I have when doing a
search...
Alex
--
Open Source Specialist
Axiom Tech Limited
W: http://www.axiomtech.co.uk
T: 0845 1270316
Axiom Tech is a Limited Company registered in England and Wales at 92 Didsbury
Road, Stockport, SK4 2JL. Axiom Tech's company number is 5684132, our VAT
registration number is 878 6568 46.
Unless agreed otherwise, all services and products supplied by Axiom Tech are
subject to our standard terms and conditions, available on request.
--
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
