CDP and Native VLANs

[ipcruiser81]

Hi Folks,

With reference to:

https://supportforums.cisco.com/docs/DOC-2157#comment-20369

Question, lets say two switchs are interlinked via access ports each  configured for a different VLAN and similarly, two switch trunk  interlinked with different native VLANs on either end. In both cases if  CDP is disabled, you shouldnt be seeing native VLAN mismatch correct,  since it is CDPv2 that carries native VLAN information? There shouldn't  be connectivity issues either in these cases since native VLANs and  access port VLANs only have local significance as a catch all for  untagged traffic.Am I on the right page here? Thanks!

Rgds

[Peter Paluch · Accepted solution]

Hi,

The situation is slightly more complex.

CDP is definitely one of the protocols that carries information about the native VLAN of a port, so if two ports do not match in their native VLAN setting and CDP is running, you will be getting warnings about native VLAN mismatch. This will happen both on access ports and on trunks. If you deactivate CDP, you will also deactivate the native VLAN mismatch detection mechanism provided by CDP.

However, Cisco's STP implementation, the PVST+ or PVRST+, uses a slightly extended BPDU format on trunks. Each PVST+ BPDU has a special record at its very end in which the originating VLAN of this BPDU is recorded. A receiving switch will compare this record from the BPDU with the VLAN in which the BPDU was received. If these two VLANs do not match then it means that the BPDU was originated in a different VLAN and was received in a different VLAN which is a typical sign of native VLAN mismatch.STP will react by blocking the trunk port for both its own local VLAN and the neigbhor's VLAN that was indicated in the BPDU. In this case, the connectivity in these two VLANs will be prohibited on this trunk to prevent possible switching loops. In STP, this is called PVID Inconsistency, and correspondingly, the port is put into PVID_Inconsistent state.

This check is not performed on access ports - on those, Cisco uses standard STP/RSTP.

So deactivating CDP will prevent it from detecting a native VLAN mismatch via CDP. Note that CDP never causes ports to become blocking - it always only reports its findings but never takes any action.

On trunk ports in particular, Cisco's PVST+ and PVRST+ perform its own native VLAN check, so even with CDP turned off, you can still detect native VLAN mismatch. Also, contrary to CDP, PVST+/PVRST+ will cause the trunk port to become blocking for the offending (mismatched) pair of VLANs. This check is not performed on access ports.

Feel welcome to ask further!

Best regards,

Peter

[Rolf Fischer]

Hello Peter,

Each PVST+ BPDU has a special record at its very end in which the originating VLAN of this BPDU is recorded.

I wonder  about that special record you mentioned.

Speaking about the two untagged BPDUs transmitted by a trunk port (IEEE and PVST+), I know there are some differences (the destination mac address and LLC organizational code / PID) but I always thought that the frame format is the same.

I think the PVID inconsistency detection is done by comparing the BID (extended system ID or MAC address) of the several STP instances because they have to be different for every VLAN.

... actually I'm not sure how it's detected.

Am I wrong? And if so, could you please give some more information about the special record (you're not refering to MST M-Records, do you?) ?

Thanks,

Rolf

[Rolf Fischer]

.. actually I'm not sure how it's detected.

Seems like my first tought wasn't that bad.

Unfortunately I've only gns3 for testing at the moment but it looks like changing the native VLAN doesn't change the untagged IEEE BPDU, it's RID and BID still belong to the VLAN 1 instance.

In contrast, the untagged PVST+ BPDU belongs to the native VLAN (not VLAN 1) - like expected.

And we have a tagged PVST+ BPDU for VLAN 1.

I think this is how the PVID inconsistency is detected.

Best regards

Rolf

[Peter Paluch]

Hello Rolf,

Speaking about the two untagged BPDUs transmitted by a trunk port (IEEE  and PVST+), I know there are some differences (the destination mac  address and LLC organizational code / PID) but I always thought that the  frame format is the same.

It is actually "appended to". Yes, the MAC addressing is different and the BPDU is SNAP-encapsulated instead of just plain LLC, but the BPDU format in PVST+ is absolutely identical to the IEEE BPDU, just at the very end of the BPDU there is a TLV comprising the following fields:

• 1 byte padding, always set 0x00, present only in PVST+ BPDUs, not in PVRST+ BPDUs
• 2 bytes - type (currently only the type 0x0000 is recognized meaning that the value will hold the VLAN number in which this BPDU was originated)
• 2 byte - length of the value field (for type 0, the length is indicated as 0x0002)
• variable length - value (for type 0, the VLAN number in which the BPDU was originated)

Read more about it here:

http://puck.nether.net/pipermail/cisco-nsp/2004-March/009079.html

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00801d11a0.shtml#topic2 (search for "TLV" in this document - there is just a single instance of it, almost an off-hand remark)

Wireshark does not currently show this field in its dissection pane, although when you capture and watch closely the PVST+ BPDUs in the hexa dump pane, you can see at their very end that there are some non-dissected bytes which clearly are not null. You can easily recognize the value there. Wireshark developers seem to be actually aware of this, just the Wireshark has not been yet extended. Perhaps when I'll have more time, I'll write an extension for this and submit it to Wireshark developers.

http://wiki.wireshark.org/STP

I have attached a Wireshark capture for you here - observe the BPDUs. One BPDU is always sent in IEEE format, is derived from VLAN1 and serves for interoperation with IEEE STP region if there is any. Apart from them, 5 PVST+ VLANs are sent each 2 seconds, appropriately tagged (VLAN1 PVST+ BPDU is not tagged as I have left the native VLAN on 1; other BPDUs are tagged). Each of these PVST+ BPDUs, however, carries the TLV at its very end.

I think the PVID  inconsistency detection is done by comparing the BID (extended system ID  or MAC address) of the several STP instances because they have to be  different for every VLAN.

This would not work. You have no guarantee that the sender is using Extended System ID, and even if it is, you can not be sure what kind information it has stored in that field.

The native VLAN mismatch detection in PV(R)ST+ is somewhat convoluted - please feel welcome to ask further!

Best regards,

Peter

[Rolf Fischer]

Hello Peter,

thank you very much for this interesting information, so far I didn't know about those TLVs!

That's what I like most on CSV: Each time I learn something new.

Wireshark does not currently show this field in its dissection pane, although when you capture and watch closely the PVST+ BPDUs in the hexa dump pane, you can see at their very end that there are some non-dissected bytes which clearly are not null.

This is important to know.

Instead of reading the details in "Tshoot STPPVID- and Type-Inconsistencies", I relied to much in what I saw in Wireshark captures.

This would not work. You have no guarantee that the sender is using Extended System ID, ...

True, but in this case the MAC addresses should give similar information.

... , and even if it is, you can not be sure what kind information it has stored in that field.

Very good point! Fortunately I'm not a protocol designer ;-)

Thanks again,

Rolf

[Peter Paluch]

Hello Rolf,

You are heartily welcome.

Instead of reading the details in "Tshoot STPPVID- and  Type-Inconsistencies", I relied to much in what I saw in Wireshark  captures.

I suggest combining the approaches. Some things can be derived from what you see in Wireshark, but even the Wireshark does not know or implement all the existing protocols - and second, there is a certain logic behind these inconsistencies, and it is always good to know what actually causes an inconsistency check to trip. For example, LOOP_Inconsistent state is triggered by sudden loss of incoming BPDUs - in fact there's nothing to see in Wireshark about this

This would not work. You have no guarantee that the sender is using Extended System ID, ...
True, but in this case the MAC addresses should give similar information.

Use MAC addresses to detect native VLAN mismatch? I do not see how. MAC address fields do not change upon tagging or untagging a frame; all PVST+ BPDUs are sourced from the same MAC address and are addressed to the same multicast MAC group - there is nothing different in MAC addressing between PVST+ BPDU for arbitrary VLANs X and Y.

The motivation behind Cisco's PVST+ native VLAN mismatch detection is that they actually use a field inside (or after) the BPDU to store the originating VLAN information that is not modified by any tagging, untagging or forwarding operation. If something wicked happens during tagging and untagging, you may end up receiving the BPDU in a different VLAN than its original VLAN - but because the BPDU contents are not modified, the TLV itself is kept constant and carries the true originating VLAN that can be used to check for these mismatches.

Best regards,

Peter

[Rolf Fischer]

Hello Peter,

Use MAC addresses to detect native VLAN mismatch? I do not see how.

I mean the MAC address as part of the Bridge ID if the extended system ID is not used.

Every ST instance has to have a distinct BID or am I mixing up something?

Nevertheless, you've totally convinced me that an additional field is needed to detect a PVID inconsistency.

Best regards

Rolf

[Aninda Chatterjee]

This is a very interesting converstaion. I would like to add a few points here and I hope I am not intruding.

As Peter had already stated, with per-VLAN spanning-tree flavors, you can have IEEE and/or SSTP BPDUs. IEEE BPDUs look something like this:

SSTP BPDUs look something like this:

As you can see, IEEE BPDUs contain no VLAN information. They are sent out of access ports where there is no requirement for tagging. IEEE BPDUs are also sent out of trunk ports only when the BPDU being generated is for VLAN 1 (this of course is followed by a SSTP BPDU for VLAN 1 as well).

SSTP BPDUs are sent out of trunk interfaces. When a BPDU is required to be generated, the first check that is done is to check whether the port is an access port or a trunk port. If it is an access port, an IEEE BPDU is sent out and that's it.

If the interface is a trunk interface, we then check which VLAN the BPDU is being generated for. If it is for VLAN 1, an IEEE BPDU is sent out which is then followed by a SSTP BPDU. If the VLAN is anything other than VLAN 1, only a SSTP BPDU is sent out.

When a SSTP BPDU needs to be generated, we do an additional check: we compare the native VLAN configured on the interface to the VLAN that the BPDU is being generated for. If they match, the SSTP BPDU is sent untagged. If they do not match, a 802.1Q header is added (which I have not shown in my SSTP BPDU diagram) just after the length. This header will contain the VLAN. However, tagged or untagged, a SSTP BPDU will always contain the VLAN for which the BPDU is being generated for within the VLAN ID field of the TLV (which is added at the end).

The mismatch is of course detected based on how spaning-tree processes BPDUs. The first check is again to check whether the interface receiving the BPDU is an access or a trunk interface. If it is an access interface, it should never be receiving SSTP BPDUs and if it does, we put it in a 'port inconsistent' state. If the BPDU received is an IEEE BPDU, we process it for whatever VLAN is locally configured on the receiving interface.

Things get more interesting on a trunking interface. The first check we do is if the BPDU received is an IEEE BPDU or a SSTP BPDU. If it is an IEEE BPDU, we process it for VLAN 1 and drop the subsequent SSTP BPDU for VLAN 1. If the BPDU received is a SSTP BPDU (for a VLAN other than VLAN 1), we do a very critical check: we check the VLAN that is present in the 802.1Q header with the VLAN present in the TLV - this is of course in the case of a tagged BPDU. In the case of an untagged BPDU, we compare the native VLAN configured on the receving port with the VLAN present in the TLV. This is where the native VLAN mismatch is finally detected.

As an example, let's say we had a switch to switch trunk link allowing VLANs 1, 10 and 20 on both sides. VLAN 10 is the native VLAN on one side and VLAN 20 on the other. SW1 will be sending an untagged SSTP BPDU for VLAN 10 to SW2 and when SW2 gets this, it compares its native VLAN with the VLAN that is present in the TLV. This would lead to a comparison of the values 10 and 20 which are not equal. The receiving switch then puts the spanning-tree instances for BOTH VLAN 10 and VLAN 20 in a broken state declaring them as PVID inconsistent.

I hope this was not too long and was a little useful.

Regards,

Aninda

Message was edited by: Aninda Chatterjee

[Peter Paluch]

Hello Aninda,

Thanks for joining in! You are heartily welcome. After all, you have the authoritative source of information

If I was to summarize the detailed information you gave us, it would be as follows:

When sending BPDUs, access ports send only IEEE BPDUs relevant to their access VLAN. Trunk ports always send a set of BPDUs:

• IEEE-formatted BPDU for VLAN1, always untagged
• PVST+ BPDUs (also called SSTP BPDUs) for all existing and allowed VLANs including VLAN1, tagged accordingly to the native VLAN of the trunk, i.e. BPDUs for the native VLAN won't be tagged, all others will. Each of these PVST+ BPDUs carries the PVID TLV

When processing received BPDUs, an access port must receive only IEEE BPDUs, otherwise a Type_Inconsistent state is declared. These IEEE BPDUs will be processed by the STP instance for the access VLAN of the port. On trunk ports, the processing is a little more complex:

• IEEE-formatted BPDU will be immediately processed by the VLAN1 STP instance
• PVST+ BPDUs are processed according to this sequence of steps:
  • Assign the BPDU to the appropriate VLAN by looking at its 802.1Q tag. If the tag is present, the BPDU is assigned to the VLAN indicated by the tag. If the tag is not present, the BPDU is assigned to the native VLAN.
  • Check the PVID TLV in the BPDU. If the VLAN stored in the PVID TLV does not match the VLAN to which the BPDU was assigned, drop the BPDU and declare PVID_Inconsistent state for the offending pair of VLANs. This is the native VLAN mismatch check.
  • BPDUs whose PVID TLV VLAN matches the assigned VLAN will be processed by STP in their appropriate VLANs except BPDUs for VLAN1. Because the information for VLAN1 is duplicated in the IEEE BPDUs and PVST+ BPDUs and the IEEE BPDUs always have to be processed, the PVST+ BPDU for VLAN1 served only the purpose of protection against native VLAN mismatch in VLAN1, and can be dropped afterwards.

Would you agree with this summary? Thank you!

Best regards,

Peter

P.S.: I know I owe you a PM answer related to PVST Simulation. I am keeping it on my mind!

[Aninda Chatterjee]

Hi Peter,

Perfectly summarized. Couldn't put it any better! I think your post is pretty much all one needs to read to understand BPDU generation/processing and why a native VLAN mismatch would lead to an inconsistent state.

I'm looking forward to your response on our PVST simulation discussion.

Regards,

Aninda

[Peter Paluch]

Hi Rolf,

I mean the MAC address as part of the Bridge ID if the extended system ID is not used.
Every ST instance has to have a distinct BID or am I mixing up something?

Well, if Extended System ID is not used then the MAC addresses in the MAC part of the BID will obviously have to be different. However, for native VLAN mismatch, we are not trying to verify that the BIDs are unique but rather to make sure that if a BPDU was originated in VLAN X and populated with data from that VLAN's STP instance, it is also going to be consumed and processed by the same VLAN X STP instance on the receiving switch. Neither MAC addresses, nor even BIDs would be helpful here.

Best regards,

Peter