On Sat, 2009-08-29 at 16:53 -0400, [email protected] wrote: > I have a question about in.routed's behavior on the receipt of RTM_LOSING. > > The problem reported in CR 6875276 can also happen in onnv afaict- > the root-cause is that in.routed is getting RTM_LOSING messages for > some remote host: > > read rtm 140 bytes > rtm: msglen 140 version 3 type 5 index 0 > rtm: flags 40 addrs 27 pid 0 seq 0 > rtm: errno 0 use 0 inits 0 > : > RTM_LOSING: 72.5.124.61/32 --> 10.4.164.1 > > This causes the code to hit in.routed`rtm_lose() (file is table.c), > which then ages and deletes the (only) default route on the system
That behavior doesn't make sense to me. RTM_LOSING could have been generated for a slew of reasons, most of which probably have nothing to do with the reachability of the gateway for the route to that host. The most likely case if that the host at the remote side of a TCP connection is itself unreachable because it's down. > > the question (for anyone who is aware of the history here) is why the > RTM_LOSING for the host is reason to wipe out the default > route itself? Sounds like a bug. > In this case, the default router (and everything in the path is fine), > it's just the tcp endpoint that died. But in.routed will nuke the > default route based on this information, and will not refresh until the > next rtradv restores it. > > So should in.routed`rtm_lose meddle with default routes based on RTM_LOSING? I don't think so. Wiping out a route simply because one host that happens to be covered by that route isn't reachable is unwise. -Seb _______________________________________________ networking-discuss mailing list [email protected]
