> Correct, so why bother to include the flags at all (since the only info > the routing socket message can have is "ce1", and not something like "ce1:5", > so that the flags give misleading info)?
Aside from the desire to have the structure definition be compatible with BSD? Yes, there are a lot of rough edges with our current routing socket implementation. > Moreover, I tried some experiments, and noticed something I did not > expect: if I do something like > # ifconfig ce1 addif 12.1.2.3/24 > no routing socket messages are intercepted by "route monitor", but if > I do "ifconfig ce1:1 unplumb", route monitor gets informed (about > an address removal whose addition it was never told about). Yes, there are a lot of oddities like that in the routing socket logic. I've filed some bugs on some of the more egregious cases, but I've always been a bit leery of making changes there since I have no idea what might be dependent on the stray routing socket messages. > then this gets worse: if (and only if) I down the 0'th address, an RTM_IFINFO > is generated as well, even though the other logical interfaces are alive > and kicking. Yes, that's another piece of the current BSD-Solaris-mutant routing socket semantics. It's because although ip_sioctl_flags_tail() always calls ip_rts_xifmsg() when IFF_UP is cleared, ip_rts_xifmsg() just returns if ipif->ipif_id != 0. > I think that just generating a DELADDR for the address (even the 0'th > one) would be sufficient. And having something like RTM_IFANNOUNCE to > track plumb/unplumb events would help track interface (ill) liveness. What are the BSD semantics for RTM_IFANNOUNCE? In general, with routing sockets I think someone needs to step back and figure out whether there's an overall semantic model that both provides BSD compatibility and deals properly with logical interfaces. (I can't see it, but maybe there is an approach.) If there is no such approach, then we need to make some hard decisions. Leaving routing sockets half-dead like they are now seems criminal. > Hiding downed addresses from GLIFCONF is a Good Thing, but maybe we > could drop the flags from NEWADDR as well. And if we really want to > keep the downed-but-not-quite-deleted addresses, then is it worthwhile > to have a separate system-call (maybe using additional flags, as with > ipmp's solution for test addresses) Separate system call? -- meem _______________________________________________ networking-discuss mailing list [email protected]
