cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
931
Views
0
Helpful
5
Replies

VLAN trunking, native vlan and management vlan

pykim
Level 1
Level 1

Hello all,

In our situation, we have 3 separate vlans: 100 for management vlan and 101 for data and 102 for voice.

We have an uplink which is trunked using .1Q. Our access ports has the data vlan as the native. Based on our design, what should be the native vlan for this uplink trunk? Should it be the management vlan or the data vlan? Thanks for your help.

1 Accepted Solution

Accepted Solutions

OK, now I understand your provlem. You are making a mistake in what the switch does to a packet. The tagging of dot1Q is AUTOMATICALLY DONE BY THE SWITCH when it forwards the packet over a trunk link. The vlan id in the tag is known from the accessport that the packet came from. The receiving switch removes the tag before forwarding the untagged frame to access ports in the same vlan.

Hence the confusion between untagged frames that you assume on the trunk is simply not possible. All traffic from user vlans is tagged when it traverses a trunk using the vlan id of the originating port.

The setting of the native vlan is not all important in this case.

Only in the case where you are using vlan 1 (assuming this is the native vlan) for user traffic, you may also get some background traffic as a result from the forwarding of untagged frames to the native vlan.

Leo

View solution in original post

5 Replies 5

lgijssel
Level 9
Level 9

To answer this question you must remember what the native vlan is. Native is where untagged packets are sent, i.e. packets without a dot1Q tag. It is there mainly for compatibility. On an access port it has no function while normal traffic is not tagged and sent to the vlan that is configured for the port. Traffic for the voice vlan is an exception to this general rule.

Native vlan setting only plays a role on trunk links where most of the traffic carries a tag. As explained, it is then used as the vlan for untagged traffic.

When you do not consider this a security breach, you may configure the data-vlan as native. Use another vlan (why not vlan1?) in the case where you want to isolate this traffic.

I find it good design practice to use the same native vlan throughout the network. This keeps things clear and it's better for anyone who is not completely obsessed with security. The latter kind of people can always find a reason to mess things up, both for themselves and for others;-)

Regards,

Leo

Thanks for the response.

I am still a bit confused. If we have used vlan1 (or management vlan) for the native vlan for uplink, how will the data be passed onto it when it has no tags since data vlan is native on the access port? Does the trunk tag it when it goes to the uplink automatically?

I have read many places that typically the native vlan for uplink trunks are the management vlan. If that is not necessary then why do people suggest it? This assumes the management vlan is not vlan1.

Thanks.

The native vlan is the only vlan on a switch that accepts untagged packets. That's why it's there!

But you may decide not to accept untagged packets into your network. Some might tap into your trunk and achieve illegal access! (Not much of a chance but OK, when you're paranoid it might seem as a way to go.) There are also some network maintenance protocols (vtp for example) that use untagged packets and one may decide that he does not want these on his uservlans.

This can be achieved by choosing a separate vlan as native. All untagged traffic will then remain in this vlan. The most straight-forward solution would be to designate the default vlan1 for this. You can achieve this by assigning other vlan-id's to the vlan's that you are actually using, just like you did. If I had to make it myself, I would leave vlan1 as native, and assign the rest like:

100 mgmt

101 data

102 user

103 voice

etc. etc.

Did this enlighten you sufficiently?

Regards,

Leo

I appreciate your answer. I am just confused in the area of native vlan on the access port. Please confirm that when the switchport access vlan 102 is defined on an access port, the native vlan is 102? If that is the case then there is no tagging for vlan 102 data. So when it goes to the uplink trunk port which has the native vlan 1, for example, will it not confuse the untagged vlan 102 data from the access port with vlan 1? I hope I convey my confusing clearly.

OK, now I understand your provlem. You are making a mistake in what the switch does to a packet. The tagging of dot1Q is AUTOMATICALLY DONE BY THE SWITCH when it forwards the packet over a trunk link. The vlan id in the tag is known from the accessport that the packet came from. The receiving switch removes the tag before forwarding the untagged frame to access ports in the same vlan.

Hence the confusion between untagged frames that you assume on the trunk is simply not possible. All traffic from user vlans is tagged when it traverses a trunk using the vlan id of the originating port.

The setting of the native vlan is not all important in this case.

Only in the case where you are using vlan 1 (assuming this is the native vlan) for user traffic, you may also get some background traffic as a result from the forwarding of untagged frames to the native vlan.

Leo