Examkin

Question

Difficulty: Very hardInterswitch Connectivity and Trunking (802.1Q)

An engineer is troubleshooting a Layer 2 connectivity issue between Switch-1 and Switch-2 connected via GigabitEthernet0/1. A host in VLAN 10 connected to Switch-1 is unable to reach a host in VLAN 10 on Switch-2. A partial CLI output from Switch-1 is shown below:

text
Switch-1# show interfaces gigabitethernet 0/1 switchport
Name: Gi0/1
Administrative Mode: dynamic auto
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
Administrative Native VLAN tagging: disabled
Trunking VLANs Enabled: 10,20,30

Switch-2's GigabitEthernet0/1 interface is configured as an 802.1Q trunk with `switchport trunk native vlan 20` and allows VLANs 10, 20, and 30. CDP logs on both switches generate regular native VLAN mismatch warnings.

Assuming global native VLAN tagging (`vlan dot1q tag native`) is disabled on both switches, how will Switch-2 process an untagged ARP request broadcast generated by the host in VLAN 10 on Switch-1 when it arrives at Switch-2's GigabitEthernet0/1 interface?

  1. Switch-2 will accept the untagged frame and forward it internally into VLAN 20, preventing VLAN 10 hosts on Switch-2 from receiving the ARP request.Answer
  2. B
    Switch-2 will drop the frame immediately at the ingress physical layer because the 802.1Q header contains a VLAN ID of 10 that conflicts with Switch-2's native VLAN.
  3. C
    Switch-2 will use CDP TLV metadata to dynamically rewrite the internal frame tag to VLAN 10 before forwarding it to access ports.
  4. D
    Switch-2 will place the trunk port into a Spanning Tree PortFast blocking state, preventing all frame ingress until the mismatch is cleared.

Answer

Switch-2 will accept the untagged frame and forward it internally into VLAN 20, preventing VLAN 10 hosts on Switch-2 from receiving the ARP request.
Under standard 802.1Q operation without global native VLAN tagging, frames originating on the native VLAN of an egress trunk interface are sent untagged. Switch-1's native VLAN is 10, so VLAN 10 traffic is transmitted without an 802.1Q header. When Switch-2 receives an untagged frame on a trunk port, it automatically maps that frame to its own configured native VLAN, which is VLAN 20. As a result, the ARP broadcast leaks into VLAN 20 on Switch-2, failing to reach hosts on VLAN 10.

Step-by-Step Solution

1
Analyze Switch-1 trunk egress behavior for VLAN 10 traffic.
Switch-1 has native VLAN configured as VLAN 10 without global native VLAN tagging enabled. Therefore, frames belonging to VLAN 10 are transmitted across the 802.1Q trunk link without an 802.1Q VLAN tag.
By default in 802.1Q trunking, traffic belonging to the configured native VLAN is sent untagged.
2
Analyze Switch-2 trunk ingress behavior for untagged frames.
Switch-2 receives an untagged frame on GigabitEthernet0/1. According to 802.1Q standard operations, any untagged frame received on a trunk interface is automatically mapped to that interface's configured native VLAN.
Switch-2's configured native VLAN is VLAN 20.
3
Determine internal forwarding destination and traffic impact.
The untagged ARP request from VLAN 10 on Switch-1 is forwarded internally into VLAN 20 on Switch-2. Hosts on VLAN 10 attached to Switch-2 never receive the broadcast ARP frame.
Native VLAN mismatch causes cross-VLAN traffic leaking into the receiving switch's native VLAN rather than maintaining isolation or reaching the intended source VLAN.

Key Concept

802.1Q Native VLAN Untagged Ingress Forwarding and Mismatch Mechanics
Estimated Time:2m 0s
Rate this question

Topics

Interswitch Connectivity and Trunking (802.1Q)

More questions from this topic