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
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?
for example, it's fairly easy to reproduce this problem by doing the
following steps
- on victim machine (must have only one default route) ssh to some offlink host
('faraway'), and run a simple script that, for example, does something like
while [ 1 ]; do
cat /var/adm/messages*
done
- on the console of faraway, type "mdb -K" to freeze it in kmdb.
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?
--Sowmini
_______________________________________________
networking-discuss mailing list
[email protected]
