Questions about native VLAN setup

[Jason Flory]

Hello everyone,

I just started at a new job and took over responsibility of the network infrastructure.  I am little confused about the current setup which is something i have never seen.  Additionally there are complaints about call quality on voip calls.

It appears that all end user ports on the switch are setup as trunk ports with native vlan 3.  Vlan 3 is supposed to be the vlan for end users.

interface FastEthernet4/0/14

switchport trunk encapsulation dot1q

switchport trunk native vlan 3

switchport mode trunk

The phones are setup on the same physical ports but there is vendor string on DHCP which tells it to put them on vlan 6. 

When i do a show vlan it shows all ports in Vlan1 and nothing in vlan 6 or vlan 3.

First is this a normal config for having voice and data on the same physical port.  I have always seen this as "voice vlan" and all ports set to access.

Second question: Will packets be tagged coming out of the switch?  My understanding of native vlans is that it will only do untagged traffic.

Any clarity on this issue would be very helpful

Thanks

Jason

[Gerald Vogt]

What device? What software version?

Yes. It's not uncommon to have voice and data on the same physical port. This saves you an additional ethernet connection to hook up a phone and a computer. Instead, you connect first to the phone and through the phone to the computer. Separation of traffic happens through VLANs.

The configuration you have says that all existing VLANs run through that port. VLAN 3 is untagged. All other VLANs are tagged.

So it basically means the phone will send voice traffic tagged with VLAN 6 and will pass the data traffic through untagged.

I don't know about the "show vlan" output. Please the output!

[Peter Paluch]

Hello Jason,

What you are seeing is an unfortunate way of configuring a port with a data and a voice VLAN. The PC is placed to the native VLAN as it is not using any 802.1Q tags, and the phone is somehow forced to reside on VLAN 6, as you have suggested. It works, but it certainly is not a best practice.

With the style of the configuration you have posted, this configuration is especially unfortunate, as all ports behave as trunks open to any VLAN - there is not even a switchport trunk allowed vlan command used which means that the VLANs flow freely to and from every connected device to such a port. In addition, the phones (if they are from Cisco) are unable to discover their Voice VLAN via CDP automatically (as there is no Voice VLAN configured), and instead rely on a different mechanism - as you say, it is VLAN 6. These ports are currently unable to perform as PortFast ports - that would have to be forced on them using the spanning-tree portfast trunk command which is again not used, according to your output, leading to unnecessary topology changes in STP when connecting and disconnecting devices, and possibly causing outages if RSTP is used. Definitely not a good idea of configuring these ports accordingly.

And by the way, the VLAN 6 as the Voice VLAN: I believe it cannot be discovered via DHCP. DHCP itself works within a VLAN, not above VLANs. If a phone does not know which VLAN it is located in, it most probably sends all its packets including DHCP messages untagged. That would place the phone immediately into VLAN 3 (the native VLAN), and the DHCP would serve the phone from the pool created for VLAN 3, not for VLAN 6. It's a chicken-and-egg problem, in a way. The phone would actually need to first boot without VLAN, obtain parameters from VLAN3 that tell it to move to VLAN6, so the phone would start tagging its frames with VLAN 6 and request its entire IP configuration anew because it has essentially moved to a different network. While possible, this approach is not typical.

So, to your questions:

First is this a normal config for having voice and data on the same  physical port.  I have always seen this as "voice vlan" and all ports  set to access.

Having a data and voice VLAN on a port is normal, but it is not common to configure in the way you have just encountered. The proper way is probably you are commenting yourself:

interface FastEthernet0/4

switchport mode access

switchport access vlan 3

switchport voice vlan 6

This port essentially behaves like a trunk port with only two VLANs allowed: VLAN3 (native) and VLAN6 (voice). In addition, it tells the phone in CDP packets to use VLAN6 for voice, and it still behaves as an access port - no DTP, no VTP, no (R)PVST+, eligible for PortFast as an access port, etc.

Second question: Will packets be tagged coming out of the switch?  My  understanding of native vlans is that it will only do untagged traffic.

In your current configuration, yes, with the exception of VLAN3. The VLAN3 is native so the frames moving within VLAN3 will not be tagged. All other frames from other VLANs will be tagged with their VLAN ID.

This is also true for access ports with voice VLAN configured - the access VLAN will be untagged, the voice VLAN will be tagged - otherwise there would be no way of distinguishing the two. However, this configuration you have just encountered currently allows all VLANs to flow in and out the ports, thereby allowing stations to do all sorts of nasty things - they can become a part of any VLAN they wish simply by tagging their frames.

I would personally recommend moving to the proper way of configuring voice VLANs as an access port+voice VLAN in the next maintenance window.

Please feel welcome to ask further.

Best regards,

Peter

[Gerald Vogt]

Some phones use DHCP to get the VLAN for the voice traffic. For example, see http://wiki.siemens-enterprise.com/wiki/VLAN_ID_Discovery_over_DHCP

[Peter Paluch]

Hello Gerald,

Thank you for updating this thread. Hmmm, I stand corrected about the Voice VLAN discovery. Thank you. In any case, however, I cannot say I like the described way of DHCP-discovering the voice VLAN. It essentially forces you to use specific DHCP options in all DHCP pools except the pool for voice VLAN, because the phone could theoretically be connected to a port in any data VLAN. In my personal opinion, it is workable but messy. I am also surprised that the Siemens phones do not use DHCPINFORM to discover the voice VLAN but rather they go over the entire cycle of acquiring and immediately releasing an IP address on the data VLAN.

Best regards,

Peter

[Jason Flory]

Thanks everyone for the quick responses.

This is really good information.  When I looked at this i could not figure out how it was even working.

We are using Shoretel phone system which does provide a DCHP option to force phones to another vlan.  Which is working all phones end up on vlan 3 and users end up a vlan 3.

To answer Gerald's questions, the software is IOS  12.2(44)SE5, shoretel phones and windows clients.

When I do a show vlan it shows all ports in vlan 1.  Even though the config shows all ports configured with native vlan 3.

For DHCP we are using Ip helper commands to forward those broadcasts.

A couple more questions:

-I am not sure i am understanding the native vlan concept.

-Is this best practice to use native vlans for user vlan?

-What is the difference between spanning-tree portfast and spanning-tree portfast trunk.

On some of our other switches i am seeing spanning-tree portfast trunk on non-trunked ports.

Thanks again guys

[cadet alain]

Hi,

1)

When I do a show vlan it shows all ports in vlan 1.  Even though the config shows all ports configured with native vlan 3.

You won't see trunk ports in the output of sh vlan.So this is normal.

2) native vlan is the untagged traffic on a trunk, here it is the data vlan as PCs are not supposed to tag frames.

3) on a trunk or access port to a phone, yes it is

4) the first is for access ports and the other for trunk ports connecting to IP phones or Server doing dot1q

  on non trunk ports this command will have no effect but if the port becomes a trunk then it will

Regards.

Alain.

[Peter Paluch]

Hi Jason,

Which is working all phones end up on vlan 3 and users end up a vlan 3.

You mean the phones land on VLAN6, right?

When I do a show vlan it shows all ports in vlan 1.  Even though the config shows all ports configured with native vlan 3.

The plain show vlan command should actually show you no ports at all. All your ports are configured as trunks, and trunks are not displayed in the show vlan or show vlan brief output. Even if for some reason they are visible in the output, the show vlan displays the VLAN they would be put into if they were configured as access ports. Because their access VLAN has not been modified, it is set to the default VLAN 1, and that is probably the reason you still see the ports being assigned to VLAN1.

The native VLAN would be visible in the show interfaces trunk command.

-I am not sure i am understanding the native vlan concept.

Simply, the 802.1Q standard requires that the port has one primary VLAN into which it belongs, and it may have additional VLANs that naturally need tagging if they are to be distinguishable from each other. The primary VLAN from 802.1Q is what Cisco calls "native VLAN", and it is the VLAN that does not use tagging on this port. If an untagged frame arrives onto a trunk port, it is assigned to the native VLAN. If a frame belonging to a native VLAN is sent out a trunk port, it will not be tagged.

-Is this best practice to use native vlans for user vlan?

In a sense, you cannot do it differently. PCs do not ordinarily produce nor process tagged frames, and untagged frames are always processed in the native VLAN. However, it is not the best practice to configure ports as you originally indicated - as trunks, with native VLAN being the data VLAN, and one of the tagged VLANs being the voice VLAN. The best practice is to set the port mode to access, define the access VLAN (which is by definition the native VLAN of this port), and define the additional voice VLAN.

-What is the difference between spanning-tree portfast and spanning-tree portfast trunk.

The spanning-tree portfast command is effective only if the port is in access mode, and is ignored if the port is in trunk mode. The spanning-tree mode portfast trunk is effective both on access and on trunk mode ports.

Best regards,

Peter

[Jason Flory]

Thanks again

Can an access port be set a native vlan?

What is the driving reason for changing the default vlan from 1 to a different vlan.

You guys are great and thanks again.

[Peter Paluch]

Hi Jason,

Can an access port be set a native vlan? 

On an access port, the native VLAN is identical to the switchport access vlan and is not configured with any other specific command.

On a trunk port, the native VLAN is configured using the switchport trunk native vlan command. If this command appears on a port configured for access mode, it will be ignored.

What is the driving reason for changing the default vlan from 1 to a different vlan.

We have to be careful with the terminology here: a native VLAN is a distinct concept from a default VLAN. The default VLAN is always VLAN1 on Cisco devices. No other VLAN can be called a default VLAN. There is one to one correspondence: VLAN1 is the default VLAN; default VLAN is the VLAN1.

If you are asking about changing the native VLAN from its default value of 1 to a different VLAN, there are two main reasons. The first reason is that you have a non-tagging device connected to a trunk port, and you want it to be in a particular VLAN different from VLAN1. The second reason is that the VLAN1 is used to carry many supervisory protocols like CDP, VTP, partially STP and possibly others. It is therefore best from security and functionality perspective to leave the VLAN1 unused and left for switches' use, and use other VLANs for user data flows.

Best regards,

Peter