Refer to the exhibit. How will switch SW2 handle traffic from VLAN 10 on SW1?
Refer to the exhibit. How will switch SW2 handle traffic from VLAN 10 on SW1?
Switch SW2 will drop the traffic. This is due to a native VLAN mismatch between SW1 and SW2. On SW1, VLAN 10 is configured as the native VLAN, while on SW2, VLAN 100 is configured as the native VLAN. Traffic from the native VLAN is sent untagged. When SW2 receives untagged traffic, it tries to associate it with its native VLAN, which is VLAN 100. However, VLAN 100 is not included in the allowed VLANs on the trunk (only VLANs 5-20 are allowed). As a result, the traffic does not get processed and is dropped.
Answer given correct - SW1 trunk native vlan 10 command will drop the tag from any Vlan 10 traffic and send it out to SW2 without a tag SW2 see's untagged traffic from SW1 and applies it to Native Vlan 100. Earlier question on this site where the answer also states that even though switches will report a Native Vlan mismatch, they will still pass traffic and essentially merge these 2 Vlan's together (unwanted scenario and switch will continue to throw warnings).
But VLAN 100 is not allowed (5-20), so it would get dropped if it thinks the traffic is for VLAN 100.
It's a native VLAN mismatch, SW2 VLAN 100 will process the traffic from SW1 VLAN 10 because it is untagged, and untagged traffic goes into the native VLAN.
ChatGPT: Native VLAN is always allowed because it is the VLAN used for device management in a VLAN network. It is not considered a regular user VLAN, but an infrastructure VLAN. This is why it is always allowed on a trunk port, regardless of the "switchport trunk native vlan" command configured on the port.
The fact that the community is split on this means I am going to have trouble trusting the answers from you all as a whole. The answer is B. Do not believe anything else. If traffic is in a native VLAN it is UNTAGGED, meaning it does not have an assignment. One switch interprets untagged as VLAN 10, the other as VLAN 100, so if untagged so the identification of VLAN is based on location. It will remain untagged where ever it goes but switches will identify it as they have been told.
facts. Im a novice with a year of experience and only been studying by watching jeremy IT on youtube and i chose B
Tested in my LAB. C is the answer.
B is correct
B its correct
It´s C. Consulted and tested with CCIE guys
Simply B in my eyes
https://learningnetwork.cisco.com/s/article/effects-of-mismatched-native-vlans-on-a-trunk-link Native Vlan mismatched
Answer B
I did this on gns3 to verify and yes it does drop the frame. I am going with answer c If using ##sh interfaces trunk## you dont see native vlan on allowed vlan section then any untagged frame will be dropped. I hope this will help or you guys can further verify on lab yourself and even leave reply on the thread
In order for PC1 and PC2 to communicate, they must be on the same VLAN, or there must be a router or a layer 3 switch to route the traffic between VLAN 10 and VLAN 100. This process is known as Inter-VLAN routing.
Certainly! When using a trunk between two switches, the native VLAN is considered untagged traffic. The rest of the frames belong to specific VLANs and are tagged to include the VLAN information, allowing them to be forwarded to their destinations1. However, it’s essential to note that the native VLAN must be the same on both sides of the trunk. If it’s not explicitly configured, it defaults to VLAN 1 therefore D is the correct answer
Seems Sw2 would tag the packet for VLAN 100, but then what ? Since the PC is in VLAN 5, and there is nothing in the shown config to say otherwise, the switch should discard the packet.
I think C is correct. Because when two switch are directly connected and connected interface is configured different native VLAN native VLAN mismatch will happen and traffic will be dropped.
A native VLAN mismatch can cause traffic to be dropped, misrouted, or broadcasted to unintended devices
When there is a native VLAN mismatch, the 2 different native VLANs will merge and form one single broadcast domain.
https://www.ciscopress.com/articles/article.asp?p=2181837&seqNum=9