Remember that the native VLAN configuration on a trunk port tells the switch on which VLAN all incoming untagged frames must be placed. By default, the native VLAN is set to VLAN1. With your configuration, you changed this to VLAN 120. With this change, pings started responding, so the first thing I think we can conclude is that the problem was that the response to the pings was being dropped at the interface, and is now not being dropped. (native VLAN affects incoming traffic).
Now Iām not quite clear on your topology, and Iām not quite sure from where you were pinging, but I can make some educated guesses. The host from which you were pinging must be on VLAN 120. The ping reached the intended host, it returned, but it hit the E1/38 port untagged for some reason and was put on VLAN1 by default. The intended destination is not on VLAN1 but on VLAN120 so the echo reply never reaches the host that initially sent the ping.
By changing the native VLAN, the return is placed correctly on VLAN 120 and reaches the host. Now I suggest that you take a look at the configuration of the Linux bridge, particularly on the port that is connecting to the Ethernet1/38 trunk port of nexus switch, and ensure that the native VLAN is correctly configured there, and that VLAN 120 is also allowed on the trunk port.
So if on every port of a given switch, i have specified the vlan(switchport access vlan x) to which i want the port to belong to, there is no need for a native vlan tag on the trunk?
The vulnerability that is introduced if you do not tag the native VLAN exists under very specific circumstances. If the attacker is on the native VLAN, and they want to gain access to another VLAN, say VLAN 2, then they can craft a frame so that it has two 802.1Q tags. The outer tag will be that of the native VLAN, and the inner tag will be the desired destination VLAN it wants to get to. When the tag is received by the switch, it will remove the outer tag and forward the frame to the VLAN indicated by the inner tag.
However, there is a catch: The attacker must also trick the switch into thinking that he is a switch, thus causing the port to which he is connected, to function as a trunk. And that requires another vulnerability, the enabling of Dynamic Trunking Protocol (DTP) which, best practice dictates, should be disabled.
So specifying a VLAN for all access ports on the switch is not enough. You must ensure that no switchport can be ātrickedā into thinking it is connected to a switch, when in actual fact it is connected to an attacker.
Andrew, you said " We configure the switch so that the native VLAN is the PC Data ". From what Iāve read elsewhere, changing the native vlan to something other than vlan 1 is for security purposes (since most hackers know Cisco uses vlan 1 for traffic like CDP, STP, VTP, etc). It seems it was not for PC data. Can you clarify?
Typically, the most common reason to change the native VLAN from VLAN 1 to something else is indeed for security reasons. This is one of the steps you should take to mitigate against such things as a VLAN hopping attack. However, what Andrew is describing is also a legitimate use of the native VLAN.
Andrew is describing a situation where IP phones are connected directly to the switch ports, and PCs are connected to the phones. This way, only one switch port is used for both the phone and the PC. But the switch must be able to differentiate between the voice packets from the phone and the data packets from the PC.
Now in older implementations, this was done exactly as Andrew described, placing the PC on the native VLAN (since its frames arrive untagged) and the tagged VLAN for the voice packets from the phone. Since then, however, Cisco switches have introduced what is known as the voice VLAN. This is a special VLAN used for such IP phone connections. The principle is the same as that Andrew describes, however, the commands are somewhat different. You can find out more about that at the following lesson:
Q-1=Why native VLAN needs to match between the switches ??
Q-2=If that does not match , Is there any impact in the network ??
Q-3=Any disadvantages of disabling the native vlan ?
Q-4=The L2 control protocol like cdp, vtp, pagp, stp uses the vlan 1 or configured native vlan ?
Q-5=Can we configure the switch trunk native vlan 1 tagged ???
Q-6= What kind security issue will be there if we keep the vlan 1 as native vlan ??
If the native VLAN does not match, then any frame sent from one switch to another will hop from one VLAN to another, something that can be taken advatnage of by attackers.
The network will still function, and all other configured VLANs will transmit their data without any problems. A syslog message will appear on either end of the trunk stating a mismatch.
You canāt disable the native VLAN. Even if you use the no form of the command, it will return to the default setting which is making VLAN 1 the native VLAN. It is however good practice to change the native VLAN to something other than VLAN 1 and then place no other ports or networks on that VLAN. That way, even if an attacker does gain access to the native VLAN, there are no hosts on it, so thereās nothing to attack.
These will always use VLAN 1. Take a look at this post to learn more about that:
Yes, you can do this using the vlan dot1q tag native command. If you do this, a trunk will always tag outgoing frames (the native VLAN setting is ignored, and all frames are tagged with a corresponding tag value.). Any incoming untagged frames that arrive at such a trunk port will be dropped.
The following lesson describes such a security issue:
@lagapidis Thanks you Sir For clearing my Doubtsā¦!
If i am not wrong , even if i will change the native vlan to something else other than 1 ,still the L2 control protocols will use the vlan 1 ā¦Right ??
Yes, that is correct. Protocols such as VTP, CDP PagP, and STP will always use VLAN 1 even if VLAN1 is not allowed, and even if VLAN 1 is not the native VLAN. Such frames will always be processed by switches on VLAN 1. The only exception is DTP, which always uses the native VLAN. So DTP may not function correctly if there is a native VLAN mismatch.
If you have a native VLAN mismatch, the actual trunk will still function correctly if the allowed VLANs are configured correctly on both ends of the trunk. Traffic sent to and from those VLANs will not be affected at all. However, there are two issues that occur when a native VLAN mismatch occurs.
First, any frames associated with the native VLANs configured on either end of the link do not successfully propagate across the trunk link. For example, the DTP protocol uses the configured native VLAN to operate. If there is a mismatch, it will fail.
Secondly, a mismatch can also cause unauthorized access to a particular VLAN. This is called VLAN leaking. For example, if you have VLAN 10 configured as the native VLAN on one end, and VLAN 11 on the other, you may have traffic from VLAN 10 on one switch leak into VLAN 11 on the other.
Hi the command vlan dot1q tag native didnāt worked on cisco packet tracer . would you recommend any simulator or emulator for switching labs ? my system is core i3 .
Yes, Packet Tracer doesnāt support all of the commands. You can use any one of GNS3, Cisco CML, or EVE-NG for most labs, for both routing and switching. Iāve used GNS3 as well as CML, and theyāre both excellent. I havenāt used EVE-NG but from what I hear it too is more than sufficient for what you need.
CML is no problem for any PC, since its processing power is online, and you simply log in to the interface. It is a paid service, however, but itās quite economical. GNS3 is free, but you must install it locally. Even with an i3, you should be able to get GNS3 running for small topologies if you configure it correctly. Simply follow the instructions on the GNS3 site, they are quite comprehensive and detailed.
Hi Rene,
i donāt quite understand the effect of the vlan dot1q tag native command on untagged frames like UDLD,STP etc.
On the CCIE Enterprise Infrastructure course there is the below explanation. we can also configure our switches to tag the native VLAN just like any other VLAN. Hereās how to do it: SW1(config)#vlan dot1q tag native
On a google search i found the below. Use the vlan dot1q tag native command to configure the switch to tag the traffic received on the native VLAN and to admit only the 802.1Q-tagged frame, dropping any untagged traffic, including untagged traffic in the native VLAN
So, the L2 untagged traffic like STP and UDLD will be droped when it will be exchanged on a trunk link between switches?
First, letās take a look at control traffic without the use of the vlan dot1q tag native command.
L2 control traffic such as CDP, VTP, PAgP, and UDLD will always use VLAN 1 over a trunk link, even if VLAN 1 is not allowed on that trunk. If the Native VLAN is VLAN 1, then these control frames will remain untagged. If the Native VLAN is something other than VLAN 1, then the control frames will be tagged with VLAN 1.
DTP is the only exception, where it will always be sent over the native VLAN.
Now, if you enable the vlan dot1q tag native command on a trunk port, the following will occur:
Native VLAN frames going out of a trunk port will be tagged.
Untagged frames received on a trunk port will be dropped.
If the native VLAN is something other than VLAN 1, this has no effect on L2 control traffic. If the native VLAN is VLAN 1, then control traffic will simply be tagged. For the case of DTP, which always uses the native VLAN, such frames will always be tagged.
So you see, this command doesnāt hinder the exchange of L2 control traffic in any way.
Still I am not clear betweent tag and untagged frame, If both are carying VLAN id 1 or any .
According to me tag frame carry vlan id and untagged frame/Native frame carry only default vlan id 1. But as you said Native VLAN can be changed from VLAN1 to something else. So what is the different between tag and untagged frame?
Here you can see that the tag includes a VLAN Identifier field which indicates the VLAN to which the tag belongs.
Now frames are tagged only on a trunk. A frame is tagged with its VLAN ID on egress of a trunk interface of a switch, and that tag is read and then removed upon ingress of a trunk interface on the other end of the link.
On egress, the switch knows what VLAN ID to place in the tag because the frame comes from a particular VLAN. On ingress, the switch reads the tag, places the frame in the correct VLAN, and removes the tag.
Now, where does the native VLAN come in? It tells a switch on which VLAN any untagged frames arriving on a trunk port should be placed. So if an untagged frame arrives on a trunk port, the switch has no idea on which VLAN to place it, because there is no indication of VLAN ID on the frame. So, it places it on the configured native VLAN.
if i have a Trunk Link , and we have multiple Vlans , assumed Ā“that vlan 1 is eliminated on Trunk . which Vlan among all Vlans is the best one for native Vlans selection on Trunk Link ?
As you suggest, it is always a good idea to change the native VLAN on a trunk from VLAN 1 due to security issues. So what VLAN should you use as the native VLAN? It can be any value. Typically the native VLAN ID is a value that is not used anywhere else. I often use 99 or 999 or some other distinct value to remember that that is the native VLAN.
