CCNA Show Interfaces Trunk Questions

MCQmedium

A network administrator is configuring a new Cisco Catalyst switch and needs to ensure that the native VLAN for 802.1Q trunk port GigabitEthernet1/0/1 is VLAN 99, which is not the default. The administrator enters the command 'switchport trunk native vlan 99' on the interface. However, after applying the configuration, the administrator notices that untagged traffic from the native VLAN is not being forwarded correctly. What is the most likely cause of this issue?

A.VLAN 99 must be created in the VLAN database before it can be used as the native VLAN.

B.The native VLAN configuration requires the 'switchport mode trunk' command to be applied first.

C.The native VLAN must be configured on both ends of the trunk link, and the other end is still using the default native VLAN.

D.The command 'switchport trunk native vlan 99' is only valid on access ports, not on trunk ports.

AnswerC

For 802.1Q trunks, the native VLAN must match on both ends; otherwise, untagged traffic is interpreted differently, causing forwarding failures or VLAN mismatches. The other end likely still uses VLAN 1, so untagged frames are placed into VLAN 1 instead of VLAN 99, breaking connectivity for that VLAN.

Why this answer

The native VLAN on an 802.1Q trunk must be consistent on both ends. If one side uses VLAN 99 and the other uses VLAN 1, untagged frames are classified differently, leading to connectivity problems for devices in the native VLAN. Ensuring both switches use the same native VLAN resolves the issue.

Exam trap

The trap here is assuming that configuring the native VLAN on one side is sufficient, overlooking the requirement for matching native VLANs on both ends of a trunk.

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

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 →

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

A trunk port uses IEEE 802.1Q tagging to carry frames from multiple VLANs simultaneously, but it handles the native VLAN uniquely by leaving those frames untagged as they traverse the trunk. All other VLANs in the allowed list are transmitted with 802.1Q tags, allowing a single physical link to carry many logical networks. The native VLAN is designated with 'switchport trunk native vlan' and is subject to the allowed VLAN list, so if that list is pruned, the native VLAN may also be excluded unless explicitly left in.

Why this answer

Option A is correct because an 802.1Q trunk port transmits frames for the native VLAN untagged while tagging frames for all other allowed VLANs, allowing one link to carry both native and multiple tagged VLANs simultaneously. Option D is correct because when a voice VLAN is configured on an access port, the switch uses CDP (or LLDP-MED) to advertise the voice VLAN ID to the attached IP phone, which then tags its voice traffic with that VLAN. Option B is wrong because a port with both an access VLAN and a voice VLAN is configured as an access port with the 'switchport voice vlan' command, not as a trunk.

Option C is wrong because 'switchport mode dynamic auto' only passively waits for the neighbor to initiate trunking; it is 'dynamic desirable' that actively attempts to form a trunk. Option E is wrong because the native VLAN is not automatically added to the allowed VLAN list by 'switchport trunk allowed vlan'; it must be explicitly included if it is to be permitted on the trunk.

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 →

MCQmedium

A network administrator is configuring DHCP snooping on a Cisco Catalyst switch. The switch has a trunk port Gi1/0/24 connecting to another switch, and several access ports connecting to end-user PCs. The administrator issues the commands 'ip dhcp snooping', 'ip dhcp snooping vlan 10', and then configures interface Gi1/0/24 with 'ip dhcp snooping trust'. A PC connected to Gi1/0/5 (an untrusted port) sends a DHCPDISCOVER. What will the switch do with this DHCPDISCOVER message?

A.Drop the DHCPDISCOVER because only trusted ports can send DHCP messages.

B.Forward the DHCPDISCOVER to trusted ports only, and drop any DHCPOFFER received on untrusted ports.

C.Forward the DHCPDISCOVER to all ports in VLAN 10, including untrusted access ports.

D.Convert the untrusted port to a trusted port automatically after receiving the first DHCPDISCOVER.

AnswerB

With DHCP snooping enabled on VLAN 10, the switch treats Gi1/0/5 as untrusted by default. It allows client-originated DHCPDISCOVER messages to be forwarded toward trusted ports (such as the uplink to the DHCP server) but blocks DHCP server replies like DHCPOFFER on untrusted ports. This prevents rogue DHCP servers on access ports while permitting legitimate client requests.

Why this answer

When DHCP snooping is enabled on a VLAN, switch ports are untrusted by default. Client DHCP messages such as DHCPDISCOVER are allowed from untrusted ports and forwarded toward trusted ports. Server messages such as DHCPOFFER, DHCPACK, and DHCPNAK are dropped if received on untrusted ports.

Trusting the uplink port allows legitimate server replies to enter the switch while blocking rogue DHCP servers on access ports.

Exam trap

The trap here is assuming that untrusted ports cannot send any DHCP messages, when in fact they can send client-originated requests but cannot receive server replies.

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 or tap steps into the slots.

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 →

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 →

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 →

MCQeasy

A network technician is connecting a new access switch to an existing distribution switch. The access switch will carry multiple VLANs, and the technician wants to ensure that the link is configured as a trunk and that only VLANs 10, 20, and 30 are allowed. Which command should be used on the access switch interface to restrict the allowed VLANs?

A.switchport access vlan 10,20,30

B.switchport trunk allowed vlan add 10,20,30

C.switchport trunk native vlan 10,20,30

D.switchport trunk allowed vlan 10,20,30

AnswerD

This command explicitly sets the allowed VLAN list on a trunk port to only VLANs 10, 20, and 30. By default, all VLANs are allowed on a trunk, so this command is necessary to restrict traffic. It is the correct way to limit VLANs on a Cisco switch trunk interface. The other options either add to the existing list or are used for different purposes, making this the right choice.

Why this answer

To restrict a trunk port to specific VLANs, the 'switchport trunk allowed vlan' command with a list of VLAN IDs is used. This replaces the default allowed list (all VLANs) with the specified ones. The 'add' keyword would append rather than replace, and other commands either set native VLAN or are for access ports.

Thus, the correct command is the one that sets the allowed VLAN list directly.

Exam trap

The trap here is confusing the 'add' keyword with the base command; using 'add' would not remove the default all-VLANs allowance.

Practice this question →