IP Multicast in a Campus Network
Catalyst 6500 Series
Without a method to control non-RPF traffic in hardware, the CPU on the supervisor engine will reach 99%. The Supervisor I requires a RACL on the non-DR (only). The RACL must allow only locally sourced multicast traffic on the VLAN interface. The no ip unreachables command must also be configured on the interface. For RACL denied traffic, if the interface does not have the no ip unreachables command configured, the ACL denied traffic is leaked to the MSFC at 10 pps per VLAN.
The following example shows how to enable manual RACL configuration for blocking non-RPF traffic on the non-DR router:
interface VLAN X ip access-group 100 in no ip unreachables
access-list access-list access-list access-list
100 permit 100 permit 100 permit 100 deny
ip ip ip ip
w.x.y.z 0.0.0.255 any any 220.127.116.11 0.0.0.255 any 18.104.22.168 0.0.0.255 any 22.214.171.124 126.96.36.199
Local subnet addresses
Versions of code for the Catalyst 6500 series Supervisor II (Catalyst OS 6.2(1) and IOS 12.1(5)EX and later) support Multicast Fast Drop (MFD) and will rate-limit non-RPF traffic by default. The mls ip multicast non-rpf cef command is enabled by default on the MSFC. Use the show mls ip multicast summary command to verify that non-RPF traffic is being rate-limited in hardware.
For more information, see h t t p : / / w w w . c i s c o . c o m / u n i v e r c d / c c / t d / d o c / p r o d u c t / l a n / c a t 6 0 0 0 / i o s 1 2 1 _ e / s w c g / m c a s t m l s . h t m # x t o c i d 2 27011. 8
Catalyst 4006 and 4500 with Supervisor III/IV
By default, the Supervisor III and IV enable MFD and handle non-RPF traffic in hardware. The ip mfib fastdrop command is used to enable this feature.
To display the MFIB table information, use the show ip mfib command. To display the information in the hardware tables, use the show platform hardware command.
The Catalyst 3550 does not use a command to enable non-RPF traffic to be hardware filtered. In 3550 switches, the non-RPF packets reach the CPU through the RPF Failure Queue. This hardware queue is separate from other queues, which are reserved for routing protocols and Spanning-Tree protocol packets. Thus, non-RPF packets will not interfere with these critical packets. The RPF Failure Queue is of minimal depth. So if this queue is full, then subsequent packets will be dropped by the hardware itself. The CPU gives low priority and shorter time to process the packets from the RPF Failure Queue to ensure that priority is given to routing protocol packets. A limited number of packet buffers are available for the RPF Failure Queue and when all of the buffers allocated for the RPF Failure Queue are full, the software will drop the incoming packets. If the rate of the non-RPF packets is still high and if this in turn makes the software process a lot of packets within a certain period of time, then the queue is disabled and re-enabled after 50 milliseconds. This will flush the queue and give the CPU a chance to process the existing packets
To see the number of packets dropped, use the show controller cpu-interface | include rpf command.
Cisco AVVID Network Infrastructure IP Multicast Design