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

Bruce Pinsky bep at whack.org
Wed Mar 16 20:45:15 EST 2005


-----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-----


More information about the cisco-nsp mailing list