Output of CDP

[Cooky]

I issued a "show cdp nei" on a Cisco 3560 switch as part of our documentation process, and the output is:
Device ID Local Intrfce Holdtme Capability Platform Port ID
c3524xl.algor.com
Gig 0/48 121 T S WS-C3524-P Fas0/24
c3560 Gig 0/19 153 S I WS-C3560G- Gig0/46
c3560 Gig 0/46 173 S I WS-C3560G- Gig0/19
c4506 Gig 0/49 138 R S I WS-C4506 Gig1/2

My concern is that the switch I issued the command on is the only switch named c3560. Why am I seeing two supposed neighbors as c3560, gi0/19 and gi0/46 in the output??

Does this indicate a switching loop?? Like port 19 goes to a desktop switch and then comes back into port 46??

 

[spidey07]

Looks like you have a loop.

check the serial numbers. bad mojo to see yourself in CDP.

Also look at the counters for unusually high broadcast traffic. If it is truly a loop spanning-tree should have taken one of the ports down.

 

[Cooky]

It was indeed a switching loop.
Port 46 was going into the uplink port of a desktop hub, and port 19 was plugged into the same hub by someone (prolly some stupid end user).

What's strange is port 46 (the uplink for hub) was in blocking mode, but yet all the users on the hub can still have network connection...can anyone please explain how this had happened??

 

[spidey07]

spanning-tree will just block the single port that caused the loop.

That's what it does - build a tree or loop free topology at layer 2.

So if port 46 was blocking, the other port in the loop was in a forwarding state and hence everybody could talkie-talkie.

Count your blessings that spanning-tree did what it was supposed to. If not, your network would grind to a screeching halt.

Some "silly" people want to disable spanning-tree arguing it causes too much overhead traffic. These are also the same people who have catastrpophic problems constantly.

 

[Cooky]

Thank you Spidey for pointing me toward the correct direction.

The blocking port in question connects to the uplink port of the hub. The forwarding port connects to a regular port on the hub.

My question was how did the users on the hub have connection through the uplink port even though it was in blocking mode??

 

[spidey07]

They didn't. It was through port 19 which was in a forwarding state.

blocking really means "not forwarding" - so no traffic is sent or received except traffic generated by the switch processor - CDP and spanning-tree BDPUs.

If you're going to be involved in networking I HIGHLY recommend really understanding spanning-tree. Its very important and knowing it will make life much easier.

http://www.cisco.com/en/US/tech/tk389/t..._technology_support_protocol_home.html

 

[Cooky]

blocking really means "not forwarding" - so no traffic is sent or received except traffic generated by the switch processor

I knew that (I had to in order to pass the CCNP switching exam); I've read through a whole lot of documents that explain the root, priority, and the whole nine yards of spanning tree.

I just didn't realize the hub can communicate w/ the switch through a non-uplink port...normally it wouldn't work but in this case it did...weird.

Also, if we only unplug port 46 and leave port 19 alone the users can't connect, which is why I thought the users were going through port 46...

 

[spidey07]

well that is weird then.

You could try it again after hours. that port should go to blocking.

Then look at the cam table/mac address table on each of those ports. That will give you an idea of what layer2 looks like from the switches perspective.

But if a port is blocking, it really is blocking. you can check with "show span" just to make sure. There is also loop guard and other things that will cause the port to be in "err-disable" state.

 

[Fallen Kell]

The current Cisco switches auto-sense if the device that is connected to it is a direct system or another switch/hub/router which in olden days would require a crossover cable. It now simply does an internal crossover on the ports. We have personally complained that this is a bad design. Yes, it makes it easier for people to setup a network without having to deal with is this the right cable, but it introduces problems like this, where if this feature did not exist, that hub/switch that the users placed at there desk might not have been as easy to connect (they would have needed to get their own crossover cable or make one)...

 

[spidey07]

I think you can turn off auto-mdx on the switch ports.

 

[Cooky]

The current Cisco switches auto-sense if the device

May I ask which models support auto-mdx?
When I tried to connect a 2950 to a 4506 I had to make a cross-over to make it work...

I totally agree that convenient features make things easy but they do creat unexpected results.
A while ago I was playing w/ this Cisco GUI tool. It asked me if I'd like to apply some sort of macro feature on the switch ports; I thought why not and clicked yes. Next thing I know thousands of unnecessary lines filled up my running-config and I had to reload to go back to the previous state.

 

[spidey07]

autoQos will add a ton.

 

[djdrastic]

Well I know for a fact 4000 series switches do not support using straight cable for uplinks . I should know I have one in my room

 

[spidey07]

Originally posted by: djdrastic
Well I know for a fact 4000 series switches do not support using straight cable for uplinks . I should know I have one in my room

I believe the newer modules do.

 

[bgroff]

Another fun fact on auto mdix - it will not work when you have a port hard coded for speed and/or duplex. And there are line cards that will do auto mdix in the 4500 series. I know for a fact that the WS-X4548-GB-RJ45 modules do that voodoo.