native vlan for trunks

vishalpatil86 · ‎09-16-2011

HI,

I have core and edge switch. core's gig3/2 is connected to edge's gig0/1.

RUN CONFIG is -

core#sh run int gig3/1

Building configuration...

Current configuration : 130 bytes

!

interface GigabitEthernet3/1

switchport trunk encapsulation dot1q

switchport trunk native vlan 10

switchport mode trunk

end

----------------------------------------------------------------------------------------

core#sh run int vlan 10

Building configuration...

Current configuration : 102 bytes

!

interface Vlan10

ip address 172.16.10.253 255.255.255.0

end

-------------------------------------------------------------------------------------------

edge#sh run int gig0/1

Building configuration...

Current configuration : 92 bytes

!

interface GigabitEthernet0/1

switchport trunk native vlan 10

switchport mode trunk

end

------------------------------------------------------------------------------------------

edge#sh run int vlan 10

Building configuration...

Current configuration : 121 bytes

!

interface Vlan10

ip address 172.16.10.246 255.255.255.0

no ip route-cache

end

trunk config -

core#sh int gig3/2 trunk

Port Mode Encapsulation Status Native vlan

Gi3/2 on 802.1q trunking 10

Port Vlans allowed on trunk

Gi3/2 1-4094

Port Vlans allowed and active in management domain

Gi3/2 1-2,10,20-23,99,201-207,209-212,214-222,301-312,314-330,332-333,401-407,409-412,414-433,501-503,509-512,514-527,532-533,601-607,609-612,614-633,701-707,709-712,714-733,801-807,809-812,814-833,901-906,909-912,914-922,924-925,927-933,3000,3080-3092,4000-4001

Port Vlans in spanning tree forwarding state and not pruned

Gi3/2 1-2,10,20-23,99,201-207,209-212,214-222,301-312,314-330,332-333,401-407,409-412,414-433,501-503,509-512,514-527,532-533,601-607,609-612,614-633,701-707,709-712,714-733,801-807,809-812,814-833,901-906,909-912,914-922,924-925,927-933,3000,3080-3092,4000-4001

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

edge#sh int gig0/1 trunk

Port Mode Encapsulation Status Native vlan

Gi0/1 on 802.1q trunking 10

Port Vlans allowed on trunk

Gi0/1 1-4094

Port Vlans allowed and active in management domain

Gi0/1 1,10,99,201-207,209-212,214-222,301-307,309-312,314-330,332-333,4000-4001

Port Vlans in spanning tree forwarding state and not pruned

Gi0/1 1,10,99,201-207,209-212,214-222,301-307,309-312,314-330,332-333,4000-4001

following are the switch port config of core and edge switch respectively -

core#sh int gig3/2 switchport

Name: Gi3/2

Switchport: Enabled

Administrative Mode: trunk

Operational Mode: trunk

Administrative Trunking Encapsulation: dot1q

Operational Trunking Encapsulation: dot1q

Negotiation of Trunking: On

Access Mode VLAN: 1 (default)

Trunking Native Mode VLAN: 10 (mgt)

Administrative Native VLAN tagging: enabled

Voice VLAN: none

Administrative private-vlan host-association: none

Administrative private-vlan mapping: none

Administrative private-vlan trunk native VLAN: none

Administrative private-vlan trunk Native VLAN tagging: enabled

Administrative private-vlan trunk encapsulation: dot1q

Administrative private-vlan trunk normal VLANs: none

Administrative private-vlan trunk associations: none

Administrative private-vlan trunk mappings: none

Operational private-vlan: none

Trunking VLANs Enabled: ALL

Pruning VLANs Enabled: 2-1001

Capture Mode Disabled

Capture VLANs Allowed: ALL

Unknown unicast blocked: disabled

Unknown multicast blocked: disabled

Appliance trust: none

-----------------------------------------------------------------------------------------------------------------------------------

edge#sh int gig0/1 switchport

Name: Gi0/1

Switchport: Enabled

Administrative Mode: trunk

Operational Mode: trunk

Administrative Trunking Encapsulation: dot1q

Operational Trunking Encapsulation: dot1q

Negotiation of Trunking: On

Access Mode VLAN: 1 (default)

Trunking Native Mode VLAN: 10 (NIMS_mgt)

Administrative Native VLAN tagging: enabled

Voice VLAN: none

Administrative private-vlan host-association: none

Administrative private-vlan mapping: none

Administrative private-vlan trunk native VLAN: none

Administrative private-vlan trunk Native VLAN tagging: enabled

Administrative private-vlan trunk encapsulation: dot1q

Administrative private-vlan trunk normal VLANs: none

Administrative private-vlan trunk associations: none

Administrative private-vlan trunk mappings: none

Operational private-vlan: none

Trunking VLANs Enabled: ALL

Pruning VLANs Enabled: 2-1001

Capture Mode Disabled

Capture VLANs Allowed: ALL

Protected: false

Unknown unicast blocked: disabled

Unknown multicast blocked: disabled

Appliance trust: none

I just have one question,

how native vlan works here? pls help me on this. i am struggling with this concept

cadet alain · ‎09-16-2011

Hi vishal,

the native vlan on a dot1q trunk is the vlan which isn't tagged. by default it is vlan1 and it must be equal on both ends of the trunk.

Regards.

Alain.

Don't forget to rate helpful posts.

Joseph W. Doherty · ‎09-16-2011

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

As Alain noted, the native vlan is where untagged frames are directed that are received on a trunk. Outbound packets, including the native vlan, should be tagged. I.e., received native vlan frames could either be tagged or not.

Not 100% sure, but not all vendors might support native vlans, i.e. untagged frames on a trunk. The feature is really there to allow acceptance of untagged frames that "somehow" are received on a trunk.

PS:

If you're wondering why the sender should tag native vlan frames, outbound. Remember there's also a CoS field in the frame besides the vlan ID.

cadet alain · ‎09-16-2011

Hi,

I don't understand this sentence:

Outbound packets, including the native vlan, should be tagged. I.e., received native vlan frames could either be tagged or not.

Aren't these 2 verbs mutually exclusive ?

If you're wondering why the sender should tag native vlan frames, outbound. Remember there's also a CoS field in the frame besides the vlan ID.

Then these are not native vlan frames anymore ? I'm a little bit confused by your answer.

let's suppose we have this:

switchport mode access

switchport access vlan 10

switchport voice vlan 10

the data vlan 10 frames will be untagged by default but the PC shouldn't be doing any QoS here only the IP phone.

now let's suppose we have a trunk to a VM then we could tag all frames but then they wouldn't be the native vlan on the switch trunk going to other switch because then by default the native vlan is vlan1.

I always thought this a was a backward compatibility feature for devices not understanding Dot1q.

Can you clarify for me please.

Regards.

Alain.

Don't forget to rate helpful posts.

Jon Marshall · ‎09-16-2011

Alain

I am also a little confused by that sentence

However in reference to another point you make -

I always thought this a was a backward compatibility feature for devices not understanding Dot1q

It basically is and we always describe the native vlan as the vlan with untagged packets. But you can if you want tell the switch to add tags to even the native vlan if you want. You may want to do this for CoS as indicated by Joseph or you may want to do it for security reasons.

Technically, if you do this then the description of the native vlan as the vlan with untagged packets is not strictly accurate but with 802.1q there always is a native vlan whether you want it or not ! So it is probably correct to say the native vlan is the vlan on an 802.1Q trunk that does not have frames tagged unless you explicitly tell the switch to tag these packets.

Jon

cadet alain · ‎09-16-2011

Hi Jon,

Thanks for this clarification.

Regards.

Alain.

Don't forget to rate helpful posts.

Joseph W. Doherty · ‎09-16-2011

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

What I saying doesn't have to be mutually exclusive verbs.

I believe a trunk port receiving tag frames will always consider such frames to belong to the vlan they're tagged with. A trunk port receiving untagged frames will consider them part of the vlan that's been configured as the native vlan. In other words, the vlan that's configured as native, can accept frames either tagged or untagged. (I think that's true, but I haven't doubled checked and it's been a while since I've looked that deeply in vlan tag processing.) This is the could part, for the configured native vlan, inbound frames could be tagged or not.

For a trunk port sending frames, I'm saying all frames should be tagged, even those for the configured native vlan. (Not really native then, as Jon points out, but bear with me.) This so other tag information, like CoS, is available. But this, as Jon noted, is optional. Why wouldn't you want to tag all frames?

My understanding about the whole point of native vlans, was to allow devices that couldn't handle tag frames to have their frames assigned to a vlan. For example, you have two switches that have trunk ports which connect through a hub. Also connected to the hub are other devices that don't know how to tag frames. Two vlan capable switches can easily exchange tagged frames between themselves, but the other devices require untagged frames. The native vlan allows these other host frames to be assigned to a vlan and so they are accepted by either switch. It also allows the switches to "natively" (i.e. no tag) send frames to these hosts, but only frames for a particular vlan.

All fine and good, but where things can get interesting, switch 1 can assign untagged frames to vlan X while switch 2 can assign untagged frames to vlan Y. If all frames were tagged, again the should, this mismatch isn't possible. But if the native vlan wasn't possible, we couldn't support a mixture of tagged and untagged frames on the same wire.

More interesting, if the two switches don't agree on what's a native vlan, the receiving switch is getting untagged frames from hosts, which it "natively" assigns to vlan X but it may get tagged frames for vlan X from the other switch because its configured vlan Y as its native vlan.

PS:

Oh, on your question using a voice and data vlan using the same port, that's sort of a special case, as the port isn't really considered a trunk port although it processes "native" and tagged frames.