CCNA Switching and Network Access Practice Question
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?
⚠ Common exam trap
Don't jump to unrelated issues like spanning tree or IP configuration when the problem is clearly trunk-related.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Check for a trunk mismatch such as native VLAN inconsistency or other trunk-parameter problems.
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.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Check for a trunk mismatch such as native VLAN inconsistency or other trunk-parameter problems.
Why this is correct
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.
- ✗
Reset OSPF process IDs on both switches.
Why it's wrong here
OSPF process IDs are locally significant values that identify a specific OSPF routing process on a router or Layer 3 switch; they have no bearing on Layer 2 VLAN trunking. Since the reported problem is that VLAN 50 is not working across a trunk, resetting OSPF process IDs would not alter trunk tagging, native VLAN treatment, or the forwarding of VLAN 50 frames, making this action irrelevant to the symptoms.
When this WOULD be correct
In a question where OSPF routing issues are explicitly mentioned, such as 'OSPF routes are not being advertised between two switches,' resetting OSPF process IDs could be a valid troubleshooting step to refresh the routing tables and re-establish adjacency.
- ✗
Add ip helper-address under every access interface.
Why it's wrong here
Adding ip helper-address to access interfaces merely configures DHCP broadcast forwarding to a remote DHCP server at Layer 3. If the trunk between the two switches is misconfigured, VLAN 50 traffic cannot traverse the link in the first place, so any DHCP broadcast or relayed unicast would never reach the destination switch. This option fails to address the underlying Layer 2 trunk fault and would not restore intra-VLAN communication.
When this WOULD be correct
In a question about configuring a router to support DHCP relay for multiple VLANs, where the scenario specifies that clients in different VLANs are unable to receive IP addresses, the option to add ip helper-address would be correct.
- ✗
Disable the MAC address table.
Why it's wrong here
Disabling the MAC address table would prevent the switch from learning or forwarding frame destination addresses, effectively halting all unicast switching on the device regardless of VLAN configuration. The trunk mismatch, such as a native VLAN inconsistency, exists before any MAC learning occurs and would not be resolved by clearing or disabling the table. The correct approach is to inspect and fix the trunk parameters, not to disable fundamental Layer 2 switching behavior.
When this WOULD be correct
In a question where the focus is on troubleshooting Layer 2 issues related to excessive MAC address table entries causing performance degradation, disabling the MAC address table temporarily could be a valid step to reset the switch's learning process and alleviate the issue.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The 200-301 exam frequently reuses these exact scenarios with slightly different constraints.
✓Check for a trunk mismatch such as native VLAN inconsistency or other trunk-parameter problems.Correct answer▾
Why this is correct
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.
✗Reset OSPF process IDs on both switches.Wrong answer — click to see why▾
Why this is wrong here
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.
★ When this WOULD be the correct answer
In a question where OSPF routing issues are explicitly mentioned, such as 'OSPF routes are not being advertised between two switches,' resetting OSPF process IDs could be a valid troubleshooting step to refresh the routing tables and re-establish adjacency.
Why candidates choose this
Candidates may confuse Layer 2 VLAN issues with Layer 3 routing problems, leading them to believe that OSPF configuration could impact VLAN traffic, especially if they have encountered similar scenarios in their studies.
✗Add ip helper-address under every access interface.Wrong answer — click to see why▾
Why this is wrong here
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.
★ When this WOULD be the correct answer
In a question about configuring a router to support DHCP relay for multiple VLANs, where the scenario specifies that clients in different VLANs are unable to receive IP addresses, the option to add ip helper-address would be correct.
Why candidates choose this
Candidates may choose this option due to a misunderstanding of how VLANs and DHCP interact, thinking that helper addresses could somehow assist with VLAN traffic issues.
✗Disable the MAC address table.Wrong answer — click to see why▾
Why this is wrong here
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.
★ When this WOULD be the correct answer
In a question where the focus is on troubleshooting Layer 2 issues related to excessive MAC address table entries causing performance degradation, disabling the MAC address table temporarily could be a valid step to reset the switch's learning process and alleviate the issue.
Why candidates choose this
Candidates may choose this option due to a misunderstanding of how MAC address tables function, thinking that clearing the table might resolve connectivity issues without considering the specific VLAN configuration and trunking parameters.
Analysis generated from the official 200-301blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Visual reference
Quick reference
Routing Protocol Comparison
| Protocol | Metric | Max Hops | Algorithm | Type |
|---|---|---|---|---|
| RIP v2 | Hop count | 15 | Bellman-Ford | Distance vector |
| OSPF | Cost (bandwidth) | Unlimited | Dijkstra (SPF) | Link state |
| EIGRP | Composite metric | Unlimited | DUAL | Hybrid |
| IS-IS | Cost | Unlimited | Dijkstra | Link state |
| BGP | Policy / attributes | Unlimited | Path vector | Path vector |
RIP's 15-hop limit makes it unsuitable for large networks. OSPF and EIGRP dominate modern enterprise deployments.
Go deeper
Related to this question
Learn chapter
Interpreting Packet Capture Output for Layer 2/3 Troubleshooting
Key term
VLAN
A VLAN (Virtual Local Area Network) is a logical grouping of network devices that behave as if they are on the same physical network segment, regardless of their actual physical location.
Key term
VLAN
A VLAN logically segments a physical network into isolated broadcast domains without requiring separate physical switches.
About these practice questions
This 200-301 question is part of Courseiva's 1,389-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 200-301 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 200-301 exam.