Curious question about ports on a switch..

[kt]

What happens when you connect one end of a cable to a port on a switch and the other end to another port on the same switch? I am kinda curious because someone in the office saw an unplugged cable and decided to plug it back in without knowing that the other end of that cable is already connected to the switch. Everyone on that switch seems to not noticed any problem. However, there are 3 other switches connected via crossover cables lost their connections. Basically, they can't even see each other or anyone on the network. I would've thought the switch with the one cable connected twice to the switch should be messed up, but instead the other switches got affected by this. Anyone has an explanation for this?

 

[Lord Evermore]

It would depend on which ports were connected. Using a straight-through cable, you end up connecting the same pins (transmit to transmit, receive to receive) so it'd basically be a broken link. But even with a crossover cable to provide a "valid" link, a switch segregates traffic, so there wouldn't be any traffic going to either of those ports normally because there wouldn't be any MAC address reachable through it.

A hub might end up with a packet storm flooding the network, since it broadcasts all traffic to every port and it might end up looping around and around.

Even if you sent out broadcast traffic on a switch with looped ports, the switch should not end up with a packet storm. It might however result in blocking of traffic due to the function of a switch which is intended to prevent circular traffic (like plugging 3 switches together in a circle), which would result in traffic from one computer going out in two directions so another switch gets it from two different ports; switches try to prevent that happening by blocking traffic that comes in from multiple ports from the same source. If traffic came from one of the other switches, then was broadcast and looped around through that cable so it looked like it came in from a local port as well, the switch might have shut down the ports going to the other switches (there's a formula that determines which ports are shut down).

 

[kt]

It was a straight-thru cable. According to the light on the switch, the cable provided a "valid" link. What I don't understand is why the other switches that are connected to this whacky switch got the short end of the stick? All the computers connected to the other switches would lose connection intermittenly while all the computers connected to the whacky switch are working just fine.

 

[ScottMac]

A switch and a hub handle broadcast and multicast traffic exactly the same way: It is flooded out all ports, every time.

With a valid cable connecting two ports, nothing may happen initially, but the first broadcast (like an ARP, or a machine doing a browser update) will begin some flavor of "bad thing." That broadcast from a properly connected port will be sent out all the other ports (including the looped ports) and begin a broadcast storm.

And that broadcast (if the self-connected switch is attached to other switches) will be propagated to the other switches and all devices or PCs connected to the storming switch and the other switches.

Some switches may have broadcast suppression (if it senses the broadcast storm it'll shutdown the ingress port). This is usually feature of commercial-grade switches, but perhaps that feature is finding it's way into consumer-grade as well, given the intended user group and the expected knowledge level of that group. It does take some time for the BC suppression to kick in; it can't kill every broadcast, because broadcasts are a normal function of TCP/IP (and IPX, and Netbeui/NETBIOS).

I haven't heard of any consumer-grade switches that support Spanning Tree, which is a protocol used to prevent Layer 2 loops (as mentioned by Lord Evermore).

A similar effect would be connecting something to the uplink port and the adjacent "regular" port (the two ports are usually just different pin-outs of the same transceiver ... basically connecting two cables to the same port).


FWIW

Scott

 

[Santa]

In this occasion wouldn't Spanning tree not even work properly since the two switch ports are not on seperate switches and I have not heard of a switch negotiating STP protocals with itself.

I don't know if this type of issue was ever designed for since no one should ever be plugging a switch into itself ever.

 

[Lord Evermore]

STP would work and result in exactly what he saw.

Switch A is the one with the looped ports. Switch B is connected to port 1, Switch C is connected to port 2. The looped ports are 3 and 4. There's some other computers on ports 5 to 8. (Note that with a straight-through cable there should be no actual link, even though the light might come on, however some switches auto-select uplink mode. Connecting a NIC to an uplink port often gets a link light too even though it's not a good connection. We'll assume a valid link.)

SWB receives traffic from Computer1 destined for Computer 2 on SWC. It forwards the traffic to SWA. If SWA does not know the path for the MAC address of Computer 2 (it's never passed traffic from computer 2) then it broadcasts it to all ports. So this packet goes out through ports 2, 3 and 4 (not 1 since that's where it came from). On port 2 it goes to SWC which sends it to Computer 2. In the meantime, port 3 has looped the traffic to port 4, and vice versa.

The switch doesn't know the traffic is coming from itself. It just sees a packet come in on each port. As far as it knows, each of those ports is going to some other node, either a computer or another switch. So it inspects the packet, and sees the source is the MAC address of Computer1. It checks its tables, and wait a second, we already have an entry for that MAC saying that it's on port 1. And what's this, port 4 is also bringing in a packet with a source for computer 1. The switch then calculates which ports need to be shut down. I forget exactly how this is calculated, it doesn't matter in this case since we know that the port to switch B got shut down. This would probably be due to the fact that the MAC table entry was older for that port than on 3 and 4. It might shut down one of those ports as well, but I'll assume not for the moment.

So now, port 1 is disabled so SWB can't get any traffic through.

Now Computer 2 responds to Computer 1. SWC sends the traffic to SWA. It tries to send it to Computer 1 over port 3 or 4. Then it gets the same packet back on the other port. It sees the source is Computer2, and shuts down port2, so now SWC can't pass traffic.

This is just how I see it happening. There may be steps in the process that I don't remember or ways that prevent it doing this, or some switches may not perform a full spanning tree process so this happens when it wouldn't usually. But it certainly seems that something close to this occurred in this case.

 

[Santa]

Sorry but I was pretty confused by your explanation but from what I understand of STP and how cisco implements the blocking of ports it is not based upon duplicate information coming from multiple ports at all.

Bridge Protocol Data Units convey the information needed to find the root switch and a calculation are made about each switch to find the best and shortest route to the root switch.

If multiple routes are found the longer routes are placed in a blocking state.

I can't see a looped port being a higher priority than going directly to another switch since if it worked at all it would go either in circles or it would add an extra hop making the link a higher cost and should be shut down thus not effecting the other switches.

Cisco switches typically indicate a blocked port with a differnt color LED. Did you have a weird flashing or weird color LED on one of the ports? Which one?

Perhaps Spanning tree calculations were being constantly run on the other ports causing the ports to flap into and out of blocking state.

 

[Lord Evermore]

Hmm. Perhaps the central switch in this case was counted as the root port, and since the packets could go out the looped port and come right back in, they wouldn't have had a hop incremented, so those would be considered higher priority. But it would depend on exactly what happened and when. Presumably when the loop came up, the switch attempted to apply STP immediately. Maybe the fact that the loops were already prioritized, and then the broadcasted traffic was looped back in, it resulted in the ports to the other switches being shut down rather than the looped ports. (The way I originally explained it, the looped traffic would indeed have an extra hop count so it should have shut down the looped ports.)

 

[ScottMac]

IIRC, there is no hop count at Layer 2. TTL is an IP (Layer 3) thing.

Any broadcast is propagated immediately out all ports (within the VLAN / subnet).

The entire segment sees the broadcast. The switch / bridge doesn't look at the source address for anything other than updateing it's forwarding tables. It see a broadcast destination address and floods. Anything attached to the port will see the broadcast. Any broadcast seen will be propagated, even if it's from the same switch/bridge.

I'd guess there is (at least) one switch that doesn't have Spanning Tree enabled, which will totally screw the system in a looped environment. Check the ports attached to the other switches and make sure that "portfast" is not enabled.

If there's a cheap hub/switch somewhere in the line, and your system is set to do Spanning Tree, remove the cheap switch/hub (any consumer-grade infrastructure). Hubs don't do Spanning Tree.

FWIW

Scott

 

[spidey07]

Everybody's already got it covered so...

Spanning-Tree will block one of the ports. If the switch isn't running spanning tree then pick your flavor of "bad things" (good description Scott) that will happen. Broadcast storm being the first thing...and it will take less than a minute for the network to become unusable.

I've done packet captures of the SOHO switches...they don't run spanning tree.