SW4 should never be root bridge

2»

Comments

  • understood. but what if task says,

    " make sure SW4 BECOME root for ALL VLAN without changing ANY switch priority"? what are the valid options?

    Default Bridge ID = Bridge Priority + VLAN + Base ethernet MAC Address (you can find the Base ethernet MAC in the output of "sho ver | inc MAC".  If all four switches have the same default Bridge Priority + VLAN, then the lower MAC address wins.  Some older fixed config switches let you change the Base ethernet MAC address in the bootrom, but I don't think you can with the 3560.

  • Yeah, I think we need to be addressing this as if it were a 3560 with current IOS version for the lab. Anything other than that would be symantecs and useless for study purposes. Getting into the "What If's" is great for playing around or trying to drum up a new idea on how to do/not do something. But if it absolutely does not equate to the lab exam I don't think the guy really cares. Though in a pinch and  the right circumstances absolutely handy to have in the back pocket.

    But for here I think he's trying to find a way to either create SW4 as root without changing priorities and maintane that ROOT status. Or remove SW4 from root without changing priorities and maintain root on other devices. Which is why I said we really need to clarify what the requirements really are for this situation.

    :)

     

    Edit: Note I wasn't trying to be pissy here. Just trying to say I don't think he wants anything that wouldn't happen in a lab. Or perhaps I was being pissy and didn't know it??? :)

  • Edit: Note I wasn't trying to be pissy here. Just trying to say I don't think he wants anything that wouldn't happen in a lab. Or perhaps I was being pissy and didn't know it??? :)

    Nope not at all, I think you posted your reply while I was researching and typing mine out.

  • Back to the initial question which is not wanting SW4 to be the root..

     

    "When UplinkFast is enabled, the bridge priority of all VLANs is set to 49152, and the path cost of all ports and VLAN trunks is increased by 3000. This change reduces the chance that the switch will become the root port. When UplinkFast is disabled, the bridge priorities of all VLANs and path costs of all ports are set to default values."

    http://www.cisco.com/en/US/docs/switches/lan/catalyst2900xl_3500xl/release12.0_5_xp/eeswcfg/masctrnk.html

     

    Having said that, since uplinkfast will set the priority to 49152. does this mean that we have changed the priority, which we are not allowed to do as per the task?

     

    If so, then we are only left with the option of root guard right?

  • could be wrong on this but I don't think the UplinkFast feature is correct. Although you point out the Cisco reference, doesn't the reference refer to as "port priority" and not the over-all bridge priority? If that is the case (which I believe is the case), then this feature will not meet the requirements stated byt he original poster.

    i believe only valid solution is change the priority on any switch EXCEPT sw4 and then enable root guard. If in doubt, lab it up and create a new vlan on sw4 and no where else and you will likley see that sw4 is the root bridge. this is assuming that you did not enable any commands like spanning-tree vlan 1-4094 root primary or by using the previous command using the priority keyword.



  • could be wrong on this but I don't think the UplinkFast feature is correct. Although you point out the Cisco reference, doesn't the reference refer to as "port priority" and not the over-all bridge priority? If that is the case (which I believe is the case), then this feature will not meet the requirements stated byt he original poster.

    i believe only valid solution is change the priority on any switch EXCEPT sw4 and then enable root guard. If in doubt, lab it up and create a new vlan on sw4 and no where else and you will likley see that sw4 is the root bridge. this is assuming that you did not enable any commands like spanning-tree vlan 1-4094 root primary or by using the previous command using the priority keyword.

     

    I'm in complete agreement with Sage here. You can beat this up any two ways to sunday. But STP only functions one way. You're either manually changing priority somewhere, or using a script/cisco developed tool to do it for you. Either way values are getting changed. UplinkFast in all my studies has never functioned as a priority value changing tool.Check this out for a better description of uplinkfast: http://cisco.biz/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094641.shtml

     

  • I think the above is a good solution, But I think it should not enable on to link to SW3 as the question was only about SW4 not become root.

     -Make SW1 and Primary

     -Make SW2 as secondary.

     -Enable root guard on the ports of SW1,SW2,SW3 to the link to SW4.

  • I was talking about this solution.

    Hi,

    First configure SW1 to be the root and SW2 to become backup root (secondary):

    SW1:

    SW1#conf ter

    SW1(config)#spanning-tree vlan 1-1005 root primary

    SW2:

    SW2#conf ter

    SW2(config)#spanning-tree vlan 1-1005 root secondary

    Second make sure that SW4,SW3,SW2 agree on SW1 becoming the root by:

    1st: check tha BID of SW1:

    SW1:

    SW1#show spanning-tree root

    2nd: go to SW2,SW3,SW4 and check that SW1 is the root for all vlan:

    SW2,SW3,SW4

    SW2,3,4#show spanning-tree root

    3rd: go to SW1,SW2 and configure root guard on the ports connected to SW3,SW4 :

    SW1,SW2:

    conf ter

    inter range fa(link to SW3)

    spanning-tree guard root

    ! you should see this msg: 

    %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port
        FastEthernet?? on VLAN0001

    exit

    inter range fa(link to SW4)

     spanning-tree guard root

    ! you should see this msg: 

    %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port
        FastEthernet?? on VLAN0001

    exit

    Test it by lowering SW4 priority, what would happen is somthing like this on either SW1 or SW2:

    %SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port
        FastEthernet?? on VLAN0001.

    Here is the Link, hope you find it usefull.

     

    http://www.informit.com/library/content.aspx?b=CCNP_Studies_Switching&seqNum=35

     

     

  • I checked in my lab and UPlinkfast does change the priority.

    I think we are on a point where we need to ask proctor.

    1) are we allowed to change the priority on other switches ?

    Yes/No

    2) on Switch 4 am I allowed to use UPLINK fast which will change the priority ?

    Yes/No

  • Just thinking outside of the box here:

    Go to the oldest switch in the topology - as we are talking about the strictest sense here. Not changing the priority on ANY switch (no utilisation of UPLINKFAST, root primary, root secondary, etc as they all indirectly change the switch priority). The oldest switch should theoretically have the lowest MAC address, right? So let's say that is SW1

    SW1(config)#hostname SW4

    [:D]

     

  • There is some STP command to filter BPDUs on intreface level

  • Enabling BPDUFilter stops the sending and receiving of all BPDUs on a port.  Regardless if you enable BPDUFilter on the Sw4 facing interfaces on Sw1, Sw2, and Sw3, or on the Sw1 - 3 facing interfaces of Sw4, then Sw4 will not receive any BPDUs and declare itself root (so now you have two root switches), which violates the original requirement (that Sw4 not become the root of any VLAN).

  • Enabling BPDUFilter stops the sending and receiving of all BPDUs on a port

    That's not quite true. If BPDU filter is enabled globally it applies to all portfast enabled ports. If that port then recieves a BPDU it doesn't stop the sending and receipt of BPDU's, it just takes that particular port out of portfast state so that BPDUs can be received on that port.

  • The global command spanning-tree portfast bpdufilter default does not apply to trunk ports even if spanning-tree portfast trunk is enabled on the port, so the global command doesn't apply in this situation.  The interface command would have to be applied.

     

     

  • quick observation, if uplinkfast is chosen as the method to prevent SW4 from becoming root, if you are running in SPT Rapid-PVST, uplinkfast is not enabled. Per the cisco document. can any experts comment on this quote from the switching guide?

    "You can configure the UplinkFast or the CSUF feature for rapid PVST+ or for the MSTP, but the feature remains disabled (inactive) until you change the spanning-tree mode to PVST+.

     

    further reading, the document states

    When UplinkFast is enabled, the switch priority of all VLANs is set to 49152. If you change the path cost to a value less than 3000 and you enable UplinkFast or UplinkFast is already enabled, the path cost of all interfaces and VLAN trunks is increased by 3000 (if you change the path cost to 3000 or above, the path cost is not altered). The changes to the switch priority and the path cost reduce the chance that a switch will become the root switch.

    so i can see how may of you might think this solution would in fact be a good choice. technically, we wouldn't be changing the siwtch priority with the spanning-tree vlan x root or spanning-tree vlan x priority command. using the uplinkfast command does however change the switch prioriy.

    in real lab, wud cisco be so devious to have us enable a spanning-tree feature that wasn't technically compatible with a certain mode such as rapid PVST?

  • in real lab, wud cisco be so devious to have us enable a spanning-tree feature that wasn't technically compatible with a certain mode such as rapid PVST?

    That's the million dollar question for the proctor -- can you indirectly change the priority of the switch?  If yes, Uplinkfast it is the way to go.  If not, seems like Root Guard is the solution.

  • Wow what a thread. I've recently become interested in this kind of task myself.

    Assuming "SW4 should never become root for any vlan", but that we have to run RSTP+ on all switches and that you shouldn't change the priority on SW4.


    • Uplinkfast changes the priority of SW4, albeit indirectly. This breaks requirements
    • Rootguard ensures the other switches don't see SW4 as root - but SW4 still sees itself as root. This breaks requirements.
    • Disabling STP altogether breaks the requirement that RSTP+ runs
    • Assuming the "don't change priority" applied only to SW4, we could drop the priority on all the other switches. However if SW4 becomes isolated, it'll be the root of it's own little network.
    To be honest, I think the wording of the task means that technically it is impossible. There is no way to ensure that SW4 does not become root if it is isolated AND keep running RSTP+ on it. I think the problem here is the wording, something in it is technically incorrect. You just have to bet on what part it is. The changing of priority (as opposed to changing priority directly) or perhaps the "never" becoming root (as opposed to never being considered root by the network).


    Place your bets now...


  • See beefhead that is exactly what I was saying. More clarification on what the wording actually is over all. I like your comment. 

  • Thanks Schoutentl

    I think it's very important to pose the correct questions to the proctor. I'd recommend carefully thinking over what you want to ask such that it's clear you have issues with the wording rather than a technology weakness.

    I guess if this WERE to come up in the lab, the poignant questions to ask the proctor would be:


    • Do you require SW4 to never consider itself a root, or just that the other switches never consider it a root?
    • Am I to ensure the priority never changes on SW4 or am I allowed to change it implicitly if I avoid the SPANN...PRIORITY command?
    If he confirmed the first part of that, then you'd have to remove STP. There's no way you could run STP on SW4 and have it never become root if isolated from the rest of the network. This would also answer the second question.


    If he confirmed the latter, then I'd say stick root-guard against anything connecting to the switch - and use SHOW SPAN to ensure you are sticking it on the actual interfaces running STP (etherchannel for example).


  • "Beef"

     

    We cannot thank you enough for your contributions to the IEOC! You can always tell when someone is about to achieve their digits, and I can "see" yours already. 

    Here are some tips I composed about dealing with the proctors - I look forward to your feedback!

     

    http://blog.ine.com/tag/proctor/

  • Hey Anthony,

    IEOC is my new day job for the time being, until I get my digits. Could be a while... :)

    What an awesome resource to have though. I think without IEOC (or dare I say INE) the CCIE numbers would be considerably lower than what they are today.

    Thanks to you and your whole team for such great material.

  • Just a thought..

    If we disable extend system-id

    no spanning-tree extend system-id on the other switches...SW4 ID would always be higher.

    Can we do this?

    will this prevent SW4 from becoming root?

  • I don't even care if this doesn't work, that's some great outside of the box thinking right there! Good work i3isking.

  • 3550 no go.

    Rack1SW3(config)#no spanning-tree extend system-id
    % Command "no spanning-tree extend system-id <cr>" was not accepted.
      This platform requires that the extended system-id feature remain enabled.

    Executes on 3560 with no error but does not disable.

     

  • The question should be like this:

    SWX should not become root for any vlan.  "not root bridge"

    then you simply use guardroot on other switches.

     

  • can we use a vlan filter or L2 protocol tunnelling to achieve this???

Sign In or Register to comment.