Table Of Contents
Application Note
Redundant Router Issues with
IP Multicast in
Stub NetworksIP Multicast uses one router to be forward data onto a LAN in redundant topologies. If multiple routers have interfaces onto a LAN only one router will forward the data—there is no load balancing for multicast traffic on LANs. Depending on the topology there may not even be multicast routing state in the redundant routers.
Multicast traffic is always visible by every router on a LAN. This is also the case even if CGMP or IGMP Snooping are configured. The routers need to see the multicast traffic so that they can make a forwarding decision.The redundant router (router not forwarding the multicast traffic stream) sees this data on the outbound interface for the LAN. The redundant router must drop this traffic because it has arrived on the wrong interface and therefore will fail the Reverse Path Forwarding (RPF) check. We call this traffic "non-RPF traffic" because it is being reflected backwards against the flow from the source.
The 6500 and 8500 multilayer switches with the right hardware can be configured to act as full-fledged routers. RPF traffic (multicast traffic flowing in the right direction) is forwarded in hardware by special ASICs in the switch. The ASICs are given information from the multicast routing state—(*,G) and (S,G)—so that a hardware shortcut can be programmed. These hardware shortcuts allow the 6500/8500 routers to forward multicast traffic in the millions of packets per second instead of thousands of packets per seconds.
The Problem
All Cisco routers may not handle non-RPF traffic for Sparse Mode groups efficiently in certain topologies. For non-RPF traffic, there is usually no (*,G) or (S,G) state in the redundant router and therefore no hardware or software shortcuts can be created to drop the packet. Each multicast packet must be examined by the processor individually. This can cause the CPU on these routers to run very high.The Solution
On the 6500/8500 routers there is an access list engine that enables filtering to take place at wire rate. This feature can be used to handle non-RPF traffic for Sparse Mode groups efficiently.To implement this solution, we place an access list on the incoming interface of the `stub network' to filter multicast traffic that did not originate from the `stub network'. The access list is pushed down to the hardware in the switch. This access list prevents the CPU from ever seeing the packet and allows the hardware to drop the non-RPF traffic.
Note:
Do not place this access list on a transit interface. It is only intended for stub networks (networks with hosts only).
Example
Assume that you have two routers with two VLANs in common. (expand this to as many VLANs as necessary)
Figure 1 Typical Redundant Network Topology
RouterA is HSRP primary for VLAN1, secondary for VLAN2. RouterB is secondary for VLAN1, and primary for VLAN2. It is recommended that you make either RouterA the Designated Router (give it a higher IP address), or pick RouterB, but make just one router the DR for all segments.
Place this access list on the non-DR router:
access-list 100 permit ip A.B.C.0 0.0.0.255 any
access-list 100 permit ip A.B.D.0 0.0.0.255 any
access-list 100 permit ip any 224.0.0.0 0.0.0.255
access-list 100 permit ip any 224.0.1.0 0.0.0.255
access-list 100 deny ip any 224.0.0.0 15.255.255.255
access-list 100 permit ip any anyHave one permit for each subnet the two routers share in common. Other permits are to allow Auto-RP and reserved groups to operate correctly.
Apply the ACLs to each VLAN interface on the non-DR with these additional commands:
ip access-group 100 in
no ip redirectsno ip unreachables
Note:
Note:
