[c-nsp] Filtering Layer 2 Multicasts on 6509

[Pete Lumbis]

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 <devinkinch at gmail.com> 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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>