There's a mobile version of our website.
Does anyone have any idea what P2P self-looped means?
I have a 3560 acting as a router, and a number of vlan virtual interfaces defined. The only port that carries those vlans is a single trunked port. Yesterday, that port suddenly moved to a spanning tree blocked state.
The switch thinks it is root, and with only one way in and out of the switch, it should never block those ports anyway. Spanning tree was left as the default configuration.
I have turned off STP for now, which has brought the port backup, however I am getting a lot of packet loss and suspect whatever caused the strange port state is still causing problems somewhere.
Any thoughts appreciated.
Thanks that is very useful. Given the amount of switches it goes through, it is going to be a tricky one to track down!
I can't see any evidence of a broadcast storm anywhere. Any suggestions on how to track it down?
As we can see the problem at the core, my best idea is to prune that vlan off all links to the rest of the campus and add them back one by one.
If you are running pvst, only the vlans that receives their own bpdus on this port will be "self-looped". Also, you're looking for a loop that is generated by a device that is not running spanning-tree. BPDUs are consumed and re-generated by bridges... they are never "looping" through a bridge. So look for hubs or bridges not running stp. And this, very close to the port showing "self-loop" because, again, this looped bpdu did not go through any bridge.
Another possibility would be a duplicate mac address in the network, if you use to have a stack that has split, it might be possible that some mac persistency could create that. But here again, it would be a matter of checking the very adjacent bridge. It's much less likely that the bpdu looping scenario.
Many thanks for the advice.
The problem turned out to be a Cisco access point PoE injector connected to some faulty wiring. For some reason the wiring fault confused the internal switch in the injector. The result was it resent all packets back out the uplink port.
When a client tried to DHCP, the request would go to the DHCP server, and the broadcast would also hit this faulty injector, it would sent the DHCP request back out, arriving at the server a split second after the initial request. Of course the second request rewrote all the MAC forwarding tables, so the reply went to the faulty device rather than the client. The client would then send another request, and so on.
This is one of the strangest network problems I have seen. The problem only appeared when any PoE injector was connected to a particular part of the structured wiring.
That is why a loop was reported, without a broadcast storm. This was more a broadcast echo. It even confused CDP, with it reporting itself as a neighbour, port 46 connecting to port 46 on itself!
Login to share your discussion activity with your friends on Facebook. You can control what you share and turn off sharing anytime.
Your Facebook friends can now see that you have started this discussion
Your Facebook friends can now see that you have commented on this discussion
Your Facebook friends can now see that you have read this discussion