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

Deepak Jain deepak at ai.net
Fri May 27 12:31:44 EDT 2005


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
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (MingW32)
> 
> iD8DBQFCOOErE1XcgMgrtyYRArxcAJ4hvekTgGXV5gjmPF9yWt3C0UqWhACdHm71
> Jx06Vts2q4KguA7NXfcDdqI=
> =vSVb
> -----END PGP SIGNATURE-----
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> 
> 


More information about the cisco-nsp mailing list