X hits on this document

PDF document

Cisco AVVID Network Infrastructure IP Multicast Design - page 25 / 98

277 views

0 shares

0 downloads

0 comments

25 / 98

Chapter 2

IP Multicast in a Campus Network

Campus Deployment

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 224.0.0.0 0.0.0.255 any 224.0.1.0 0.0.0.255 any 224.0.0.0 15.255.255.255

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.

Tip

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.

Catalyst 3550

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

956651

2-5

Document info
Document views277
Page views277
Page last viewedSun Dec 11 10:29:02 UTC 2016
Pages98
Paragraphs2650
Words25637

Comments