Cisco port down and notconnect after changing port speed

cisco

In my network, I have a main Cisco 2950 that connects to my outside bandwidth, then individual Cisco 2950s in each cabinet that connect back to the main one.

I recently had someone in one cabinet start consuming 100% of the bandwidth in my network. As a quick fix, I set the speed on the main switch to be 10Mbps for the port that connects to the switch in the cabinet.

After doing that however, the port now shows down (notconnect). I've tried setting the speed back to 100, and shutting down/starting the port again, but it never reconnects. Any recommendations on getting this port back up, short of rebooting the switch in the end cabinet (I can't connect to the switch)

Here is what I did:

config t
int FastEthernet1/0/47
speed 100
duplex full
end

Even after resetting the speed, I'm getting:

sh int FastEthernet1/0/47
FastEthernet1/0/47 is down, line protocol is down (notconnect) 
  Hardware is Fast Ethernet, address is 0016.4797.4633 (bia 0016.4797.4633)
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, 
     reliability 255/255, txload 1/255, rxload 73/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/s, media type is 10/100BaseTX

Before changing the speed:

sh int FastEthernet1/0/47
FastEthernet1/0/47 is up, line protocol is up (connected) 
  Hardware is Fast Ethernet, address is 0016.4797.4633 (bia 0016.4797.4633)
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, 
     reliability 255/255, txload 1/255, rxload 209/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/s, media type is 10/100BaseTX

Best Answer

Per the comments, the solution was set the port to autonegotiate, rather than manually defining speed and duplex settings.

And this kind of problem (as well as other potential issues) is why it's a bad idea to limit bandwidth by forcing a switch-to-switch port to a lower speed and/or duplex setting manually.

Related Solutions

Cisco – Hubs/switches taking out switches

We operate a couple network implementations where third-party connections are linked up to a centralized Cisco backbone (i.e. multi-tenant setup). I can say I've seen a bunch of diverse (okay, ghetto) devices connected up to the Catalyst platform, and if there's one thing I've learned, it's that the Cisco platform is remarkably resilient to these kinds of things.

There is one achilles heel, though - A cheap hub in the right configuration can easily bring down an entire network with a broadcast storm, and it's not even the Cisco platform's fault. I discovered this in a production configuration, and the only real research I did was finding the closest trash can for that hub, but here's how it happened:

Connect hub to Cisco switch as normal, with uplink port
Connect a workstation to a hub port (in our case, running Windows XP OS, but shouldn't matter)
Connect two other ports together on the hub (either directly, with a single CAT5 or indirectly through another hub).

Everything runs smoothly until that workstation sends out a broadcast announcement. While the hub and the Cisco are smart enough to prevent a broadcast storm on other broadcast packets, the hub isn't smart enough to detect that two of its ports are connected to each other, and will use up almost 100% of its processing power to broadcast that packet in an infinite loop back and forth, as well as out all the other ports (i.e. the uplink to your Cisco).

If this is the case in your configuration, you will notice that across your network, all of the ports on that broadcast VLAN will go nuts, up until the hub can't sustain the capacity and drops the magical looping packet (could be a couple minutes depending on the competing traffic), and then all is back to normal.

In this situation SNMP won't help you since all the ports on that VLAN go crazy with traffic. However, Wireshark is your friend here, since it's easy to capture which IP (and sometimes machine name if it's a broadcast packet) caused the loop, and quickly locate the offending device.

May not be the exact case you're experiencing, but this one bit us hard and might give you some ideas to research with your situation.

Cisco – Issue forwarding port through Cisco 881 router

It doesn't look like you have a security zone setup for the 'out' to 'in' traffic. You may need something like this:

!
class-map type inspect match-any ccp-ssh
 match protocol ssh
!
policy-map type inspect ccp-permit-ssh
 class type inspect ccp-ssh
  inspect
!
zone-pair security ccp-zp-out-in source out-zone destination in-zone
 service-policy type inspect ccp-permit-ssh

Related Topic