[c-nsp] L2 multicast forwarding probs after 76k RPR-plus failover

[Andrew Fort]

Hi guys,

We had a 76k (w/2xSup3A, ver 12.2(18)SXD3) failover to its backup 
supervisor the other day.  The failover was not otherwise (physically) 
provoked, the only sign of anything wrong before the failover was this 
strange log message (repeated - from both supervisor linecards, or from 
one, twice?)

--
551: Apr 27 07:04:08.976 AEST: SP: Linecard endpoint of Channel 7 lost 
Sync. to Higher fabric and trying to recover now!
552: Apr 27 14:37:02.928 AEST: SP: Linecard endpoint of Channel 7 lost 
Sync. to Higher fabric and trying to recover now!
--

Anyhow, onto the main problem...

After the failover, we had a couple of customers complain about their 
RIPv2 not exchanging routes, and no EIGRP adjacencies on their metro 
VLANs that run through said box.  There's >100 VLANs attached to access 
facing ports on the box.

Their unicast traffic continued to work fine, but their multicast 
traffic (i.e., traffic to destinations 0100.5e00.0009 and 
0100.5e00.000a, respectively) wasn't passing.  Other parts of the L2 
network were forwarding this traffic, so the RIPv2 customer had some 
routes exchanging between those sites (not passing through the box 
w/failed sup), but no routes from the head site (behind the box w/failed 
sup).

One customer (the EIGRP guy) was fixed, apparently by removing and 
readding the VLAN from the trunk interface.  The other (RIPv2 guy), 
well, that didn't work for.

Has anyone seen such similar bizarre L2 multicast behaviour?  For the 
record, we have Sup3A and DFCs on the 16-port GigE linecards (ws-x6816 
cards).  Traffic is flowing between two different DFC-enabled 6816 cards 
(on slots 1 and 8).

How do you even debug this sort of thing? (since it's a 'arp-free' 
multicast destination, I don't see it in the CAM tables at all).

Any help always appreciated. :-)

cheers,
andrew