Re: STP Port Priority

From: Garth Bryden <hacked.the.planet.on.28.8k.dialup_at_gmail.com>
Date: Wed, 8 Sep 2010 15:54:08 +0800

Hi Bob,

Thanks for the assistance

"The PVST and MST BPDUs contain two bridge IDs, the BID of the root and the
BID of the sending bridge. Given equal path costs, your SW3 should choose
its root based on Sending BID, regardless of sender port ID."

I want to clarify what you mean here.

In all versions of STP apart from MST this is definately true. Octets 18
through 25 contains the senders bridge ID.

In the case of MST Octets 18 through 25 contains the Regional Root ID which
is the switch with the lowest cost the to CIST Root, as per the standard

*"Octets 18 through 25 shall take the value of the CIST Regional Root
Identifier when transmitted in RST and MST BPDUs, and the value of the CIST
Bridge Identifier of the transmitting Bridge when transmitted in STP
Configuration BPDUs. On receipt of an STP Configuration or RST BPDU, both
the CIST Regional Root Identifier and the CIST Designated Bridge Identifier
shall be decoded from this field. On receipt of an MST BPDU, the CIST
Regional Root Identifier shall be decoded from this field."*
**
Then you have these new fields in octets 94 - 101

*"Octets 94 through 101 convey the CIST Bridge Identifier of the
transmitting Bridge. The 12-bit system id extension component of the CIST
Bridge Identifier shall be transmitted as 0. The behavior on receipt is
unspecified if it is non-zero"*

Now in my understanding octets 94 - 101 do not exist in RSTP BPDU and I
believe that from this, if we were interoperating with say RPVST+
switch that had two links into two different switches in the same MST Region
that the senders bridge ID would be the same, because the standard says that
the value of the CIST Bridge Identifier when transmitted in STP
Configuration BPDU's.

I dont have a lab to test right now as they are all booked up, but then if
we went back to my original question where "what if the ports connecting to
the rpvst domain had the same port-id" what would be the tiebreaker?

I Guess first off I have to see if running RPVST+ what the senders bridge ID
will actually be in Cisco's implementation before getting to the second
part.

Cheers,

Garth
On Tue, Sep 7, 2010 at 10:38 PM, Bob Sinclair <bob_at_bobsinclair.net> wrote:

> Hi Garth,
>
> The PVST and MST BPDUs contain two bridge IDs, the BID of the root and the
> BID of the sending bridge. Given equal path costs, your SW3 should choose
> its root based on Sending BID, regardless of sender port ID.
>
> Below you see output from a CIERS2 lab I had handy. In this case SW4 is
> dual-homed to an MST region. You see the root and sender bridge IDs are
> the
> same whether SW4 is PVST or MST:
>
> SW4 in PVST mode:
>
> SW4#sh span int f0/20 det
> Port 22 (FastEthernet0/20) of VLAN0001 is blocking
> Port path cost 19, Port priority 128, Port Identifier 128.22.
> Designated root has priority 12288, address *0023.05c4.bb00*
> Designated bridge has priority 32768, address *0023.05c9.5e80*
> Designated port id is 128.22, designated path cost 0
> Timers: message age 3, forward delay 0, hold 0
> Number of transitions to forwarding state: 0
> Link type is point-to-point by default
> BPDU: sent 2, received 85
>
>
> SW4#show span int f0/21 det
> Port 23 (FastEthernet0/21) of VLAN0001 is forwarding
> Port path cost 19, Port priority 128, Port Identifier 128.23.
> Designated root has priority 12288, address *0023.05c4.bb00*
> Designated bridge has priority 12288, address *0023.05c4.bb00*
> Designated port id is 128.23, designated path cost 0
> Timers: message age 2, forward delay 0, hold 0
> Number of transitions to forwarding state: 1
> Link type is point-to-point by default
> BPDU: sent 3, received 128
>
>
> SW4 in MST mode:
>
> SW4#show span int f0/20 det
> Port 22 (FastEthernet0/20) of MST0 is alternate blocking
> Port path cost 200000, Port priority 128, Port Identifier 128.22.
> Designated root has priority 12288, address *0023.05c4.bb00*
> Designated bridge has priority 32768, address *0023.05c9.5e80*
> Designated port id is 128.22, designated path cost 0
> Timers: message age 4, forward delay 0, hold 0
> Number of transitions to forwarding state: 0
> Link type is point-to-point by default, Boundary RSTP
> BPDU: sent 2, received 10
> SW4#show span int f0/21 det
> Port 23 (FastEthernet0/21) of MST0 is root forwarding
> Port path cost 200000, Port priority 128, Port Identifier 128.23.
> Designated root has priority 12288, address *0023.05c4.bb00*
> Designated bridge has priority 12288, address *0023.05c4.bb00*
> Designated port id is 128.23, designated path cost 0
> Timers: message age 4, forward delay 0, hold 0
> Number of transitions to forwarding state: 1
> Link type is point-to-point by default, Boundary RSTP
> BPDU: sent 4, received 15
>
>
> So, if I understand you question, yes: the sending bridge puts its own ID
> in
> the BPDU, but it does not replace the root BID.
>
> HTH,
>
> Bob Sinclair CCIE 10427 CCSI 30427
> CIERS2 Online Instructor
> www.tinyurl.com/ciers2online
>
>
> > -----Original Message-----
> > From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> > Garth Bryden
> > Sent: Tuesday, September 07, 2010 5:00 AM
> > To: Cisco certification
> > Subject: Re: STP Port Priority
> >
> > I have just built a topology based on the cabling infrastructure I have
> > available to me at the moment as below.
> >
> > <SW1>----<SW3 >
> > | /
> > | /
> > | /
> > <SW2>/
> >
> > SW1 and SW2's link to SW3 is Port 16 (Both have Port ID 128.18)
> > according to
> > SW3
> >
> > SW3 link into SW 1 is Port 13
> >
> > SW3's link into SW2 is Port 16
> >
> > SW1 and SW2 are in an MSTP Region "12"
> >
> > SW1 is the CIST Root
> >
> > SW3 is running PVST+
> >
> > As you can see,from the below output the
> >
> > SW3# show spanning-tree detail
> > VLAN0001 is executing the ieee compatible Spanning Tree protocol
> > Bridge Identifier has priority 32768, sysid 1, address 0013.c419.7b80
> > Configured hello time 2, max age 20, forward delay 15
> > Current root has priority 0, address 0019.55bb.8b80
> > Root port is 13 (FastEthernet0/13), cost of root path is 19
> > Topology change flag not set, detected flag not set
> > Number of topology changes 0 last change occurred 00:00:59 ago
> > Times: hold 1, topology change 35, notification 2
> > hello 2, max age 20, forward delay 15
> > Timers: hello 0, topology change 0, notification 0, aging 300
> >
> > Port 13 (FastEthernet0/13) of VLAN0001 is root forwarding
> > Port path cost 19, Port priority 128, Port Identifier 128.13.
> > Designated root has priority 0, address 0019.55bb.8b80
> > Designated bridge has priority 0, address *0019.55bb.8b80*
> > *Designated port id is 128.18, designated path cost 0*
> > Timers: message age 2, forward delay 0, hold 0
> > Number of transitions to forwarding state: 1
> > Link type is point-to-point by default
> > BPDU: sent 3, received 28
> >
> > Port 16 (FastEthernet0/16) of VLAN0001 is alternate blocking
> > Port path cost 19, Port priority 128, Port Identifier 128.16.
> > Designated root has priority 0, address 0019.55bb.8b80
> > Designated bridge has priority 32768, address *001b.d4df.bf80*
> > *Designated port id is 128.18, designated path cost 0*
> > Timers: message age 2, forward delay 0, hold 0
> > Number of transitions to forwarding state: 0
> > Link type is point-to-point by default
> > BPDU: sent 2, received 29
> >
> > Does this mean that a when exiting a MSTP Region a switch will insert
> > its
> > own Bridge ID in place of the "CIST Regional Root ID"?
> >
> > Guess it'd make sense, there is not really any use for the CIST
> > Regional
> > Root bits in the BPDU outside a region?
> >
> > On Tue, Sep 7, 2010 at 4:41 PM, Garth Bryden <
> > hacked.the.planet.on.28.8k.dialup_at_gmail.com> wrote:
> >
> > > Hello,
> > >
> > > I'm wondering how STP works out the Port ID part of the port
> > priority...
> > >
> > > Say we have four switches
> > >
> > > <SW1>--------------- <SW3>
> > > | |
> > > | |
> > > | |
> > > | |
> > > <SW 2>---------------<SW4>
> > >
> > >
> > > Say SW1 + 2 are running MST Region name 12
> > >
> > > Say SW3 + 4 are running MST Region name 34
> > >
> > > The Intra Region Links on both switches are port fa0/1
> > > The Inter Region Links on both switches are port fa0/2
> > >
> > > The Port Costs between the regions are the same.
> > >
> > > SW1 is the CIST ROOT.
> > >
> > > Either SW3 or SW4 will elect the Boundary Root Port towards the CIST
> > Root
> > > based on the lowest cost and become the CIST Regional Root. Now from
> > what I
> > > understand that Port Cost for CIST is only cumulative between
> > boundary ports
> > > and will not be adjusted within a region. So then if SW3 and SW4 have
> > the
> > > same link costs there is going to be a tiebreaker, which would have
> > to be
> > > broken
> > > based on Bridge ID.
> > >
> > > The Bridge ID in MST being the CIST Regional Root Bridge ID (Which I
> > am
> > > assuming going off the MSTP BPDU which has the CIST Regional Root ID
> > in
> > > place of where the Bridge ID used to be)...
> > >
> > > Further down, I then see that we have the "CIST Bridge ID" it looks
> > as if
> > > these a additional fields for MST. So this would likely act as the
> > > tiebreaker for who becomes the CIST Regional Root in Region 34.
> > >
> > > Which brings me to my next question.
> > >
> > > If SW3 / SW4 was then running PVST+ it would not understand the "CIST
> > > Bridge ID" and Region 12 would look like a single Virtual Bridge.
> > This is
> > > fine, except what if then my Port Priority and Port ID's are the
> > same?
> > >
> > > What is the tiebreaker?
> > >
> > > Thanks,
> > >
> > > Garth
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
> > No virus found in this incoming message.
> > Checked by AVG - www.avg.com
> > Version: 9.0.851 / Virus Database: 271.1.1/3118 - Release Date:
> > 09/06/10 14:34:00

Blogs and organic groups at http://www.ccie.net
Received on Wed Sep 08 2010 - 15:54:08 ART

This archive was generated by hypermail 2.2.0 : Fri Oct 01 2010 - 05:58:05 ART