Ben Greear <[EMAIL PROTECTED]> wrote: > Bruce M Simpson wrote: > > > > Hi, > > > > The register vif is a virtual interface in the MROUTING code which is > > used to send PIM register messages upstream to the Rendezvous Point > > (RP) with the correct encapsulation. > > > > The FEA code does not give the register vif any special handling, to > > avoid introducing a lot of special cases into the code. If you look at > > mfea_node.cc you will see the code which allocates a vif index in FEA > > space for the register VIF. > > > > However: The MROUTING vif numbers are unrelated to ifindex, they do > > NOT occupy the same space. By the looks of it you've hit the assertion > > where the MFEA has allocated a VIF index inside the FEA, where there > > is a 'real' system interface sharing the same index. > > > > Unfortunately the MROUTING code does not allocate a real interface > > descriptor from the underlying system. If you look at the MROUTING > > code you will see it has a 32 vif limitation due to the API used. > > > > This is why I strongly recommended looking at the other issues in > > MROUTING first before attempting to add multiple FIB support. > Well, I haven't actually tested multiple routing tables yet...just > working on a single one. The FEA seems to assume that there > is no duplication of pif-index, but it seems that the fake register_vif > interface just steals a pif_index from a physical interface. > I don't think this has anything in particular to do with the multicast > vif-index, at least not for the assert that I hit.
You are right. This is a bug in the MFEA, because register_vif shouldn't reuse the pif_index from another interface. I just committed a fix to CVS that basically sets the pif_index for the register_vif to 0 (i.e., no valid pif_index for this interface). I believe now it should work (e.g., note that the existing IfTree::insert_ifindex() and erase_ifindex() methods correctly ignore interfaces if the pif_index is zero), but please let me know if you run across some related issue. Thanks, Pavlin _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
