Finding the root cause of Spanning-Tree recalculations (on Cisco Nexus 9000s)VLAN load sharing on Metro-E links between two Juniper EX 4200Cisco 2960 Portfast ports generate Spanning Tree TCNHow can I determine the STP designated bridge on Cisco IOS?Why showing IEEE Spanning Tree protocolCisco proprietary protocol - Spanning TreeHow do modern switches forward ethernet frames logically?Finding the optimum root bridge for a spanning treeSpanning tree root bridge process validationAdding new switch to Spanning Tree networkCisco nexus spanning-tree logging to syslog
How to cope with regret and shame about not fully utilizing opportunities during PhD?
How about space ziplines
White foam around tubeless tires
Why does lemon juice reduce the "fish" odor of sea food — specifically fish?
Why does the headset man not get on the tractor?
Why weren't the bells paid heed to in S8E5?
A case where Bishop for knight isn't a good trade
Use of さ as a filler
How do I adjust encounters to challenge my lycanthrope players without negating their cool new abilities?
Can a tourist shoot a gun for recreational purpose in the USA?
Is it wrong to omit object pronouns in these sentences?
Uh oh, the propeller fell off
Was this seat-belt sign activation standard procedure?
How to add block near a product image in a product detail page in Magento 2
Why did the metro bus stop at each railway crossing, despite no warning indicating a train was coming?
How do I identify the partitions of my hard drive in order to then shred them all?
Why didn't the Avengers use this object earlier?
Were any of the books mentioned in this scene from the movie Hackers real?
Given 0s on Assignments with suspected and dismissed cheating?
is it correct to say "When it started to rain, I was in the open air."
Is this possible when it comes to the relations of P, NP, NP-Hard and NP-Complete?
Acronyms in HDD specification
Is there any way to adjust the damage type of the Eldritch Blast cantrip so that it does fire damage?
What dog breeds survive the apocalypse for generations?
Finding the root cause of Spanning-Tree recalculations (on Cisco Nexus 9000s)
VLAN load sharing on Metro-E links between two Juniper EX 4200Cisco 2960 Portfast ports generate Spanning Tree TCNHow can I determine the STP designated bridge on Cisco IOS?Why showing IEEE Spanning Tree protocolCisco proprietary protocol - Spanning TreeHow do modern switches forward ethernet frames logically?Finding the optimum root bridge for a spanning treeSpanning tree root bridge process validationAdding new switch to Spanning Tree networkCisco nexus spanning-tree logging to syslog
I have a nagging Rapid PVST problem on some Nexus 9000 switches. Rapid-PVST keeps recalculating 3 to 5 times an hour. We have in this topology (summarized):
Edge Router Access Layer
+-------------+ +-------------+
| | Eth1/28 Eth1/54 | |
| Nexus9000_1 +-------------------------+ Nexus9000_2 |
| | Vlan350 | |
+-------------+ dot1q Trunk +-------------+
|Eth1/45 (dot1q trunk)
|
Something_Important
SHOW OUTPUT: Nexus9000_1
Nexus9000_1# sh spanning-tree vlan 350 detail | i from|topology|VLAN
VLAN0350 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 1348 last change occurred 0:35:39 ago <---
from Ethernet1/28 <---
Times: hold 1, topology change 35, notification 2
Timers: hello 0, topology change 0, notification 0
... Output snipped ...
SHOW OUTPUT: Nexus9000_2
Nexus9000_2# sh spanning-tree vlan 350 detail | i from|topology|VLAN
VLAN0350 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 1157 last change occurred 0:35:39 ago <---
from Ethernet1/54 <---
Times: hold 1, topology change 35, notification 2
Timers: hello 0, topology change 0, notification 0
... Output snipped ...
BACKGROUND
The reason I found the STP recalculations is because we got so many complaints about the device connected to Nexus9000_2 Eth1/45 having 30-ish second outages over and over again. Configuring Nexus9000_2 Eth1/45 as spanning-tree port type edge trunk
made the problem much less visible because STP moves into a forwarding state much faster with that port-type.
I checked and know that the interfaces in this diagram are not flapping.
QUESTION
Each of those switches says it received a topology change notification (TCN) from the other switch. That's not very helpful... and I don't want to band-aid the problem with spanning-tree port type edge trunk
on port Eth1/45.
What is the best way to find the root cause of these STP topology changes using the tools available on Nexus 9000 switches?
Please don't respond with show spanning-tree internal event-history all
or other show spanning-tree internal
commands without explaining what exactly to look for in those commands.
cisco spanning-tree cisco-nexus
add a comment |
I have a nagging Rapid PVST problem on some Nexus 9000 switches. Rapid-PVST keeps recalculating 3 to 5 times an hour. We have in this topology (summarized):
Edge Router Access Layer
+-------------+ +-------------+
| | Eth1/28 Eth1/54 | |
| Nexus9000_1 +-------------------------+ Nexus9000_2 |
| | Vlan350 | |
+-------------+ dot1q Trunk +-------------+
|Eth1/45 (dot1q trunk)
|
Something_Important
SHOW OUTPUT: Nexus9000_1
Nexus9000_1# sh spanning-tree vlan 350 detail | i from|topology|VLAN
VLAN0350 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 1348 last change occurred 0:35:39 ago <---
from Ethernet1/28 <---
Times: hold 1, topology change 35, notification 2
Timers: hello 0, topology change 0, notification 0
... Output snipped ...
SHOW OUTPUT: Nexus9000_2
Nexus9000_2# sh spanning-tree vlan 350 detail | i from|topology|VLAN
VLAN0350 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 1157 last change occurred 0:35:39 ago <---
from Ethernet1/54 <---
Times: hold 1, topology change 35, notification 2
Timers: hello 0, topology change 0, notification 0
... Output snipped ...
BACKGROUND
The reason I found the STP recalculations is because we got so many complaints about the device connected to Nexus9000_2 Eth1/45 having 30-ish second outages over and over again. Configuring Nexus9000_2 Eth1/45 as spanning-tree port type edge trunk
made the problem much less visible because STP moves into a forwarding state much faster with that port-type.
I checked and know that the interfaces in this diagram are not flapping.
QUESTION
Each of those switches says it received a topology change notification (TCN) from the other switch. That's not very helpful... and I don't want to band-aid the problem with spanning-tree port type edge trunk
on port Eth1/45.
What is the best way to find the root cause of these STP topology changes using the tools available on Nexus 9000 switches?
Please don't respond with show spanning-tree internal event-history all
or other show spanning-tree internal
commands without explaining what exactly to look for in those commands.
cisco spanning-tree cisco-nexus
Do they actually recalculate the spanning tree, or are they just flooding another switch's TC flagged BPDU? (while flushing their CAM tables)
– Marc 'netztier' Luethi
May 10 at 5:09
add a comment |
I have a nagging Rapid PVST problem on some Nexus 9000 switches. Rapid-PVST keeps recalculating 3 to 5 times an hour. We have in this topology (summarized):
Edge Router Access Layer
+-------------+ +-------------+
| | Eth1/28 Eth1/54 | |
| Nexus9000_1 +-------------------------+ Nexus9000_2 |
| | Vlan350 | |
+-------------+ dot1q Trunk +-------------+
|Eth1/45 (dot1q trunk)
|
Something_Important
SHOW OUTPUT: Nexus9000_1
Nexus9000_1# sh spanning-tree vlan 350 detail | i from|topology|VLAN
VLAN0350 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 1348 last change occurred 0:35:39 ago <---
from Ethernet1/28 <---
Times: hold 1, topology change 35, notification 2
Timers: hello 0, topology change 0, notification 0
... Output snipped ...
SHOW OUTPUT: Nexus9000_2
Nexus9000_2# sh spanning-tree vlan 350 detail | i from|topology|VLAN
VLAN0350 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 1157 last change occurred 0:35:39 ago <---
from Ethernet1/54 <---
Times: hold 1, topology change 35, notification 2
Timers: hello 0, topology change 0, notification 0
... Output snipped ...
BACKGROUND
The reason I found the STP recalculations is because we got so many complaints about the device connected to Nexus9000_2 Eth1/45 having 30-ish second outages over and over again. Configuring Nexus9000_2 Eth1/45 as spanning-tree port type edge trunk
made the problem much less visible because STP moves into a forwarding state much faster with that port-type.
I checked and know that the interfaces in this diagram are not flapping.
QUESTION
Each of those switches says it received a topology change notification (TCN) from the other switch. That's not very helpful... and I don't want to band-aid the problem with spanning-tree port type edge trunk
on port Eth1/45.
What is the best way to find the root cause of these STP topology changes using the tools available on Nexus 9000 switches?
Please don't respond with show spanning-tree internal event-history all
or other show spanning-tree internal
commands without explaining what exactly to look for in those commands.
cisco spanning-tree cisco-nexus
I have a nagging Rapid PVST problem on some Nexus 9000 switches. Rapid-PVST keeps recalculating 3 to 5 times an hour. We have in this topology (summarized):
Edge Router Access Layer
+-------------+ +-------------+
| | Eth1/28 Eth1/54 | |
| Nexus9000_1 +-------------------------+ Nexus9000_2 |
| | Vlan350 | |
+-------------+ dot1q Trunk +-------------+
|Eth1/45 (dot1q trunk)
|
Something_Important
SHOW OUTPUT: Nexus9000_1
Nexus9000_1# sh spanning-tree vlan 350 detail | i from|topology|VLAN
VLAN0350 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 1348 last change occurred 0:35:39 ago <---
from Ethernet1/28 <---
Times: hold 1, topology change 35, notification 2
Timers: hello 0, topology change 0, notification 0
... Output snipped ...
SHOW OUTPUT: Nexus9000_2
Nexus9000_2# sh spanning-tree vlan 350 detail | i from|topology|VLAN
VLAN0350 is executing the rstp compatible Spanning Tree protocol
Number of topology changes 1157 last change occurred 0:35:39 ago <---
from Ethernet1/54 <---
Times: hold 1, topology change 35, notification 2
Timers: hello 0, topology change 0, notification 0
... Output snipped ...
BACKGROUND
The reason I found the STP recalculations is because we got so many complaints about the device connected to Nexus9000_2 Eth1/45 having 30-ish second outages over and over again. Configuring Nexus9000_2 Eth1/45 as spanning-tree port type edge trunk
made the problem much less visible because STP moves into a forwarding state much faster with that port-type.
I checked and know that the interfaces in this diagram are not flapping.
QUESTION
Each of those switches says it received a topology change notification (TCN) from the other switch. That's not very helpful... and I don't want to band-aid the problem with spanning-tree port type edge trunk
on port Eth1/45.
What is the best way to find the root cause of these STP topology changes using the tools available on Nexus 9000 switches?
Please don't respond with show spanning-tree internal event-history all
or other show spanning-tree internal
commands without explaining what exactly to look for in those commands.
cisco spanning-tree cisco-nexus
cisco spanning-tree cisco-nexus
edited May 10 at 22:06
Mike Pennington
asked May 9 at 21:30
Mike PenningtonMike Pennington
26.9k1166140
26.9k1166140
Do they actually recalculate the spanning tree, or are they just flooding another switch's TC flagged BPDU? (while flushing their CAM tables)
– Marc 'netztier' Luethi
May 10 at 5:09
add a comment |
Do they actually recalculate the spanning tree, or are they just flooding another switch's TC flagged BPDU? (while flushing their CAM tables)
– Marc 'netztier' Luethi
May 10 at 5:09
Do they actually recalculate the spanning tree, or are they just flooding another switch's TC flagged BPDU? (while flushing their CAM tables)
– Marc 'netztier' Luethi
May 10 at 5:09
Do they actually recalculate the spanning tree, or are they just flooding another switch's TC flagged BPDU? (while flushing their CAM tables)
– Marc 'netztier' Luethi
May 10 at 5:09
add a comment |
1 Answer
1
active
oldest
votes
In my case, I was able to solve the problem by turning on these debugs on Nexus9000_2:
debug spanning-tree rstp interface eth1/54
debug spanning-tree event interface eth1/54
debug spanning-tree bpdu_rx interface eth1/54
The next time a BPDU triggered a calculation, the debug gave me detailed information on what was happening on the switchport.
The output of this command was also useful: sh spanning-tree internal event-history all | begin VLAN0350
2
Do tell what the ultimate problem was!
– Ron Trunk
May 10 at 1:49
vpcpeer-switch
configured on a non-RPVST root switch
– Mike Pennington
May 10 at 17:02
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "496"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f59019%2ffinding-the-root-cause-of-spanning-tree-recalculations-on-cisco-nexus-9000s%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
In my case, I was able to solve the problem by turning on these debugs on Nexus9000_2:
debug spanning-tree rstp interface eth1/54
debug spanning-tree event interface eth1/54
debug spanning-tree bpdu_rx interface eth1/54
The next time a BPDU triggered a calculation, the debug gave me detailed information on what was happening on the switchport.
The output of this command was also useful: sh spanning-tree internal event-history all | begin VLAN0350
2
Do tell what the ultimate problem was!
– Ron Trunk
May 10 at 1:49
vpcpeer-switch
configured on a non-RPVST root switch
– Mike Pennington
May 10 at 17:02
add a comment |
In my case, I was able to solve the problem by turning on these debugs on Nexus9000_2:
debug spanning-tree rstp interface eth1/54
debug spanning-tree event interface eth1/54
debug spanning-tree bpdu_rx interface eth1/54
The next time a BPDU triggered a calculation, the debug gave me detailed information on what was happening on the switchport.
The output of this command was also useful: sh spanning-tree internal event-history all | begin VLAN0350
2
Do tell what the ultimate problem was!
– Ron Trunk
May 10 at 1:49
vpcpeer-switch
configured on a non-RPVST root switch
– Mike Pennington
May 10 at 17:02
add a comment |
In my case, I was able to solve the problem by turning on these debugs on Nexus9000_2:
debug spanning-tree rstp interface eth1/54
debug spanning-tree event interface eth1/54
debug spanning-tree bpdu_rx interface eth1/54
The next time a BPDU triggered a calculation, the debug gave me detailed information on what was happening on the switchport.
The output of this command was also useful: sh spanning-tree internal event-history all | begin VLAN0350
In my case, I was able to solve the problem by turning on these debugs on Nexus9000_2:
debug spanning-tree rstp interface eth1/54
debug spanning-tree event interface eth1/54
debug spanning-tree bpdu_rx interface eth1/54
The next time a BPDU triggered a calculation, the debug gave me detailed information on what was happening on the switchport.
The output of this command was also useful: sh spanning-tree internal event-history all | begin VLAN0350
edited May 10 at 2:56
answered May 9 at 22:22
Mike PenningtonMike Pennington
26.9k1166140
26.9k1166140
2
Do tell what the ultimate problem was!
– Ron Trunk
May 10 at 1:49
vpcpeer-switch
configured on a non-RPVST root switch
– Mike Pennington
May 10 at 17:02
add a comment |
2
Do tell what the ultimate problem was!
– Ron Trunk
May 10 at 1:49
vpcpeer-switch
configured on a non-RPVST root switch
– Mike Pennington
May 10 at 17:02
2
2
Do tell what the ultimate problem was!
– Ron Trunk
May 10 at 1:49
Do tell what the ultimate problem was!
– Ron Trunk
May 10 at 1:49
vpc
peer-switch
configured on a non-RPVST root switch– Mike Pennington
May 10 at 17:02
vpc
peer-switch
configured on a non-RPVST root switch– Mike Pennington
May 10 at 17:02
add a comment |
Thanks for contributing an answer to Network Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f59019%2ffinding-the-root-cause-of-spanning-tree-recalculations-on-cisco-nexus-9000s%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Do they actually recalculate the spanning tree, or are they just flooding another switch's TC flagged BPDU? (while flushing their CAM tables)
– Marc 'netztier' Luethi
May 10 at 5:09