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>