[Xorp-hackers] vif indeces

[Bruce Simpson]

Hi,

Thanks for your question about VIF indexes.

If you are just trying to hook off the IGMP module to discover new 
multicast endpoints, you shouldn't need to implement a ProtoNode.

At the moment, b) is probably the cleanest solution overall. If it is a 
simple matter of looking up the MFEA VIF index based on a VIF name, then 
please feel free to submit a patch which exposes 
ProtoNode<V>::vif_find_by_name() via an XRL.

pmv wrote:
> ...
> I can get the list of interfaces and vifs using 
> finder://fea/ifmgr/0.1/get_configured_interface_names and 
> get_configured_vif_names, respectively, but fea_ifmgr (or any other 
> targets) does not seem to provide a way to retrieve the corresponding 
> vif_index of each. Is there a way to do this?
>
> My current options are as follows
> a) Implement my module as a full-fledged ProtoNode<V>, and have my own 
> list of vifs
> b) Hack the IGMP module to locate the vif using only the vif_name, or 
> add a new XRL call to do this, since ProtoNode<V>::vif_find_by_name() 
> is available. I do not know why redundant vif identifiers are required 
> anyway. This would however require changes to xorp code.

Some background information:
    The MFEA code is very tied to the BSD MROUTING kernel multicast 
forwarding code -- and the VIF indexes in the MFEA aren't directly 
related to the FEA's notion of a VIF; they aren't redundant, as such, 
they are different identifiers.
    In MROUTING, a VIF index is what's found in the 'struct mfcctl2' 
structure used to configure multicast forwarding, and I believe this is 
what the MFEA is dealing with internally.
    Linux largely follows MROUTING in its implementation, and there are 
weaknesses in this implementation; struct mfcctl2 contains a bitfield 
mask which is 32 bits wide. This means that multicast forwarding can't 
scale beyond 32 interfaces in either Linux or any of the BSDs.
    MROUTING was a research implementation in the beginning, and one of 
the goals was to keep multicast forwarding separate from the unicast 
forwarding path. Whilst I've had discussions privately with Pavlin 
Radoslavov about how this limitation might be addressed, there hasn't 
been any demand from outside to fix it -- yet.

There are platforms (e.g. Windows) where the multicast forwarding plane 
is configured in a completely different way, and the MFEA wouldn't be 
suitable for driving it without significant code refactoring.

thanks,
BMS