Filter Multicast traffic

[adithya ac]

Can we filter Multicast traffic using CoPP?

We are getting frequent LAN performance issues due to multicast traffic burst on Cisco 6500 and 4500 switches.

ip access-list ipv4_multi
permit ip any 224.0.0.0 0.0.0.255
exit

class-map ipv4_multi_CM
match access-group namw ipv4_multi
exit

policy-map ipv4_multicast_policy
class ipv4_multi_CM
police 8000000 conform-action transmit exceed-action drop
exit

control-plane
service-policy in ipv4_multicast_policy
exit

I'm not so familiar with multicast, please let me know if I'm doing something wrong...

- Adithya

[M02@rt37]

Hello @adithya ac,

Multicast traffic can include protocols like OSPF, EIGRP and others, which are essential for network functionality. Policing and dropping multicast traffic might lead to unintended consequences or network instability.

Identify the specific multicast traffic causing the performance issues. It's crucial to distinguish between essential multicast traffic (e.g., routing updates) and non-essential multicast traffic.

[DanielP211]

Hello,

Did you recognise what is generating the multicast traffic? Best would be to use storm-control and block multicast per recived ports or maybe use copp.

BR

[adithya ac]

Someone running an Multicast video stream (PixStream WinSend)

[DanielP211]

In that case it seems OK, as long as the address is correct. Can you check the copp (show policy-map control-plane)?

[balaji.bandi]

Technically that should work as expected - after apply just monitor

also look some Limitation depends on the IOS Code you running on the box :

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/copp.pdf

[adithya ac]

Yes, I don't intend to block the EIGRP or STP or other multicast traffic, which are essential protocols.
When I monitored, the ideal multicast traffic will not exceed beyond 1Mbps on all the 4500 and 6500 that we have.

So is it good enough to allow ~1Mbps traffic and drop beyond that…

[balaji.bandi]

Sure agreed your comments, but as i stated  when you apply the policy always Monitor and see if all working as expected. keep Monitor and ammend anything required to meet the desire outcome.

[adithya ac]

I'm not sure, why it is not working...
I tried the below configuration..

class-map match-all TEST
match access-group name test
class-map match-all ipv4_multi_CM
match access-group name ipv4_multi
!
policy-map ipv6
class TEST
police 320000 conform-action drop exceed-action drop
class ipv4_multi_CM
police 1000000 conform-action transmit exceed-action drop

ip access-list extended ipv4_multi
permit ip any 224.0.0.0 31.255.255.255
permit igmp any 224.0.0.0 31.255.255.255

ipv6 access-list test
permit ipv6 any any
!
control-plane
service-policy input ipv6

----------------

It did not drop any packets at all...

sh policy-map control-plane
Control Plane

Service-policy input: ipv6

Class-map: TEST (match-all)
350172515 packets
Match: access-group name test
police:
cir 320000 bps, bc 10000 bytes
conformed 8530123735 bytes; actions:
drop
exceeded 29091089576 bytes; actions:
drop
conformed 3000 bps, exceeded 0000 bps

Class-map: ipv4_multi_CM (match-all)
393107 packets
Match: access-group name ipv4_multi
police:
cir 1000000 bps, bc 31250 bytes
conformed 37226952 bytes; actions:
transmit
exceeded 0 bytes; actions:
drop
conformed 0000 bps, exceeded 0000 bps

Class-map: class-default (match-any)
2131818972 packets
Match: any

-----------------

Where am I doing wrong?

[Joseph W. Doherty]

Whoa!!!

Possibly a very fundamental question is why your switches' control-plane is processing this multicast traffic?

"Someone running an Multicast video stream (PixStream WinSend)"

Do your switches, as hosts, want to "see" this multicast stream?

If not, ideally, switches should filter out such multicast frames, like any frames the switch, itself, has no interest in.  Don't believe the control plane should be involved.

However, with Ethernet, multiple IPs map into the same Ethernet multicast MAC, so it's possible for a host to be unable to do the L2 filtering, it must next jump to IP filtering.  I.e. does host (switch) want to "see" this multicast stream.

If not, the multicast packet should be quickly (and efficiently) ignored.  Does a 4K and/or 6K switch do so?

Well, I can only go by experience, but I've supported multicast video applications on network using 4K and 6K, and never saw this be an issue.  (I did see, on 7609s [fully populated with 6704 line cards with DFCs], doing lots and lots and lots [100+gig?] of video multicast, their hardware being unable to meet their multicast video replication needs, but I don't recall the control-plane being impacted [I recall it was their EARLs that couldn't keep up]).

So, I really wonder what's happening that you need to consider CoPP for some video streams.

"We are getting frequent LAN performance issues due to multicast traffic burst on Cisco 6500 and 4500 switches."

Might you also mean to LAN clients?  If so, traffic bursts, can cause issues, but if that's what's happening, CoPP would unlikely be a solution.