Show Interfaces Trunk practice questions

You are connected to a Multilayer Switch MLS1. Configure the switch so that interface GigabitEthernet1/0/1 is an access port for VLAN 10, with voice VLAN 110 for an IP phone, and enable PoE. Additionally, interface GigabitEthernet1/0/2 must be an access port for VLAN 20 to connect an AP. Verify the configuration using 'show interfaces switchport' and 'show power inline'.

Exhibit

Current running-config (partial):
!
hostname MLS1
!
vlan 10
 name DATA
!
vlan 20
 name AP
!
vlan 110
 name VOICE
!
interface GigabitEthernet1/0/1
 description IP Phone Port
!
interface GigabitEthernet1/0/2
 description AP Port
!
interface Vlan1
 ip address 192.168.1.1 255.255.255.0
 no shutdown
!
line con 0
 logging synchronous
 exit

Trap 1: interface GigabitEthernet1/0/1 switchport mode trunk switchport…

This is incorrect because Gi1/0/1 is configured as a trunk port instead of an access port. While a trunk can carry multiple VLANs, the requirement is for an access port with a voice VLAN. The 'switchport mode trunk' command changes the port to trunk mode, which is not desired.

Trap 2: interface GigabitEthernet1/0/1 switchport mode access switchport…

This is incorrect because 'power inline never' disables PoE on Gi1/0/1, preventing the IP phone from receiving power. The requirement explicitly states to enable PoE. The correct command is 'power inline auto' (or no command, as auto is default).

Trap 3: interface GigabitEthernet1/0/1 switchport mode access switchport…

This is incorrect because the access VLAN and voice VLAN are swapped. The access VLAN should be 10 (data) and the voice VLAN should be 110 (voice). This misconfiguration would place the IP phone's data traffic in VLAN 110 and voice traffic in VLAN 10, which is not the requirement.

A
interface GigabitEthernet1/0/1 switchport mode access switchport access vlan 10 switchport voice vlan 110 power inline auto interface GigabitEthernet1/0/2 switchport mode access switchport access vlan 20
This configuration correctly sets Gi1/0/1 as an access port in VLAN 10, assigns voice VLAN 110, and enables PoE (auto is default). Gi1/0/2 is correctly set as an access port in VLAN 20. The 'show interfaces switchport' and 'show power inline' commands will verify these settings.
B
interface GigabitEthernet1/0/1 switchport mode trunk switchport trunk allowed vlan 10,110 power inline auto interface GigabitEthernet1/0/2 switchport mode access switchport access vlan 20
Why wrong: This is incorrect because Gi1/0/1 is configured as a trunk port instead of an access port. While a trunk can carry multiple VLANs, the requirement is for an access port with a voice VLAN. The 'switchport mode trunk' command changes the port to trunk mode, which is not desired.
C
interface GigabitEthernet1/0/1 switchport mode access switchport access vlan 10 switchport voice vlan 110 power inline never interface GigabitEthernet1/0/2 switchport mode access switchport access vlan 20
Why wrong: This is incorrect because 'power inline never' disables PoE on Gi1/0/1, preventing the IP phone from receiving power. The requirement explicitly states to enable PoE. The correct command is 'power inline auto' (or no command, as auto is default).
D
interface GigabitEthernet1/0/1 switchport mode access switchport access vlan 110 switchport voice vlan 10 power inline auto interface GigabitEthernet1/0/2 switchport mode access switchport access vlan 20
Why wrong: This is incorrect because the access VLAN and voice VLAN are swapped. The access VLAN should be 10 (data) and the voice VLAN should be 110 (voice). This misconfiguration would place the IP phone's data traffic in VLAN 110 and voice traffic in VLAN 10, which is not the requirement.

Question 2hardScenario

You are connected to SW1. Two switches, SW1 and SW2, are connected via four GigabitEthernet links. Configure LACP EtherChannel between them using interfaces GigabitEthernet0/1 through GigabitEthernet0/4 on SW1. Set the channel-group mode to active on SW1. The port-channel interface must be configured as a trunk, allowing VLANs 10, 20, 30. However, the EtherChannel is not forming. The current configuration is shown below. Identify and fix the issue, then verify the EtherChannel is operational.

Network Topology

Trap 1: Change the channel-group mode on the member interfaces from active…

This is incorrect because the mode mismatch is not the issue; both sides can use active mode. Changing to passive would still work if the other side is active, but it does not fix the Layer 2/Layer 3 mismatch.

Trap 2: Add the 'switchport nonegotiate' command to the member interfaces.

Adding 'switchport nonegotiate' to the member interfaces disables Dynamic Trunking Protocol (DTP) on those ports, which only stops automatic trunk negotiation. It does nothing to align the Layer 3 nature of Port-channel1 (configured with 'no switchport' and an IP address) with the Layer 2 member switchports. The EtherChannel fails because the port-channel interface itself is a routed interface while the members are Layer 2 switchports; without converting the port-channel to Layer 2 trunk mode, this command cannot resolve the mismatch.

Trap 3: Configure the member interfaces with 'channel-group 1 mode on'…

Changing the channel-group mode from 'active' to 'on' forces the EtherChannel to form without LACP negotiation, bypassing the protocol-state check. However, 'mode on' does not alter the fundamental Layer 2/Layer 3 incompatibility: the member interfaces are Layer 2 switchports, whereas Port-channel1 has been configured as a Layer 3 interface with 'no switchport' and an IP address. The switch still enforces interface-layer consistency for bundling, so even forced mode fails until the port-channel is changed to a Layer 2 trunk.

A
Remove 'no switchport' and IP address from Port-channel1, then configure 'switchport mode trunk' and 'switchport trunk allowed vlan 10,20,30'.
The EtherChannel fails because Port-channel1 is configured as a Layer 3 interface (no switchport, IP address) while the member ports are Layer 2 switchports. This mismatch prevents bundling. Converting Port-channel1 to a Layer 2 trunk with the same allowed VLANs resolves the issue.
B
Change the channel-group mode on the member interfaces from active to passive.
Why wrong: This is incorrect because the mode mismatch is not the issue; both sides can use active mode. Changing to passive would still work if the other side is active, but it does not fix the Layer 2/Layer 3 mismatch.
C
Add the 'switchport nonegotiate' command to the member interfaces.
Why wrong: Adding 'switchport nonegotiate' to the member interfaces disables Dynamic Trunking Protocol (DTP) on those ports, which only stops automatic trunk negotiation. It does nothing to align the Layer 3 nature of Port-channel1 (configured with 'no switchport' and an IP address) with the Layer 2 member switchports. The EtherChannel fails because the port-channel interface itself is a routed interface while the members are Layer 2 switchports; without converting the port-channel to Layer 2 trunk mode, this command cannot resolve the mismatch.
D
Configure the member interfaces with 'channel-group 1 mode on' instead of active.
Why wrong: Changing the channel-group mode from 'active' to 'on' forces the EtherChannel to form without LACP negotiation, bypassing the protocol-state check. However, 'mode on' does not alter the fundamental Layer 2/Layer 3 incompatibility: the member interfaces are Layer 2 switchports, whereas Port-channel1 has been configured as a Layer 3 interface with 'no switchport' and an IP address. The switch still enforces interface-layer consistency for bundling, so even forced mode fails until the port-channel is changed to a Layer 2 trunk.

Question 3mediumdrag order

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

5Step 5

Trap 1: Assign access ports, create VLANs, configure 802.1Q trunks, set…

Attempting to assign access ports before creating the VLANs violates the fundamental dependency that the VLAN must exist in the switch's VLAN database for the port assignment to be valid. If the VLAN is not yet defined, the switch either rejects the 'switchport access vlan' command or creates an implicit VLAN dynamically, leading to inconsistent configuration that may not match the design intent. The correct sequence is to first create the VLANs globally, then assign access ports, and only after those steps should trunking and native VLAN configuration be considered.

Trap 2: Create VLANs, assign access ports, set native VLAN, configure…

Setting the native VLAN before enabling 802.1Q trunking is logically flawed because the native VLAN parameter applies exclusively to trunk interfaces and is either ignored or rejected while the port is in access mode. On most Cisco switches, the command may be accepted but silently stored without taking effect until the interface is changed to trunk mode, potentially causing confusion during troubleshooting. Therefore, the native VLAN must be configured after the trunk has been established, ensuring the trunk can properly handle untagged frames on the correct VLAN.

Trap 3: Assign access ports, configure 802.1Q trunks, create VLANs, set…

This ordering errs twice: it assigns access ports and configures trunking before VLANs exist, and it also creates VLANs after trunk configuration, which is far too late for the earlier commands to remain valid. Without a populated VLAN database, the access ports cannot be correctly mapped to their intended VLANs, and trunks have no valid VLANs to carry across the link. The proper process is to create VLANs first, then assign access ports, then configure 802.1Q trunks, and finally set the native VLAN, with verification performed after all steps to ensure the configuration matches the intended design.

A
Create VLANs, assign access ports, configure 802.1Q trunks, set native VLAN, verify with 'show vlan brief' and 'show interfaces trunk'
VLANs must be created before any switchport can reference them, so building the VLAN database first is mandatory. With the VLANs in place, access ports can be assigned to their respective broadcast domains using 'switchport access vlan', after which trunk interfaces are configured via 'switchport mode trunk' and 802.1Q encapsulation if required. The native VLAN is a trunk-specific property that only becomes meaningful after the trunk is operational, so it is set last with 'switchport trunk native vlan'. Finally, 'show vlan brief' validates VLAN existence and access port membership, while 'show interfaces trunk' confirms trunking parameters and the active native VLAN.
B
Assign access ports, create VLANs, configure 802.1Q trunks, set native VLAN, verify with 'show vlan brief' and 'show interfaces trunk'
Why wrong: Attempting to assign access ports before creating the VLANs violates the fundamental dependency that the VLAN must exist in the switch's VLAN database for the port assignment to be valid. If the VLAN is not yet defined, the switch either rejects the 'switchport access vlan' command or creates an implicit VLAN dynamically, leading to inconsistent configuration that may not match the design intent. The correct sequence is to first create the VLANs globally, then assign access ports, and only after those steps should trunking and native VLAN configuration be considered.
C
Create VLANs, assign access ports, set native VLAN, configure 802.1Q trunks, verify with 'show vlan brief' and 'show interfaces trunk'
Why wrong: Setting the native VLAN before enabling 802.1Q trunking is logically flawed because the native VLAN parameter applies exclusively to trunk interfaces and is either ignored or rejected while the port is in access mode. On most Cisco switches, the command may be accepted but silently stored without taking effect until the interface is changed to trunk mode, potentially causing confusion during troubleshooting. Therefore, the native VLAN must be configured after the trunk has been established, ensuring the trunk can properly handle untagged frames on the correct VLAN.
D
Assign access ports, configure 802.1Q trunks, create VLANs, set native VLAN, verify with 'show vlan brief' and 'show interfaces trunk'
Why wrong: This ordering errs twice: it assigns access ports and configures trunking before VLANs exist, and it also creates VLANs after trunk configuration, which is far too late for the earlier commands to remain valid. Without a populated VLAN database, the access ports cannot be correctly mapped to their intended VLANs, and trunks have no valid VLANs to carry across the link. The proper process is to create VLANs first, then assign access ports, then configure 802.1Q trunks, and finally set the native VLAN, with verification performed after all steps to ensure the configuration matches the intended design.

Question 4mediumdrag order

Drag and drop the following steps into the correct order to configure an LACP EtherChannel on two Cisco switches using active mode.

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

5Step 5

A
Enter interface configuration mode for the physical ports (interface range gigabitethernet 0/1-2).
The initial step is to enter interface configuration mode for the member ports, typically via the interface range command (e.g., interface range gigabitethernet 0/1-2). This is mandatory because the channel-group command is only available in interface configuration mode, not in global configuration mode. Using a range ensures the same settings are applied consistently to both physical ports, which is a prerequisite for forming a single logical bundle.
B
Configure the channel-group for the interfaces using mode active (channel-group 1 mode active).
Executing channel-group 1 mode active on the physical interfaces is critical because it enables LACP negotiation. The active mode instructs the switch to actively send LACP PDUs and respond to the peer, allowing the EtherChannel to form regardless of whether the peer is configured as active or passive. This standard-based approach differs from PAgP and ensures interoperability with other vendors; the channel-group number (here 1) links the physical ports to the logical Port-Channel interface.
C
Optionally configure the Port-Channel interface (for example, switchport mode trunk).
While the Port-Channel interface is automatically created when a channel-group is configured, it is optional but highly recommended to apply Layer 2 settings (such as switchport mode trunk) directly to the logical interface. This guarantees that all member ports share identical VLAN and trunking parameters, avoiding conflicts that could cause inconsistent forwarding or spanning-tree loops. Without these settings on the Port-Channel, the bundle may form but traffic might not pass correctly, especially if the default access VLAN behavior is not intended.
D
Verify the EtherChannel status with the show etherchannel summary command.
Verification with show etherchannel summary is essential after configuration to confirm that the EtherChannel is actually operational. This command displays the protocol (LACP), the Port-Channel number, and the status of each member interface, typically showing SU and P flags for an up, layer 2 bundle. It reveals problems such as mismatched modes, physical port errors, or ports that failed to join due to mismatched parameters. This step is the last line of defense before relying on the bundle in production traffic.

Question 5hardmultiple choice

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?

Trap 1: The trunk port is using ISL encapsulation, which does not support…

ISL encapsulation supports VLANs 1–1005, so VLAN 40 is within the valid range. Modern Cisco switches default to 802.1Q, and if encapsulation were mismatched the trunk would likely be down. The root cause is not encapsulation.

Trap 2: The technician omitted the 'add' keyword when adding VLAN 40 to the…

When the 'add' keyword is omitted, the allowed list is overwritten and all previously allowed VLANs are removed. In that case, the show interfaces trunk command would not show VLAN 40 in the allowed list at all, contradicting the symptom of it being allowed but not in forwarding state.

Trap 3: VTP pruning is enabled, and VLAN 40 is not needed by any downstream…

VTP pruning removes VLAN traffic from trunks when no downstream switch has ports in that VLAN, but it requires a VTP domain and is a separate feature. Without any indication of VTP configuration, the most likely reason a single VLAN is missing from the forwarding list after being allowed is that the VLAN itself has not been created.

A
The trunk port is using ISL encapsulation, which does not support VLAN 40.
Why wrong: ISL encapsulation supports VLANs 1–1005, so VLAN 40 is within the valid range. Modern Cisco switches default to 802.1Q, and if encapsulation were mismatched the trunk would likely be down. The root cause is not encapsulation.
B
The technician omitted the 'add' keyword when adding VLAN 40 to the allowed list, so the trunk no longer permits VLAN 40.
Why wrong: When the 'add' keyword is omitted, the allowed list is overwritten and all previously allowed VLANs are removed. In that case, the show interfaces trunk command would not show VLAN 40 in the allowed list at all, contradicting the symptom of it being allowed but not in forwarding state.
C
VLAN 40 has not been created in the VLAN database on the switch.
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.
D
VTP pruning is enabled, and VLAN 40 is not needed by any downstream neighbor, so it is pruned from this trunk.
Why wrong: VTP pruning removes VLAN traffic from trunks when no downstream switch has ports in that VLAN, but it requires a VTP domain and is a separate feature. Without any indication of VTP configuration, the most likely reason a single VLAN is missing from the forwarding list after being allowed is that the VLAN itself has not been created.

Question 6hardmultiple choice

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?

Trap 1: Add VLAN 99 to the allowed VLAN list on the trunk interface of SW1.

Even if VLAN 99 were added to the allowed list, the native VLANs would still be mismatched. The CDP warning is about the inconsistency of the untagged VLAN, not about VLAN 99 being absent from the allowed list. Untagged traffic would continue to be placed into different VLANs on each switch, preserving the loop risk.

Trap 2: Remove the trunk configuration and set both interfaces as access…

This action is unnecessarily disruptive. The trunk is working (data traffic flows), so removing it would break connectivity across switches. The issue is only a configuration mismatch, which can be fixed without changing the port type. This skips the straightforward corrective step and introduces a network outage.

Trap 3: Enable spanning‑tree PortFast on the trunk ports.

PortFast is designed for access ports (edge ports) to bypass listening and learning states. Applying PortFast to a trunk port is inappropriate and would not resolve the native VLAN mismatch. It also risks creating immediate forwarding loops, worsening the problem.

A
Add VLAN 99 to the allowed VLAN list on the trunk interface of SW1.
Why wrong: Even if VLAN 99 were added to the allowed list, the native VLANs would still be mismatched. The CDP warning is about the inconsistency of the untagged VLAN, not about VLAN 99 being absent from the allowed list. Untagged traffic would continue to be placed into different VLANs on each switch, preserving the loop risk.
B
Remove the trunk configuration and set both interfaces as access ports in VLAN 1.
Why wrong: This action is unnecessarily disruptive. The trunk is working (data traffic flows), so removing it would break connectivity across switches. The issue is only a configuration mismatch, which can be fixed without changing the port type. This skips the straightforward corrective step and introduces a network outage.
C
Enable spanning‑tree PortFast on the trunk ports.
Why wrong: PortFast is designed for access ports (edge ports) to bypass listening and learning states. Applying PortFast to a trunk port is inappropriate and would not resolve the native VLAN mismatch. It also risks creating immediate forwarding loops, worsening the problem.
D
Configure the native VLAN to match on both ends of the trunk.
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.

Question 7hardmultiple choice

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?

Trap 1: There is a native VLAN mismatch between the two switches.

A native VLAN mismatch does not prevent a trunk from forming. DTP negotiates trunking irrespective of native VLAN assignment. A mismatch will allow the trunk to come up but cause CDP/STP notifications and possible untagged traffic leakage, yet the trunk interface appears in show interfaces trunk.

Trap 2: The connecting cable is a straight-through Ethernet cable rather…

Modern Cisco switches support auto-MDIX, which automatically adjusts the interface to work with either a straight-through or crossover cable. A cable type mismatch would not prevent the link from coming up or forming a trunk. The link is already up, so this is not the cause.

Trap 3: One switch lacks a VLAN that exists on the other switch.

Trunk formation does not require identical VLAN databases. Trunk negotiation uses DTP, not VLAN presence. A missing VLAN would result in traffic for that VLAN being discarded or not forwarded, but the trunk itself would still be established and shown as a trunk port.

A
There is a native VLAN mismatch between the two switches.
Why wrong: A native VLAN mismatch does not prevent a trunk from forming. DTP negotiates trunking irrespective of native VLAN assignment. A mismatch will allow the trunk to come up but cause CDP/STP notifications and possible untagged traffic leakage, yet the trunk interface appears in show interfaces trunk.
B
The connecting cable is a straight-through Ethernet cable rather than a crossover cable.
Why wrong: Modern Cisco switches support auto-MDIX, which automatically adjusts the interface to work with either a straight-through or crossover cable. A cable type mismatch would not prevent the link from coming up or forming a trunk. The link is already up, so this is not the cause.
C
One switch lacks a VLAN that exists on the other switch.
Why wrong: Trunk formation does not require identical VLAN databases. Trunk negotiation uses DTP, not VLAN presence. A missing VLAN would result in traffic for that VLAN being discarded or not forwarded, but the trunk itself would still be established and shown as a trunk port.
D
Both ports are set to dynamic auto, so neither switch initiates DTP negotiation.
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.

Question 8hardmultiple choice

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?

Exhibit

Switch#show vlan brief

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gi1/0/1, Gi1/0/2, Gi1/0/3
10   Sales                            active    Gi1/0/12
20   Engineering                      active    Gi1/0/15
1002 fddi-default                     act/unsup
1003 token-ring-default               act/unsup
1004 fddinet-default                  act/unsup
1005 trnet-default                    act/unsup

Switch#show interfaces trunk

Port        Mode         Encapsulation  Status        Native vlan
Gi1/0/24    on           802.1q         trunking      1

Port        Vlans allowed on trunk
Gi1/0/24    1-4094

Port        Vlans allowed and active in management domain
Gi1/0/24    1,10,20

Port        Vlans in spanning tree forwarding state and not pruned
Gi1/0/24    1,10,20

Trap 1: The trunk port Gi1/0/24 is not in trunking mode.

The trunk port Gi1/0/24 is not the cause because the switch output explicitly shows Gi1/0/24 in a trunking state, with the administrative mode set to 'on' and the operational mode as trunk. If the trunk were not functioning, VLAN 20 frames would not reach the router at all, but the router would still need a subinterface to accept them. Since the trunk is up and carrying VLAN 10 and 20 traffic as expected, this option is incorrect.

Trap 2: The switch port Gi1/0/12 is not assigned to VLAN 10.

The switch port Gi1/0/12 is not the problem because the 'show vlan brief' output clearly lists Gi1/0/12 as an access port assigned to VLAN 10, which matches the PC's expected VLAN. If the port were in the wrong VLAN, the PC would not be able to reach its VLAN 10 gateway at all, yet it can ping that gateway successfully. Thus, the PC's Layer 2 connectivity is correct, and the fault must lie upstream in the routing configuration.

Trap 3: The PC has a duplicate IP address with the server.

A duplicate IP address between the PC and the server would cause address conflicts, typically resulting in intermittent connectivity, ARP table instability, and both devices struggling to communicate. However, the PC can successfully ping its VLAN 10 gateway, which proves its IP stack and addressing are functional and unique on the local segment. The observed problem is isolated to inter-VLAN routing to VLAN 20, which a duplicate IP would not selectively cause, so this option is wrong.

A
The trunk port Gi1/0/24 is not in trunking mode.
Why wrong: The trunk port Gi1/0/24 is not the cause because the switch output explicitly shows Gi1/0/24 in a trunking state, with the administrative mode set to 'on' and the operational mode as trunk. If the trunk were not functioning, VLAN 20 frames would not reach the router at all, but the router would still need a subinterface to accept them. Since the trunk is up and carrying VLAN 10 and 20 traffic as expected, this option is incorrect.
B
The router is missing a subinterface for VLAN 20.
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.
C
The switch port Gi1/0/12 is not assigned to VLAN 10.
Why wrong: The switch port Gi1/0/12 is not the problem because the 'show vlan brief' output clearly lists Gi1/0/12 as an access port assigned to VLAN 10, which matches the PC's expected VLAN. If the port were in the wrong VLAN, the PC would not be able to reach its VLAN 10 gateway at all, yet it can ping that gateway successfully. Thus, the PC's Layer 2 connectivity is correct, and the fault must lie upstream in the routing configuration.
D
The PC has a duplicate IP address with the server.
Why wrong: A duplicate IP address between the PC and the server would cause address conflicts, typically resulting in intermittent connectivity, ARP table instability, and both devices struggling to communicate. However, the PC can successfully ping its VLAN 10 gateway, which proves its IP stack and addressing are functional and unique on the local segment. The observed problem is isolated to inter-VLAN routing to VLAN 20, which a duplicate IP would not selectively cause, so this option is wrong.

Question 9mediummulti select

Which TWO statements are true about configuring and verifying VLANs, 802.1Q trunking, native VLAN, and inter-VLAN routing with router-on-a-stick?

Trap 1: The native VLAN is always tagged on an 802.1Q trunk link.

This statement is false because the native VLAN is specifically exempt from 802.1Q tagging on a trunk link. In 802.1Q, frames belonging to the native VLAN are transmitted without a VLAN tag to maintain backward compatibility with legacy switches that do not understand tagging. Only non-native VLANs receive a 4-byte 802.1Q tag; therefore, stating that the native VLAN is always tagged contradicts the very definition of native VLAN behavior.

Trap 2: The command switchport trunk native vlan 10 is used to restrict…

The `switchport trunk native vlan 10` command does not filter or restrict which VLANs traverse the trunk; it simply designates VLAN 10 as the native VLAN for that trunk port. Allowed VLANs on a trunk are controlled with `switchport trunk allowed vlan` (or `remove`), which builds the permitted VLAN list. Misinterpreting this command often leads to native VLAN mismatch or unintended VLAN pruning, so it is important to distinguish between native VLAN assignment and allowed VLAN filtering.

Trap 3: The command show interfaces trunk displays the IP addresses…

This is incorrect because `show interfaces trunk` is a switch-only command used to display trunk status, the native VLAN, and the list of allowed VLANs on each trunk interface. It does not show IP addresses, because Layer 3 addressing is not part of a switch's trunk port configuration. To view IP addresses configured on router subinterfaces, you would use `show ip interface brief` or `show running-config` on the router, not the switch's trunk verification command.

A
On a router-on-a-stick configuration, each subinterface must be configured with an IP address and the encapsulation dot1Q command to specify the VLAN ID.
In router-on-a-stick, a single physical router interface is divided into logical subinterfaces, each dedicated to a distinct VLAN. For every subinterface, you must assign an IP address that falls within the VLAN's subnet and issue the `encapsulation dot1Q <vlan-id>` command so the router tags outgoing frames and recognizes incoming tagged frames for that VLAN. Without this encapsulation, the router cannot distinguish which VLAN a frame belongs to, breaking inter-VLAN routing.
B
The native VLAN is always tagged on an 802.1Q trunk link.
Why wrong: This statement is false because the native VLAN is specifically exempt from 802.1Q tagging on a trunk link. In 802.1Q, frames belonging to the native VLAN are transmitted without a VLAN tag to maintain backward compatibility with legacy switches that do not understand tagging. Only non-native VLANs receive a 4-byte 802.1Q tag; therefore, stating that the native VLAN is always tagged contradicts the very definition of native VLAN behavior.
C
The command switchport trunk native vlan 10 is used to restrict which VLANs are allowed on a trunk.
Why wrong: The `switchport trunk native vlan 10` command does not filter or restrict which VLANs traverse the trunk; it simply designates VLAN 10 as the native VLAN for that trunk port. Allowed VLANs on a trunk are controlled with `switchport trunk allowed vlan` (or `remove`), which builds the permitted VLAN list. Misinterpreting this command often leads to native VLAN mismatch or unintended VLAN pruning, so it is important to distinguish between native VLAN assignment and allowed VLAN filtering.
D
When configuring a router-on-a-stick, the native VLAN must match on both the switch and the router subinterface to avoid miscommunication.
On a router-on-a-stick setup, the native VLAN must be identical on the switch trunk and the router subinterface to prevent untagged frames from being assigned to the wrong VLAN. When the router receives untagged traffic from the switch's native VLAN, it assumes the frame belongs to the VLAN configured as native on the subinterface (often using `encapsulation dot1Q <vlan> native`). If the native VLAN IDs differ, the router may place frames into an incorrect subnet, causing connectivity failures or security risks.
E
The command show interfaces trunk displays the IP addresses configured on router subinterfaces.
Why wrong: This is incorrect because `show interfaces trunk` is a switch-only command used to display trunk status, the native VLAN, and the list of allowed VLANs on each trunk interface. It does not show IP addresses, because Layer 3 addressing is not part of a switch's trunk port configuration. To view IP addresses configured on router subinterfaces, you would use `show ip interface brief` or `show running-config` on the router, not the switch's trunk verification command.

Question 10mediummultiple choice

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?

Trap 1: Gi0/1 is an access port in VLAN 1

The output explicitly identifies Gi0/1 as 'on 802.1q trunking,' which means the interface is currently operating as an 802.1Q trunk, not as an access port. An access port is configured for a single VLAN, typically VLAN 1 by default, and would show 'access' with a VLAN assignment rather than 'trunking' in the interface status. The presence of 'trunking' in the output contradicts the claim that Gi0/1 is an access port, so this option is incorrect.

Trap 2: Gi0/2 is forced to trunk mode

The DTP mode 'auto' sets Gi0/2 to dynamic auto, which is strictly passive: it will never send DTP frames and therefore cannot force a trunk link. A truly forced trunk is achieved with the 'switchport mode trunk' (DTP 'on') command, which unconditionally enables trunking regardless of the far end's configuration. Since the output shows 'auto' rather than 'on' or 'trunk', Gi0/2 is not forced into trunking and will only trunk if the neighbor actively initiates the negotiation.

Trap 3: Neither interface can carry tagged traffic

This statement is false because Gi0/1 is an operational 802.1Q trunk, and the entire purpose of such a trunk is to carry tagged 802.1Q frames from multiple VLANs across the link. Tagged traffic is essential for inter-switch trunking, allowing VLANs to extend between switches. Gi0/2, while currently in auto mode, may also become a trunk if DTP negotiation succeeds, so claiming that neither interface can carry tagged traffic is completely contradicted by Gi0/1's active trunking state.

A
Gi0/1 is an access port in VLAN 1
Why wrong: The output explicitly identifies Gi0/1 as 'on 802.1q trunking,' which means the interface is currently operating as an 802.1Q trunk, not as an access port. An access port is configured for a single VLAN, typically VLAN 1 by default, and would show 'access' with a VLAN assignment rather than 'trunking' in the interface status. The presence of 'trunking' in the output contradicts the claim that Gi0/1 is an access port, so this option is incorrect.
B
Gi0/1 is trunking, and Gi0/2 is waiting for DTP negotiation
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.
C
Gi0/2 is forced to trunk mode
Why wrong: The DTP mode 'auto' sets Gi0/2 to dynamic auto, which is strictly passive: it will never send DTP frames and therefore cannot force a trunk link. A truly forced trunk is achieved with the 'switchport mode trunk' (DTP 'on') command, which unconditionally enables trunking regardless of the far end's configuration. Since the output shows 'auto' rather than 'on' or 'trunk', Gi0/2 is not forced into trunking and will only trunk if the neighbor actively initiates the negotiation.
D
Neither interface can carry tagged traffic
Why wrong: This statement is false because Gi0/1 is an operational 802.1Q trunk, and the entire purpose of such a trunk is to carry tagged 802.1Q frames from multiple VLANs across the link. Tagged traffic is essential for inter-switch trunking, allowing VLANs to extend between switches. Gi0/2, while currently in auto mode, may also become a trunk if DTP negotiation succeeds, so claiming that neither interface can carry tagged traffic is completely contradicted by Gi0/1's active trunking state.