On Thu, Dec 17, 2009 at 09:17:12PM +0000, Stuart Henderson wrote: > On 2009-12-15, Doran Mori <dhm...@gmail.com> wrote: > > It looks like the last road block in my router project is going to be > > similar to Vladimir Kirillov's problem. In my case I'm having a > > downed link layer host route take precedence over an up ospf /32 route > > So it seems that any host routes, even RTP_DOWN, take priority over > higher priority net routes for the same address. >
Host routes are allways more specific then network routes (even /32 ones). So they will used in that case. Currently the lookup will not try less specific routes in case their RTP_DOWN (or actually not RTF_UP). This could be regarded as bug -- the code is just too insane to fix it easily. > This explains a little trouble I've been having when I restart ospfd > (which I do a bit more often than is good for me, but haven't been able > to put my finger on exactly why I have to...) > Hmm. If you know what goes wrong I will try to fix it :) > My bgp routers run sessions between loopbacks on lo1 which are advertised > into ospf. My defaults are localhost -reject routes. A pretty typical setup > for a network with multiple links between routers. > > If I stop and restart ospfd on router X, typically the bgp sessions > go down, and if I go to the other routers I see dynamic host routes > directing X's traffic towards 127.0.0.1; > > Y# route -n get X > route to: aa.bb.cc.9 > destination: aa.bb.cc.9 > gateway: 127.0.0.1 > interface: lo0 > if address: 127.0.0.1 > priority: 56 (default) > flags: <UP,GATEWAY,HOST,DYNAMIC,DONE> > use mtu expire > 41060 33160L 522 > > Y# netstat -rnfinet | grep aa.bb.cc.9 > aa.bb.cc.9 127.0.0.1 UGHD 2 41188 33160 L 56 lo0 > aa.bb.cc.9/32 aa.bb.cc.244 UGP 0 0 - 32 vlan2244 > aa.bb.cc.9/32 aa.bb.cc.243 UGP 0 0 - 32 vlan2244 > > and I have to route delete aa.bb.cc.9 to get things flowing again. > I'm not quite sure why it's RTF_DYNAMIC, ICMP redirects are off and > I haven't spotted where other than ICMP redirects that sets this, > so I'm not entirely sure where this entry has come from. > This is PMTU fucking around because TCP is no longer getting ACKs back and so it goes and tries to disable PMTU by creating a dynamic route cloned from the parent route. In your case that's the default reject route. Now that's totaly stupid I know and especially the created route is wrong in so far that the reject bit is dropped. It is also questionable why we should create a dynamic route cloned from a reject or blackhole route. > All pretty recent code, Y is running Nov 11th, X running Dec 14th, > this isn't new though, I have just managed to get past enough other > problems that I can see it a bit more clearly..;-) > As a workaround I would try to use blackhole routes instead of reject ones and see if this will make the event of TCPs PMTU magic kicking in less probable. -- :wq Claudio
