spanning tree RootGuard question on vPC switches











up vote
3
down vote

favorite
1












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


enter image description here










share|improve this question




















  • 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















up vote
3
down vote

favorite
1












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


enter image description here










share|improve this question




















  • 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













up vote
3
down vote

favorite
1









up vote
3
down vote

favorite
1






1





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


enter image description here










share|improve this question















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


enter image description here







cisco switch spanning-tree






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 8 hours ago

























asked 8 hours ago









Satish

1,3632151




1,3632151








  • 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














  • 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








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










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



enter image description here



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



enter image description here



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






share|improve this answer























  • 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












  • 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


















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.







share|improve this answer























    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',
    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
    });


    }
    });














    draft saved

    draft discarded


















    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

























    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



    enter image description here



    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



    enter image description here



    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






    share|improve this answer























    • 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












    • 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















    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



    enter image description here



    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



    enter image description here



    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






    share|improve this answer























    • 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












    • 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













    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



    enter image description here



    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



    enter image description here



    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






    share|improve this answer














    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



    enter image description here



    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



    enter image description here



    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







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 7 hours ago

























    answered 7 hours ago









    Ron Maupin

    60.3k1058109




    60.3k1058109












    • 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












    • 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










    • @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










    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.







    share|improve this answer



























      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.







      share|improve this answer

























        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.







        share|improve this answer














        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.








        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 1 hour ago

























        answered 2 hours ago









        Karl Billington

        4,084422




        4,084422






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            Eastern Orthodox Church

            Understanding the information contained in the Deep Space Network XML data?

            Zagreb