CCNA Show Interfaces Trunk Questions

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

VLAN 40 must exist in the local VLAN database before it can participate in spanning tree on a trunk port. Even if the trunk is configured to allow VLAN 40, if the VLAN has not been created on the switch, the spanning tree protocol will not place it in a forwarding state. The 'show interfaces trunk' output will list only VLANs that are both allowed and existent, so the absence of VLAN 40 in the forwarding state indicates it was never created.

Exam trap

Cisco often tests the distinction between allowing a VLAN on a trunk and actually creating the VLAN in the VLAN database—candidates mistakenly assume that configuring the trunk alone is sufficient for the VLAN to be operational.

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

This is the correct answer because the router is configured for router-on-a-stick inter-VLAN routing but only has a subinterface for VLAN 10. Since the router lacks a subinterface with the appropriate 802.1Q encapsulation and an IP address in the VLAN 20 subnet, it simply drops or ignores VLAN 20 frames arriving over the trunk. Even though the switch and trunk are configured correctly, VLAN 20 hosts have no default gateway on the router and therefore cannot route traffic to VLAN 10 or any other network.

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 →

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 →

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 switch ports are configured with switchport mode dynamic auto, neither actively initiates Dynamic Trunking Protocol (DTP) negotiation. DTP dynamic auto ports wait for the other side to send DTP frames to form a trunk; since both sides are passive, the link remains in access mode and does not become a trunk, preventing traffic from multiple VLANs from passing.

Exam trap

Cisco often tests the subtle difference between dynamic auto (passive) and dynamic desirable (active) DTP modes, leading candidates to incorrectly assume that two dynamic auto ports will automatically form a trunk.

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

A trunk with VLAN 50 allowed on both ends is only a prerequisite for Layer 2 connectivity; native VLAN mismatch or an inconsistent allowed VLAN list can still cause VLAN 50 frames to be tagged with the wrong VLAN ID or dropped entirely. Verifying trunk encapsulation (802.1Q), trunk mode (desirable/trunk), and especially native VLAN consistency is the correct next step because these parameters govern whether frames in VLAN 50 are correctly forwarded across the link.

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

Switch A is configured for Link Aggregation Control Protocol (LACP) using `mode active`, whereas Switch B is configured for Port Aggregation Protocol (PAgP) using `mode desirable`. LACP and PAgP are distinct EtherChannel negotiation protocols. For an EtherChannel to establish using a negotiation protocol, both connected switches must utilise the identical protocol, as they are incompatible with each other. This protocol mismatch directly causes the EtherChannel to fail.

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

The output shows Gi0/1 with DTP mode 'on' and the operational state 'trunking' with 802.1Q encapsulation, meaning it is actively carrying tagged frames for multiple VLANs. Gi0/2 is in 'auto' mode, a passive DTP setting that neither initiates nor advertises trunking but listens for DTP frames from its neighbor. If the neighbor is set to 'on' or 'desirable', Gi0/2 will successfully negotiate and become a trunk as well; until then, it remains in a waiting/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 'ip routing' global configuration command is what enables IPv4 forwarding between VLANs on a multilayer switch. With SVIs created and IP addresses assigned, the switch can answer pings to those addresses for local subnet traffic, but it will not route packets between VLANs unless 'ip routing' is enabled. Since Host A can successfully ping 10.10.10.1 (its own SVI gateway) but fails to reach Host B on VLAN 20, the missing command precisely explains the failure: the switch is essentially acting as a host on each VLAN rather than a router.

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 →