×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

RPVST+ on Trunk interface

Answered Question
Aug 29th, 2012
User Badges:

Hi all,

I've some questions about RPVST+ BPDU on trunk interface on Cisco swicth (catalyst3560G),

regarding to this document:

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00801d11a0.shtml#topic1


This list shows how PVST+ interoperates with IEEE 802.1Q or IEEE 802.1D, if the Native VLAN on an IEEE 802.1Q trunk is VLAN 1:

  • VLAN 1 STP BPDUs are sent to the IEEE STP MAC address (0180.c200.0000), untagged.
  • VLAN 1 STP BPDUs are also sent to the PVST+ MAC address, untagged.
  • Non-VLAN 1 STP BPDUs are sent to the PVST+ MAC address (also called the Shared Spanning Tree Protocol [SSTP] MAC address, 0100.0ccc.cccd), tagged with a corresponding IEEE 802.1Q VLAN tag.


and explanation by Peter Paluch ( https://supportforums.cisco.com/thread/2100370 )

In short, a trunk always sends a combination of standard and (R)PVST BPDUs:

  • A standard IEEE BPDU for VLAN1 is sent untagged to the IEEE STP address
  • (R)PVST+ BPDUs for all allowed VLANs are sent to the PVST address, tagged as appropriate (all BPDUs will be tagged except the BPDU for the native VLAN on the trunk)


I connect Catalyst with non-Cisco L2 switch (RSTP enabled) over trunk and capture packets from Cisco (via Gi0/3), and I dont see any IEEE STP BPDU from Cisco (only PVST+ BPDU):


Catalyst config:



interface GigabitEthernet0/1

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1010

switchport mode trunk

switchport nonegotiate

end




Switch#sh int sw

Name: Gi0/1

Switchport: Enabled

Administrative Mode: trunk

Operational Mode: trunk

Administrative Trunking Encapsulation: dot1q

Operational Trunking Encapsulation: dot1q

Negotiation of Trunking: Off

Access Mode VLAN: 1 (default)

Trunking Native Mode VLAN: 1 (default)


Switch#show monitor session 1

Session 1

---------

Type                   : Local Session

Source Ports           :

    Both               : Gi0/1

Destination Ports      : Gi0/3

    Encapsulation      : Replicate

          Ingress      : Disabled


Screenshot.png


so my question - why cisco sends only PVST+ BPDU out gi0/1?

Correct Answer by Peter Paluch about 4 years 11 months ago

Hi Maxim,


so my question - why cisco sends only PVST+ BPDU out gi0/1?


This is because Cisco's PVST+ implementation interoperates with pure 802.1D/802.1w switches using VLAN1 exclusively, and you have not allowed the VLAN1 on your Gi0/1 trunk. Try modifying the switchport trunk allowed vlan command on your Gi0/1 port so that it includes VLAN1, and then try capturing the traffic again.


Best regards,

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (5 ratings)
Loading.
Correct Answer
Peter Paluch Wed, 08/29/2012 - 01:31
User Badges:
  • Cisco Employee,

Hi Maxim,


so my question - why cisco sends only PVST+ BPDU out gi0/1?


This is because Cisco's PVST+ implementation interoperates with pure 802.1D/802.1w switches using VLAN1 exclusively, and you have not allowed the VLAN1 on your Gi0/1 trunk. Try modifying the switchport trunk allowed vlan command on your Gi0/1 port so that it includes VLAN1, and then try capturing the traffic again.


Best regards,

Peter

maxim.alyakin Wed, 08/29/2012 - 01:57
User Badges:

Hi, Peter

many thanks for reply, I thought what

Trunking Native Mode VLAN: 1 (default)

also allowed vlan 1 on trunk interface,

so after

switchport trunk allowed vlan add 1

on Gi0/1 interface I see both PVST+ and original IEEE BPDU and all ports roles became correctly according to bridges priority, but BPDU from non-Cisco switch are dissapeared. As I know, In RSTP all bridges are send BPDU every 2sec (hello interval).

I cant explain this behavior Any idea?

Peter Paluch Wed, 08/29/2012 - 02:20
User Badges:
  • Cisco Employee,

Hi Maxim,


on Gi0/1 interface I see both PVST+ and  original IEEE BPDU and all ports roles became correctly according to  bridges priority, but BPDU from non-Cisco switch are dissapeared. As I  know, In RSTP all bridges are send BPDU every 2sec (hello interval).


In 802.1D STP, only the root bridge originates BPDUs and sends them out all Designated ports. Other switches receive these BPDUs, modify them and relay them further. Non-root switches are not allowed to originate BPDUs themselves. They only modify BPDUs received on their Root ports and send them further out their own Designated ports. If the root bridge died in a way that no port would go down but just the STP BPDUs stopped being originated, there would be no BPDUs sent in the entire switched topology for max_age seconds.


Note that neither Root nor Non-Designated ports in 802.1D STP send BPDUs.


In 802.1w RSTP, each switch is allowed to continue sending BPDUs according to the BPDU stored on their Root port, regardless of whether the BPDU recently arrived or not (the timeout for this continuation is 3x Hello timer, after which the BPDU stored on the Root port expires). This means that even if no BPDUs are recei ved on the Root port of a non-root switch, it will still send its own BPDUs each Hello seconds as if the BPDU arrived on the Root port. This allows the BPDUs to be used as a simplified Hello mechanism: because each switch is allowed to continue sending its own BPDUs even if it does not receive any BPDUs on its own Root port, a missing BPDU precisely indicates that the failure is on the direct link between the two switches.


The fact that RSTP switches are allowed to continue sending BPDUs does not influence which ports are allowed to send BPDUs. Even in RSTP, ports that are Alternate, Backup or Root ports do not send BPDUs.


I believe this is what you experienced here: the Cisco became the root switch, the non-Cisco has a Root port towards the Cisco switch, so it stopped sending its own BPDUs from its Root port.


Best regards,

Peter

maxim.alyakin Wed, 08/29/2012 - 03:31
User Badges:

Peter, many thanks for so detailed explanation! 


Best regards, Maxim.

Sherif Atef Ahm... Tue, 04/09/2013 - 16:39
User Badges:

Dear Peter/Maxim

This is something new to me   .. I always thought native vlan is allowed by default on trunk 


One more question please regarding same topic

On Cisco side, If native vlan was for example 600 and both vlans (600 & 1010) were allowed on trunk

1- Then everything should work fine cause Cisco would send IEEE standard BPDU for VLAN 1 spanning instance on the native vlan 600 , correct ?

2- Now what If no interfaces were defined for vlan 1 on cisco switch , i.e. no spanning instace for vlan 1 as normally vlan 1 in live networks is not used due to security reasons .. what would be the case ?

Many Thanks


Regards,

Sherif Ismail      

Actions

This Discussion

Related Content