HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Comware Based
cancel
Showing results for 
Search instead for 
Did you mean: 

Prevent STP recalculation

 
alexandere
Visitor

Prevent STP recalculation

Hi

 

We currently have two HP5900AF 10Gb switches configured in an IRF stack with forty-gig cabling.

This network stack is running SMB3 storage traffic for Hyper-V hosts so they are extremely sensitive to network jitter.

 

Last year we had another switch (ProCurve) connected to this IRF stack which caused a network outage probably because the STP topolopy was recalculated. The Hyper-V hosts lost their VM storage so to speak causing all VMs to reboot.

 

If we (temporary) need to connect additional switches on an uplink port to our HP5900 Stack,

what should be configured on that uplink port to prevent this issue?

 

stp root-protection?

stp disable?

stp BPDU Guard?

 

Regards

Alexander

 

 

 

5 REPLIES
Vince-Whirlwind
Honored Contributor

Re: Prevent STP recalculation

First, design your STP topology.

 

Then, configure Rootguard and STP priorities as per your design.

 

Configure the Procurve switch before you patch it in.

alexandere
Visitor

Re: Prevent STP recalculation

Hi Thank you for your reply.

 

So the only STP configuration on the IRF stack is

 

 stp instance 0 priority 8192
 stp mode rstp
 stp global enable

 

The ProCurve uses other values for priority you set for a single value (0-15) which is then multiplied with 4096.

Does the H3C switch understand this?

 

However this time we problably will add an additional  H3C switch.

 

So, will enabling Rootguard on the uplink port prevent STP convergence/recalculation when connecting

the cable from an additional switch into the Root Guard enabled uplink port on the existing switch?

 

Thanks

/A

 

TerjeAFK
Respected Contributor

Re: Prevent STP recalculation

On our 5900 switches (also connected with IRF) we use the following STP config:

 

 stp instance 0 root primary
 stp global enable

 

In addition we use "stp edged-port" on every interface not connected to other switches.

 

VoIP-Buddy
HPE Pro

Re: Prevent STP recalculation

If you don't need to communicate STP down to the lower level switch for some reason, you can set the port as an EDGE port and it will not cause a spanning tree reconfiguration when that lower level switch reboots, or loses connectivity to either of the 5900's.   STP will also not be forced to recalculate if the lower level switch experiences it's own port bouncing from other attached devices.

 

If this is so critical to your VM environment, why not dedicate switches to that environment and its storage so that no external force can destabilize it?  Aside from the expense, of course.

 

Regards,

 

David

alexandere
Visitor

Re: Prevent STP recalculation

Hi Thank you for your replies!

 

As I said in my original post the additional switches is temporary. We are going to move all our infrastructure to a new datacenter (in the same building). To do this with minimial amount of downtime we want to setup a receiving environment (network & storage).

 

Therefore we need to connect additional 10Gb switches (borrowed during migration) in our exisitng 10Gb switches without causing STP recalculation.

 

So, Can the uplink trunk port be configured as an edge port even though it is supposed to connect end user devices?

(The storage traffic flows on two separate VLANs for SMB multichannel to work properly) The reason I mention this is that I noticed that STP can be disabled for specific VLANs.

 

Or is this the solution?

 

1.1.38  stp root-protection

Syntax

stp root-protection

undo stp root-protection

View

Ethernet port view

Parameters

None

Description

Use the stp root-protection command to enable the root guard function on the current port.

Use the undo stp root-protection command to restore the root guard function to the default state on the current port.

By default, the root guard function is disabled.

Configuration errors or attacks may result in configuration BPDUs with their priorities higher than that of a root bridge, which causes new root bridge to be elected and network topology jitter to occur. In this case, flows that are to travel along high-speed links may be led to low-speed links, and network congestion may occur.

You can avoid this by utilizing the root guard function. Ports with this function enabled can only be kept as designated ports in all MSTIs. When a port of this type receives configuration BPDUs with higher priorities, it changes to discarding state (rather than becomes a non-designated port) and stops forwarding packets (as if it is disconnected from the link). It resumes the normal state if it does not receive any configuration BPDUs with higher priorities for a specified period.

Related commands: stp interface root-protection.

 

 

Alex