STP vs LoopDetect clarification

[Cameron_PDX]

Thank you in advance for any time you can take to help me out here!

So I am fairly new to HP STP and have never used the Loopback detection feature.  Correct me if I am wrong here, but my understanding is that STP can create redundancy and detect loops (rather makes a backup link but doesn't forward traffic) only within the STP domain on other managed devices;  where loop detection is designed more for a per port basis on edge ports or ports connected to unmanaged devices (small switch, access point, etc) and only protects against loops.  

If this understanding is correct, I have a few questions that I have been unable to find answers to in documentation.  I don't have a lab to play with and prefer not to test in production so I haven't simply tried any of the things I am asking below.  The switches I am working with are mostly 1910 and 1920 series each location having around 4-6 of them.

1. Can STP and Loop detection be enabled at the same time on the same switch?  Can they both be enabled globally on each switch or does each individual port need to be one or the other?  For one example, if I have STP enabled globally on a 1910-48G and plug in an unmanaged switch to port 48, can I just add loop detection to port 48 on top of STP or do I need to disable STP on port 48 and enable loop detect in place of it?
2. What are the potential problems of enabling both features as opposed to just choosing one (can they conflict)?  For example, if I enabled loop detection with STP enabled, would loop detection disable my designated/root ports to other switches if a redundant link was connected resulting in lost connection alltogether?
3. I have RSTP enabled globally across all switches with priority on my root switch, but when I tried enabling BPDU protection as recommended by HP it took down my network and had to power cycle the root switch that I enabled it on just to be able to log back in and disable it.  Is this normal or a one time fluke?  Does BPDU protection have to be enabled across all switches if implemented and on all STP ports?
4. How are Link aggregated ports/BAGG's affected by loop detection and STP (are they viewed as a single port by these technologies) and is it even recommended to enable these on aggregated ports?

I know there is a lot here, but I would really like to understand how it all works together and the recommended practices between these 2 technologies so that I can get as close as possible to complete loop protected networks.  There may be some documentation on it somewhere, but I cannot seem to find it HP specific.  I watched hours of ExpertOne video training on these switches too but they only talk about the technologies independantly with no explanation of using them together.

Thank you again for any assistance! 

P.S. This thread has been moevd from Comware-Based to Web and Unmanaged. - Hp Forum Moderator

[Apachez- · Accepted solution]

I didnt fully read up on loopdetect but this is what I got from the back of my head (anyone is free to refresh its contents

1) As far as I know loopdetect and STP can both be enabled at the same time.

2) Yes they can conflict because they doesnt know of each other. The drawback of STP are the system resources needed, potential way for a bad client to make trouble in the rest of the network and convergence time (stuff will stand still until a new tree is calculated and the link(s) are enabled again). Another drawback is that devices usually must have STP enabled in order to forward the BPDUs (spanning tree frames). For example if you have a cisco switch and dont wish it to participate in the spanning tree and just run "no spanning-tree" this will in fact drop all incoming BDPUs making the rest of the network not be able to spot the loop and hey presto - you now have an amplifying loop in your network...

3) As far as I understand "BPDU protection" means "if a BPDU (spanning tree frame that is) is seen arriving on this interface, put this interface into blocking state". This is handy in order to automatically shutdown evil clients from where you shouldnt see any BPDU arriving. Depending on how the rest of your network is connected this could of course put your network into some kind of halt.

4) If using static trunk then the resulting trunk will be the "interface" used to participate in the spanning tree/used for loopdetect. If dynamic trunk is being used (such as LACP) then each physical interface will be an interface until the trunk has formed and then only the resulting interface will be used for the STP / loopdetect.

Some background:

Spanning-tree (if we ignore modifications such as RSTP and MSTP) will calculate a tree out of the participating devices and then figure out the optimal way to "disable" interfaces in order to avoid a loop. This is done by taking linkspeed into consideration (link cost) etc. That is with STP an interface has 5 possible states: blocking, listening, learning, forwarding and disabled.

The drawback with STP is that each time something changes in your L2-network for the links and devices who participate in the STP the full tree must be recalculated (convergence time so it takes about 35 seconds for a link to become active). This means this is a great "feature" to hog the system cpu in your network devices (switches and routers who are part of the STP). If you also get a loop who for some reason isnt detected properly then the situation can get even worse (then the looping link will drop frames which if unlucky will drop the BPDUs which then will start to recalculate the tree back and forth eating up all system cpu).

Also due to how STP works if its badly configured an evil client can become "root bridge" in your network so instead of having your 10G links as backbone this 10Mbit client will become backbone instead (which of course will make the network feel sluggish).

Another drawback with STP is as I explained regarding how different devices interpret "no spanning-tree". In cisco-world this means that ALL BPDUs will get dropped so the loop will continue undetected. Compared to with HP E-series where "no spanning-tree" means forward any BPDUs but dont participate yourself in the tree-calculation.

So one can say that STP is a protocol to exchange information of how a network is interconnected in order to calculate best links to keep up (and the others to be put in blocking state).

The difference to loopdetect is that loopdetect is a per device feature. Loopdetect doesnt exchange any information and doesnt care about loop frames from other devices. It only monitors and waits for loop frames to show up that was sent by the device itself.

This way there is no system cpu hogging going on because some far link (in your L2-network) is flapping.

Loopdetect will just send out a broadcast (I think it was) which contains the device mac-address. If this frame is seen on another interface then this other interface will get disabled (didnt read up on if it will become permanently disabled or if it will recover itself later by continue to listen for the loop frames to arrive and once they stop it will reenable the interface causing the loop.

So in short, loopdetect is a great replacement for STP but its not as "smart" as STP. A good recommendation is to keep your L2-networks as small as possible and by that virtually make it unneccessary to run STP. However using STP on infrastructure links can still be a good idea as a safety measure (given that you configure it correctly regarding root bridges, timers etc).

If using STP dont forget to secure it, SEC (Secure Enduser Connection) is a great set of documents who describes best practices to apply in order to secure your network: https://secureenduserconnection.se/wp-content/uploads/2010/06/SEC-Secure-End-user-Connection-2015-08-26.pdf

[Vince-Whirlwind]

STP is used to prevent loops within the group of switches running STP together.

Loopdetect is used to detect loops that have occurred in other switches that are beyond the group of STP switches and not participating in the STP.

So loopdetect can't prevent loops, it just protects your switch from the effects of loops that have occurred elsewhere.

[Cameron_PDX]

Thank you for your detailed response Apachez-!  This is exactly the kind of information I am looking for and in depth too.

When you say that STP can be a resource hog for the network equipment due to constant packet broadcasts, does loopdetect not repeatedly broadcast packets creating more traffic on each switches CPU?  I assume if the latter is true, then enabling both features would create even higher resource utilization?

[Cameron_PDX]

Thank you Vince for your explanation of the key differences as this helps me understand better how and when to use each technology!  I appreciate your simple explanation too!

[Apachez-]

Loopdetect takes very little resources from the system cpu in the device who runs it.

it sends out these special broadcast-frames on all interfaces and looks for a reply.

The "look for reply" is done in hardware (the asic/fpga) so it doesnt affect the performance of other frames.

STP does similar stuff except that each detected change in toplogy will involve the system cpu to calculate a new tree in order to figure out which interface(s) to put in block state and which shouldnt be in block state. This calculation is resource intense and if badly configured and/or badly configured network your system cpus in your switches could basically be locked at 100% making other stuff that needs the system cpu feel sad. This can get even worse if you have L3 switches doing routing and suddently the dynamic routing protocols will suffer and you will end up with an nightmare to resolve.

These **bleep**ups are not that common but they do exist and thats a difference from using loopdetect.

As I previously said loopdetect will most likely solve most of the situations where a loop occurs. But its not as smart as STP who will resolve the loop. That is with loopdetect the loop can still exist out in the network but your device will protect itself from the effects of that loop.

[Vince-Whirlwind]

Hopefully your network design is aimed at achieving:

 - an ideal of zero loops.

 - an ideal of never requiring STP reconvergence.

Generally, seeing any kind of STP activity is probably a sign of trouble, in a well-designed network which should be stable from a topology point of view.

The way to ensure you have *no* blocked links on your network is  to use:

 - star topology

 - stackable switches

 - aggregated redundant links

 - No BPDUs allowed on edge ports.

You still enable STP (plus looprotect on your edge switches) just in case, and make sure you think about your STP topology and assign STP priorities accordingly.

[Cameron_PDX]

I have star topology with 1910-48G as the core switch. This has BAGG's configured for uplinks to all 1910-24G "edge" switches and to teamed NIC's on servers.

RSTP is globally enabled on all switches with the lowest priority being on the 48G switch so it is the STP root. All redundant links are configured via Link Aggregation and not using STP, therefore I have no "blocking" state ports unless someone creates a loop directly on one of those switches.  I will be testing rollout of loopdetect on all but my core switch (sounds like from your last line that you only enable this on the edge switches).

There are 3 unmanaged switches on the network (that I am aware of) but doesn't appear to be any loops. Looking at the CPU utilization on all of these 1910 switches during peak use is never maxed over %60 with this config. When I introduced a test loop from an unmanaged switch to a 1910 the CPU jumped to %100 and then I lost connection to the GUI, so fairly certain I don't have any current loops. Looks like the busiest thing is just alot of ARP broadcasting going all over the place so far.

I have not stacked them because the max stacking on 1910's is supposedly 4 switches and I have 6 so don't see any benefit of partial stacking.

Have only played with BPDU protection once (just turned it on) and for some reason it took down my 48 port core switch to the point I had to powercycle it. So I will probably do some more research on that one to better understand before testing again.

Thanks again for your helpful insights and recommended configurations Vince!  I have saved all these notes.

[Vince-Whirlwind]

Your network sounds great. (Although it would be more fun if they had given you 5130s to play with... :)

Rootguard is another option to put on your edge switches on their uplink ports. Not a huge priority that one.

Your unmanaged switches are the reason you need Loopprotect on your managed ones - because they are unmanaged, you can't put BPDU guard on them, so loops are (as per Murphys Law) inevitably going to happen.

[sdide]

Hi,

If you have a startopology, with all edges having BAGGs to the core, the advantage of stacking, or at least partially stacking, your core is that each edge could have be BAGG'ed into 2 different units in a core-stack, and you would not loose that edge if a single core-unit breaks.

Also your stp diameter would probably be less if you have less stp-units (i.e more stacking).

 "stp bpdu-protection" (global option) basically means, that ports that have the "stp edged-port", will be disabled (for the shutdown-interval (default 30 secs) ) if they receive a bpdu.

I'm not sure why you would loose connection to your core when you enable bpdu-protection on it-  unless of course  the interfaces towards your access swithes have "stp edged-port", then doing "stp bpdu-protection", will disable the interface if it recieves a BPDU (which it will within the Hello Time (default 2 seconds).

Regards.