What is P2P self-looped

Unanswered Question
Jun 17th, 2008

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.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
dominic.caron Tue, 06/17/2008 - 04:31

The 3560 is receiving it's own BPDU back. You got a loop in the L2 switch under the 3560.

davehartburn Tue, 06/17/2008 - 04:48

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.

dominic.caron Tue, 06/17/2008 - 04:52

You say you have many vlan on the 3560 interface. Do they all get into blocking state ?

Francois Tallet Tue, 06/17/2008 - 08:17

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.

davehartburn Thu, 06/19/2008 - 01:09

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!

dan.letkeman Mon, 03/28/2011 - 14:36

Just had this happen to me as well, with a third party poe injector....very odd.

Thanks for the post, saved me a lot of time!


This Discussion