Cart
It has been a long time since we last busted a CCIE myth. Today, we’ll tackle one of the most prevailing ones. This one will probably leave you thinking about it long time after we’ve done. The myth is very simple: “VLAN 1 is always allowed on switch trunks”. We’ll see about that…As it is customary with many of my blogs and especially with these myth busting ones, we will be doing quite a bit of hands-on work. To do that, I will use the network as shown on the diagram below.
All interfaces except those shown on the diagrams are in shutdown. All configuration on all three switches is factory default, except the additional configurations shown below.
Cat2:
hostname Cat2 ! cdp timer 5 cdp holdtime 10 ! interface range FastEthernet0/1 - 24 , GigabitEthernet0/1 - 2 shutdown ! interface FastEthernet0/1 switchport access vlan 1 switchport mode access switchport nonegotiate spanning-tree portfast no shutdown ! interface FastEthernet0/20 switchport trunk encapsulation dot1q switchport mode trunk switchport nonegotiate no shutdown ! interface Vlan1 ip address 192.168.1.2 255.255.255.0 no shutdown !
Cat3:
hostname Cat3 ! cdp timer 5 cdp holdtime 10 ! interface range FastEthernet0/1 - 24 , GigabitEthernet0/1 - 2 shutdown ! interface range FastEthernet0/20 , FastEthernet0/24 switchport trunk encapsulation dot1q switchport mode trunk switchport nonegotiate no shutdown ! interface Vlan1 ip address 192.168.1.3 255.255.255.0 no shutdown !
Cat4:
hostname Cat4 ! cdp timer 5 cdp holdtime 10 ! interface range FastEthernet0/1 - 24 , GigabitEthernet0/1 - 2 shutdown ! interface FastEthernet0/24 switchport trunk encapsulation dot1q switchport mode trunk switchport nonegotiate no shutdown ! interface Vlan1 ip address 192.168.1.4 255.255.255.0 no shutdown !
R1:
hostname R1 ! cdp timer 5 cdp holdtime 10 ! interface FastEthernet0/1 ip address 192.168.1.1 255.255.255.0 no shutdown !
Before we begin, let’s just confirm that everything in our network works. What we’re looing for is ping between all hosts in VLAN 1, as well as CDP neighbors between switches.
Cat3:
Cat3#show cdp neighbors | begin ^$
Device ID Local Intrfce Holdtme Capability Platform Port ID
Cat4 Fas 0/24 5 S I WS-C3560- Fas 0/24
Cat2 Fas 0/20 6 S I WS-C3560- Fas 0/20
R1:
R1#tclsh R1(tcl)#foreach ip { +>(tcl)#192.168.1.1 +>(tcl)#192.168.1.2 +>(tcl)#192.168.1.3 +>(tcl)#192.168.1.4 +>(tcl)#} { ping $ip repeat 3 timeout 1 } Type escape sequence to abort. Sending 3, 100-byte ICMP Echos to 192.168.1.1, timeout is 1 seconds: !!! Success rate is 100 percent (3/3), round-trip min/avg/max = 1/2/4 ms Type escape sequence to abort. Sending 3, 100-byte ICMP Echos to 192.168.1.2, timeout is 1 seconds: !!! Success rate is 100 percent (3/3), round-trip min/avg/max = 1/2/4 ms Type escape sequence to abort. Sending 3, 100-byte ICMP Echos to 192.168.1.3, timeout is 1 seconds: !!! Success rate is 100 percent (3/3), round-trip min/avg/max = 1/2/4 ms Type escape sequence to abort. Sending 3, 100-byte ICMP Echos to 192.168.1.4, timeout is 1 seconds: !!! Success rate is 100 percent (3/3), round-trip min/avg/max = 1/3/4 ms
We’re now ready to explore the myth. I will just quickly reiterate what the common myth says: “VLAN 1 is always allowed on trunks and cannot be disabled.”
So, to test this theory, let’s disable all VLANs on Cat3′s trunks and see what happens.
Cat3:
interface range FastEthernet0/20 , FastEthernet0/24 switchport trunk allowed vlan none !
If I try to ping Cat3 or Cat4 from R1, this will fail miserably.
R1:
R1#ping 192.168.1.3 repeat 3 timeout 1 Type escape sequence to abort. Sending 3, 100-byte ICMP Echos to 192.168.1.3, timeout is 1 seconds: ... Success rate is 0 percent (0/3) R1#ping 192.168.1.4 repeat 3 timeout 1 Type escape sequence to abort. Sending 3, 100-byte ICMP Echos to 192.168.1.4, timeout is 1 seconds: ... Success rate is 0 percent (0/3)
Obviously, VLAN 1 is no longer allowed on the trunk. If it were this easy, we could leave it here. This is CCIE-level stuff, so we won’t leave it here.
We can conclude at this point that Cat3 is not passing (switching) any traffic on VLAN 1, but is it receiving and/or sending it? Let’s take a look at CDP for example.
Cat3:
Cat3#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID Local Intrfce Holdtme Capability Platform Port ID
Cat4 Fas 0/24 6 S I WS-C3560- Fas 0/24
Cat2 Fas 0/20 8 S I WS-C3560- Fas 0/20
Interesting. Even with VLAN 1 disabled, CDP works. At least Cat3 is receiving those frames. How about Cat2 for example? Is it receiving anything from Cat3?
Cat2:
Cat2#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID Local Intrfce Holdtme Capability Platform Port ID
R1 Fas 0/1 9 R S I 2811 Fas 0/1
Cat3 Fas 0/20 8 S I WS-C3560- Fas 0/20
Sure enough, there it is! At this point, we can see that some of the traffic is being allowed on this trunk, even though it appears to be disabled. I’m still curious about traffic not being switched. What is happening with spanning tree at this point? Let’s take a look.
Cat2:
Cat2#show spanning-tree vlan 1 VLAN0001 Spanning tree enabled protocol ieee Root ID Priority 32769 Address 001b.d4d3.0280 This bridge is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 32769 (priority 32768 sys-id-ext 1) Address 001b.d4d3.0280 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 Interface Role Sts Cost Prio.Nbr Type ------------------- ---- --- --------- -------- -------------------------------- Fa0/1 Desg FWD 19 128.3 P2p Edge Fa0/20 Desg FWD 19 128.22 P2p
Cat3:
Cat3#show spanning-tree vlan 1
Spanning tree instance(s) for vlan 1 does not exist.
Cat4:
Cat4#show spanning-tree vlan 1 VLAN0001 Spanning tree enabled protocol ieee Root ID Priority 32769 Address 0018.baf8.5a80 This bridge is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 32769 (priority 32768 sys-id-ext 1) Address 0018.baf8.5a80 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 Interface Role Sts Cost Prio.Nbr Type ------------------- ---- --- --------- -------- -------------------------------- Fa0/24 Desg FWD 19 128.26 P2p
We can see that both Cat2 and Cat4 assume they are root bridge. At the same time, Cat3 says there is no instance for STP in VLAN1. The reason is that there are no ports that are active in VLAN 1. Let’s see to fix that. I will just bring up one “dummy” port and make it access in VLAN1. This should be enough to activate STP in VLAN 1 on Cat3.
Cat3:
interface FastEthernet0/4 switchport access vlan 1 switchport mode access spanning-tree portfast no shutdown !
Let’s re-run our test, looking only at relevant bits.
Cat2:
Cat2#show spanning-tree vlan 1 | include Address|root
Address 001b.d4d3.0280
This bridge is the root
Address 001b.d4d3.0280
Cat3:
Cat3#show spanning-tree vlan 1 | include Address|root
Address 0018.baf8.a200
This bridge is the root
Address 0018.baf8.a200
Cat4:
Cat4#show spanning-tree vlan 1 | include Address|root
Address 0018.baf8.5a80
This bridge is the root
Address 0018.baf8.5a80
Clearly, we seem to have three spanning-tree islands, as Cat3 is not passing traffic in VLAN 1. Clear enough? Let’s confuse things a little bit…
The Twist
Until now we have seen that CDP works even with VLAN 1 disabled. Spanning-tree, running in default PVST+ mode will not pass over the trunk with VLAN 1 disabled… for VLAN 1. What happens if we add VLAN 2 for example? What happens with VTP configuration – will that go through? Let’s test things out.
Cat2:
vtp domain IPexpert vtp mode server ! vlan 2 name VLAN-2 !
Cat3:
Cat3#show vtp status VTP Version : running VTP1 (VTP2 capable) Configuration Revision : 1 Maximum VLANs supported locally : 1005 Number of existing VLANs : 6 VTP Operating Mode : Server VTP Domain Name : IPexpert VTP Pruning Mode : Disabled VTP V2 Mode : Disabled VTP Traps Generation : Disabled MD5 digest : 0x9D 0xF8 0x98 0x0C 0xBA 0x69 0x52 0x56 Configuration last modified by 192.168.1.2 at 3-3-93 17:38:10 Local updater ID is 192.168.1.2 on interface Vl1 (lowest numbered VLAN interface found) Cat3#show vlan id 2 VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 2 VLAN-2 active Fa0/20 VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2 ---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------ 2 enet 100002 1500 - - - - - 0 0 Remote SPAN VLAN ---------------- Disabled Primary Secondary Type Ports ------- --------- ----------------- ------------------------------------------
Amazing! Cat3 received and processed this information! What about Cat4?
Cat4:
Cat4#show vlan id 2
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
2 VLAN-2 active Fa0/20
VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
2 enet 100002 1500 - - - - - 0 0
Remote SPAN VLAN
----------------
Disabled
Primary Secondary Type Ports
------- --------- ----------------- ------------------------------------------
It’s there, too! How about if we change the spanning-tree from PVST+ to MST and make Cat4 the root. Will that information propagate to Cat1? Let’s take a look.
Cat2, Cat3 and Cat4:
spanning-tree mst configuration name IPexpert revision 1 ! spanning-tree mode mst
Cat4:
spanning-tree mst 0 priority 4096
Cat2:
Cat2#show spanning-tree mst | include Bridge|Root
Bridge address 001b.d4d3.0280 priority 32768 (32768 sysid 0)
Root this switch for the CIST
Cat3:
Cat3#show spanning-tree mst | include Bridge|Root
Bridge address 0018.baf8.a200 priority 32768 (32768 sysid 0)
Root this switch for the CIST
Cat4:
Cat4#show spanning-tree mst | include Bridge|Root
Bridge address 0018.baf8.5a80 priority 4096 (4096 sysid 0)
Root this switch for the CIST
Nothing has changed. Let’s now allow VLAN 2 on Cat3′s trunks.
Cat3:
interface range FastEthernet0/20 , FastEthernet0/24 switchport trunk allowed vlan 2 !
Cat2:
Cat2#show spanning-tree mst | include ^(Bridge|Root)
Bridge address 001b.d4d3.0280 priority 32768 (32768 sysid 0)
Root address 0018.baf8.5a80 priority 4096 (4096 sysid 0)
Cat3:
Cat3#show spanning-tree mst | include ^(Bridge|Root)
Bridge address 0018.baf8.a200 priority 32768 (32768 sysid 0)
Root address 0018.baf8.5a80 priority 4096 (4096 sysid 0)
Cat4:
Cat4#show spanning-tree mst | include ^(Bridge|Root)
Bridge address 0018.baf8.5a80 priority 4096 (4096 sysid 0)
Root this switch for the CIST
The information has propagated now. We can see that all three switches can clearly see that Cat4 is the root. How is our ping from R1 doing?
R1:
R1#ping 192.168.1.3 repeat 3 timeout 1
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 192.168.1.3, timeout is 1 seconds:
...
Success rate is 0 percent (0/3)
Still not working, but network control traffic does. How, when VLAN 1 is disabled?
Conclusions
The answer to “how” question I just asked is not simple. First of all, there is really nothing special about VLAN 1. The whole myth relies on “special and magical” abilities of VLAN 1. There are none. VLAN 1 is simply VLAN just like any other. However, when using 802.1q, control traffic (VTP, CDP, STP) is sent untagged. Untagged frames are also called “native”. All untagged traffic on trunks belongs to native VLAN… except for those control frames which don’t.
Control frames don’t really belong to any VLAN per-se – they belong to the switch, regardless of the VLAN they are received on. This is why traffic like VTP and CDP makes it through. The switch will process those frames, regardless of their internal VLAN membership. But what about spanning-tree? Why is behavior of spanning-tree “erratic” as shown above? Reason is simple.
By default, Catalyst switches operate in PVST+ spanning-tree mode. In this mode, there is a separate instance of spanning-tree for each VLAN. In this case, STP frames received on native VLAN are going to be treated as belonging to that VLAN and not belonging to the control plane of the whole switch. For this reason, they are being dropped on trunks not allowing them. The same applies for rapid-PVST+.
However, things change when we change the mode of operation to MST. In MST we have VLAN-to-instance mapping. In this case, STP frames do belong to the switch as a whole and will be processed and passed to other switches… untagged. Or at least… they should be.
We have clearly seen that this is not always true. For example, not even MST BPDUs were passed on trunks by Cat3 when no other VLANs were allowed. As soon as we allowed VLAN 2 on the trunk, BPDUs were forwarded. Why is that so? The only correct answer can be given by someone with access to this piece of IOS code, but my guess is – if there are no VLANs allowed, why bother forwarding BPDUs in the first place?
Where does this leave us with our myth? Busted or not? I say busted because all of this academic discussion made absolutely no difference for R1. It couldn’t access anything in VLAN 1 beyond Cat2.
Happy studies!
EDIT: In a follow-up quick-analysis of this blog, a reader un-busted part of this myth and proved some of my comments above as wrong. As it appears, VLAN 1 is indeed used for non-transit traffic on the link, even when it’s not allowed. It has some of the “magic” abilities. Link to the “un-busting” article can be found in the comments below.
–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List
Tags: 802.1q, CCIE, CCIE R&S, CCIE Security, CCIE SP, CCIE Wireless, myth, Trunks
Hi Marko, nice info. I actually did some POC myself when reading the following lines from Cisco Press CCNP Practical Studies – Switching.
Below is my interpretation upon that,
Even if the native VLAN on an 802.1Q trunk is not VLAN 1, CDP, VTP, PAgP, LACP, and STP are still sent on VLAN 1, with an 802.1Q tag attached indicating that VLAN 1 is not the native VLAN. If the native VLAN is VLAN 1, then the messages are sent without an 802.1Q tag.
This info is indeed false. :-)
Nice POC angle on the MST, I missed that out during my testing, mainly due to the fact that I haven’t study about MST yet. :p
Yet another thing to discredit that book, I’m afraid. Older BCMSN book was much better material than the current SWITCH. Unfortunately, it’s the only Catalyst IOS focused book on the market right now.
One should approach it carefully. In this “Old CCIE Myths” series, this is at least 2nd blow to the material written in that book. I wonder if authors are reading this blog :-)
[or CiscoPress editors in search for new authors for that matter ;-) ]
–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List
“This info is indeed false.”
Hmm… I gotta disagree:
http://www.fragmentationneeded.net/2011/01/revisiting-vlan-1-myth-again.html
The book is correct.
Very, very nice follow-up! I guess we can un-bust at least a part of the myth :-).
–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List
Marko, I forgot to mention: Thanks for writing this article! I have some understanding of the effort that goes into it, and really appreciate your taking the time to share. Especially when it gets me into the lab to test something that’s been nagging at me :-)
You are welcome. Thanks for following-up. Overall the goal of the blog has been fulfilled – we all learned from the experience :-)
–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List
Nice explanation.
I believe on the older Catalyst XL switches VLAN 1 could actually not be removed from the allowed VLANs statement, which probably helped form the perception. On newer switches it can be administratively removed.
That’s absolutely correct. There is one avenue that I didn’t explore, because I didn’t find it too relevant these days, but it could explain the behavior on those older switches.
Cisco’s ISL trunk encapsulation doesn’t support untagged frames. It is very likely that in case of using ISL control traffic may be sent tagged. This may be worth exploring as a follow-up to this.
–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List
I’ve only been doing this for a short time, but I must say… This was the best explanation of the VLAN 1 myth that I’ve seen so far. Clear, concise with great examples. Although I was unsure of the end… Did you mean that R1 could only get out to Cat2 on Vlan 1?
Thanks for this great post
That’s exactly right. While we could see that some frames were exchanged untagged, this wasn’t VLAN 1. For R1, anything beyond Cat 2 was unreachable – the result of disabling VLAN 1 on Cat3′s trunks.
–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List
Completely understand. You might want to correct this line at the end of your blog post though.
” It couldn’t access anything in VLAN 1 beyond Cat3.”
Hi Marko,
If the trunks are ISL, will you see unencapsulated CDP, VTP?
If encapsulation is mandatory on ISL, how does the switch know that the frame is for the switch control plane and not the VLAN (by the MAC address 01-00-0C-CC-CC-CD)??
I was hoping noone would bring the subject of ISL up ;-).
In a case of ISL, control frames will be sent in VLAN 1, as ISL does not allow untagged frames. However, I have hard time proving and verifying this, as the server I use for packet captures does not allow me to capture frames with VLAN information intact. Real shame … :-)
–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List
Nice writeup.
There is a Catalyst best practice document available at CCO that sums up control traffic and VLAN 1 pruning nicely (and is a handy reference in general):
http://www.cisco.com/en/US/products/hw/switches/ps700/products_white_paper09186a00801b49a4.shtml#pre6
I never saw a tagged CDP packet. I’m really surprised to see this. But i’m not able to see the same with my 3550′s. I’ve attached a PC to one port and i always see the CDP packets without tag, no matter how the port is configured. Can someone run the test and confirm what Chris was able to see ?
On PC with Windows or Linux the VLAN stripping seems to be done before any packets ever reaches the CPU even if tagging is enabled on the nic.
Tunnelling the traffic of the link may do the same trick as the tap. For example connecting a chain of two routers (via L2TP or EoMPLS port-mode) and one middle switch with SPAN – should capture the entire frame on a PC.
Dynamips can definitely do part of the trick with NM-16ESW and it’s internal capture feature. I’ve emulated two 3745 12.4SP one with NM-1FE-TX and the other with NM-16ESW.
After changing the default native VLAN:
On the routed port the neighbord is learnt on the subinterface (dot1q native). However the CDP generated by the routed port is tagged with 1!
Also LOOP frames are tagged with 1 when generated by the routed port.
The CDP is stil untagged when generated by the switching port (including forcing the CDP to be generated by SVI 1 adn SVI 202). The control traffic that is tagged with 1 is the PVST+ for Vlan 1. The PVST BPDUs are sent untagged for the new native VLAN along with standard STP BPDUs just on the switch port.
As a conclusion on 3745 dynamips the routed ports are tagging control traffic (CDP and LOOP) with 1 when the native VLAN is modified. The switch ports on a NM does not. It may as well behave different on a standalone real switch. A possible explanation may reside in some kind of decoupling b/w the NM and the CPU that generates CDP.
Edi
Hi
In my case I have connected pairs of switches HP and cisco.
It seems that there is no need for native vlan on either end…I have configuration where on cisco native vlan 1 is shutdown and on HP native (default) vlan 1 is in state “no untagged” on uplink port.Even that MST BPDU are exchanged over trunk with 2 other vlans.It would be good if someone could explain me why? Then recommendation from HP or Cisco that native vlan is required are incorrect.
BR
Grzegorz