[c-nsp] 6500/Sup2/6516A - Strange GE problems...

[David Wolsefer]

We are seeing a similar issue on two Catalyst 6500s with Sup2MSFC2 and a
WS-6516 in each. We are running Hybrid mode with CatOS 6.3.10. We also tried
different fiber, different GBICs, different ports, etc. In our case, we were
connecting a new CSS11506 which uses the LC MM fiber. I finally moved it to
another blade. I have not tried the shut/no shut workaround yet. If anyone
has a Cisco Bug ID, could you please post it? 

Regards,

David

Message: 3
Date: Fri, 27 May 2005 12:31:44 -0400
From: Deepak Jain <deepak at ai.net>
Subject: Re: [c-nsp] 6500/Sup2/6516A - Strange GE problems...
To: bep at whack.org
Cc: cisco-nsp at puck.nether.net
Message-ID: <42974B70.8060107 at ai.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Bruce et al -

	Just following up. TAC confirmed it was a problem with Cisco GBICs
in 
the WS-6516A. They don't even know which GBICs will work and which ones 
won't.

	They didn't know about certain work arounds that we had figured
out...

Thanks for all your help.

Deepak

Bruce Pinsky wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Deepak Jain wrote:
> | This seems a bit strange, but its consistent between two chassises 
> | in identical configurations so I'm wondering if its a feature or a 
> | bug. OS is identical: System image file (native) is 
> | "sup-bootflash:c6sup22-pk2sv-mz.121-26.E.bin"
> |
> | Basically, when connecting any GE device to either of these routers 
> | -- on the Sup2 or the 6516A, we have to do a "shut, no shut" on a 
> | port to get link.
> |
> | A typical show interface shows up/down:
> | GigabitEthernet2/1 is up, line protocol is down (notconnect)
> |    Hardware is C6k 1000Mb 802.3, address is
> |    MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
> |       reliability 255/255, txload 1/255, rxload 1/255
> |    Encapsulation ARPA, loopback not set
> |    Keepalive set (10 sec)
> |    Full-duplex, 1000Mb/s, media type is SX
> |    input flow-control is off, output flow-control is off
> |    Clock mode is auto
> |    ARP type: ARPA, ARP Timeout 04:00:00
> |    Last input never, output 00:26:47, output hang never
> |    Last clearing of "show interface" counters never
> |    Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
> |    Queueing strategy: fifo
> |    Output queue: 0/40 (size/max)
> |    5 minute input rate 0 bits/sec, 0 packets/sec
> |    5 minute output rate 0 bits/sec, 0 packets/sec
> |    L2 Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes
> |    L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast
> |    L3 out Switched: ucast: 0 pkt, 0 bytes
> |       0 packets input, 0 bytes, 0 no buffer
> |       Received 0 broadcasts (0 IP multicast)
> |       0 runts, 0 giants, 0 throttles
> |       0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
> |      0 watchdog, 0 multicast, 0 pause input
> |      0 input packets with dribble condition detected
> |      0 packets output, 0 bytes, 0 underruns
> |      0 output errors, 0 collisions, 0 interface resets
> |      0 babbles, 0 late collision, 0 deferred
> |      0 lost carrier, 0 no carrier, 0 PAUSE output
> |      0 output buffer failures, 0 output buffers swapped out
> |
> | ----
> |
> | Yet, a shut/no shut with no physical changes will bring the link 
> | right up. Remove the cable and re-insert, and this shut/no shut 
> | needs to be repeated on both sides (for a connection between these 
> | two 6500s). If a 6500 is connected to known working 3550 or 3548, 
> | the 6500s need the shut/no shut but the 3xxx ones don't.  The GBICs 
> | on the 3xxx switches will recognize each other immediately with no 
> | operator intervention.
> |
> | We've tried swapping GBICs, re-inserting cards, new cables, new 
> | connectors, cleaning the connectors, using different ports & 
> | different cable lengths.
> |
> | Since the problem is essentially identical between the same hardware 
> | running the same IOS versions (native) I'm wondering if the line 
> | cards need their versions upgraded or we need to be running these on 
> | a different IOS version or if maybe we have a bad batch of GBICs or 
> | hardware.
> |
> | Suggestions, comments, ideas would be appreciated. Cisco-nsp has 
> | been quicker to the solution than TAC in almost every case.
> |
> 
> Sounds a lot like an auto-negotiation problem between the devices and 
> the 6500.
> 
> - --
> =========
> bep