From: Curt Girardin (curt.girardin@chicos.com)
Date: Mon Dec 05 2005 - 13:38:50 GMT-3
Hi Group,
THE PROBLEM:
I've been having a weird multicast problem for many months that think
I've finally solved today, so I thought I'd share it with you in case
anyone else has ran into the same problem.
I'm running my own home lab, which consists of four 3640's, two 2621's,
and two 3550's. I've been working on the NMC labs and have the EXACT
same IOS as they use, and I occasionally find myself wrapped up in a
seemingly unsolvable multicast issue for hours at a time.
The issue was that a non-multicast-enabled router sending pings to some
multicast group, for example 225.5.5.5 (today I'm working on doitversion
2, lab 1 - router 5), would never yeild any replies from the other
routers. The upstream multicast-enabled router would never "hear" the
ping packets (I did a debug on each side) and never create state for
this source. After double-checking the NMC answer-key and checking the
NMC Show-IT engine, I have usually decided that the problem was caused
by what I call "Network VooDoo".
The problem I had with the explanation of "Network VooDoo" was that the
issue was able to survive a re-boot of all the equipment. Furthermore,
if I reconfigured my lab to "igmp join-group" any group in the range of
224-239.0.0.x (as long as the middle two octects were both 0), and sent
a ping to that group from the non-multicast router, everything would
work fine.
So what is it that this non-multicast-enabled router didn't like about
the middle two octects being non-zero? Does it have problems
translating the IP address to a layer-2 Mac address? Is it more
forgiving with the middle two octects being zero because many routing
protocols use 224.0.0.x? Who knows?
THE SOLUTION:
Today I ran into the same problem, so after rebooting a couple times,
trying to configure R5 with different combinations of ip
multicast-routing, pim dense-mode, and igmp join-group, I decided to
take a quick visual. I noticed that the fastethernet0/0 interface was
one of those older-looking PRI/T1-type combo network modules.
Specifically it was an NM-1FE1CT1. I swapped it out with another one
just like it and powered everything back on, removed all
multicast-related config from R5, and it now works great and receives
all the ping replies to 225.5.5.5.
I'm not sure if this is a problem with my "revision" of this network
module, or if mine is just broken. In either case I don't trust these
cards very much anymore and I think I'll be going to ebay to find some
newer, better cards.
Here is the info on the working and non-working card. The non-working
card has an older hardware revision, so it might have been a problem
with just this hardware-revision. Has anyone else ran into similar
issues? Should I just replace the non-working card? or all three of my
NM-1FE1CT1 cards?
Thanks,
Curt
Working card:
Slot 0:
Fast-ethernet, CT1 Port adapter, 2 ports
Port adapter is analyzed
Port adapter insertion time unknown
EEPROM contents at hardware discovery:
Hardware revision 1.1 Board revision C0
Serial number 11973765 Part number 800-03502-03
FRU Part Number NM-1FE1CT1=
Test history 0x0 RMA number 00-00-00
EEPROM format version 1
EEPROM contents (hex):
0x00: 01 86 01 01 00 B6 B4 85 50 0D AE 03 00 00 00 00
0x10: 60 00 00 00 99 01 20 00 FF FF FF FF FF FF FF FF
0x20: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x30: FF FF FF FF FF FF FF FF FF FF FF FF
NON-working card:
Slot 0:
Fast-ethernet, CT1 Port adapter, 2 ports
Port adapter is analyzed
Port adapter insertion time unknown
EEPROM contents at hardware discovery:
Hardware revision 1.0 Board revision A0
Serial number 9895647 Part number 800-03502-01
FRU Part Number NM-1FE1CT1=
Test history 0x0 RMA number 00-00-00
EEPROM format version 1
EEPROM contents (hex):
0x00: 01 86 01 00 00 96 FE DF 50 0D AE 01 00 00 00 00
0x10: 50 06 A1 00 98 09 28 00 FF FF FF FF FF FF FF FF
0x20: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x30: FF FF FF FF FF FF FF FF FF FF FF FF
This archive was generated by hypermail 2.1.4 : Mon Jan 09 2006 - 07:07:50 GMT-3