[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