All things related to multicast

[Gordon Rogier <>]

I am hoping that some of the Cisco guy's on this list can respond to this
issue.  I am reluctant to take this directly up with Cisco TAC.  I do not
expect Cisco TAC to efficiently recognize the subtle of this issue.

It appears to me that the CGMP process on the Catalyst 5000 and Catalyst
2900XL series, puts the respective multicast mapped MAC address
(05001exxxxxx) address into the MAC address/port forwarding table (aka.
Cisco's CAM or MAC address table) with the table aging time as defined
for the related VLAN, etc. OK... However, it also appears that the aging
time on these entries do _not_ get updated by subsequent cgmp updates.
Thus, once the mcast MAC entry decrements it's aging counter to 0, the
respective mcast traffic flow is disrupted for about 1-5minutes as the
IGMP/CGMP/PIM process re-instantiates the related mcast group.

Last week, KU hosted the Chautauqua 2000 event which was produced in the
wider area using IP multicast transport.  We had a couple of incidents of
multicast outages which I believe are a result from what appears to be a
flaw in CGMP.  Now, bear in mind, I have not done exhaustive
packet or cgmp process level analysis on this issue (and i am not sure i
can even access the cgmp process details to let me analyze it that
detailed).

KU sets it's MAC aging in the layer 2 switches to 8hrs (we do this for
some localized MAC address network management collections we have been
doing for years).

Now, during the Chautauqua event, right at 8hr into production, we
observed at short period (~1-3mins) of mcast traffic disruption.  First
mcast traffic flows  (including flows from the adjacent cisco
port connected video capture machine) _stopped_ abruptly, followed by
and/or during which a clearly observable (~1-2min) 'flood' of traffic
(which i believe to have been the locally captured streams not being
contrainted by the Cisco switches, due to this cgmp aging issue).
Finally, (~1-2min into 'flooding') the wide area streams were re-acquired,
the 'flooding' stopped, and production went back to normal.

greg shepherd and others, any insights??

--*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*--
Gordon Rogier                        

            
Network Engineer                     785-864-0381wk 785-550-4468 cell
Great Plains Network                 785-864-9330 FAX