Cisco Best practices RE: Native VLAN/VLAN 1

[visitor68]

Good folks - Hope everyone is OK and staying healthy (and sane) during these challenging days. 

Quick question: Unfortunately, I have been away from Cisco-specific or Cisco-only networking, as I used to be. Therefore, I am a bit rusty concerning Rapid-PVST+ and Cisco best practices with regard to vlan 1 and how it should be treated. 

If I recall, a security-related best practice is to change the native vlan on a dot1Q trunk that is running rapid-PVST+ from vlan 1 to an otherwise unused vlan for the purpose of preventing a so-called vlan hopping attack. 

That said, I am pretty sure that a CIsco best practice is NOT to block vlan 1. VLAN 1 is the control plane vlan, if you will, in which LACP, VTP, DTP trunking and other switch infrastructure protocols run, so vlan 1 has to be allowed.

Am I correct on everything I said?

[balaji.bandi]

Personally VLAN1 is for all Native VLAN if not mentioned as specific VLAN as native VLAN. as you said due to security reason VLAN 1 can be disabled and you can have site based VLAN to be part of Native VLAN and it allowed in Trunk  List  for other communication you mentioned.

This not necesary to be VLAN 1, can be any VLAN.

[visitor68]

Thank you, but I'm afraid I don't understand your answer - don't understand what you're trying to say. It's the language barrier. 

[balaji.bandi]

- For Technolgoy there is no Language barrier. (it is  all depending on how one can understand and interprete by individual)

- It's the language barrier. -  Cisco made very good documentation in different Lanuguages for the users to understand better - which some users not able to interpret correctly in Technical way "that is the reason you are here".

Most important - This is Csico community forum and we are here to help.

Coming back to your question in short as per my view :

A native VLAN is assigned to an 802.1Q trunk port. Trunk ports are the links between switches that support the transmission of traffic associated with more than one VLAN. An 802.1Q trunk port supports traffic coming from many VLANs (tagged traffic), as well as traffic that does not come from a VLAN (untagged traffic). Tagged traffic refers to traffic that has a 4-byte tag inserted within the original Ethernet frame header, specifying the VLAN to which the frame belongs. The 802.1Q trunk port places untagged traffic on the native VLAN, which by default is VLAN 1.(Cisco Default -  New IOS Enviroment this can be changed an be changed).

VLAN hopping enables traffic from one VLAN to be seen by another VLAN. Switch spoofing is a type of VLAN hopping attack that works by taking advantage of an incorrectly configured trunk port ( since VLAN 1 known by default, security point of view use desired VLAN number for better security approach.

Hope this make sense ? (Still not clear) wait for better answer - Other mates of community can give you more shed on this topic.

[visitor68]

Hi, Balaji. Thank you for responding again. I hope I did not offend you with my comment about language. It wasn't meant to be an insult. Sometimes language can get in the way of smart people expressing their thoughts. I know it happens to me... :-) 

Anyway, I really am aware of everything you have said just now. This is CCNA stuff. I'm rusty, but not THAT rusty! :-) 

Allow me to ask a few direct questions:

1.) Can vlan1, the default untagged vlan that all ports are in when you take the switch out of the box, be DISABLED in NX-OS? By disabled, I do not mean pruned from a dot1q trunk or changing the native vlan from vlan 1 to some other unused vlan. I mean actually deleting it...removing it from the vlan database. Yes or No?

2.) I know that all non-IP control plane switch infrastructure traffic uses vlan 1 by default, such as CDP, STP, LACP, etc. That said, is it a Cisco best practice to prune vlan 1 from any inter-switch dot1q link?

3.) Assuming vlan 1 is indeed pruned from a dot1q inter-switch link switch port, what happens to that control plane traffic? Will the switches simply not exchange such traffic or will the switch leverage a different vlan? I know for rapid-pvst+, each vlan will get its own BPDUs anyway, but what becomes of the IEEE BPDUs that the Cisco switch normally transmits on vlan 1 and are used for RSTP convergence on the CST (to accommodate non-Cisco switches running IEEE rstp)?

[Sergiu.Daniluk · Accepted solution]

Hi @visitor68 

Allow me to answer your queries:

1.) Can vlan1, the default untagged vlan that all ports are in when you take the switch out of the box, be DISABLED in NX-OS? By disabled, I do not mean pruned from a dot1q trunk or changing the native vlan from vlan 1 to some other unused vlan. I mean actually deleting it...removing it from the vlan database. Yes or No?

Vlan 1 cannot be deleted on Nexus switches. it is restricted by the NXOS. The following message appears while trying to delete vlan1 and  SVI1, and I believe are pretty explanatory:

N9K(config)# no vlan 1
Deletion of VLAN 1 is not allowed!!
N9K(config)# no int vlan 1
Warning: Vlan 1 is default vlan and cannot be deleted

Going a bit further this discussion, VLAN1 being the default VLAN, it will use only default values, and you cannot create, delete, or suspend activity in the default VLAN.

2.) I know that all non-IP control plane switch infrastructure traffic uses vlan 1 by default, such as CDP, STP, LACP, etc. That said, is it a Cisco best practice to prune vlan 1 from any inter-switch dot1q link?

Regardless if you prune or not vlan 1 on a trunk CDP, STP, LACP will work. At least on NXOS. maybe IOS has some limitations, but NX-OS is programmed to accept L3 control plane packets (if the feature is enabled for the respective process). So answer to your question, I am not aware of a best practice about vlan 1 pruning. If you do not have user traffic in vlan 1 (which you should not have), then no need for vlan 1 on a trunk.

3.) Assuming vlan 1 is indeed pruned from a dot1q inter-switch link switch port, what happens to that control plane traffic? 

Answered in pct2.

Hope it helps,

Sergiu

[visitor68]

Sergiu to the rescue! Again! :-D My man!!

A small follow-up...

"Regardless if you prune or not vlan 1 on a trunk CDP, STP, LACP will work."

How will it work? If these control plane protocols are running on vlan 1 and vlan 1 has been pruned (for whatever reason), how do these protocol packets make it across the trunk between switches?

[Sergiu.Daniluk · Accepted solution]

Hello again :-)

The switch will still send the packets CDP packets with vlan 1 tagged. I know sounds strange or and you will ask why this would happen? Well, is just a mechanism to make sure that the control protocols works.

BTW, below are some logs confirming this:

N9K# sh run int e 1/54
version 9.2(2) Bios:version 05.33 

interface Ethernet1/54
  switchport
  switchport mode trunk
  switchport trunk native vlan 10
  switchport trunk allowed vlan 3500

N9K# show cdp internal event-history debugs
<snip> 
2020 May  4 20:50:11.342825 cdp: TAG : Sending CDP packet directly on port  0x1a006a00, payload_len 240 
2020 May  4 20:50:11.342851 cdp: Sent CDP packet On Netstack with vlan 1 tagged, interface 0x1a006a00, payload_len 240 

N9K# show interface snmp-ifindex | grep 0x1a006a00
Eth1/54         436234752  (0x1a006a00)

In reality, it is not magic. There are just some internal TCAM entries that allows control pkts to be forwarded to CPU.

N9K# show system internal access-list sup-redirect-stats all 

slot  1
=======

Instance: 0  [Unit: 0 Slice: 0]
===============================

------------------------------------------------------------------------
            Sup Redirect Entry Statistics             
------------------------------------------------------------------------
Ingress:
----------
Entry-ID  Description                                        Packet Count
------------------------------------------------------------------------
    3072                                             DOT1X    0
    3120                            PTP EVENT TX TIMESTAMP    0
    3121                                BFDC TCLASS PACKET    0
    3122                                SUP TX AQM DISABLE    0
    3128                                               CDP    29516
    3129                                           SDP-SRP    0
    3130                                            LLDP-1    59119
    3131                                            LLDP-2    0
    3132                                           CFSOE-1    0
    3133                                           CFSOE-2    56
    3134                                               PFC    0
    3136                                          FEX TFTP    0
    3137                                               STP    44
    3138                                              SSTP    4352063
    3139                                              LACP    1078803
<snip>

You can use: show system internal access-list tcam ingress region ing-sup to 'see' the entries, 
but I can tell you, the output is cryptic and is only used by TAC for low-level t-shoot. 

Hope it helps,

Sergiu

P.S. I found this document explaining how CDP is being sent out (tagged/untagged)

https://www.cisco.com/c/en/us/support/docs/network-management/discovery-protocol-cdp/118736-technote-cdp-00.html 

I did not read it yet (kinda late night here), but I think it will describe in greater details the behavior.

[visitor68 · Accepted solution]

Sergiu, thanks once again. 

OK, here is my take...ready? :-) Humor me, my friend.

What you showed me just now actually does make sense to me. Some years ago, when I worked as a sales engineer for a Cisco competitor, I ran stp convergence tests in my home lab to test IEEE 802.1w RSTP convergence with Cisco's rapid-pvst+ using a Cisco 3550 switch (Yes, I am OLD!). In the process, I discovered that - at least in Cisco IOS switches - vlan 1 could not be deleted. Moreover, it was also the only vlan that would accommodate the IEEE protocol. Here is an excerpt from a white paper I wrote:

As we have just learned, IEEE RSTP converges with PVST+ on a Cisco switch on the native VLAN, which is VLAN 1 by default, to form what is called the CST. But what happens when the native VLAN is changed from VLAN 1 to some other number on the dot1q interface of the Cisco switch as a preventive measure to counter a VLAN hopping attack?

EXAMPLE: switchport trunk native vlan 999

The IEEE RSTP bridge will simply converge on the new native VLAN (999) to form the CST, right? Wrong!
On a Cisco IOS switch (I’m assuming it’s the same with NX-OS), it is ONLY VLAN 1 that is sympathetic to the requirements of the IEEE standard. No other VLAN, including a renumbered native VLAN, will transmit BPDUs on the open standard MAC address. In other words, it is only on VLAN 1 that a Cisco switch will transmit STP BPDUs on the IEEE MAC (0180.c200.0000) to create that CST. The new native VLAN (999) will only send STP BPDUs to the Cisco MAC address.

So, although we cannot delete vlan 1 from the vlan database, and although we can prune vlan 1 from the inter-switch dot1q trunk by excluding it from the "allowed vlans" configuration command statement, the Cisco switch will continue to transmit and receive control plane PDUs on vlan 1 (as you just showcased), but the traffic will be tagged, which also makes sense because the native (untagged) vlan has been changed. So, what does pruning vlan 1 actually accomplish then if control plane traffic will still be permitted? It will block any data plane traffic on vlan 1, which you really should not have anyway because you don't want any resource contention with the control plane. 

Finally, as you said, I do not see any Cisco best practice that dictates pruning vlan 1. BUT, if you did, and you have changed the native vlan to something other than vlan 1, and you need to connect an IEEE 802.1w bridge dot1q  port to the Cisco rapid-pvst+ dot1q port, ensure that the native vlan is changed on the 3rd party bridge, too, of course. That will ensure two things: first, that the native vlans match on both ends  (no kidding, right? :-)), and secondly, that vlan 1's traffic will also be tagged on that 3rd party bridge. 

OK, I think I am done with this topic. Would love to have your thoughts!

[Sergiu.Daniluk · Accepted solution]

Hello my friendly @visitor68,

First, I must admit, with great curiosity I searched on google (unfortunately, without success) for this article of yours ^_^  Maybe if you want, you can share some references :D

Now that the discussion was moved from CDP to STP, the story becomes a bit (not too much, but just a bit) more complex. With the hope I will not shatter your train of thoughts, on the contrary I would like to bring more light, I have some few notes regarding what you mentioned. There are some small changes in how a Cisco switch will send STP BPDUs depending on the native vlan on a trunk. This is described in this document:

https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/24063-pvid-inconsistency-24063.html#topic1 

The relevant part is this one:

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.

If the Native VLAN on an IEEE 802.1Q trunk is not VLAN 1:

• VLAN 1 STP BPDUs are sent to the PVST+ MAC address, tagged with a corresponding IEEE 802.1Q VLAN tag.

• VLAN 1 STP BPDUs are also sent to the IEEE STP MAC address on the Native VLAN of the IEEE 802.1Q trunk, untagged.

• Non-VLAN 1 STP BPDUs are sent to the PVST+ MAC address, tagged with a corresponding IEEE 802.1Q VLAN tag.

  Note: Native VLAN STP BPDUs are sent untagged.

So as a summary, standard STP BPDU is always derived from VLAN1 and is always sent untagged. I would also like to share the following discussion about the very same topic of STP vs VLAN1: https://community.cisco.com/t5/switching/how-bpdu-is-transmitted-with-native-vlan-for-pvst-and-mstp/td-p/1631995

EDIT: I wanted to share some debugs related to this, but unfortunately (or rather fortunately?) I do not have any device talking 802.1D connected to my Nexus switch. And since NXOS can only run RapidPVST or MST, I cannot really do the tests.

However, I found this mentioned in config guide, confirming that same behavior happens in NXOS to allow interoperability with CST.

When you connect two Cisco devices through 802.1Q trunks, the switches exchange spanning tree BPDUs on each VLAN allowed on the trunks. The BPDUs on the native VLAN of the trunk are sent untagged to the reserved 802.1D spanning tree multicast MAC address (01-80-C2-00-00-00). The BPDUs on all VLANs on the trunk are sent tagged to the reserved Cisco Shared Spanning Tree Protocol (SSTP) multicast MAC address (01-00-0c-cc-cc-cd).

Ref: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/6-x/layer2/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_Layer_2_Switching_Configuration_Guide/b_Cisco_Nexus_9000_Series_NX-OS_Layer_2_Switching_Configuration_Guide_chapter_... 

Regarding this part:

So, what does pruning vlan 1 actually accomplish then if control plane traffic will still be permitted? It will block any data plane traffic on vlan 1, which you really should not have anyway because you don't want any resource contention with the control plane.

This is absolutely right. Data plane traffic will be not forwarded in vlan1 if the vlan is pruned from the switchport.

Let me know of your feedback.

Cheers,

Sergiu

[visitor68]

Sergiu...yet another fantastic, informative and detailed post from you. Thank you! 

So, now I got it...the slight change is that even if the native vlan is changed from vlan 1 to something else, for 802.1w rstp, the BPDUs will be sent UNtagged. 

I'm really going to check out those links you gave me. Thank you so much, again. 

By the way, I will be happy to send you the 2 white papers I wrote. I drew all my conclusions in the white papers by leveraging my home lab with Wireshark, Cisco documentation, and the third party's switch configuration guide, too. I think I can sen you a private message on here...let me see. The white papers used to be searchable online, but the repository my company was using changed and the link broke. 

[paul driver]

Hello
You are correct , You cannot block vlan1 due to the reliance on the control plane protocols that others on here have stated but you can if the switch allows prune it from the trunks and not use it anywhere in your switch configuration.

I have found quite a few people believe native vlans are switch specific which contrary to believe they are not they are interface specific however in most networks that I’ve come across most have parity relating to the native on all their trunk interconnects using vlan1 or not.

Due to the possibility of a security flaw called vlan hopping which can be used with the globally known untagged native vlan 1 to gain access to a network its best practice not to use vlan 1 whatsoever in your network

A few things you can do to mitigate this security flaw is:

Tag all vlans (including native vlan)
Assigned all unused access-port to a vlan other vlan 1
Use a native vlan other vlan 1
Prune vlan1 and any other specified native vlan off the trunk interconnects

Personally I try to apply suggest/include the last 3 of these options into a network with additional L2 security features which also includes disabling discovery protocols (DTP, CDP etc..) whenever i have the opportunity to do so

Example:
vlan 900
name native vlan
state suspend
shutdown

int x/x
switchport mode trunk
switchport trunk allowed vlan 2,3
switchport nonegotiate
switchport trunk native vlan 900

int x/x
description access-port
no cdp enable
switchport mode access
switchport nonegotiate
switchport access vlan 900
shutdown

[visitor68]

Great points, Paul, especially the first paragraph.

Language is so important, so I try to be absolutely meticulous about how I convey a thought. Meaning, I would have said "you can prune vlan 1 by disallowing it on a trunk interface. The CLI will allow that without hiccups. BUT the switch will not fully block vlan 1, notwithstanding your configuration. It will block only the data plane, not the control plane."

Don't get me wrong, your statement was 100% correct, but when someone says "you can't block vlan 1" one may wonder what is meant - can you not even enter the syntax correctly or the switch will only partially comply with the attempt to prune. 

[paul driver]

Hello @visitor68 
To answer your question, yes pruning vlan 1 of trunk interconnects wont effect the running of management control protocols traversing the trunk
I tend to look at it in a away that management control protocols such ad DTP, CDP, VTP etc, Are not actually tied to vlan 1 because if they were and you to prune vlan 1 off trunks then these protocols would cease to work, However most switches nowadays allow you to prune vlan 1 off trunks and these control protocols do continue to work, So yes these control protocols frames maybe be untagged and we know the native vlan is also but as I said I view it as they are not really linked, But on the flip side to this reasoning is the switch wont allow you to disable vlan1 which has be related to making sure these management protocols continue to work!