Notes on Cisco 65xx and IP multicast

Bill Nickless nickless at
Sun Oct 1 18:31:50 CDT 2000


If you, or someone you know, is deploying Cisco 65xx switch routers to 
support IP multicast for an Access Grid node, here are some pieces of 
information that you might find useful.  This note does not cover 
deployment of PIM Sparse Mode, Multiprotocol BGP, or MSDP, but rather 
concentrates on Cisco 65xx specific issues.

describes a problem with PIM Sparse Mode on versions of MSFC IOS that are 
based on IOS prior to 12.0(10).  Essentially what will happen is that a 
locally-attached (S,G) will get into a state where it's not sending PIM 
Register messages towards your MSDP-speaking Rendezvous Point.  When that 
happens, your MSDP-speaking RP will not send MSDP Source Active messages 
out to your peers.  That means your source will not be heard by new 
joiners.  You can work around this in real time by clearing the (S,G) 
[clear ip mroute <group> <source>] but this is obviously not something you 
want to be stuck doing regularly.

[Note: this is true of all Cisco IOS releases prior to 12.0(10), not just 
those running on the 65xx MSFCs.]

This setting on the switch side of the 65xx seems to work best for us:

>stardust> (enable) show multicast protocols status
>IGMP enabled
>IGMP fastleave disabled
>RGMP disabled
>GMRP disabled 
ulti.htm talks about these various services in more detail.  In summary, 
though, IGMP is the protocol that the Access Grid specified host software 
(Windows 9x, Red Hat Linux, and Windows 2000) knows and operates with 
best.  You have to choose between GMRP and IGMP when you configure the 
multicast switching protocols: I strongly recommend IGMP.

In a situation where you have multiple hosts connected to a port on the 
65xx, such as all four hosts of an AG node connected by a hub, IGMP fast 
leave is probably a bad idea.  When an IP multicast tool like vic exits 
(say, on the video capture machine) it causes the host to send an IGMP 
leave message to the network.  If IGMP leaves are being processed by the 
65xx, the traffic for that group is immediately stopped.  This causes a 
loss of traffic to other hosts on that port which still want to receive the 
traffic (like the display machine[s]).  Thus I strongly recommend 
*disabling* IGMP fast leave processing.

MLS IP Multicast shortcuts are programmed into the forwarding hardware on 
the switch side of the 65xx.  This means the traffic never gets up to the 
MSFC, so it doesn't require CPU resources to forward.  At Argonne we've 
seen Access Grid situations where the MSFC doing software switching cannot 
keep up with the traffic.  When this happens the CPU goes up to 99% and it 
starts dropping packets.  With MLS IP Multicast the CPU load goes down to 
sub-5% given the same traffic load.

There is a problem when you try to do these three things simultaneously on 
a Cisco 65xx/MSFC VLAN:

  - mls ip multicast
  - inbound access list
  - ip unreachables

With all three of these features running simultaneously, the MLS IP 
Multicast forwarding hardware in the 65xx will be programmed with the 
appropriate shortcuts, but packets will simply not be forwarded.  You can 
run with any two of the three features, but all three together may cause 
the 65xx to silently drop the incoming IP multicast packets.

Here at Argonne I run with 'no ip unreachables' in the VLAN configurations, 
as the other two features are more important.  This may cause you problems 
with TCP MTU Discovery if your MSFC is routing between interfaces with 
different MTU sizes, such as GRE tunnels or VLANs supporting Gigabit 
Ethernet Jumbo Frames.  I had to move a couple of GRE tunnels off of my 
6509 because of this situation.
Bill Nickless      +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     nickless at

Version: PGPfreeware 6.5.8 for non-commercial use <>


More information about the ag-tech mailing list