Devin, I did a bunch of testing and checking in the lab and here is the scoop: Any multicast mac that is received on an SVI will be punted. The short reason is because we only look for the "01" in the MAC to indicate that this is multicast then we flood to the VLAN. Unlike a unicast flood, we put the CPU as a destination for the multicast flood because we don't yet know if the CPU wants that frame/packet or not. The best explanation I could come up with as to why we flood is a consequence of only looking for "01" in the MAC. The NIC doesn't know if this is control traffic or junk, but it does know that it's multicast so it /could/ be control traffic. The NIC passes this to the CPU where it is dropped since the box doesn't care about that frame, but at this point you've already burned a CPU cycle.
I'm not sure what the behavior is on the nexus or gsr but this stands in contrast to software based routers where we will only program the MACs we want to receive into the controller. There is no flooding concept like there is for an SVI on the Sup720. Now how to fix it? As I mentioned in an email I forgot to include the list in, you can create a CoPP policy that matches a mac ACL, but I don't know if this is supported, but it seems to work. I also have no idea if that works in software or hardware. The other fix is to create a static MAC entries on the box pointing out all the interface that want this traffic. With a static MAC entry we no longer flood, so we no longer hit the CPU. The flip side is that since we aren't flooding we are also not sending to any ports except those statically configured. Hope this helps. -Pete On Wed, Jan 19, 2011 at 2:54 PM, Devin Kinch <[email protected]> wrote: > I have a network running two 6509's with VSS in the core of the network. > Several of the attached VLANs are used by an application that transmits audio > with a non-IP based layer 2 multicast (016b.68xx.xxxx or something like that) > stream. It uses many different destination MAC addresses and the frames have > their own vendor proprietary Ethertype. We also need layer 3 routing in the > same VLANs to manage these devices. > > The issue I have is that all these layer 2 multicasts are causing the CPU > usage on the Sup to hover at around 70-80%. It isn't causing any noticeable > impact to the network today, but it may impact future scalability. I've > tried using CoPP (which doesn't support L2 filtering)... is there an obvious, > elegant way of filtering this traffic from hitting the RP, while still > forwarding at layer 2? Perhaps static MAC entries? > > > Devin Kinch > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
