[Xorp-hackers] Patch to fix issue with interface removal and multicast.

Ben Greear greearb at candelatech.com
Mon Sep 1 13:23:49 PDT 2008


The attached patch fixes (or hacks around) some problems I see with
certain scenarios related to removing interfaces dynamically when
multicast is enabled.  It's possible this problem is because of my other
fea changes, but I think it's a problem with the base logic.

There is likely more that one issue here, but I think this use case 
described
below would probably reproduce this on un-patched xorp configured with
multicast.

My case is with my patched xorp, and the patch is on top of my other 
patches.

Here is the scenario:

Suppose a xorp instance has 3 interfaces, br0, eth0, eth1, and suppose 
eth0 and eth1
are usb NICs that can dissappear when removed from the machine (I'm using
different virtual interfaces, but the logic is similar.)

I have a control program that notices (or causes) interface removal, and 
when it does,
it sends cli commands to xorpsh to remove the config related to that 
interface.

Now, xorp is all fine with 3 interfaces.
...
eth0 is removed
 my monitor program initiates xorpsh commands to remove eth0 config info
eth1 is removed
 xorp notices eth0 is removed and cleans up fea logic.
 xorp notices eth1 is removed and cleans up fea logic.
 xorpsh commands above get to the 'commit' stage
 monitor program queues additional commands to remove eth1 config info

The commit fails, because the commit tries to set info for eth1, and the 
device is no
longer in the kernel.  Since this commit fails, the next one to remove 
eth1 will as well
(because eth0 is still in the config, and still not in the OS).

The scenario above can happen in several different orders, but the basic 
problem is that
xorp commit cannot deal with interfaces being removed from the OS at 
arbitrary times.

The attached patch ignores failure cases related to interfaces being 
removed.  I think
it would be better if we could return a warning message to the xorpsh 
without
failing the commit, but that is beyond the scope of what I have time to 
accomplish
currently.

Please consider applying any part of this you see as useful, and/or 
coming up with something
better.

Thanks,
Ben


-- 

Ben Greear <greearb at candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: xorp_mcast_commit.patch
Type: text/x-patch
Size: 8929 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20080901/c04d7161/attachment.bin 


More information about the Xorp-hackers mailing list