On Fri, Dec 18, 2009 at 02:22:11PM +0000, Stuart Henderson wrote:
> On 2009/12/18 12:31, Claudio Jeker wrote:
> > > 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.
>
> Hmmm... given this, would it make any kind of sense to have the routing
> daemons install /32 as host rather than network routes?
>
No I don't think this is a good decision. I prefer having them different
from the dynamic host routes generated by arp and icmp.
This is a very simple way to ensure that this those special routes are a
best match and work (or don't work) in all cases.
> > > 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 :)
>
> The relevant machines were running old code, but this week I've finally
> got them over the nat-to bump, so I'll be able to do some meaningful
> testing with -current soon (I hate reporting problems unless I know
> I've collected enough information to at least point someone in
> approximately the right direction ;)
>
I know a few things especially with new interface addresses are still not
perfect. I will try to unslack on ospfd and ospf6d in the next days.
> > 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.
>
> aha...yes this does indeed seem to be the explanation, and certainly
> for disabling PMTU, cloning a reject or blackhole route makes no sense.
>
See attached diff. Not seriously tested but until now no flames are
exiting my laptop...
> > 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.
>
> This doesn't noticably help. But now I remember that since I started
> sending full BGP tables everywhere I don't actually need a default route
> to redist into OSPF any more...and after removing the route completely,
> this does work as expected, fixing my immediate problem.
>
--
:wq Claudio
Index: netinet/ip_icmp.c
===================================================================
RCS file: /cvs/src/sys/netinet/ip_icmp.c,v
retrieving revision 1.86
diff -u -p -r1.86 ip_icmp.c
--- netinet/ip_icmp.c 13 Nov 2009 20:54:05 -0000 1.86
+++ netinet/ip_icmp.c 18 Dec 2009 14:41:42 -0000
@@ -881,6 +881,11 @@ icmp_mtudisc_clone(struct sockaddr *dst,
if (rt == 0)
return (NULL);
+ /* Check if the route is actually usable */
+ if (rt->rt_flags & (RTF_REJECT | RTF_BLACKHOLE) ||
+ (rt->rt_flags & RTF_UP) == 0)
+ return (NULL);
+
/* If we didn't get a host route, allocate one */
if ((rt->rt_flags & RTF_HOST) == 0) {
