Date: Wed, 6 Jun 2001 07:40:04 -0700 (PDT) From: Andre Albsmeier <andre.albsmeier@mchp.siemens.de> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/27890: FreeBSD not always seems to take the best route Message-ID: <200106061440.f56Ee4D30875@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/27890; it has been noted by GNATS.
From: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
To: Ruslan Ermilov <ru@FreeBSD.org>
Cc: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>,
bug-followup@FreeBSD.org
Subject: Re: kern/27890: FreeBSD not always seems to take the best route
Date: Wed, 6 Jun 2001 16:29:33 +0200
On Wed, 06-Jun-2001 at 15:32:05 +0300, Ruslan Ermilov wrote:
> On Wed, Jun 06, 2001 at 12:29:04PM +0200, Andre Albsmeier wrote:
> > > : 127.0.0.1 127.0.0.1 UH 1 6 lo0
> > > : 192.168.1 link#1 UC 4 0 rl0 =>
> > > : 192.168.2 192.168.1.2 UGSc 1 3 rl0
> > >
> > > The refcount on 192.168.2 route has grown to 1, indicating that the
> > > UDP socket now holds on this route. The `Use' count of 3 corresponds
> > > to our three UDP datagrams (ping4, ping5, and ping6).
> > >
> > > Could you please repeat these steps in your environment, and try to
> > > detect where it behaved differently in your case.
> >
> > It doesn't behave differently, that's interesting. May I ask you to
> > try it using syslogd?
> >
> > - Let host C log to host S (with the route installed).
> > - Watch C's messages appear on S.
> > - Delete C's route to S (via router 2)
> > - Let host C log again (run tcpdump on router 1 to see the packets come in)
> > - Install the route to S (via router 2) again on C
> > - Log more stuff. If you don't see the packets go into router 1 anymore
> > I am really lost...
> >
> Yes, I have reproduced the problem here. My test misses one step.
Hmm, I just wonder why syslogd behaves differently...
> OK, now about what happens here.
>
> Initially, there is the route (cloned from the network route) to S
> (192.168.2.1) through the router 2 (192.168.1.2). UDP socket uses
> this route initially. When this (and the 192.168.2 network) routes
> disappear, on the next write (!), ip_output() detects that the S
> route is DOWN, and "allocates" (caches) another route, which happens
> to be the "default" route pointing to router 1 (192.168.1.1).
> Later, when the route to the 192.168.2 network gets installed again,
> it's not taken into account, as the cached ("default") route is still
> UP.
So this would match my (rather amateurish) description when saying:
It seems that as long as packets can be send somewhere, the
kernel doesn't bother if there is a better route to the
destination until the socket is closed and opened again.
> Unfortunately, there is no easy way to fix this. Checking for
> the best-match route on every write may be too time consuming.
> As the workaround, you can delete and re-add your "default"
> route. This worked for me here. `route delete default' will
Just tried it, worked here as well.
> delete the "default" route from the routing table, but because
> it has a refcnt>0 will not delete it immediately, but will mark
> it as DOWN. ip_output() for this UDP socket's write will detect
> that the cached route is DOWN, will free it, and allocate a new
> route, which will be the route to the 192.168.2 network through
> router 2 (192.168.1.2) this time.
>
> The actual fix would be to notify protocol (from within the
> routing code) whenever its routing table is modified. This
> notification could then be saved in a variable as timestamp,
> and every PCB-cached route could have a similar timestamp as
> well, indicating when this "caching" took place. Having
> that, ip_output() would "invalidate" cached route if it was
> cached before the last routing table modification was done.
>
> I could probably try to implement this, if no one else can
> come up with a better idea.
I can only offer to test any new code since my knowledge about
the corresponding parts in the kernel is not sufficient to
implement it.
Thanks so far,
-Andre
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106061440.f56Ee4D30875>