Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This question already has an answer here:

Note: I think my question has a poor title but I am not sure how to fix it, so please correct if you think of something better.

In my office our phones are equipped with a "daisy-chain" port so that users may plug in both their phone and PC into a single network port.

One of our users messed up and connected the daisy-chain port back into the network (as there were two data ports). This created a ton of problems very quickly and it was only due to dumb luck that I discovered the misconfiguration.

Even while the phone was doubly-connected I was able to connect to other network machines and even browse the web, albeit extremely slowly. There was packet loss and high latency while pinging other machines on the network.

I am wondering:

  1. What was happening while the phone/switch was doubly-connected?
  2. How would you diagnose something like this without unplugging stuff from the main switch or patch panel?
share|improve this question

marked as duplicate by Tonny, Ward, mdpc, Tom O'Connor Aug 26 '13 at 23:45

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

This must be migrated to superuser. Any netwerk-admin should now about spanning-tree and bpdu-guard. It's in LAN-101. – Tonny Aug 26 '13 at 9:23
up vote 1 down vote accepted

The loop-back (via the internal hub in the phone) caused your switches to go into a spanning-tree discovery loop.
This slows down the network to a crawl, may even make normal operation completely impossible.
Troubleshooting this is difficult as the problem itself makes LAN operation problematic.

If you can't determine the cause immediately the quickest approach is to simply shutdown a switch. See if the network stabilizes (takes about 60 seconds worst case).
If it stabilizes the problem is connected to that switch. So check each wall-outlet connected to that switch for wiring problems.
If it doesn't stabilize do the same with the next switch until you have found the problem.

Pretty basic but it works. Major nightmare for the users though....

Better is to prevent this altogether.
All modern switches have a configuration option called "BPDU-guard".
Basically this causes a port that detects BPDU packets coming in to automatically shutdown before problems start. (BPDU is the same as spanning-tree.)
Enable this on all end-point ports (don't do it on links between switches, you need it there).

share|improve this answer
The BPDU packets loop around (go out from the switch and come back over the same interface). This causes the STP (re-)calculation algorythm to be re-triggered continuously across all switches in the LAN. If you don't have any STP running you get another effect: Broadcast traffic keeps bouncing around until the entire LAN is flooded with broadcast. From a users point of view the effect is identical: LAN down or very slow. You will have to look at switch logs to tell what really happens. Or monitor traffic with Wireshark: Look for BPDU packets (STP related) or broadcast packets in case 2. – Tonny Aug 26 '13 at 14:36
I'm familiar with switch flooding that is created by a switch loop but I've never heard of it being caused by STP BPDU's. – joeqwerty Aug 26 '13 at 14:40
@joeqwerty Count yourself lucky. I have to deal with it on a regular basis. Several sites with developers working on network-capable devices, that contain buildin 5-port switches with STP capability. (STP is integral to the product itself, they develop their own version of it.) Sometimes they "forget" and plug their stuff into the normal LAN. – Tonny Aug 27 '13 at 15:41

i actually don't know about daisy-chain port. But it seems the problem was caused by STP mechanism on your network devices, STP is a method to disable some traffic passing some ports(to avoid loop because of link redundancy). This kind of problem is usually happen if user accidentally create redundant link.

share|improve this answer
@joeqwerty See my comment below. A switch loop, which STP normally prevents, is not the same as a "spanning tree discovery loop", otherwise known as "runaway STP recalculation". – Tonny Aug 26 '13 at 14:38
STP doesn't CAUSE switch loops. So, the problem wasn't CAUSED by STP. The problem was CAUSED by the user creating a switch loop. – joeqwerty Aug 26 '13 at 14:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.