Can anyone help with STP - HP V1910 switch.
Discussion
I'm getting myself really confused here.
I installed a new switch, enabled STP and plugged everyone in, and promptly took that segment of the network down.
I'm new to this particular model of HP, and even newer to having to configure everything via a web gui...
So, here's a few screenshots of what I have done so far..
Port status (currently discarding).
Global configuration:
Options I selected before clicking 'Apply'.
If I toggle these options on and off - the port springs to life, with STP loop protection enabled.
I guess I'm doing something stupid here - and any help would be much appreciated.
In the example below - the port is not working so..
TIA.
I installed a new switch, enabled STP and plugged everyone in, and promptly took that segment of the network down.
I'm new to this particular model of HP, and even newer to having to configure everything via a web gui...
So, here's a few screenshots of what I have done so far..
Port status (currently discarding).
Time since last TC :0 days 0h:7m:32s
----[Port24(GigabitEthernet1/0/24)][DISCARDING]----
Port Protocol :enabled
Port Role :CIST Designated Port
Port Priority :128
Port Cost(Legacy) :Config=auto / Active=20
Desg. Bridge/Port :0.cc3e-5fc8-090a / 128.24
Port Edged :Config=disabled / Active=disabled
Point-to-point :Config=auto / Active=true
Transmit Limit :10 packets/hello-time
Protection Type :Loop
MST BPDU Format :Config=auto / Active=legacy
Port Config-
Digest-Snooping :disabled
Num of Vlans Mapped :1
PortTimes :Hello 2s MaxAge 20s FwDly 15s MsgAge 0s RemHop 20
BPDU Sent :147
TCN: 0, Config: 0, RST: 147, MST: 0
BPDU Received :0
TCN: 0, Config: 0, RST: 0, MST: 0
Global configuration:
Options I selected before clicking 'Apply'.
If I toggle these options on and off - the port springs to life, with STP loop protection enabled.
I guess I'm doing something stupid here - and any help would be much appreciated.
In the example below - the port is not working so..
TIA.
And to add.. (this is the result of 'toggling' STP whilst the port remains connected.)
If I do this, then move the client to another port, it stops workng.
If I do this, then move the client to another port, it stops workng.
STP enabled:
Instance 0
----[Port24(GigabitEthernet1/0/24)][DISCARDING]----
Port Protocol :enabled
Port Role :CIST Designated Port
Port Priority :128
Port Cost(Legacy) :Config=auto / Active=20
Desg. Bridge/Port :32768.cc3e-5fc8-090a / 128.24
Port Edged :Config=disabled / Active=disabled
Point-to-point :Config=auto / Active=true
Transmit Limit :10 packets/hello-time
Protection Type :Loop
MST BPDU Format :Config=auto / Active=legacy
Port Config-
Digest-Snooping :disabled
Num of Vlans Mapped :1
PortTimes :Hello 2s MaxAge 20s FwDly 15s MsgAge 2s RemHop 20
BPDU Sent :27
TCN: 0, Config: 0, RST: 27, MST: 0
BPDU Received :0
TCN: 0, Config: 0, RST: 0, MST: 0
^^^^^^^^^^^^^^ before changes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
** STP disabled **
Instance 0
----[Port24(GigabitEthernet1/0/24)][DISABLED]----
Port Protocol :disabled
-----------------------------------------------------------
*** STP re-enabled ***
Instance 0
----[Port24(GigabitEthernet1/0/24)][LEARNING]----
Port Protocol :enabled
Port Role :CIST Designated Port
Port Priority :128
Port Cost(Legacy) :Config=auto / Active=20
Desg. Bridge/Port :32768.cc3e-5fc8-090a / 128.24
Port Edged :Config=disabled / Active=disabled
Point-to-point :Config=auto / Active=true
Transmit Limit :10 packets/hello-time
Protection Type :Loop
MST BPDU Format :Config=auto / Active=legacy
Port Config-
Digest-Snooping :disabled
Num of Vlans Mapped :1
PortTimes :Hello 2s MaxAge 20s FwDly 15s MsgAge 2s RemHop 20
BPDU Sent :12
TCN: 0, Config: 0, RST: 12, MST: 0
BPDU Received :0
TCN: 0, Config: 0, RST: 0, MST: 0
^^^^^^^^^^^^^^^ post changes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Nothing has changed - yet it works????
Argh STP.
Ok so a few things to ask/comment on first.
- You definitely want STP on, so we should work around getting the settings right for STP being enabled.
- What does the topology look like? Have you just got two switches, running CST/MST with VLAN 1? Are there any loops in the network?
- Have you considered which of your switches will be the root bridge? I noticed that the switch configuration you've put up has a priority of 32768 (The standard out of the box setting). If you leave these settings the same, the network may re-converge upon bringing in the new switch, to have a (re)election of who the root bridge will be. You should try to set your core bridge to something lower, such as 4096, so that you ensure that the core stays as the core.
- Have you waited up to 1 minute for things to start working? A spanning tree election generally takes 50 seconds to go from listening/learning/forwarding/blocking (I think discarding is the same as blocking, which is probably a HP-ism...)
- Have you configured the ports that connect the two switches together as tagged ports on VLAN 1? And are you using aggregation (LACP/PAGP)?
Mike.
Ok so a few things to ask/comment on first.
- You definitely want STP on, so we should work around getting the settings right for STP being enabled.
- What does the topology look like? Have you just got two switches, running CST/MST with VLAN 1? Are there any loops in the network?
- Have you considered which of your switches will be the root bridge? I noticed that the switch configuration you've put up has a priority of 32768 (The standard out of the box setting). If you leave these settings the same, the network may re-converge upon bringing in the new switch, to have a (re)election of who the root bridge will be. You should try to set your core bridge to something lower, such as 4096, so that you ensure that the core stays as the core.
- Have you waited up to 1 minute for things to start working? A spanning tree election generally takes 50 seconds to go from listening/learning/forwarding/blocking (I think discarding is the same as blocking, which is probably a HP-ism...)
- Have you configured the ports that connect the two switches together as tagged ports on VLAN 1? And are you using aggregation (LACP/PAGP)?
Mike.
Polariz said:
Argh STP.
Ok so a few things to ask/comment on first.
- You definitely want STP on, so we should work around getting the settings right for STP being enabled.
- What does the topology look like? Have you just got two switches, running CST/MST with VLAN 1? Are there any loops in the network?
I have 5 switches on total, 4 of which are uplinked to the 5th switch.Ok so a few things to ask/comment on first.
- You definitely want STP on, so we should work around getting the settings right for STP being enabled.
- What does the topology look like? Have you just got two switches, running CST/MST with VLAN 1? Are there any loops in the network?
The VLAN is the standard VLAN0001.
There are no loops that I can see - it's a new network, and we only have 6 clients on the LAN currently.
I am using RSTP rather than MSTP (I assume that's what you meant by the CST/MST comment?).
Polariz said:
- Have you considered which of your switches will be the root bridge?
No... 
Polariz said:
I noticed that the switch configuration you've put up has a priority of 32768 (The standard out of the box setting). If you leave these settings the same, the network may re-converge upon bringing in the new switch, to have a (re)election of who the root bridge will be. You should try to set your core bridge to something lower, such as 4096, so that you ensure that the core stays as the core.
I wonder if this is the cause of my problems.Polariz said:
- Have you waited up to 1 minute for things to start working? A spanning tree election generally takes 50 seconds to go from listening/learning/forwarding/blocking (I think discarding is the same as blocking, which is probably a HP-ism...)
Yes. Even longer!Polariz said:
- Have you configured the ports that connect the two switches together as tagged ports on VLAN 1? And are you using aggregation (LACP/PAGP)?
Mike.
No, I haven't configured tagged ports, should I do this?Mike.
We're not using LACP.
Thanks for your help so far!
No problem!
So given the topology you mentioned this is indeed a bit weird. Typically one can take down the network when STP/Layer 2/Layer 3 is concerned because (And I appreciate some of these might not be relevant, but you never know what has changed within the downtime window):
a) You turned STP off somewhere, created a loop and then let it explode (I assume you know why this happens)
b) Plugging in a switch that has a lower bridge priority ID, or the same bridge priority (Because then the re-election becomes based on lowest MAC address I believe). This will cause a re-election but generally service does get restored once the election has happened.
c) You have BPDU guard turned on on the ports that connect two switches together. BPDU Guard basically is used as a security precaution to prevent me turning up at your building and plugging my own switch into a floor port and start doing nasty things. BPDUs detected on that port will cause the port to get shut down.
d) You have DHCP snooping turned on, and plugged in a DHCP server. This is another security precaution to prevent me turning up and adding my own DHCP server into the network.
e) You've configured an SVI/default gateway on the new switch which is a duplicate of somewhere else
So, a few recommendations:
- If this is a new network, set the Bridge priority of your core to something lower than 32768. If you don't want to change the core, just change the edge switches to be something higher. You have to use a multiple of 4096 I believe so you can't just type in 40000
- Technically, you don't have to use a tagged port because you only have one VLAN. In most cases, let's say I have VLANs 1,2,3 and 4, I would use a tagged port, allow VLANs 1-4, but make VLAN 1 the native VLAN (IE, VLAN 1 isn't tagged). The short answer is, if you just have VLAN 1, leave it untagged.
- Ensure that on uplink ports between switches, BPDUGuard, and DHCP Snooping are turned off.
- If this still doesn't work, ensure that all switches are using the same CST/MST instance (0 I assume). Also check that all switches are using the same spanning tree method, preferably RSTP.
So given the topology you mentioned this is indeed a bit weird. Typically one can take down the network when STP/Layer 2/Layer 3 is concerned because (And I appreciate some of these might not be relevant, but you never know what has changed within the downtime window):
a) You turned STP off somewhere, created a loop and then let it explode (I assume you know why this happens)
b) Plugging in a switch that has a lower bridge priority ID, or the same bridge priority (Because then the re-election becomes based on lowest MAC address I believe). This will cause a re-election but generally service does get restored once the election has happened.
c) You have BPDU guard turned on on the ports that connect two switches together. BPDU Guard basically is used as a security precaution to prevent me turning up at your building and plugging my own switch into a floor port and start doing nasty things. BPDUs detected on that port will cause the port to get shut down.
d) You have DHCP snooping turned on, and plugged in a DHCP server. This is another security precaution to prevent me turning up and adding my own DHCP server into the network.
e) You've configured an SVI/default gateway on the new switch which is a duplicate of somewhere else
So, a few recommendations:
- If this is a new network, set the Bridge priority of your core to something lower than 32768. If you don't want to change the core, just change the edge switches to be something higher. You have to use a multiple of 4096 I believe so you can't just type in 40000
- Technically, you don't have to use a tagged port because you only have one VLAN. In most cases, let's say I have VLANs 1,2,3 and 4, I would use a tagged port, allow VLANs 1-4, but make VLAN 1 the native VLAN (IE, VLAN 1 isn't tagged). The short answer is, if you just have VLAN 1, leave it untagged.
- Ensure that on uplink ports between switches, BPDUGuard, and DHCP Snooping are turned off.
- If this still doesn't work, ensure that all switches are using the same CST/MST instance (0 I assume). Also check that all switches are using the same spanning tree method, preferably RSTP.
Oh one more very silly question, but what actually stops working exactly? A client can pass traffic, but then that particular client stops working? Or does the whole network go down? Would you mind popping down the steps of what you're doing from where it's working, to when it stops working? Sorry!
M.
M.
Firstly - a digram (for what it's worth!)
Polariz said:
No problem!
So given the topology you mentioned this is indeed a bit weird. Typically one can take down the network when STP/Layer 2/Layer 3 is concerned because (And I appreciate some of these might not be relevant, but you never know what has changed within the downtime window):
a) You turned STP off somewhere, created a loop and then let it explode (I assume you know why this happens)
Yes I do.So given the topology you mentioned this is indeed a bit weird. Typically one can take down the network when STP/Layer 2/Layer 3 is concerned because (And I appreciate some of these might not be relevant, but you never know what has changed within the downtime window):
a) You turned STP off somewhere, created a loop and then let it explode (I assume you know why this happens)
Polariz said:
b) Plugging in a switch that has a lower bridge priority ID, or the same bridge priority (Because then the re-election becomes based on lowest MAC address I believe). This will cause a re-election but generally service does get restored once the election has happened.
c) You have BPDU guard turned on on the ports that connect two switches together. BPDU Guard basically is used as a security precaution to prevent me turning up at your building and plugging my own switch into a floor port and start doing nasty things. BPDUs detected on that port will cause the port to get shut down.
I experimented with this setting to no avail.c) You have BPDU guard turned on on the ports that connect two switches together. BPDU Guard basically is used as a security precaution to prevent me turning up at your building and plugging my own switch into a floor port and start doing nasty things. BPDUs detected on that port will cause the port to get shut down.
Polariz said:
d) You have DHCP snooping turned on, and plugged in a DHCP server. This is another security precaution to prevent me turning up and adding my own DHCP server into the network.
These switches don't appear to have a DHCP snoop setting (unless it's known by another name..)Polariz said:
e) You've configured an SVI/default gateway on the new switch which is a duplicate of somewhere else
I've not configured anything like this - the switches simply have an IP address with no gateway set (there's nowhere to input the gateway that I can see).Polariz said:
So, a few recommendations:
I'm trying these today.Polariz said:
- If this still doesn't work, ensure that all switches are using the same CST/MST instance (0 I assume). Also check that all switches are using the same spanning tree method, preferably RSTP.
They are all using RTSP.Polariz said:
Oh one more very silly question, but what actually stops working exactly? A client can pass traffic, but then that particular client stops working? Or does the whole network go down? Would you mind popping down the steps of what you're doing from where it's working, to when it stops working? Sorry!
M.
All clients stop working *only* if I unplug the ethernet cable, and then plug it back in again (or plug it in to an alternate port on the saem switch / another switch). No amount of waiting for the STP to 'settle' brings the port back up.M.
ffc said:
How many ports do you have uplinked to the central switch? Is the port you showed the output from at the top of the page the uplink port from the new switch to the central one?
There are 5 ports on the core switch, uplinked to each individual switch.There is no loop that I can see.
The only potential oddity (but I think it's fine) is that there are 2 servers running HyperV, and each of those two servers has 2 connections into the same switch - however...
One of each connection is connected to a Virtual Switch (HyperV) so I can't see this being an issue.
If I had set that up, I probably would have used a VLAN for the HyperV switches, but I didn't set it up.
I have triple checked the entire network, and still cannot find a loop - and yet the switch ports still shut down...
Never had so much trouble enabling STP before..
The only potential oddity (but I think it's fine) is that there are 2 servers running HyperV, and each of those two servers has 2 connections into the same switch - however...
One of each connection is connected to a Virtual Switch (HyperV) so I can't see this being an issue.
If I had set that up, I probably would have used a VLAN for the HyperV switches, but I didn't set it up.
I have triple checked the entire network, and still cannot find a loop - and yet the switch ports still shut down...
Never had so much trouble enabling STP before..
Problem solved I think (I hope!).
It looks like there's an oddity with the way the HP switch presents the status data.
With STP enabled globally:
Protection Type :None
Yet STP is clearly enabled and functional, as I connected several ports together and the switch continues to function normally, shutting the port down as expected.
However, the STP status is not reported in the port status above - barring the "PortTimes" option which hints at STP being enabled.
Quite odd really.
Give me a command line any day - managing switches via a gui = yuk.
eta: Fixed spelling.
It looks like there's an oddity with the way the HP switch presents the status data.
With STP enabled globally:
----[Port18(GigabitEthernet1/0/18)][FORWARDING]----
Port Protocol :enabled
Port Role :CIST Designated Port
Port Priority :128
Port Cost(Legacy) :Config=auto / Active=20
Desg. Bridge/Port :4096.cc3e-5fc8-12de / 128.18
Port Edged :Config=disabled / Active=disabled
Point-to-point :Config=auto / Active=true
Transmit Limit :10 packets/hello-time
[b]Protection Type :None[/b]
MST BPDU Format :Config=auto / Active=legacy
Port Config-
Digest-Snooping :disabled
Rapid transition :false
Num of Vlans Mapped :1
PortTimes :Hello 2s MaxAge 20s FwDly 15s MsgAge 0s RemHop 20
BPDU Sent :45
TCN: 0, Config: 0, RST: 45, MST: 0
BPDU Received :0
TCN: 0, Config: 0, RST: 0, MST: 0
Protection Type :None
Yet STP is clearly enabled and functional, as I connected several ports together and the switch continues to function normally, shutting the port down as expected.
However, the STP status is not reported in the port status above - barring the "PortTimes" option which hints at STP being enabled.
Quite odd really.
Give me a command line any day - managing switches via a gui = yuk.
eta: Fixed spelling.
Edited by TonyRPH on Friday 14th March 18:20
Ah excellent! Sorry I hadn't updated today. Meetings : /
That diagram you produced does show this was pretty weird! I guess what I should have said in hindsight is (rule of thumb) get all of the basics working first and then turn on protection methods afterwards. I have unfortunately lost too many hours to problems like this where there was strange behaviour and I was troubleshooting the basic, just to find that DHCP snooping etc were running and just overriding everything!
And CLI for the win every time. Glad you're sorted!
That diagram you produced does show this was pretty weird! I guess what I should have said in hindsight is (rule of thumb) get all of the basics working first and then turn on protection methods afterwards. I have unfortunately lost too many hours to problems like this where there was strange behaviour and I was troubleshooting the basic, just to find that DHCP snooping etc were running and just overriding everything!
And CLI for the win every time. Glad you're sorted!
TonyRPH said:
Problem solved I think (I hope!).
It looks like there's an oddity with the way the HP switch presents the status data.
With STP enabled globally:
Protection Type :None
Yet STP is clearly enabled and functional, as I connected several ports together and the switch continues to function normally, shutting the port down as expected.
However, the STP status is not reported in the port status above - barring the "PortTimes" option which hints at STP being enabled.
Quite odd really.
Give me a command line any day - managing switches via a gui = yuk.
eta: Fixed spelling.
The RSTP status for the port you are showing is listed as forwarding which should indicate that RSTP is running. Also as you say the PorTimes line includes a hello timer which is an RSTP mechanism. It looks like there's an oddity with the way the HP switch presents the status data.
With STP enabled globally:
----[Port18(GigabitEthernet1/0/18)][FORWARDING]----
Port Protocol :enabled
Port Role :CIST Designated Port
Port Priority :128
Port Cost(Legacy) :Config=auto / Active=20
Desg. Bridge/Port :4096.cc3e-5fc8-12de / 128.18
Port Edged :Config=disabled / Active=disabled
Point-to-point :Config=auto / Active=true
Transmit Limit :10 packets/hello-time
[b]Protection Type :None[/b]
MST BPDU Format :Config=auto / Active=legacy
Port Config-
Digest-Snooping :disabled
Rapid transition :false
Num of Vlans Mapped :1
PortTimes :Hello 2s MaxAge 20s FwDly 15s MsgAge 0s RemHop 20
BPDU Sent :45
TCN: 0, Config: 0, RST: 45, MST: 0
BPDU Received :0
TCN: 0, Config: 0, RST: 0, MST: 0
Protection Type :None
Yet STP is clearly enabled and functional, as I connected several ports together and the switch continues to function normally, shutting the port down as expected.
However, the STP status is not reported in the port status above - barring the "PortTimes" option which hints at STP being enabled.
Quite odd really.
Give me a command line any day - managing switches via a gui = yuk.
eta: Fixed spelling.
Edited by TonyRPH on Friday 14th March 18:20
ffc said:
The RSTP status for the port you are showing is listed as forwarding which should indicate that RSTP is running. Also as you say the PorTimes line includes a hello timer which is an RSTP mechanism.
With these switches - there is an option to apply STP to selected ports. (see 2nd screenshot in my OP)STP: Enable ---- Protection type: Loop.*
When you do this - the port status shows "Protection Type : Loop"
That's when it all goes wrong however!
I guess the management software for these switches isn't that good...
I'm assuming of course that "Loop protection" and RSTP are one and the same. Perhaps I'm wrong?
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff