Ethernet Switching
Highlighted
Ethernet Switching

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

4 weeks ago

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

11 REPLIES 11
Highlighted
Ethernet Switching

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

4 weeks ago

Hi 

 

 

Highlighted
Ethernet Switching

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

4 weeks ago

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?

4 weeks ago

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 :slightly_smiling_face:

 

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?

4 weeks ago

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?

4 weeks ago

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?

4 weeks ago

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 ]
4 weeks ago

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?

4 weeks ago

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?

4 weeks ago

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?

4 weeks ago

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. :grinning_face:

 

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?

4 weeks ago

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

Feedback