Cisco 3750G intermittent amber/green blinking

[idscomm]

Folks,

I ran into a problem this afternoon and I can't find the cause or solution.

I have a Cisco 3750G in a LAN, I have a PoE device connected to port #16, configure as access port. The device is a Unifi Cloud Key which is powered and the lights are blinking green on the switch which shows that the port is working.  Then I noticed that randomly the light on the switch for port #16 starts going from green to amber for 5-10 seconds, then goes back to green and so on.  I have no connectivity whatsoever on this port no matter what color is the light.

Now, I tried to connect a laptop on port #16 and it worked properly (minus a few crc/input errors). Then I connected my Unifi Could Key into port #15 and it worked properly as well.  Both ports are access port with the same parameters (unless I missed something).

For now I left my cloud key in port #15 as it is working properly.  Any idea what the problem might be?

Thanks!

Dom

[Leo Laohoo]

Post the complete output to the command "sh interface Gi 1/0/16 controll".

[idscomm]

Hello Leo,

Thanks for helping me out with this issue.  This is the output for that command:

GigabitEthernet1/0/16 is down, line protocol is down (notconnect)
Hardware is Gigabit Ethernet, address is ec30.9115.eb10 (bia ec30.9115.eb10)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 225/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Auto-duplex, Auto-speed, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 11:39:23, 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
813 packets input, 281166 bytes, 0 no buffer
Received 82 broadcasts (35 multicasts)
0 runts, 0 giants, 0 throttles
1111 input errors, 303 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 35 multicast, 0 pause input
0 input packets with dribble condition detected
5095 packets output, 1160362 bytes, 0 underruns
0 output errors, 0 collisions, 1 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

Transmit GigabitEthernet1/0/16 Receive
0 Bytes 0 Bytes
0 Unicast frames 0 Unicast frames
0 Multicast frames 0 Multicast frames
0 Broadcast frames 0 Broadcast frames
0 Too old frames 0 Unicast bytes
0 Deferred frames 0 Multicast bytes
0 MTU exceeded frames 0 Broadcast bytes
0 1 collision frames 0 Alignment errors
0 2 collision frames 0 FCS errors
0 3 collision frames 0 Oversize frames
0 4 collision frames 0 Undersize frames
0 5 collision frames 0 Collision fragments
0 6 collision frames
0 7 collision frames 0 Minimum size frames
0 8 collision frames 0 65 to 127 byte frames
0 9 collision frames 0 128 to 255 byte frames
0 10 collision frames 0 256 to 511 byte frames
0 11 collision frames 0 512 to 1023 byte frames
0 12 collision frames 0 1024 to 1518 byte frames
0 13 collision frames 0 Overrun frames
0 14 collision frames 0 Pause frames
0 15 collision frames
0 Excessive collisions 0 Symbol error frames
0 Late collisions 0 Invalid frames, too large
0 VLAN discard frames 0 Valid frames, too large
0 Excess defer frames 0 Invalid frames, too small
0 64 byte frames 0 Valid frames, too small
0 127 byte frames
0 255 byte frames 0 Too old frames
0 511 byte frames 0 Valid oversize frames
0 1023 byte frames 0 System FCS error frames
0 1518 byte frames 0 RxPortFifoFull drop frame
0 Too large frames
0 Good (1 coll) frames
0 Good (>1 coll) frames

Really hope to fing the issue, last thing I need is a bad port on that switch  :(

[rasmus.elmholt]

What happens if you reset the counters. Do you still get new input errors?

The only cisco switches I've seen defective ports on is actually the 3750 but the ports didn't work at all.

[idscomm]

I did reset it last night and I was still getting some from the new device connected to that port #16 but at a way lower rate... mine is a 3750G with PoE but like I said the port seems to be working... with some issued but up and running

[Leo Laohoo]

---

@idscomm wrote:

reliability 225/255, txload 1/255, rxload 1/255

---

The amber LED is caused by faulty cabling.  Do the following: 

1.  Command:  test cable tdr int Gi1/0/16; 

2.  Wait for approximately 5 to 7 seconds; 

3.  Command:  sh cable tdr int Gi1/0/16; and

4.  Post the complete output to #3.

[rasmus.elmholt]

For inspiration: https://supportforums.cisco.com/t5/network-infrastructure-documents/how-to-use-time-domain-reflectometer-tdr/ta-p/3119327

The recommendation is to disconnect the end device while measuring as far as I rememeber to avoid spiking the end device.

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/release/15-0_2_se/configuration/guide/scg3750/swtrbl.html?bookSearch=true#38827

[idscomm]

Thanks for these links... really good to know!! :)

[Leo Laohoo]

---

@rasmus.elmholt wrote:
For inspiration: https://supportforums.cisco.com/t5/network-infrastructure-documents/how-to-use-time-domain-reflectometer-tdr/ta-p/3119327

---

I wrote that.

---

@rasmus.elmholt wrote:
The recommendation is to disconnect the end device while measuring as far as I rememeber to avoid spiking the end device.

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/release/15-0_2_se/configuration/guide/scg3750/swtrbl.html?bookSearch=true#38827

---

That's old school thinking.  Not applicable nowadays.

[rasmus.elmholt]

Hi Leo

Great article

And thank you for the update.

[idscomm]

I ran that command yesterday and it gave me 1 failure on 1 Pair. I replaced the cable, re-ran the test and came back clean. I can give it a try again to see if it changed ... I even tried with a new crossover cable but I was getting the same behaviour from port #16... I kind of eliminated cable issue after that. What do you think?

[rasmus.elmholt]

Just to make sure I understand this correctly.
You only see the problems when the device is connected to port 16. If you move it to port 15 everything works as expected?

[idscomm]

Yesterday it does. I have connectivity with the new device connected to port 16, and also connectivity with the cloud key now on port 15. Very strange, that’s why I was leaning on a config issue. 

[idscomm]

Yes and not yesterday lol. **bleep** autocorrect!

[Leo Laohoo]

---

@idscomm wrote:
I ran that command yesterday and it gave me 1 failure on 1 Pair. I replaced the cable, re-ran the test and came back clean. I can give it a try again to see if it changed ... I even tried with a new crossover cable but I was getting the same behaviour from port #16... I kind of eliminated cable issue after that. What do you think?

---

I want to see the result to the command "sh test cable tdr int g 1/0/16".  

Also post the complete output to the command "sh version".