On Fri, 2008-11-07 at 14:28 -0500, Peter Memishian wrote: > > Regarding the IPv4/IPv6 multicast nominations, I'm trying to rationalize > > and verify with you what happens when different underlying interfaces > > are picked for IPv4 and IPv6 multicast respectively, and the "allmulti" > > group is joined for each. > > > > I think what ends up happening is that (because DL_PROMISC_MULTI is > > enabled on two interfaces) the link-layer receives duplicates of all > > multicast packets (one on each link), but the underlying drivers (or > > GLDv3) each filter out either IPv4 or IPv6 multicast depending on the > > sap of the respective DLPI client that enabled DL_PROMISC_MULTI, so ip > > doesn't end up receiving multicast dups. > > Right; DL_PROMISC_MULTI still honors the bound SAP. If it didn't, even in > the single-IP-interface case IP would get confused because it'd start > receiving e.g. IPv6 packets on the IPv4 ill once DL_PROMISC_MULTI got > enabled via e.g. ill_join_allmulti(). > > > If that's the case, there could be a potential optimization (if one were > > somehow concerned with multicast routing performance, ha!), and that > > would be to have a single phyint_t nomination for the allmulti group, so > > that only one link enables DL_PROMISC_MULTI. I don't think I'd consider > > doing that since the code works as I described above (right?), and I > > don't believe that this affects performance in the vast majority of > > cases. > > Right, the code should work as you describe above.
Thanks, it's as I thought. All good. > > > > * Section 5.14: To simplify the implementation, only SIOCSLIFUSESRC > > > will fail in conjunction with IPMP; the other ioctls (SIOCGLIFUSESRC > > > and SIOCGLIFSRCOF) now trivially succeed. > > > > Can you remind me why SIOCLIFUSESRC is incompatible with the new IPMP > > interfaces? > > It's not incompatible, just out-of-scope -- hence the statement that the > constraint could be lifted in the future. Section 3.19.4 covers this in > more detail. Okay, thanks, that looks good. -Seb
