[quagga-dev 4317] Re: ripd fails to leave multicast group on deletedinterface
gdt at ir.bbn.com
Mon Aug 21 16:12:06 BST 2006
Michal Ruzicka <michal.ruzicka at comstar.cz> writes:
>> One is the handling of memberships on interfaces that are deleted.
>> The kernel should remove these, as otherwise they'd be dangling
>> references, and if not it's simply a kernel bug.
> The linux kernel unfortunately does not do that. And I'm not sure
> if it ever will since it would make (I think) deleting an interface
> quite expensive as the number of the sockets (and their associated
> multicast list) that would have to be walked through could be quite
> large. But maybe I'm wrong, in any case I'll try to suggest that
> on the kernel-netdev mailing list.
Deleting an interface is a big deal; walking the set of sockets
shouldn't be an issue. IMHO it's better to have correct behavior than
>> The more complex problem is handling memberships on interfaces that
>> are down but not deleted. Here, I'd argue that the drop membership
>> ioctl should succeed.
>> The workaround for the down case is in ospfd, where if joining a group
>> fails the group is left and then rejoined. As Paul said, this should
>> be genericized.
> What about performing the drop membership on the "down" interface and
> keeping the workaround in place to catch some currently unforseen
The problem is that on some systems, drop requests fail on down
interfaces. But I think it's good for quagga to keep track of what
it's done so it can at least report discrepancies. And the real world
is messy in terms of the various behaviors out there.
> Sorry for that, but all the whitespace changes (I belive) was removal
> of whitespace on otherwise empty lines (which only makes the source
> longer and nothing else).
Sure, but patches should only change real code, or be solely
whitespace cleanups, so that they can be either read by humans or
ignored, and not a mixture.
>> Did you find that a leave could be done on a replacement interface
>> when the old one had been deleted?
> No, I'm affraid I've missed that. (It seems that I haven't reviewed
> the patch for zebra-0.94 [which I've based mine upon] thoroughly enough.)
> What is the sequence of events to trigger that?
not sure, but maybe
interface foo0 deleted
interface foo1 arrives, gets address that foo0 used to have
[now, how do you remove the foo0 membership]
> As I said before, there is (currently) no purge mechanism of socket
> multicast memberships in the linux kernel, so it seems neccessary
> to make the explicit drop membership setsockopt call there. Probably
> conditionally compiled as other OSes (like the presented example
> of NetBSD) may perform the drop implicitly.
Does Linux store memberships by ifindex? How can the membership be
dropped if the new ifindex doesn't match? Is it only luck that the
numbers are reused?
I don't object to bookkeeping and retries, but the current Linux
behavior you describe seems incorrect and should be fixed.
Greg Troxel <gdt at ir.bbn.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 185 bytes
Desc: not available
More information about the Quagga-dev