What are the advantages of Native VLAN ?

showint

Let's assume we have configured isl protocol as trunk link encapsulation, as other vendors did not support isl, we will use Native VLAN. But I guess there might be other usages of Native VLAN. Could you enumerate them plz ?

I found in some article the following excerpt "Native VLAN is responsible for all of the untagged traffic". The following question popd up in my mind: in which cases do we use untagged traffic?

I'd really appreciate if you could help me understand it.

Hondabuff

You change the Native VLAN from 1 so Joe Bob in accounting doesn't bring in his switch from home and plugs it in and makes a mini network in his cube.

[Deleted User]

That is true. All VLAN traffic on the native VLAN is not tagged with either 802.1Q or ISL encapsulation. Technically (not recommended however) You could have out of the box devices connected together and they can all communicate.

Nightflier101BL

The main advantage would be that the native VLAN allows switches to communicate with each other prior to configuring any VLAN trunking. Basically for ease of configuration right out of the box.

Theoretically, if you had more than 60% of your network in a particular VLAN you could make that VLAN the native and remove the overhead of the 4 byte 802.1q header. However, this is a security issue.

Frames associated with CDP, VTP, PaGP, etc are all sent over the native VLAN. STP and BPDU are sent over native and are also tagged. You can see this if you run Wireshark on a non-configured switch.

You can also change the native VLAN to another number for security reasons - basically choose a number that is harder to guess/figure out by attackers.

showint

Thanks everyone for a reply!

Nightflier101BL, I would like to express my deepest gratitude to you.I am satisfied with your very precise and concrete answer. Thank you!

You said "basically choose a number that is harder to guess/figure out by attackers". What if an attacker finds out Native VLAN number, what benefit will it bring him?

Dieg0M

Nightflier101BL wrote: »

Frames associated with CDP, VTP, PaGP, etc are all sent over the native VLAN. STP and BPDU are sent over native and are also tagged. You can see this if you run Wireshark on a non-configured switch.

This is not completely true. For CDP and VTP frames on a trunk with native vlan set other than 1, they are tagged VLAN 1. This means that CDP and VTP traffic are not always sent on the native VLAN.

Nightflier101BL

Thanks for the clarification, Dieg0M

As far as the OP's previous question, the attacker could have access to the entire network. Someone could "VLAN hop" by modifying the VLAN header.

showint

Dieg0M, I checked what you wrote here in GNS3.

I placed 3 switches, created 3 VLANs (101, 102 and 103). Then I changed Native VLAN from 1 to 103 on all 3 switches. I captured packets by Wireshark. CDP is still sent without tagging, which in turn means that cdp is sent via VLAN 103. That is, cdp is not attached exactly to VLAN 1 and is (always) sent on the native VLAN in my case.

I am a novice, I can misunderstand you. I apologize beforehand if I misinterpret your words.

hurricane1091

So let's look at VLAN hopping for a second, which is not in the R&S but you might want to know. If a user is plugged into the wall and that VLAN is 300, and their packet is going to go into the switch and flow out the other side over a trunk port, you're going to want the native VLAN to be something that you are not using anywhere. The problem if the native VLAN for the trunk the user is going to go over is 300 is that double tagging VLAN hopping can occur. The user can craft a packet that has a second 802.1Q header on the inside of the original 802.1Q header that is tagged VLAN300. That VLAN300 header is going to be stripped off by the switch before it is sent over the trunk since it's the native VLAN. The second switch will get it but see the second VLAN header (say 200) and VLAN200 is actually for the servers, and it's going to forward that packet out all ports on VLAN200. Dangerous! But the benefit of a native VLAN is for communication out of the box like mentioned.

Dieg0M

showint wrote: »

Dieg0M, I checked what you wrote here in GNS3.

I placed 3 switches, created 3 VLANs (101, 102 and 103). Then I changed Native VLAN from 1 to 103 on all 3 switches. I captured packets by Wireshark. CDP is still sent without tagging, which in turn means that cdp is sent via VLAN 103. That is, cdp is not attached exactly to VLAN 1 and is (always) sent on the native VLAN in my case.

I am a novice, I can misunderstand you. I apologize beforehand if I misinterpret your words.

Not sure if IOU switches behave the same as hardware switches. I have tested this a couple of years back using real gear.

FrankGuthrie

I was under the impression the Native VLAN concept is not used in ISL, Am I wrong about this?

showint

The Native VLAN is what a switch assumes untagged traffic belongs to.

802.1Q tags by adding a 32-bit field between the source MAC address and the EtherType. But ISL doesn't tag, it encapsulates the original frame. It encpsulates whatever frame it gets in trunk port. So there's no need for the Native VLAN in ISL

showint

I don't know how true this is, but I read in some article that It is not usual for a Switch port configured as a trunk port to receive untagged Ethernet frames. But it will happen if you are using Cisco VOIP phones in your network.