R-PVST is ignoring port-priority

I am not understanding why RPVST is ignoring the port-priority that I hard coded to the switchport - see below

As you can see in the screenie, F0/11 has a lower priority and it should become root port of "evo" in vlan 1. It never does become root until all ports(segments) shuts off except f0/11. All ports are connected to the same switch so they have the same root cost as well as BID. Priority should have been the next tie breaker?

Find more posts tagged with

Comments

CCIE Wanna Be

I'm learning this too, but since they are all connected to the same switch isn't it going to use the lowest interface id of the sending port from the root bridge before it uses the lowest receive port value on the non-root bridge. so if F 0/9 is connected to a lower port on the root, then it will be chosen even though F0/11 has a lower priority.

Total guess, hope I'm close.

streetking

According to the Odom book, interface ID/Nbr is the last to be considered.

The order of tie breakers to be considered would be cost>BID>priority>internal port number

Connected to the same switch would make the switch to receive BPDUs with the same root cost to both ports. BID would fail to be the tie breaker as it's the same BID on both BPDUs on received on both ports. Odom mentioned that most of the time people don't change the default port-priority on the physical interface, hence the switch would resort to internal port number to determine the root port.

In this case, the priority was manually changed to be lower than default on int f 0/11, hence it's better and supposed to be the RP - BUT IT DIDN'T! WHY? DID I MISUNDERSTAND?

CCIE Wanna Be wrote: »

I'm learning this too, but since they are all connected to the same switch isn't it going to use the lowest interface id of the sending port from the root bridge before it uses the lowest receive port value on the non-root bridge. so if F 0/9 is connected to a lower port on the root, then it will be chosen even though F0/11 has a lower priority.

Total guess, hope I'm close.

DCD

Add the root bridge information.

CCIE Wanna Be

I am looking at it from the perspective of the root bridge to the non-root bridge. What interface on the root bridge is each port connected to.

Experiment: Change the priority of the port on the root bridge connected to f 0/11 and see if it f 0/11 becomes root port after the change, if it does, my guess is that the tie-breakers are based off the values coming from the root bridge (the key term here is received),

i.e if you left the port priority 128 on the root bridge, it would choose the lowest interface id coming off the root bridge, so which ever port is associated with that port on your non-root bridge becomes the root port on the non- root bridge.

I think!, not 100% though

EdTheLad

The output you have show i.e. "show span vlan 1" shows the locally configured priority of the interface. This priority will be added to bpdu's that are egress to this interface, so it will affect the remote switch. If you want to influence the election of the local switch you need to change the port priority on the remote switch.

streetking

That was it. I missed the point that all port cost and tie breakers are determined by the parameters in the BPDU received from the remote switch -

I just changed the port-priority on the remote switch and viola! The root port switched immediately. Kinda like how preempt is configured on the FHRP backups.