On a switch running Huawei VRP: What is the safest way to deconfigure a dynamic priority value on a root bridge and then configure a static priority value?

What's the problem?

I can do this:

[Switch]stp instance 0 priority 20480
[Switch]stp instance 0 root primary

But I can't do this:

[Switch]stp instance 0 root primary
[Switch]stp instance 0 priority 20480

So I have to do this:

[Switch]undo stp instance 0 root
[Switch]stp instance 0 priority 20480

In the meantime, the bridge has a priority value of 32768.

I can't assign a priority value because the command is not accepted: Error: Failed to modify priority because the switch is configured as a primary root or secondary root.

Currently, I have three options. None of them are satisfying. 1) Disconnect the bridge from the network and configure it from a terminal. 2) Decrease the priority value on every other bridge below the default value of 32768. 3) Deconfigure and reconfigure as fast as possible and hope for the best.

  • If you are using the primary or secondary keywords to set the priority, why do you then want to change the priority right away? In effect, you are setting the priority, then setting it again. The default value is 32786, and setting the priority to root sets the value below the default value, and setting the priority value to secondary sets it somewhere between the root and default values. You should not need to change the value after setting it to root.
    – Ron Maupin
    Jul 23 '16 at 20:02
  • I don't want to change it right away. It's an example of what can be done and what can't be done in VRP. It's supposed to show that those command can't be entered in any sequence. Jul 23 '16 at 20:36
  • "It's supposed to show that those command can't be entered in any sequence." OK, many network devices have commands which cannot be entered in just any sequence. Before entering a new command, it is sometimes required that you remove a previous command. There is nothing unusual about that. For instance, on a Cisco switch, you will need to remove the switchport command with no switchport before you can enter the ip address <address> <mask> command.
    – Ron Maupin
    Jul 23 '16 at 20:55
  • Changing a configuration on a network device without first understanding the current configuration can cause big problems. The behavior you describe prevents you from making a foolish mistake and possibly changing the root of the LAN by accident. You seem to get a proper message, which will lead you to the correct solution: either leave it alone, or remove the root status first.
    – Ron Maupin
    Jul 23 '16 at 21:08
  • IOS is a good example because it allows what I'm forbidded to do on VRP. I doubt that VRP has a flaw. It must be my fault, my lack of understanding. Jul 23 '16 at 21:14

When you specify the bridge as a root bridge, you are, in fact, setting the priority -- to a value lower than any other bridge.

You can't have it both ways: Either you make the bridge the root and let the switch figure out the best priority value,


if you want to set a particular priority value, then you can't say it's the root. It may end up being the root if you set the priority low enough, but that's not guaranteed.

  • I don't want to have it both ways. I want to change the current setting. VRP doesn't allow to overwrite the stp instance 0 root primary command, although it allows to overwrite the stp instance 0 priority 20480 command with stp instance 0 root primary. Jul 23 '16 at 20:30
  • Then the last example you posted is correct. Undo the root command, then set the priority.
    – Ron Trunk
    Jul 23 '16 at 20:31
  • I know that the last example is correct. However, it has a pitfall: For at least a second, the default priority value is in force. I'd like to avoid that. Jul 23 '16 at 20:33
  • Hmmm. I don't know a way around that. I suppose you could raise the priority value of the other switches so no TCNs are sent.
    – Ron Trunk
    Jul 23 '16 at 20:39
  • What problem are you trying to solve, or is this just a lab exercise?
    – Ron Trunk
    Jul 23 '16 at 20:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.