> > * Section 4.2.3: To improve observability, ipmpstat now separates IPv4 > > and IPv6 multicast nominations, and identifies IP interfaces that > > have been taken offline due to hardware address conflicts. In > > addition, the "disabled" link state proved unnecessary and thus has > > been removed. > > 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. > > * 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. Thanks! -- meem
