spanning tree RootGuard question on vPC switches
up vote
3
down vote
favorite
I have following diagram and two distribution switch connected back to back over vPC
Related spanning-tree question is it ok to use RootGuard
on both distribution switch where access switch is connected or i should only use RootGuard
on ROOT
switches?
- RG - Root Guard
- BG - BPDU Guard
cisco switch spanning-tree
add a comment |
up vote
3
down vote
favorite
I have following diagram and two distribution switch connected back to back over vPC
Related spanning-tree question is it ok to use RootGuard
on both distribution switch where access switch is connected or i should only use RootGuard
on ROOT
switches?
- RG - Root Guard
- BG - BPDU Guard
cisco switch spanning-tree
1
Normally, you putrootguard
on all the switches, except the root switches. You put it on the downstream interfaces to prevent superior BPDUs from entering the switch.
– Ron Maupin♦
8 hours ago
Oh wait, really i thought we should putrootguard
on all ROOT bridge switches ports connected to other switches.. am i missing anything here?
– Satish
8 hours ago
1
You are trying to protect all the switches from getting a bad, superior BPDU from an incorrect location and electing a wrong root switch. Placing it on the root switch does not facilitate that.
– Ron Maupin♦
8 hours ago
I found one document on google and it seems they are puttingRG
on all switch path toward root rogerperkin.co.uk/spanning-tree/spanning-tree-root-guard
– Satish
8 hours ago
Look at what Cisco says about it: cisco.com/c/en/us/support/docs/lan-switching/…
– Ron Maupin♦
8 hours ago
add a comment |
up vote
3
down vote
favorite
up vote
3
down vote
favorite
I have following diagram and two distribution switch connected back to back over vPC
Related spanning-tree question is it ok to use RootGuard
on both distribution switch where access switch is connected or i should only use RootGuard
on ROOT
switches?
- RG - Root Guard
- BG - BPDU Guard
cisco switch spanning-tree
I have following diagram and two distribution switch connected back to back over vPC
Related spanning-tree question is it ok to use RootGuard
on both distribution switch where access switch is connected or i should only use RootGuard
on ROOT
switches?
- RG - Root Guard
- BG - BPDU Guard
cisco switch spanning-tree
cisco switch spanning-tree
edited 8 hours ago
asked 8 hours ago
Satish
1,3632151
1,3632151
1
Normally, you putrootguard
on all the switches, except the root switches. You put it on the downstream interfaces to prevent superior BPDUs from entering the switch.
– Ron Maupin♦
8 hours ago
Oh wait, really i thought we should putrootguard
on all ROOT bridge switches ports connected to other switches.. am i missing anything here?
– Satish
8 hours ago
1
You are trying to protect all the switches from getting a bad, superior BPDU from an incorrect location and electing a wrong root switch. Placing it on the root switch does not facilitate that.
– Ron Maupin♦
8 hours ago
I found one document on google and it seems they are puttingRG
on all switch path toward root rogerperkin.co.uk/spanning-tree/spanning-tree-root-guard
– Satish
8 hours ago
Look at what Cisco says about it: cisco.com/c/en/us/support/docs/lan-switching/…
– Ron Maupin♦
8 hours ago
add a comment |
1
Normally, you putrootguard
on all the switches, except the root switches. You put it on the downstream interfaces to prevent superior BPDUs from entering the switch.
– Ron Maupin♦
8 hours ago
Oh wait, really i thought we should putrootguard
on all ROOT bridge switches ports connected to other switches.. am i missing anything here?
– Satish
8 hours ago
1
You are trying to protect all the switches from getting a bad, superior BPDU from an incorrect location and electing a wrong root switch. Placing it on the root switch does not facilitate that.
– Ron Maupin♦
8 hours ago
I found one document on google and it seems they are puttingRG
on all switch path toward root rogerperkin.co.uk/spanning-tree/spanning-tree-root-guard
– Satish
8 hours ago
Look at what Cisco says about it: cisco.com/c/en/us/support/docs/lan-switching/…
– Ron Maupin♦
8 hours ago
1
1
Normally, you put
rootguard
on all the switches, except the root switches. You put it on the downstream interfaces to prevent superior BPDUs from entering the switch.– Ron Maupin♦
8 hours ago
Normally, you put
rootguard
on all the switches, except the root switches. You put it on the downstream interfaces to prevent superior BPDUs from entering the switch.– Ron Maupin♦
8 hours ago
Oh wait, really i thought we should put
rootguard
on all ROOT bridge switches ports connected to other switches.. am i missing anything here?– Satish
8 hours ago
Oh wait, really i thought we should put
rootguard
on all ROOT bridge switches ports connected to other switches.. am i missing anything here?– Satish
8 hours ago
1
1
You are trying to protect all the switches from getting a bad, superior BPDU from an incorrect location and electing a wrong root switch. Placing it on the root switch does not facilitate that.
– Ron Maupin♦
8 hours ago
You are trying to protect all the switches from getting a bad, superior BPDU from an incorrect location and electing a wrong root switch. Placing it on the root switch does not facilitate that.
– Ron Maupin♦
8 hours ago
I found one document on google and it seems they are putting
RG
on all switch path toward root rogerperkin.co.uk/spanning-tree/spanning-tree-root-guard– Satish
8 hours ago
I found one document on google and it seems they are putting
RG
on all switch path toward root rogerperkin.co.uk/spanning-tree/spanning-tree-root-guard– Satish
8 hours ago
Look at what Cisco says about it: cisco.com/c/en/us/support/docs/lan-switching/…
– Ron Maupin♦
8 hours ago
Look at what Cisco says about it: cisco.com/c/en/us/support/docs/lan-switching/…
– Ron Maupin♦
8 hours ago
add a comment |
2 Answers
2
active
oldest
votes
up vote
3
down vote
Based on the comments I think you are confused about rootguard
. You configure rootguard
on the downstream interfaces of all the switches, except the root switch. Basically, you are trying to protect the root interfaces on a switch (root switches do not have root interfaces) by preventing the other interfaces from becoming root interfaces. This will protect the topology that you have put in place. Interfaces that have portfast
and bpduguard
do not need rootguard
because they will disable if any BPDU is received on the interface.
Cisco explains it in Spanning Tree Protocol Root Guard Enhancement. Notice in the example, it tells you to configure rootguard
on the Switch C (non-root switch) interface toward Switch D.
The example in this section demonstrates how a rogue root bridge can
cause problems on the network and how root guard can help.
In Figure 1, Switches A and B comprise the core of the network,
and A is the root bridge for a VLAN. Switch C is an access layer
switch. The link between B and C is blocking on the C side. The arrows
show the flow of STP BPDUs.
Figure 1
In Figure 2, device D begins to participate in STP. For example,
software-based bridge applications are launched on PCs or other
switches that a customer connects to a service-provider network. If
the priority of bridge D is 0 or any value lower than the priority of
the root bridge, device D is elected as a root bridge for this VLAN.
If the link between device A and B is 1 gigabit and links between A
and C as well as B and C are 100 Mbps, the election of D as root
causes the Gigabit Ethernet link that connects the two core switches
to block. This block causes all the data in that VLAN to flow via a
100-Mbps link across the access layer. If more data flow via the core
in that VLAN than this link can accommodate, the drop of some frames
occurs. The frame drop leads to a performance loss or a connectivity
outage.
Figure 2
The root guard feature protects the network against such issues.
The configuration of root guard is on a per-port basis. Root guard
does not allow the port to become an STP root port, so the port is
always STP-designated. If a better BPDU arrives on this port, root
guard does not take the BPDU into account and elect a new STP root.
Instead, root guard puts the port into the root-inconsistent STP
state. You must enable root guard on all ports where the root bridge
should not appear. In a way, you can configure a perimeter around the
part of the network where the STP root is able to be located.
In Figure 2, enable root guard on the Switch C port that connects
to Switch D.
Switch C in Figure 2 blocks the port that connects to Switch D,
after the switch receives a superior BPDU. Root guard puts the port in
the root-inconsistent STP state. No traffic passes through the port in
this state. After device D ceases to send superior BPDUs, the port is
unblocked again. Via STP, the port goes from the listening state to
the learning state, and eventually transitions to the forwarding
state. Recovery is automatic; no human intervention is necessary.
This message appears after root guard blocks a port:
%SPANTREE-2-ROOTGUARDBLOCK: Port 1/1 tried to become non-designated in VLAN 77.
Moved to root-inconsistent state
Based on your answer i should removeRG
from my TOP two switch from my diagram and just keepRG
in middle layer toward access layer switches, is that right?
– Satish
4 hours ago
@RonMaupin "Basically, you are trying to protect the root interfaces on a switch (root switches do not have root interfaces) by preventing the other interfaces from becoming root interfaces" – A “root” switch shouldn’t have any root interfaces, but if it receives a superior BPDU, it will lose its root status and will develop a root port – so there are some advantage to having Root Guard configured on a root switch (for the downlinks anyway)
– Karl Billington
1 hour ago
now you guys confusing me more :) but i enjoying it.. please keep going and tell me what is the best scenario for me?
– Satish
8 mins ago
add a comment |
up vote
0
down vote
Root Guard exists to stop a rogue or misconfigured switch becoming the root bridge in a network which would cause disruption of the spanning tree topology. Usually your core switch should be root bridge. If a switch in a lower layer became root, not only would it cause a reconvergence of the STP topology (causing an outage), but it would also create an inefficient topology rooted at a lower capacity (hardware and interface bandwidth) and less connected switch. Root Guard can be configured on any port that should not become a Root Port (i.e. it should not be facing a Root or Secondary Root switch). The port can then only become a designated or blocking port.
You could potentially configure Root Guard on your downlinks (towards the access layer) on both the core layer and distribution layer switches, but consider the following:
If Root Guard is configured on the core switch only and an access layer switch generates a superior BDPU, the core switch will chop off the link to the distribution switch. This will disconnect the distribution layer switch, disconnecting ALL access layer switches connected to that distribution switch.
If Root Guard is configured on the distribution switch and the same superior BPDU is received, it will only disconnect the single access layer switch.
Configuring on both the core and distribution layer adds an extra layer of protection in case you forget to add it to one of the downlinks on the distribution layer switch, but in a correctly configured network, you should only need to configure Root Guard on the distribution layer downlinks.
I guess there is a situation where a core-core (i.e. root to secondary root) link could be severed. If Root Guard was configured on the downlinks of both core switches, the distribution layer would not be used as a path to the secondary root (Root Guard would chop it off on the secondary root). If there were any single-homed switches/hosts connected directly to the secondary core they would be disconnected from the network.
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
Based on the comments I think you are confused about rootguard
. You configure rootguard
on the downstream interfaces of all the switches, except the root switch. Basically, you are trying to protect the root interfaces on a switch (root switches do not have root interfaces) by preventing the other interfaces from becoming root interfaces. This will protect the topology that you have put in place. Interfaces that have portfast
and bpduguard
do not need rootguard
because they will disable if any BPDU is received on the interface.
Cisco explains it in Spanning Tree Protocol Root Guard Enhancement. Notice in the example, it tells you to configure rootguard
on the Switch C (non-root switch) interface toward Switch D.
The example in this section demonstrates how a rogue root bridge can
cause problems on the network and how root guard can help.
In Figure 1, Switches A and B comprise the core of the network,
and A is the root bridge for a VLAN. Switch C is an access layer
switch. The link between B and C is blocking on the C side. The arrows
show the flow of STP BPDUs.
Figure 1
In Figure 2, device D begins to participate in STP. For example,
software-based bridge applications are launched on PCs or other
switches that a customer connects to a service-provider network. If
the priority of bridge D is 0 or any value lower than the priority of
the root bridge, device D is elected as a root bridge for this VLAN.
If the link between device A and B is 1 gigabit and links between A
and C as well as B and C are 100 Mbps, the election of D as root
causes the Gigabit Ethernet link that connects the two core switches
to block. This block causes all the data in that VLAN to flow via a
100-Mbps link across the access layer. If more data flow via the core
in that VLAN than this link can accommodate, the drop of some frames
occurs. The frame drop leads to a performance loss or a connectivity
outage.
Figure 2
The root guard feature protects the network against such issues.
The configuration of root guard is on a per-port basis. Root guard
does not allow the port to become an STP root port, so the port is
always STP-designated. If a better BPDU arrives on this port, root
guard does not take the BPDU into account and elect a new STP root.
Instead, root guard puts the port into the root-inconsistent STP
state. You must enable root guard on all ports where the root bridge
should not appear. In a way, you can configure a perimeter around the
part of the network where the STP root is able to be located.
In Figure 2, enable root guard on the Switch C port that connects
to Switch D.
Switch C in Figure 2 blocks the port that connects to Switch D,
after the switch receives a superior BPDU. Root guard puts the port in
the root-inconsistent STP state. No traffic passes through the port in
this state. After device D ceases to send superior BPDUs, the port is
unblocked again. Via STP, the port goes from the listening state to
the learning state, and eventually transitions to the forwarding
state. Recovery is automatic; no human intervention is necessary.
This message appears after root guard blocks a port:
%SPANTREE-2-ROOTGUARDBLOCK: Port 1/1 tried to become non-designated in VLAN 77.
Moved to root-inconsistent state
Based on your answer i should removeRG
from my TOP two switch from my diagram and just keepRG
in middle layer toward access layer switches, is that right?
– Satish
4 hours ago
@RonMaupin "Basically, you are trying to protect the root interfaces on a switch (root switches do not have root interfaces) by preventing the other interfaces from becoming root interfaces" – A “root” switch shouldn’t have any root interfaces, but if it receives a superior BPDU, it will lose its root status and will develop a root port – so there are some advantage to having Root Guard configured on a root switch (for the downlinks anyway)
– Karl Billington
1 hour ago
now you guys confusing me more :) but i enjoying it.. please keep going and tell me what is the best scenario for me?
– Satish
8 mins ago
add a comment |
up vote
3
down vote
Based on the comments I think you are confused about rootguard
. You configure rootguard
on the downstream interfaces of all the switches, except the root switch. Basically, you are trying to protect the root interfaces on a switch (root switches do not have root interfaces) by preventing the other interfaces from becoming root interfaces. This will protect the topology that you have put in place. Interfaces that have portfast
and bpduguard
do not need rootguard
because they will disable if any BPDU is received on the interface.
Cisco explains it in Spanning Tree Protocol Root Guard Enhancement. Notice in the example, it tells you to configure rootguard
on the Switch C (non-root switch) interface toward Switch D.
The example in this section demonstrates how a rogue root bridge can
cause problems on the network and how root guard can help.
In Figure 1, Switches A and B comprise the core of the network,
and A is the root bridge for a VLAN. Switch C is an access layer
switch. The link between B and C is blocking on the C side. The arrows
show the flow of STP BPDUs.
Figure 1
In Figure 2, device D begins to participate in STP. For example,
software-based bridge applications are launched on PCs or other
switches that a customer connects to a service-provider network. If
the priority of bridge D is 0 or any value lower than the priority of
the root bridge, device D is elected as a root bridge for this VLAN.
If the link between device A and B is 1 gigabit and links between A
and C as well as B and C are 100 Mbps, the election of D as root
causes the Gigabit Ethernet link that connects the two core switches
to block. This block causes all the data in that VLAN to flow via a
100-Mbps link across the access layer. If more data flow via the core
in that VLAN than this link can accommodate, the drop of some frames
occurs. The frame drop leads to a performance loss or a connectivity
outage.
Figure 2
The root guard feature protects the network against such issues.
The configuration of root guard is on a per-port basis. Root guard
does not allow the port to become an STP root port, so the port is
always STP-designated. If a better BPDU arrives on this port, root
guard does not take the BPDU into account and elect a new STP root.
Instead, root guard puts the port into the root-inconsistent STP
state. You must enable root guard on all ports where the root bridge
should not appear. In a way, you can configure a perimeter around the
part of the network where the STP root is able to be located.
In Figure 2, enable root guard on the Switch C port that connects
to Switch D.
Switch C in Figure 2 blocks the port that connects to Switch D,
after the switch receives a superior BPDU. Root guard puts the port in
the root-inconsistent STP state. No traffic passes through the port in
this state. After device D ceases to send superior BPDUs, the port is
unblocked again. Via STP, the port goes from the listening state to
the learning state, and eventually transitions to the forwarding
state. Recovery is automatic; no human intervention is necessary.
This message appears after root guard blocks a port:
%SPANTREE-2-ROOTGUARDBLOCK: Port 1/1 tried to become non-designated in VLAN 77.
Moved to root-inconsistent state
Based on your answer i should removeRG
from my TOP two switch from my diagram and just keepRG
in middle layer toward access layer switches, is that right?
– Satish
4 hours ago
@RonMaupin "Basically, you are trying to protect the root interfaces on a switch (root switches do not have root interfaces) by preventing the other interfaces from becoming root interfaces" – A “root” switch shouldn’t have any root interfaces, but if it receives a superior BPDU, it will lose its root status and will develop a root port – so there are some advantage to having Root Guard configured on a root switch (for the downlinks anyway)
– Karl Billington
1 hour ago
now you guys confusing me more :) but i enjoying it.. please keep going and tell me what is the best scenario for me?
– Satish
8 mins ago
add a comment |
up vote
3
down vote
up vote
3
down vote
Based on the comments I think you are confused about rootguard
. You configure rootguard
on the downstream interfaces of all the switches, except the root switch. Basically, you are trying to protect the root interfaces on a switch (root switches do not have root interfaces) by preventing the other interfaces from becoming root interfaces. This will protect the topology that you have put in place. Interfaces that have portfast
and bpduguard
do not need rootguard
because they will disable if any BPDU is received on the interface.
Cisco explains it in Spanning Tree Protocol Root Guard Enhancement. Notice in the example, it tells you to configure rootguard
on the Switch C (non-root switch) interface toward Switch D.
The example in this section demonstrates how a rogue root bridge can
cause problems on the network and how root guard can help.
In Figure 1, Switches A and B comprise the core of the network,
and A is the root bridge for a VLAN. Switch C is an access layer
switch. The link between B and C is blocking on the C side. The arrows
show the flow of STP BPDUs.
Figure 1
In Figure 2, device D begins to participate in STP. For example,
software-based bridge applications are launched on PCs or other
switches that a customer connects to a service-provider network. If
the priority of bridge D is 0 or any value lower than the priority of
the root bridge, device D is elected as a root bridge for this VLAN.
If the link between device A and B is 1 gigabit and links between A
and C as well as B and C are 100 Mbps, the election of D as root
causes the Gigabit Ethernet link that connects the two core switches
to block. This block causes all the data in that VLAN to flow via a
100-Mbps link across the access layer. If more data flow via the core
in that VLAN than this link can accommodate, the drop of some frames
occurs. The frame drop leads to a performance loss or a connectivity
outage.
Figure 2
The root guard feature protects the network against such issues.
The configuration of root guard is on a per-port basis. Root guard
does not allow the port to become an STP root port, so the port is
always STP-designated. If a better BPDU arrives on this port, root
guard does not take the BPDU into account and elect a new STP root.
Instead, root guard puts the port into the root-inconsistent STP
state. You must enable root guard on all ports where the root bridge
should not appear. In a way, you can configure a perimeter around the
part of the network where the STP root is able to be located.
In Figure 2, enable root guard on the Switch C port that connects
to Switch D.
Switch C in Figure 2 blocks the port that connects to Switch D,
after the switch receives a superior BPDU. Root guard puts the port in
the root-inconsistent STP state. No traffic passes through the port in
this state. After device D ceases to send superior BPDUs, the port is
unblocked again. Via STP, the port goes from the listening state to
the learning state, and eventually transitions to the forwarding
state. Recovery is automatic; no human intervention is necessary.
This message appears after root guard blocks a port:
%SPANTREE-2-ROOTGUARDBLOCK: Port 1/1 tried to become non-designated in VLAN 77.
Moved to root-inconsistent state
Based on the comments I think you are confused about rootguard
. You configure rootguard
on the downstream interfaces of all the switches, except the root switch. Basically, you are trying to protect the root interfaces on a switch (root switches do not have root interfaces) by preventing the other interfaces from becoming root interfaces. This will protect the topology that you have put in place. Interfaces that have portfast
and bpduguard
do not need rootguard
because they will disable if any BPDU is received on the interface.
Cisco explains it in Spanning Tree Protocol Root Guard Enhancement. Notice in the example, it tells you to configure rootguard
on the Switch C (non-root switch) interface toward Switch D.
The example in this section demonstrates how a rogue root bridge can
cause problems on the network and how root guard can help.
In Figure 1, Switches A and B comprise the core of the network,
and A is the root bridge for a VLAN. Switch C is an access layer
switch. The link between B and C is blocking on the C side. The arrows
show the flow of STP BPDUs.
Figure 1
In Figure 2, device D begins to participate in STP. For example,
software-based bridge applications are launched on PCs or other
switches that a customer connects to a service-provider network. If
the priority of bridge D is 0 or any value lower than the priority of
the root bridge, device D is elected as a root bridge for this VLAN.
If the link between device A and B is 1 gigabit and links between A
and C as well as B and C are 100 Mbps, the election of D as root
causes the Gigabit Ethernet link that connects the two core switches
to block. This block causes all the data in that VLAN to flow via a
100-Mbps link across the access layer. If more data flow via the core
in that VLAN than this link can accommodate, the drop of some frames
occurs. The frame drop leads to a performance loss or a connectivity
outage.
Figure 2
The root guard feature protects the network against such issues.
The configuration of root guard is on a per-port basis. Root guard
does not allow the port to become an STP root port, so the port is
always STP-designated. If a better BPDU arrives on this port, root
guard does not take the BPDU into account and elect a new STP root.
Instead, root guard puts the port into the root-inconsistent STP
state. You must enable root guard on all ports where the root bridge
should not appear. In a way, you can configure a perimeter around the
part of the network where the STP root is able to be located.
In Figure 2, enable root guard on the Switch C port that connects
to Switch D.
Switch C in Figure 2 blocks the port that connects to Switch D,
after the switch receives a superior BPDU. Root guard puts the port in
the root-inconsistent STP state. No traffic passes through the port in
this state. After device D ceases to send superior BPDUs, the port is
unblocked again. Via STP, the port goes from the listening state to
the learning state, and eventually transitions to the forwarding
state. Recovery is automatic; no human intervention is necessary.
This message appears after root guard blocks a port:
%SPANTREE-2-ROOTGUARDBLOCK: Port 1/1 tried to become non-designated in VLAN 77.
Moved to root-inconsistent state
edited 7 hours ago
answered 7 hours ago
Ron Maupin♦
60.3k1058109
60.3k1058109
Based on your answer i should removeRG
from my TOP two switch from my diagram and just keepRG
in middle layer toward access layer switches, is that right?
– Satish
4 hours ago
@RonMaupin "Basically, you are trying to protect the root interfaces on a switch (root switches do not have root interfaces) by preventing the other interfaces from becoming root interfaces" – A “root” switch shouldn’t have any root interfaces, but if it receives a superior BPDU, it will lose its root status and will develop a root port – so there are some advantage to having Root Guard configured on a root switch (for the downlinks anyway)
– Karl Billington
1 hour ago
now you guys confusing me more :) but i enjoying it.. please keep going and tell me what is the best scenario for me?
– Satish
8 mins ago
add a comment |
Based on your answer i should removeRG
from my TOP two switch from my diagram and just keepRG
in middle layer toward access layer switches, is that right?
– Satish
4 hours ago
@RonMaupin "Basically, you are trying to protect the root interfaces on a switch (root switches do not have root interfaces) by preventing the other interfaces from becoming root interfaces" – A “root” switch shouldn’t have any root interfaces, but if it receives a superior BPDU, it will lose its root status and will develop a root port – so there are some advantage to having Root Guard configured on a root switch (for the downlinks anyway)
– Karl Billington
1 hour ago
now you guys confusing me more :) but i enjoying it.. please keep going and tell me what is the best scenario for me?
– Satish
8 mins ago
Based on your answer i should remove
RG
from my TOP two switch from my diagram and just keep RG
in middle layer toward access layer switches, is that right?– Satish
4 hours ago
Based on your answer i should remove
RG
from my TOP two switch from my diagram and just keep RG
in middle layer toward access layer switches, is that right?– Satish
4 hours ago
@RonMaupin "Basically, you are trying to protect the root interfaces on a switch (root switches do not have root interfaces) by preventing the other interfaces from becoming root interfaces" – A “root” switch shouldn’t have any root interfaces, but if it receives a superior BPDU, it will lose its root status and will develop a root port – so there are some advantage to having Root Guard configured on a root switch (for the downlinks anyway)
– Karl Billington
1 hour ago
@RonMaupin "Basically, you are trying to protect the root interfaces on a switch (root switches do not have root interfaces) by preventing the other interfaces from becoming root interfaces" – A “root” switch shouldn’t have any root interfaces, but if it receives a superior BPDU, it will lose its root status and will develop a root port – so there are some advantage to having Root Guard configured on a root switch (for the downlinks anyway)
– Karl Billington
1 hour ago
now you guys confusing me more :) but i enjoying it.. please keep going and tell me what is the best scenario for me?
– Satish
8 mins ago
now you guys confusing me more :) but i enjoying it.. please keep going and tell me what is the best scenario for me?
– Satish
8 mins ago
add a comment |
up vote
0
down vote
Root Guard exists to stop a rogue or misconfigured switch becoming the root bridge in a network which would cause disruption of the spanning tree topology. Usually your core switch should be root bridge. If a switch in a lower layer became root, not only would it cause a reconvergence of the STP topology (causing an outage), but it would also create an inefficient topology rooted at a lower capacity (hardware and interface bandwidth) and less connected switch. Root Guard can be configured on any port that should not become a Root Port (i.e. it should not be facing a Root or Secondary Root switch). The port can then only become a designated or blocking port.
You could potentially configure Root Guard on your downlinks (towards the access layer) on both the core layer and distribution layer switches, but consider the following:
If Root Guard is configured on the core switch only and an access layer switch generates a superior BDPU, the core switch will chop off the link to the distribution switch. This will disconnect the distribution layer switch, disconnecting ALL access layer switches connected to that distribution switch.
If Root Guard is configured on the distribution switch and the same superior BPDU is received, it will only disconnect the single access layer switch.
Configuring on both the core and distribution layer adds an extra layer of protection in case you forget to add it to one of the downlinks on the distribution layer switch, but in a correctly configured network, you should only need to configure Root Guard on the distribution layer downlinks.
I guess there is a situation where a core-core (i.e. root to secondary root) link could be severed. If Root Guard was configured on the downlinks of both core switches, the distribution layer would not be used as a path to the secondary root (Root Guard would chop it off on the secondary root). If there were any single-homed switches/hosts connected directly to the secondary core they would be disconnected from the network.
add a comment |
up vote
0
down vote
Root Guard exists to stop a rogue or misconfigured switch becoming the root bridge in a network which would cause disruption of the spanning tree topology. Usually your core switch should be root bridge. If a switch in a lower layer became root, not only would it cause a reconvergence of the STP topology (causing an outage), but it would also create an inefficient topology rooted at a lower capacity (hardware and interface bandwidth) and less connected switch. Root Guard can be configured on any port that should not become a Root Port (i.e. it should not be facing a Root or Secondary Root switch). The port can then only become a designated or blocking port.
You could potentially configure Root Guard on your downlinks (towards the access layer) on both the core layer and distribution layer switches, but consider the following:
If Root Guard is configured on the core switch only and an access layer switch generates a superior BDPU, the core switch will chop off the link to the distribution switch. This will disconnect the distribution layer switch, disconnecting ALL access layer switches connected to that distribution switch.
If Root Guard is configured on the distribution switch and the same superior BPDU is received, it will only disconnect the single access layer switch.
Configuring on both the core and distribution layer adds an extra layer of protection in case you forget to add it to one of the downlinks on the distribution layer switch, but in a correctly configured network, you should only need to configure Root Guard on the distribution layer downlinks.
I guess there is a situation where a core-core (i.e. root to secondary root) link could be severed. If Root Guard was configured on the downlinks of both core switches, the distribution layer would not be used as a path to the secondary root (Root Guard would chop it off on the secondary root). If there were any single-homed switches/hosts connected directly to the secondary core they would be disconnected from the network.
add a comment |
up vote
0
down vote
up vote
0
down vote
Root Guard exists to stop a rogue or misconfigured switch becoming the root bridge in a network which would cause disruption of the spanning tree topology. Usually your core switch should be root bridge. If a switch in a lower layer became root, not only would it cause a reconvergence of the STP topology (causing an outage), but it would also create an inefficient topology rooted at a lower capacity (hardware and interface bandwidth) and less connected switch. Root Guard can be configured on any port that should not become a Root Port (i.e. it should not be facing a Root or Secondary Root switch). The port can then only become a designated or blocking port.
You could potentially configure Root Guard on your downlinks (towards the access layer) on both the core layer and distribution layer switches, but consider the following:
If Root Guard is configured on the core switch only and an access layer switch generates a superior BDPU, the core switch will chop off the link to the distribution switch. This will disconnect the distribution layer switch, disconnecting ALL access layer switches connected to that distribution switch.
If Root Guard is configured on the distribution switch and the same superior BPDU is received, it will only disconnect the single access layer switch.
Configuring on both the core and distribution layer adds an extra layer of protection in case you forget to add it to one of the downlinks on the distribution layer switch, but in a correctly configured network, you should only need to configure Root Guard on the distribution layer downlinks.
I guess there is a situation where a core-core (i.e. root to secondary root) link could be severed. If Root Guard was configured on the downlinks of both core switches, the distribution layer would not be used as a path to the secondary root (Root Guard would chop it off on the secondary root). If there were any single-homed switches/hosts connected directly to the secondary core they would be disconnected from the network.
Root Guard exists to stop a rogue or misconfigured switch becoming the root bridge in a network which would cause disruption of the spanning tree topology. Usually your core switch should be root bridge. If a switch in a lower layer became root, not only would it cause a reconvergence of the STP topology (causing an outage), but it would also create an inefficient topology rooted at a lower capacity (hardware and interface bandwidth) and less connected switch. Root Guard can be configured on any port that should not become a Root Port (i.e. it should not be facing a Root or Secondary Root switch). The port can then only become a designated or blocking port.
You could potentially configure Root Guard on your downlinks (towards the access layer) on both the core layer and distribution layer switches, but consider the following:
If Root Guard is configured on the core switch only and an access layer switch generates a superior BDPU, the core switch will chop off the link to the distribution switch. This will disconnect the distribution layer switch, disconnecting ALL access layer switches connected to that distribution switch.
If Root Guard is configured on the distribution switch and the same superior BPDU is received, it will only disconnect the single access layer switch.
Configuring on both the core and distribution layer adds an extra layer of protection in case you forget to add it to one of the downlinks on the distribution layer switch, but in a correctly configured network, you should only need to configure Root Guard on the distribution layer downlinks.
I guess there is a situation where a core-core (i.e. root to secondary root) link could be severed. If Root Guard was configured on the downlinks of both core switches, the distribution layer would not be used as a path to the secondary root (Root Guard would chop it off on the secondary root). If there were any single-homed switches/hosts connected directly to the secondary core they would be disconnected from the network.
edited 1 hour ago
answered 2 hours ago
Karl Billington
4,084422
4,084422
add a comment |
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f55117%2fspanning-tree-rootguard-question-on-vpc-switches%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
1
Normally, you put
rootguard
on all the switches, except the root switches. You put it on the downstream interfaces to prevent superior BPDUs from entering the switch.– Ron Maupin♦
8 hours ago
Oh wait, really i thought we should put
rootguard
on all ROOT bridge switches ports connected to other switches.. am i missing anything here?– Satish
8 hours ago
1
You are trying to protect all the switches from getting a bad, superior BPDU from an incorrect location and electing a wrong root switch. Placing it on the root switch does not facilitate that.
– Ron Maupin♦
8 hours ago
I found one document on google and it seems they are putting
RG
on all switch path toward root rogerperkin.co.uk/spanning-tree/spanning-tree-root-guard– Satish
8 hours ago
Look at what Cisco says about it: cisco.com/c/en/us/support/docs/lan-switching/…
– Ron Maupin♦
8 hours ago