CCNA Show Interfaces Trunk Questions

PBQhard

You are connected to R1. Configure R1 and SW1 so that hosts in VLAN 10 (192.168.10.0/24) and VLAN 20 (192.168.20.0/24) can communicate via the router-on-a-stick setup. The current configuration has errors: the trunk port between SW1 and R1 has a native VLAN mismatch, VLAN 30 is not allowed on the trunk, and the subinterface encapsulation is incorrect. Correct these issues and enable inter-VLAN routing.

Network Topology

Hints

•Check the native VLAN on both ends of the trunk: R1's subinterface .30 should use the native keyword.
•Ensure VLAN 30 is allowed on the SW1 trunk; you may need to add it to the allowed list.
•Enable ip routing globally on R1 to route between VLANs.

A.On R1, configure interface GigabitEthernet0/0.30 with encapsulation dot1Q 99 native; on SW1, allow VLAN 30 on the trunk interface.

B.On R1, configure interface GigabitEthernet0/0.30 with encapsulation dot1Q 30; on SW1, remove VLAN 30 from the trunk allowed list.

C.On R1, configure interface GigabitEthernet0/0.30 with encapsulation dot1Q 30; on SW1, set the native VLAN to 1 on the trunk.

D.On R1, configure interface GigabitEthernet0/0.30 with encapsulation dot1Q 30; on SW1, configure the trunk to allow only VLANs 10 and 20.

AnswerA

solution

! R1
configure terminal
interface GigabitEthernet0/0.30
encapsulation dot1Q 30 native
exit
interface GigabitEthernet0/0
no shutdown
exit
ip routing
exit
copy running-config startup-config

Why this answer

The native VLAN on SW1 is 99 but R1's physical interface defaults to VLAN 1, causing a mismatch. To fix this, R1's subinterface Gi0/0.30 must be set with encapsulation dot1Q 99 native, making R1's native VLAN 99 and matching SW1. VLAN 30 is not allowed on the trunk, preventing any traffic in that VLAN; it must be added to the trunk's allowed list on SW1.

After these corrections, inter-VLAN routing for VLANs 10 and 20 will function correctly.

Exam trap

Candidates often assume that setting a subinterface's encapsulation to 'dot1Q 30 native' will fix any mismatch, but the native VLAN ID must be explicitly aligned with the switch's native VLAN configuration.

Why the other options are wrong

The specific factual error: VLAN 30 must be allowed on the trunk for the router to receive and forward traffic for that VLAN.

The specific factual error: The native VLAN must match on both ends of the trunk; changing SW1 to VLAN 1 would not resolve the mismatch with R1's native VLAN 30.

The specific factual error: The trunk must allow all VLANs that need to be routed, including the native VLAN (30), otherwise the router cannot communicate with hosts in VLAN 30.

Practice this question →

MCQhard

After configuring a trunk port to allow VLAN 40, a technician finds that VLAN 40 is not listed among the VLANs in spanning tree forwarding state in the show interfaces trunk output. What is the most likely cause?

A.The trunk port is using ISL encapsulation, which does not support VLAN 40.

B.The technician omitted the 'add' keyword when adding VLAN 40 to the allowed list, so the trunk no longer permits VLAN 40.

C.VLAN 40 has not been created in the VLAN database on the switch.

D.VTP pruning is enabled, and VLAN 40 is not needed by any downstream neighbor, so it is pruned from this trunk.

AnswerC

A VLAN must be defined in the local VLAN database for the switch to build a spanning-tree instance and forward frames for that VLAN. If it is permitted on the trunk but does not exist, the switch marks it as pruned and it will not appear in the 'VLANs in spanning tree forwarding state' list. This is the exact symptom presented.

Why this answer

Even if a VLAN is included in the trunk's allowed list, the switch cannot forward frames for that VLAN unless it exists in the local VLAN database. A non-existent VLAN is placed in a pruned state and will not appear as forwarding in show interfaces trunk. The allowed-list command worked, but the missing VLAN definition prevents the VLAN from being active on the trunk.

Exam trap

Option B: the classic mistake of omitting the 'add' keyword when modifying the allowed list is tempting because it is a very common trunk configuration error. However, that error would result in the VLAN not even appearing in the allowed list column, not simply missing from the forwarding state. The question states the VLAN was added to the allowed list, so the missing VLAN database entry is the correct culprit.

Why the other options are wrong

Candidates might associate VLAN support with trunk encapsulation types, but ISL fully supports VLAN 40. This is a distractor.

This is a common operational mistake, but the resulting output would show VLAN 40 missing from the 'Vlans allowed' column, not from the forwarding list.

Candidates might confuse local pruning (due to non-existent VLAN) with VTP pruning. VTP pruning would also require a multi-switch VTP domain and is less likely in a standalone troubleshooting scenario.

Practice this question →

MCQhard

A network technician is troubleshooting a connectivity issue for a PC connected to switch port Gi1/0/12. The PC can ping its default gateway (192.168.10.1) but cannot ping a server at 192.168.20.10. The switch is configured with VLAN 10 for the access port and is connected to a router-on-a-stick. The technician runs 'show vlan brief' and 'show interfaces trunk' on the switch. What is the most likely cause of the problem?

A.The trunk port Gi1/0/24 is not in trunking mode.

B.The router is missing a subinterface for VLAN 20.

C.The switch port Gi1/0/12 is not assigned to VLAN 10.

D.The PC has a duplicate IP address with the server.

AnswerB

The PC in VLAN 10 can ping its gateway, but VLAN 20 traffic cannot be routed because the router lacks a subinterface for VLAN 20.

Why this answer

The PC can ping its default gateway (192.168.10.1) but not the server at 192.168.20.10, indicating Layer 3 routing is failing between VLANs. Since the switch is configured with VLAN 10 for the access port and uses a router-on-a-stick, the router must have a subinterface for VLAN 20 to route traffic to the server's subnet. The absence of a subinterface for VLAN 20 prevents the router from forwarding packets from VLAN 10 to VLAN 20, making option B correct.

Exam trap

Cisco often tests the misconception that a trunk misconfiguration (option A) is the cause, but the PC's ability to ping the gateway confirms the trunk is working for VLAN 10, so the real issue is the missing subinterface for the destination VLAN.

Why the other options are wrong

The trunk port Gi1/0/24 is in 'on' mode and trunking, as shown in 'show interfaces trunk'. Therefore, the trunk is operational and not the cause of the issue.

The 'show vlan brief' output shows that port Gi1/0/12 is assigned to VLAN 10, so the PC is in the correct VLAN. This is not the issue.

A duplicate IP address would cause connectivity issues to the gateway as well, but the PC can ping the gateway successfully. Therefore, duplicate IP is not the problem.

Practice this question →

MCQhard

A network technician notices CDP native VLAN mismatch warnings between switches SW1 and SW2 on their trunk link. The technician runs 'show interfaces trunk' on SW1 and sees native VLAN 1, then on SW2 and sees native VLAN 99. Data traffic is currently passing, but the mismatch can cause broadcast loops. What should the technician do next?

A.Add VLAN 99 to the allowed VLAN list on the trunk interface of SW1.

B.Remove the trunk configuration and set both interfaces as access ports in VLAN 1.

C.Enable spanning‑tree PortFast on the trunk ports.

D.Configure the native VLAN to match on both ends of the trunk.

AnswerD

The root cause is a configured native VLAN mismatch (1 vs 99). Changing one switch’s native VLAN to match the other (or setting both to a common VLAN) immediately resolves the CDP warning and eliminates the potential for broadcast loops caused by the mismatch. This is the most direct and least disruptive next step.

Why this answer

The correct action is to configure the native VLAN to match on both ends of the trunk. CDP reports a native VLAN mismatch when the native VLANs differ on the two sides of a trunk link. Although data traffic may still pass because 802.1Q does not tag frames on the native VLAN, the mismatch can cause broadcast loops and security risks, as frames from one native VLAN may be misinterpreted on the other side.

Setting both sides to the same native VLAN (e.g., VLAN 1 or VLAN 99) resolves the mismatch and ensures proper Layer 2 behavior.

Exam trap

Cisco often tests the misconception that data traffic passing means the configuration is fine, but the trap here is that the native VLAN mismatch can still cause serious issues like broadcast loops and security vulnerabilities, even if user data appears to work.

Why the other options are wrong

Common misconception: the warning message implies a VLAN is not allowed, but native VLAN mismatch means the trunk ports disagree on the native VLAN, not that a VLAN is missing from the allowed list.

Over‑reaction: candidates might think a trunk problem requires eliminating the trunk, but the correct approach is to correct the native VLAN parameter on the existing trunk.

Wrong feature: PortFast addresses access port convergence, not VLAN mismatches. Candidates may reach for any familiar command, but it targets the wrong layer and port type.

Practice this question →

MCQhard

A switch displays the following output: Switch# show interfaces trunk Port Mode Encapsulation Status Native vlan Gi1/0/24 on 802.1q trunking 99 Port Vlans allowed on trunk Gi1/0/24 10,20,30 Port Vlans active in management domain Gi1/0/24 10,20,30,40 Users in VLAN 40 cannot reach resources across this trunk. What is the most likely reason?

A.VLAN 40 is active, so spanning tree must be blocking it

B.VLAN 40 is not in the native VLAN, so it cannot cross the trunk

C.VLAN 40 is not permitted on the trunk

D.802.1Q trunks can carry only three VLANs at a time

AnswerC

Correct. This is correct. The allowed VLAN list controls which VLANs are transported across the trunk. Because VLAN 40 is absent from that list, users in VLAN 40 cannot use that trunk to reach resources on the far side.

Why this answer

The trunk is not carrying VLAN 40 because VLAN 40 is missing from the allowed VLAN list (only 10, 20, 30 are allowed). Option A is incorrect because spanning tree does not block VLANs by default without evidence of a loop; the output shows no STP blocking. Option B is incorrect because native VLAN only affects tagging, not whether a VLAN can traverse a trunk; all VLANs can cross a trunk if permitted.

Option D is incorrect because 802.1Q can carry up to 4094 VLANs, not just three. The key distinction is that a VLAN may be active on the switch but still fail to cross a specific trunk if it is not in the allowed list.

Exam trap

Ensure you differentiate between VLANs configured on the switch and those allowed on the trunk. Just because a VLAN is active doesn't mean it's allowed on a trunk.

Why the other options are wrong

Spanning Tree Protocol (STP) can block a VLAN if there is a loop, but the output shows VLAN 40 is active in the management domain and not listed as blocked. The explicit absence of VLAN 40 from the allowed VLAN list is the direct cause, not STP.

The native VLAN is only for untagged traffic on an 802.1Q trunk. All other VLANs are tagged and can cross the trunk regardless of the native VLAN. VLAN 40 is not the native VLAN, but that does not prevent it from being carried if permitted.

802.1Q has no limit of three VLANs per trunk; it can support up to 4094 VLANs. The output shows only three VLANs allowed because of configuration, not a protocol limitation.

Practice this question →

Multi-Selectmedium

Which TWO statements are true regarding switch port configuration for access, voice, and trunk ports?

Select 2 answers

A.A switch port configured as a trunk port can simultaneously carry untagged traffic for the native VLAN and tagged traffic for multiple other VLANs.

B.When a port is configured with both an access VLAN and a voice VLAN, the switchport must be set to trunk mode.

C.The switchport mode dynamic auto command sets the port to actively attempt to form a trunk if the neighbor initiates negotiation.

D.An access port with a voice VLAN configured sends CDP or LLDP information to the IP phone to identify the voice VLAN.

E.Issuing the switchport trunk allowed vlan command automatically includes the native VLAN in the allowed list, so it never needs to be explicitly added.

AnswersA, D

Trunk ports support one native VLAN (untagged) and allow tagged traffic for additional VLANs listed in the allowed VLAN list.

Why this answer

Option A is correct because a trunk port, by definition, carries untagged frames for the native VLAN (typically VLAN 1 unless changed) and simultaneously carries tagged frames for all other VLANs allowed on the trunk. This behavior is fundamental to IEEE 802.1Q trunking, where the native VLAN is the only VLAN whose frames are sent untagged to maintain backward compatibility with devices that do not understand VLAN tagging.

Exam trap

Cisco often tests the distinction between 'dynamic auto' and 'dynamic desirable' DTP modes, where candidates mistakenly think 'auto' actively initiates trunk negotiation, when in fact it only responds to incoming DTP messages.

Why the other options are wrong

Multi-VLAN access ports (access + voice) stay in access mode; trunk mode is not required and would incorrectly pass all VLANs.

Dynamic desirable actively initiates, but dynamic auto is passive.

When you prune the allowed VLANs, any omitted VLANs (including the native VLAN) are blocked unless added back.

Practice this question →

MCQhard

A network engineer has enabled DHCP snooping on a Catalyst switch to prevent rogue DHCP servers. All access ports in VLAN 10 are untrusted. A router attached to a trunk port on the switch acts as the default gateway for VLAN 10 and is configured with the ip helper-address 10.1.2.5, which points to a remote DHCP server. After enabling DHCP snooping, hosts in VLAN 10 cannot obtain IP addresses; packet captures show DHCPDISCOVER messages are sent, but no DHCPOFFER is received. What is the most likely cause?

A.The router's ip helper-address command is pointing to an incorrect DHCP server IP address.

B.The switch port connecting to the router is not configured as a trusted port for DHCP snooping.

C.The DHCP server is on a different subnet, so the switch needs a switched virtual interface (SVI) in VLAN 10 with an IP address for Layer 3 connectivity.

D.DHCP snooping is dropping DHCPDISCOVER messages because the client access ports are untrusted.

AnswerB

DHCP snooping trusts only designated ports to forward DHCP server messages. Since the router relays the DHCPOFFER onto the trunk port, an untrusted port will cause the switch to discard the offer, resulting in DHCP failure.

Why this answer

DHCP snooping treats all ports as untrusted by default. When a router acting as a DHCP relay is connected to an untrusted trunk port, the switch drops DHCPOFFER messages received from the router because they originate from an untrusted interface. Configuring the trunk port as trusted allows DHCP server responses (OFFER, ACK) to pass through to clients.

Exam trap

Cisco often tests the distinction that DHCP snooping blocks DHCP server messages (OFFER/ACK/NAK) on untrusted ports, not client messages (DISCOVER/REQUEST), leading candidates to incorrectly assume client messages are dropped.

Why the other options are wrong

This distractor exploits the common tendency to blame the helper address configuration first, overlooking the security feature that silently drops the returning DHCPOFFER.

This plays on the misconception that a switch requires an IP address on the client VLAN to facilitate DHCP, when in fact the router acting as the relay agent provides Layer 3 connectivity.

This misinterprets DHCP snooping behavior: it assumes all DHCP traffic is filtered on untrusted ports, overlooking the critical distinction that only server-side messages are blocked, not client requests.

Practice this question →

Drag & Dropmedium

Drag and drop the following steps into the correct order to create VLANs, assign access ports, configure 802.1Q trunks, set the native VLAN, and verify with 'show vlan brief' and 'show interfaces trunk'.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

VLANs must be created before assigning ports; trunking is configured after access ports; verification is the final step.

Exam trap

Do not confuse the order of VLAN creation and port assignment. VLANs must be created before ports can be assigned to them. Also, native VLAN configuration is part of trunk configuration and should be done after trunk mode is set.

Practice this question →

PBQhard

You are troubleshooting inter-VLAN routing on a router-on-a-stick setup. R1 is connected to SW1 via trunk port G0/0. VLANs 10, 20, and 30 exist on SW1, and R1 should route between them. Currently, hosts in VLAN 10 can communicate with VLAN 20 but cannot reach VLAN 30. Review the provided configuration and fix the issue.

Network Topology

Hints

•Check the VLAN ID used in the encapsulation on each subinterface.
•Compare the subinterface VLAN ID with the actual VLAN number for that subnet.
•Use 'show interfaces trunk' on the switch to confirm which VLANs are active.

A.Change the encapsulation on subinterface G0/0.30 to dot1Q 30 and reapply the IP address.

B.Add a subinterface for native VLAN 1 on R1 and assign an IP address.

C.Enable IP routing on R1 with the 'ip routing' command.

D.Change the allowed VLAN list on the trunk to include VLAN 30.

AnswerA

solution

! R1
interface GigabitEthernet0/0.30
no encapsulation dot1Q 100
encapsulation dot1Q 30
no ip address 192.168.30.1 255.255.255.0
ip address 192.168.30.1 255.255.255.0
end

Why this answer

The subinterface for VLAN 30 (G0/0.30) is misconfigured with encapsulation dot1Q 100 instead of dot1Q 30, so R1 cannot forward packets to VLAN 30. VLAN 20 is correctly set up, which is why VLAN 10-to-VLAN 20 pings succeed. Changing the encapsulation to dot1Q 30 and reapplying the IP address restores full inter-VLAN routing.

IP routing is enabled by default, so no additional command is needed; the native VLAN does not require a subinterface because no hosts are in that VLAN.

Exam trap

Do not confuse the subinterface number with the VLAN ID; they can be different, but the encapsulation must match the actual VLAN. Also, remember that IP routing is enabled by default on routers, and the native VLAN does not require a subinterface unless routing for that VLAN is needed.

Why the other options are wrong

The native VLAN is untagged on the trunk, and R1 can handle it via the physical interface if needed, but a missing subinterface for native VLAN 1 is not the cause of the issue.

IP routing is already enabled; the issue is a configuration error on the subinterface, not a missing global command.

The trunk configuration is correct; the problem is the encapsulation mismatch on the router subinterface.

Practice this question →

PBQmedium

You are connected to the console of R1. The network administrator reports that hosts on VLAN 10 cannot ping the default gateway (192.168.10.1). R1's GigabitEthernet0/1 is connected to a switch with trunk port allowing VLAN 10 and 20. The interface configuration on R1 appears correct, but the VLAN 10 interface is not operational.

Network Topology

Hints

•Check the status of the subinterface.
•Verify that the physical interface is not administratively down.
•Confirm that the encapsulation command is correct.

A.The physical interface GigabitEthernet0/1 was administratively down.

B.The VLAN 10 subinterface was configured with the wrong encapsulation dot1q VLAN ID.

C.The switch port connected to R1 was not configured as a trunk.

D.The VLAN 10 subinterface was missing the 'no shutdown' command.

AnswerA

solution

! R1
interface GigabitEthernet0/1
no shutdown
interface GigabitEthernet0/1.10
encapsulation dot1Q 10
ip address 192.168.10.1 255.255.255.0

Why this answer

The GigabitEthernet0/1 interface was administratively down (missing 'no shutdown' in the initial config). Although the subinterface had 'no shutdown', the physical interface must also be up. Bringing up the physical interface resolved the issue.

Exam trap

Do not assume that subinterfaces can be independently brought up; always check the physical interface state first. A common trap is to focus on subinterface configuration while ignoring the parent interface.

Why the other options are wrong

The specific factual error is that the subinterface would still show as up/up (though traffic would not be forwarded) if the encapsulation were wrong; the problem is the physical interface being down.

The specific factual error is that the switch trunk configuration is given as correct; the problem is on the router side, not the switch.

The specific factual error is that subinterfaces do not have an independent administrative state; they rely on the physical interface being up.

MCQhard

A network engineer notices that a newly connected switch-to-switch link is up, but traffic from multiple VLANs is not passing. When issuing the show interfaces trunk command, no trunk ports are listed. Both switch ports are configured with switchport mode dynamic auto. What is the most likely cause?

A.There is a native VLAN mismatch between the two switches.

B.The connecting cable is a straight-through Ethernet cable rather than a crossover cable.

C.One switch lacks a VLAN that exists on the other switch.

D.Both ports are set to dynamic auto, so neither switch initiates DTP negotiation.

AnswerD

In dynamic auto mode, a switch port passively waits for DTP negotiation requests. When both ends are dynamic auto, no side initiates the negotiation, so the ports default to access mode. This perfectly matches the symptom: the link is up, but no trunk appears under show interfaces trunk, and multi-VLAN traffic is not passing.

Why this answer

When both ends of a link are set to switchport mode dynamic auto, neither switch will initiate DTP negotiation. Dynamic auto responds only to DTP requests; it never sends them. Therefore, no DTP messages are exchanged, and both ports silently remain in access mode.

This explains why the link is up and passing traffic only for the access VLAN, and no trunk ports appear in the output. Other issues (native VLAN mismatch, straight-through cable, missing VLANs) do not prevent trunk formation—they affect operational behavior or management reporting but would still show a trunk interface if DTP negotiation succeeded.

Exam trap

Many candidates incorrectly believe a native VLAN mismatch prevents trunk formation because they confuse DTP negotiation failure with CDP/STP native VLAN mismatch errors. In reality, DTP does not check native VLAN compatibility; a trunk will still form and then generate log messages about the mismatch.

Why the other options are wrong

Confusing DTP trunk negotiation with the operational consequences of a native VLAN mismatch.

Assuming that a crossover cable is mandatory for switch-to-switch connections, ignoring auto-MDIX.

Mistaking the ability to forward traffic for a specific VLAN with the ability to negotiate a trunk.

Practice this question →

MCQhard

An administrator notices that hosts in VLAN 30 on SW1 cannot communicate with hosts in VLAN 30 on SW2, even though both switches are connected via an 802.1Q trunk. Traffic for VLANs 10 and 20 passes without issues across the same trunk. The trunk is configured to allow all VLANs, and the allowed VLAN list explicitly includes VLAN 30. What is the most likely cause of the problem?

A.The native VLAN is mismatched between SW1 and SW2, and VLAN 30 is the native VLAN on one side.

B.The trunk encapsulation is set to ISL on one switch and 802.1Q on the other.

C.Spanning Tree Protocol has placed VLAN 30 in a blocking state on the trunk link.

D.The switched virtual interface (SVI) for VLAN 30 on SW1 is administratively down.

AnswerA

A native VLAN mismatch causes one switch to send untagged frames for VLAN 30 while the other expects tagged frames, so the receiving switch cannot associate the untagged traffic with VLAN 30, leading to a communication failure only for that VLAN.

Why this answer

The most likely cause is a native VLAN mismatch. When the native VLAN is mismatched on an 802.1Q trunk, traffic for the native VLAN is not tagged, so frames from VLAN 30 on one switch are received as untagged frames on the other switch and placed into the switch's configured native VLAN. If the native VLAN on one side is VLAN 30 and on the other side is a different VLAN (e.g., VLAN 1), the hosts in VLAN 30 cannot communicate because the frames are interpreted as belonging to different VLANs.

Traffic for VLANs 10 and 20 passes because they are not the native VLAN and are properly tagged.

Exam trap

Cisco often tests the native VLAN mismatch scenario by describing a trunk that works for most VLANs but fails for one specific VLAN, leading candidates to incorrectly suspect STP blocking or SVI issues instead of recognizing the native VLAN mismatch.

Why the other options are wrong

This would cause a complete trunk failure, not a failure limited to a single VLAN.

STP would not randomly block one VLAN on a point-to-point trunk while the rest are forwarding; this is not a typical behavior.

Layer 2 switching within the same VLAN does not require an SVI; an SVI is only needed for routing between VLANs or management.

Practice this question →

MCQhard

A network engineer is troubleshooting connectivity between two hosts in different VLANs on the same switch. Host A in VLAN 10 (10.10.10.5/24) cannot ping Host B in VLAN 20 (10.10.20.5/24). The switch is configured as a router-on-a-stick with a trunk port to an external router. The trunk port is up/up, but inter-VLAN routing fails. What is the most likely cause?

A.The trunk port is not in trunking mode; it is in dynamic desirable mode.

B.The native VLAN on the switch trunk is VLAN 1, but the router subinterface for VLAN 1 is not configured with the 'native' keyword or is missing.

C.The VLANs are not allowed on the trunk; the allowed VLAN list is missing VLAN 10 and 20.

D.The switch ports Gi0/4 and Gi0/5 are in access mode but not assigned to the correct VLANs.

AnswerC

When an allowed VLAN list on a trunk is configured and does not include VLAN 10 and VLAN 20, all tagged frames from those VLANs are dropped, causing inter-VLAN routing failure even though the trunk is up/up.

Why this answer

The most likely cause is that the allowed VLAN list on the trunk is missing VLAN 10 and 20. Even though the trunk port is up/up, if the switch's allowed VLAN list has been restricted (for example, using the switchport trunk allowed vlan command) and does not include those VLANs, all frames tagged with VLAN 10 or 20 will be discarded at the trunk. This directly prevents inter-VLAN routing despite the trunk being operational, whereas a native VLAN mismatch only affects untagged traffic and would not impact the tagged frames between the two hosts.

Exam trap

A common trap is assuming an up/up trunk automatically passes traffic for all VLANs, overlooking that the allowed VLAN list can be manually pruned and must include every VLAN that needs to traverse the trunk.

Why the other options are wrong

Dynamic desirable mode can still form a trunk if the other side is willing; the trunk is already up/up, so the port mode is not the issue.

A native VLAN mismatch or missing native subinterface only affects untagged frames; the hosts in VLAN 10 and VLAN 20 send tagged traffic, so this would not break their routing.

The hosts' access port configurations would prevent intra-VLAN communication if misassigned, but the question describes an inter-VLAN routing failure through the trunk, not a problem with the access ports themselves.

Practice this question →

MCQhard

Two switches are connected by a trunk. VLAN 50 exists on both switches, but traffic still fails across the link. The allowed VLAN list is correct. Which additional item should be checked next?

A.Check for a trunk mismatch such as native VLAN inconsistency or other trunk-parameter problems.

B.Reset OSPF process IDs on both switches.

C.Add ip helper-address under every access interface.

D.Disable the MAC address table.

AnswerA

This is correct because VLAN permission alone does not guarantee the trunk is healthy end to end.

Why this answer

After confirming that the VLAN exists on both switches and is allowed on the trunk, another important item to verify is whether the trunk itself is actually operational with the expected encapsulation and whether there is a native VLAN or other trunk inconsistency. In plain language, just because the VLAN is listed does not guarantee the trunk is healthy in every relevant way. Trunking problems can still occur because of broader configuration mismatches.

This question is about disciplined troubleshooting. Once the obvious allowed-list issue is ruled out, the next step is to keep checking other trunk-related characteristics rather than jumping immediately to unrelated routing or service features. The correct answer is the one that stays grounded in trunk-specific verification.

Exam trap

Don't jump to unrelated issues like spanning tree or IP configuration when the problem is clearly trunk-related.

Why the other options are wrong

Resetting OSPF process IDs does not address VLAN traffic issues over a trunk link, as OSPF is a routing protocol and unrelated to Layer 2 VLAN configurations.

Adding an ip helper-address is irrelevant to VLAN traffic issues across a trunk link, as this command is used for forwarding DHCP requests, not for resolving VLAN connectivity problems.

Disabling the MAC address table would not resolve VLAN traffic issues across a trunk link, as it pertains to Layer 2 forwarding and would disrupt normal switch operations, leading to further connectivity problems.

Practice this question →

MCQhard

A network administrator is configuring a Layer 2 EtherChannel between two switches. Switch A uses 'channel-group 1 mode active', and Switch B uses 'channel-group 1 mode desirable'. All member interfaces are trunk ports with identical allowed VLANs. The EtherChannel fails to form. What is the most likely cause?

A.The switches are using different EtherChannel negotiation protocols.

B.A Layer 2 EtherChannel cannot carry trunk links.

C.The channel-group number must be different on each switch.

D.The member interfaces must be in access mode before the bundle can form.

AnswerA

LACP active cannot form a channel with PAgP desirable.

Why this answer

The two switches are using different negotiation protocols: LACP (active) on one side and PAgP (desirable) on the other. EtherChannel requires both sides to use the same protocol, so this protocol mismatch prevents the bundle from forming. The other settings—trunking, VLAN configuration, and channel-group number—are correctly configured and do not cause the failure.

Exam trap

Ensure both sides of an EtherChannel use the same negotiation protocol; mismatches are a common setup error.

Why the other options are wrong

This option is incorrect because a Layer 2 EtherChannel can indeed carry trunk links, allowing multiple VLANs to be transmitted over the same logical link. The issue with the EtherChannel not forming is more likely related to mismatched negotiation protocols or other configuration errors.

This option is wrong because the channel-group number must be the same on both switches for an EtherChannel to form. Different numbers would prevent the aggregation of the links.

This option is wrong because a Layer 2 EtherChannel can indeed carry trunk links, allowing multiple VLANs to be transmitted over the same link. Therefore, the inability to form the EtherChannel is not due to the mode of the member interfaces.

Practice this question →

PBQmedium

You are connected to SW1 via the console. SW1 is a Layer 2 switch connected to router R1 via trunk port G0/1. The trunk is currently using VLAN 1 as native VLAN, but the network administrator wants to change the native VLAN to VLAN 99 for security. Configure the trunk on G0/1 to use native VLAN 99 and verify.

Hints

•The native VLAN is configured per trunk interface.
•Use show interfaces trunk to see allowed VLANs and native VLAN.

A.SW1(config)# interface g0/1 SW1(config-if)# switchport trunk native vlan 99 SW1(config-if)# end SW1# show interfaces trunk

B.SW1(config)# interface g0/1 SW1(config-if)# switchport trunk allowed vlan 99 SW1(config-if)# end SW1# show vlan brief

C.SW1(config)# vlan 99 SW1(config-vlan)# name Native SW1(config-vlan)# exit SW1(config)# interface g0/1 SW1(config-if)# switchport mode trunk SW1(config-if)# switchport trunk native vlan 99 SW1(config-if)# end SW1# show interfaces trunk

D.SW1(config)# interface g0/1 SW1(config-if)# switchport trunk native vlan 99 SW1(config-if)# end SW1# show vlan id 99

AnswerA

solution

! SW1
interface GigabitEthernet0/1
switchport trunk native vlan 99

Why this answer

Changing the native VLAN on a trunk prevents VLAN hopping attacks. The native VLAN carries untagged traffic; here it is changed from default VLAN 1 to VLAN 99.

Exam trap

The exam trap is confusing the 'switchport trunk native vlan' command with 'switchport trunk allowed vlan' or thinking that you need to create the VLAN or re-enter trunk mode. Also, ensure you use the correct verification command: 'show interfaces trunk' shows native VLAN, not 'show vlan'.

Why the other options are wrong

The specific factual error is confusing the allowed VLAN list with the native VLAN configuration. The native VLAN is set with 'switchport trunk native vlan', not 'switchport trunk allowed vlan'.

The specific factual error is including extra steps that are not needed. The trunk already exists, so 'switchport mode trunk' is redundant. Creating VLAN 99 is also unnecessary if it already exists or is not required for the native VLAN change.

The specific factual error is using the wrong verification command. 'show interfaces trunk' is needed to see trunk parameters including native VLAN.

MCQmedium

A switch shows this output from the "show interfaces trunk" command: Gi0/1 on 802.1q trunking 1 Gi0/2 auto 802.1q not-trunking 1 Which statement is correct?

A.Gi0/1 is an access port in VLAN 1

B.Gi0/1 is trunking, and Gi0/2 is waiting for DTP negotiation

C.Gi0/2 is forced to trunk mode

D.Neither interface can carry tagged traffic

AnswerB

Correct. Gi0/1 is trunking now; Gi0/2 is in a passive DTP negotiation state.

Why this answer

Gi0/1 is already operating as an 802.1Q trunk. Gi0/2 is in dynamic auto mode, which waits for the other side to actively negotiate trunking.

Exam trap

Beware of confusing 'on' with access mode and misunderstanding dynamic auto's capability to negotiate trunking.

Why the other options are wrong

This option is incorrect because Gi0/1 is configured as a trunk port, not an access port, and it is actively trunking VLANs. Access ports do not participate in VLAN tagging and would not show trunking status.

This option is incorrect because Gi0/2 is set to 'auto' for trunking, meaning it is not forced into trunk mode but is instead waiting for Dynamic Trunking Protocol (DTP) negotiation to determine if it should become a trunk port.

This option is incorrect because Gi0/1 is configured as a trunk port and can carry tagged traffic, while Gi0/2 is in a state waiting for DTP negotiation, which means it can potentially become a trunk port as well.

Practice this question →

MCQhard

A network engineer notices that Host A in VLAN 10 (10.10.10.50/24) can successfully ping its default gateway 10.10.10.1, but cannot ping the VLAN 20 SVI (10.20.20.1) or any hosts in VLAN 20. The SVIs for both VLAN 10 and VLAN 20 are in an up/up state, and the switch's trunk ports are correctly allowing both VLANs. What is the most likely cause?

A.The ip routing global configuration command is missing.

B.The VLAN 20 SVI is administratively shut down.

C.The trunk between the access switch and the Layer 3 switch is misconfigured as an access port.

D.The default gateway on Host A is configured incorrectly.

AnswerA

The missing 'ip routing' command prevents the Layer 3 switch from performing routing between VLANs, even though the SVIs are up and hosts can reach their own gateways.

Why this answer

Host A can reach its default gateway (10.10.10.1), which is the VLAN 10 SVI, but cannot reach the VLAN 20 SVI (10.20.20.1) or any hosts in VLAN 20. This indicates that Layer 2 connectivity is working (trunk allows both VLANs, SVIs are up/up), but inter-VLAN routing is failing. On a multilayer switch, inter-VLAN routing requires the global command 'ip routing' to enable the switch's IP routing engine; without it, the switch acts as a Layer 2 device only and cannot forward packets between different VLANs.

Exam trap

Cisco often tests the distinction between a switch operating as a Layer 2 device versus a Layer 3 device, and the trap here is that candidates assume SVIs in an up/up state automatically provide inter-VLAN routing, forgetting the mandatory 'ip routing' command.

Why the other options are wrong

Candidates may overlook the explicit mention that the SVIs are up/up, mistakenly thinking a shut SVI could be the problem.

Trunk misconfiguration is a common inter-VLAN issue, but the scenario explicitly says the trunks are working properly, making this answer invalid.

The successful ping to the default gateway proves the gateway is correct. Without 'ip routing', the switch can't forward packets from VLAN 10 to VLAN 20, but it can respond to local VLAN requests.

Practice this question →

MCQhard

A network engineer notices that a workstation in VLAN 10 cannot communicate with hosts in VLAN 20. The workstation is connected to an access layer switch port that shows 'up/up' in show ip interface brief. The switch's trunk port to the router is up, and the router's sub-interface for VLAN 10 is also in an up/up state. The router-on-a-stick configuration appears operational, but inter-VLAN traffic still fails. What is the most likely cause?

A.The switch port to the workstation is incorrectly configured as a trunk instead of an access port.

B.The native VLAN on the trunk between the switch and router is mismatched.

C.VLAN 10 is not allowed on the trunk link.

D.The router sub-interface for VLAN 10 is missing the encapsulation dot1q command.

AnswerD

In router-on-a-stick, each sub-interface must be mapped to a VLAN with the 'encapsulation dot1q <vlan>' command. Without it, the sub-interface cannot identify or tag frames for VLAN 10, so it never processes them, despite showing up/up. This perfectly explains why the workstation can't reach other VLANs.

Why this answer

The router-on-a-stick configuration requires each sub-interface to use the `encapsulation dot1q <vlan-id>` command to tag traffic with the correct VLAN ID. Without this command, the sub-interface will not accept or forward frames tagged for VLAN 10, even if the interface is administratively up. Since the workstation in VLAN 10 can reach its local gateway but not VLAN 20, the missing encapsulation is the most likely cause.

Exam trap

Cisco often tests the misconception that a sub-interface being 'up/up' guarantees it is fully operational for inter-VLAN routing, when in fact the missing `encapsulation dot1q` command leaves the sub-interface unable to process tagged frames.

Why the other options are wrong

Candidates may confuse the access port configuration with a trunk, but the stem explicitly states the port shows 'up/up' in show ip interface brief, which does not indicate trunk status.

Native VLAN mismatch is a common troubleshooting issue, but it only affects untagged traffic on the native VLAN—not tagged VLANs like VLAN 10.

Candidates often assume the allowed VLAN list is the culprit, but default trunk behavior permits all VLANs unless explicitly pruned, and the stem gives no indication of pruning.

Practice this question →