Ethernet Switching
Highlighted
Ethernet Switching

What is the use case for native-vlan-id?

‎07-17-2020 07:38 AM

Hi team.

 

According to https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/native-vl...

 

You may need to configure native-vlan-id if your switch has a trunk port that's receiving untagged frames.

 

But in what scenario will a trunk port ever need to receive untagged frames?

 

Thanks,

Deepak

17 REPLIES 17
Highlighted
Ethernet Switching

Re: What is the use case for native-vlan-id?

‎07-17-2020 07:47 AM

Hi 

 

 

Highlighted
Ethernet Switching

Re: What is the use case for native-vlan-id?

‎07-17-2020 07:56 AM

Hi

 

Greetings,

 

When a native VLAN ID is configured and the same VLAN is configured under the port mode trunk, the switch receives untagged frames, as well as tagged frames for the configured native VLAN ID and forwards it to the VLAN that is configured as native.

 

For the same configuration, when packets are sent out on the native VLAN, the frames are sent as tagged frames, as it is added under the port mode trunk.

 

For example:

In the following configuration, native-vlan-id 1 equals the MGMT VLAN (ID 1) and the MGMT VLAN is also configured as a member of the trunk VLAN:

ge-0/0/23 {
    unit 0 {
        family ethernet-switching {
            port-mode trunk;
            vlan {
                members [ MGMT Cust_150 Cust_151 ]; < Reason why MGMT packets are tagged
            }
            native-vlan-id 1;
        }
    }
}

The EX switch will tag and transmit the MGMT packets. To send untagged packets on the native VLAN, the MGMT VLAN has to be removed as a member of the trunk; but left in the native VLAN that is set to the MGMT.

 

Here is how it works:

MGMT is NOT a member of trunk, but it is a member of native VLAN:

Transmit = untagged (pass)
Receive = untagged (pass)
Receive = tagged to MGMT (drop)

MGMT IS a member of the trunk and native VLANs:

Transmit = tagged (pass)
Receive = untagged (pass - mapped to MGMT)
Receive = tagged (pass)

So, if a tagged VLAN needs to be sent as untagged traffic, it should be configured only with the native VLAN ID and the VLAN should not be added under the port mode trunk configuration.

ge-0/0/23 {
    unit 0 {
        family ethernet-switching {
            port-mode trunk;
            vlan {
                members [ Cust_150 Cust_151 ];
            }
            native-vlan-id 1;   << will be sent as untagged.
        }
    }
}

Another way to achieve this is by using the hidden command, 'except'. This is helpful when the VLAN count is higher and it is difficult to mention all the VLANs individually.

root@jtac-EX4200-8POE-r2028# show interfaces ge-0/0/23
unit 0 {
    family ethernet-switching {
        port-mode trunk;
        vlan {
            members all;
            except MGMT;
        }
        native-vlan-id 1;
    }
}

 Please mark "Accepted Solution" if this helps you solve your query. Kudos are always appreciated.

 

Thanks 

Suraj

Highlighted
Ethernet Switching

Re: What is the use case for native-vlan-id?

‎07-17-2020 08:00 AM

Hi djadhav,

 

The switch assigns any untagged frame that arrives on a tagged port to the native VLAN. If a frame on the native VLAN leaves a trunk (tagged) port, the switch strips the VLAN tag out.

 

As per my understanding, the native VLAN is a way of carrying untagged traffic across one or more switches.

 

Assume a scenario as below:

 

Host A------------(ge-0/0/1)--Switch A--(ge-0/0/2)----------------Host B

 

Here,  the ports that the hosts connect to are trunk ports, with native VLAN 15 configured.

 

  1. Host A sends a frame with no VLAN tag
  2. Switch A receives the frame on the trunk port. It does not have a tag, so it adds the VLAN ID 15 tag to the frame
  3. The switch sends the frame out of port ge-0/0/2. The frame has a tag for VLAN 15, which matches the native VLAN on port ge-0/0/2, so the switch strips the tag out
  4. Host B receives the frame.

Carrying untagged traffic has its uses. This happens when one switch wants to send information to another switch. In this case, if there is a trunk link between two switches, how does the sending switch decide which VLAN to use? In short, it sends untagged traffic, which is on the native VLAN.

 

You may also refer the below for more details:

https://kb.juniper.net/InfoCenter/index?page=content&id=KB17419#:~:text=When%20a%20native%20VLAN%20I...

 

Hope this helps 🙂

 

Please mark "Accepted Solution" if this helps you solve your query. Kudos are always appreciated!

Highlighted
Ethernet Switching

Re: What is the use case for native-vlan-id?

‎07-17-2020 08:27 AM

Thanks Mohamed.

 

But why is the other switch sending untagged frames over the trunk link in the first place? In what scenario is this needed?

 

--Deepak

Highlighted
Ethernet Switching

Re: What is the use case for native-vlan-id?

‎07-17-2020 08:49 AM

Hi djadhav,

 

To able to work with a switches that does not support tagging in the middle. For example, you have 2 switches able to read tags connected through a switch or hub that can not read vlans. With this you can also connect other devices to this switch, and they would be able to reach the network. So, my understanding that it was used, when the switches  or hubs that do not support tags are common.

 

If this solves your problem, please mark this post as "Accepted Solution."

Best Regards,

Mohamed

 

 

Highlighted
Ethernet Switching

Re: What is the use case for native-vlan-id?

‎07-17-2020 09:32 AM

Thanks bmanvita.

 

You mentioned that switch-to-switch communication would need to occur untagged over a trunk link. Does this include STP BPDUs? 

 

Regards,

Deepak

Highlighted
Ethernet Switching

Re: What is the use case for native-vlan-id?

[ Edited ]
‎07-17-2020 11:15 AM

Hi

 

 

 

 

If this solves your problem, please mark this post as "Accepted Solution" so we can help others too \:)/

 

Regards,

Lil Dexx
JNCIE-ENT#863, 3X JNCIP-[SP-ENT-DC], 4X JNCIA [cloud-DevOps-Junos-Design], Champions Ingenius, SSYB

 

Highlighted
Ethernet Switching

Re: What is the use case for native-vlan-id?

‎07-17-2020 08:06 PM

Hello,

 

Basically if the connection is between the switch to switch then the native-vlan-id use case will depend  if both the switches support the native-vlan-id however this case is not usually why native-vlan-id is used. 

 

The native-vlan-id concept comes when we have a IP phone and a PC connected to the same interface on the switch.

By default the interface will be in the data vlan however the interface will receive untagged packet on data vlan from the PC and tagged packet on the voice vlan from the IP phone. Hence the untagged packet received on the data vlan will be assigned to native-vlan configured on the switch.

 

Hope this helps

Highlighted
Ethernet Switching

Re: What is the use case for native-vlan-id?

‎07-17-2020 10:58 PM

Hello,

 


@djadhav wrote:

 

But in what scenario will a trunk port ever need to receive untagged frames?

 

 


 

Imagine the situation where You have an install base of CSCO switches and You need to deploy another one 300 miles away. 

There is a remote hand onsite who is able to plug/unplug the power cable, network cable and flick the power switch but nothing else , this guy is actually a security guard, not a network engineer.

So, You unpack Your shiny new CSCO switch, connect a console cable, bang an IP address to "interface Vlan1", enable Telnet, then pack the switch back and post to the site.

On the night the switch arrives, Your security guy unpacks it, slides it into the rack, connects a power cable, connects a crossover cable between the new switch and one of Your existing switches and voila! You are able to telnet to this switch from Your office desk and proceed to configure it. 

The beauty of this approach is that even if security guy made a mistake and plugged the right cable into the wrong port(s), it still works because all CSCO switches have the same default native VLAN 1 on all ports.

HTH

Thx

Alex

 

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Highlighted
Ethernet Switching

Re: What is the use case for native-vlan-id?

‎07-17-2020 11:28 PM

Hi djadhav,

 

Greetings, 

 

Yes, the switch-to-switch communication would need to occur untagged over a trunk link. As per my understanding, the STP BPDU's are part of the control traffic and not the data traffic. The use case of native-vlan-id is untagged data traffic.

  • Typically, trunk ports, which connect switches to each other, accept untagged control packets but do not accept untagged data packets.
  • As already being discussed, we can enable a trunk port to accept untagged data packets by configuring a native VLAN ID on the interface on which you want the untagged data packets to be received.
  • Also note that the logical interface on which untagged packets are to be received must be configured with the same VLAN ID as the native VLAN ID configured on the physical interface.

 

One way of usage is securing the trunk interface and not letting any untagged traffic on trunk by configuring a vlan without any traffic as native vlan id, so untagged traffic would never leave the trunk. 

 

Some of the use case of native-vlan-id are: 

  1. It could be used for security purpose by setting the native VLAN to a VLAN that is not in use so that the untagged traffic essentially gets dropped.  
  2. We could also use native VLANs on access point's trunk ports where the management VLAN is set to native so the AP gets an IP address from it.

 

Hope this helps. 😀

 

Please mark "Accept as solution" if this answers your query. 

Kudos are appreciated too! 

 

Regards, 

Sharat Ainapur

Highlighted
Ethernet Switching

Re: What is the use case for native-vlan-id?

‎07-18-2020 05:02 AM

The history of native-vlan comes from our friends at Cisco.  When Cisco implemented proprietary STP version, PVSTP, each VLAN basically ran its own STP calculation.  With this usage, one could program or assign, vlans to different paths of redundant connections, thereby making both links active.  Since this involved multiple VLANs, the links needed to be setup as Trunks or Tagged Interfaces.  At same time, STP needed to run.  At the time, most implementations of STP over a Trunk/Tagged interface, sent the BPDUs as un-tagged.  With Cisco PVSTP since each VLAN ran its own STP, Cisco came up with [again at the time, proprietary] concept of native-vlan, such that untagged STP BPDUs would be associated with that VLAN, and then any VLAN ID could be used as a Tagged ID.  So with native-vlan ID VLAN 1 could be used as tagged, and any other VLAN ID could be used to pass the un-tagged STP BPDUs.

 

This forced many other vendors, to follow the 100 lb gorilla, and also implement something that could interoperate with PVSTP and native-vlan-id.  PVSTP became the default STP configuration in Cisco IOS, which help Cisco try an lock customers into using only their products.  Similar use case to IGRP and EIGRP as the default routing protocols.

 

Today native-vlan-id use case is generally STP (PVSTP/PVSTP+) interoperability between vendor X and Cisco for STP operation.  Since STP based network designs went out of vogue 10+ years ago, this is generally only a consideration for older legacy networks.  Native-vlan-id now has some other use cases, and it is the vlan designated for untagged traffic received on a Tagged Interface.  Old implementations generally dropped un-tagged packets on a Tagged Interface, and Tagged packets on an un-Tagged Interface, by default.  This has generally changed to opposite default behavior, but is generally configurable in most of today's more modern implementations.

 

HTH

Highlighted
Ethernet Switching

Re: What is the use case for native-vlan-id?

a week ago

Thanks Alex for your reply.

 

But isn't your explanation for the default vlan? My question was about the native VLAN.

 

Thanks,

Deepak

Highlighted
Ethernet Switching

Re: What is the use case for native-vlan-id?

a week ago

Hi Lil.

 

Thank you for your reply.

 

You've given the use case for the voice vlan, where an access port can receive untagged frames from a desktop as well as tagged frames from an IP phone.

 

However, I'm interested in the use case for the native VLAN, where untagged frames are received on a trunk port.

 

Thanks,

Deepak

Highlighted
Ethernet Switching

Re: What is the use case for native-vlan-id?

a week ago

Thanks Ravi for reply.

 

You've given the use case for the voice vlan, where an access port can receive untagged frames from a desktop as well as tagged frames from an IP phone.

 

However, I'm interested in the use case for the native VLAN, where untagged frames are received on a trunk port.

 

Thanks,

Deepak

Highlighted
Ethernet Switching

Re: What is the use case for native-vlan-id?

a week ago

Hello,

 


@djadhav wrote:

 

 

But isn't your explanation for the default vlan? My question was about the native VLAN.

 

 

My explanation is for both default AND native VLAN being 1 on CSCO switches if You read it carefully.

It was not configurable for a short few years back then (in end of 1990s-beginning 2000s) hence everyone started to copy CSCO IOS behaviour to be compatible with CSCO implementation.

And later on when CSCO has intoduced a possibility to tag native VLAN, the whole definition of native VLAN has changed from "native VLAN is a port-based VLAN where [1] untagged native Ethernet frames are placed irrespective of the ingress port" to "native VLAN is a port-based VLAN where  untagged native Ethernet frames are placed when received on edge ports or [2] trunk ports, OR a VLAN where tagged Ethernet frames are placed when received on [3] trunk ports if such tag has been specified as dedicated tag for <<native VLAN>> in the switch config".

Use case [1] is the original intention of native VLAN.

Use cases [2] and [3] were added later on in the process. 

Hope this makes sense.

HTH

Thx

Alex

 

 

_____________________________________________________________________

Please ask Your Juniper account team about Juniper Professional Services offerings.
Juniper PS can design, test & build the network/part of the network as per Your requirements

+++++++++++++++++++++++++++++++++++++++++++++

Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
Highlighted
Ethernet Switching

Re: What is the use case for native-vlan-id?

a week ago

A new [different?] use case for proper native-vlan-id has popped up.  You want to do ZTP from say Cloud (MIST) for EX switches.  This means plug and play, so switch is only [initially] running with default operation.  For revenue ports means local VLAN 1 (default) and DHCP.  The switch connection is eventually going to hit some Router (combo DHCP Server) whose Interface connection to switch (for future operation) is most likely tagged/trunked.  Therefore the Router (not the EX switch) must have proper native-vlan-id set to take the untagged [default] packets from the switch and put them in right VLAN so switch can eventually connect to Internet/Cloud.  From there the Cloud (MIST) will supply switch with all info and config it needs to properly work - fully plug and play.

 

FYI only.

Highlighted
Ethernet Switching

Re: What is the use case for native-vlan-id?

Friday

All the above explanations are fine and historically accurate but to maybe make case simpler to understand and to answer your question I have real life examples of using native vlans on trunks.

 

First use is for connecting Wireless Access Points that are centrally managed by controller. By default, they search for controller and send management traffic without tag. Yet, when you want to separate SSID on different subnets (VLANs) you need to tag those so you have a trunk facing the AP. To still have a management connection to it, you configure native vlan id that you set up on controller for management.

 

Second use is in lab or small deployments scenario where I have only one VLAN for basic access and use other for APs/Servers/Switches. In that situation, when I configure port in trunk mode, set access VLAN as my native I can connect all above devices and regular PC interchangeably.

 

To make things simpler, don't think about soft limitations like port modes trunk/access and just think about 802.1q tags.

Port mode access is just a limitation to one, untagged VLAN on that link where as trunk gives u option to also handle tags so separation of networks on one link without losing that functionality of handling untagged vlan traffic.

Feedback