An access switch shows two healthy physical uplinks, but users on one VLAN lose connectivity whenever a link is added to an EtherChannel. Elsewhere, a seemingly harmless edge port causes a spanning-tree topology change and reconvergence across the campus. These problems have different mechanisms: trunk negotiation changes which VLAN traffic is carried, channel consistency determines whether parallel links operate as one logical interface, and Spanning Tree Protocol controls which redundant Layer 2 paths may forward. A professional troubleshooting method separates those facts instead of disabling loop prevention until traffic returns.<\/p>\n
The Infrastructure domain of Cisco 350-401 ENCOR v1.2<\/a> explicitly includes troubleshooting 802.1Q trunking and EtherChannel and configuring or verifying RSTP, MST and enhancements such as BPDU guard and root guard. This is a step beyond the foundational descriptions in CCNA VLANs and native VLAN behavior<\/a>. ENCOR-level judgment is demonstrated by isolating the control-plane decision and verifying the actual forwarding path before making a production change.<\/p>\n Start by identifying the physical endpoints, administrative interface mode, negotiated trunk status, allowed VLAN list, native VLAN, Layer 2 or Layer 3 role, and expected spanning-tree instance. A link that is up at Layer 1 does not guarantee the intended VLAN is active in both directions. Likewise, a trunk that passes a management VLAN can silently omit an application VLAN because its allowed list differs from the peer’s.<\/p>\n Use commands such as IEEE 802.1Q tags identify VLAN membership for transported frames, while the configured native VLAN may be carried untagged according to platform and policy. Dynamic Trunking Protocol can negotiate trunk mode on supported Cisco devices, but it is not a protocol needed between every vendor’s switches. Where trunking is intentional, a deliberate static configuration often reduces surprises; where an endpoint should remain an access device, disable unwanted trunk negotiation according to the platform’s documented controls.<\/p>\n Suppose a new switch uplink carries the voice and user VLANs but drops management traffic. Before creating a new routed interface, compare allowed-VLAN lists, native VLAN, VLAN existence, and any pruning or security feature along the path. A native-VLAN mismatch can cause unexpected untagged traffic handling and may show up as log warnings, but not every VLAN outage stems from that mismatch. Test the affected tagged VLAN directly with an authorized source and destination.<\/p>\n An EtherChannel bundles compatible physical ports into a logical port channel. Link Aggregation Control Protocol (LACP) supports negotiated aggregation; some environments also use static Check Rapid Spanning Tree Protocol (RSTP) converges more quickly than classic STP in supported topologies, but it still must select a stable root and place redundant ports into suitable roles or states. Multiple Spanning Tree (MST) maps multiple VLANs into spanning-tree instances, which can reduce independent control-plane calculations but requires consistent instance-to-VLAN mappings and region attributes. A port that forwards for one instance may legitimately be alternate for another.<\/p>\n Use BPDU guard and root guard solve different problems. BPDU guard is commonly used with properly designated edge ports to prevent an unexpected switch or bridge from participating in the topology; receiving a BPDU under such protection can place the port into an error-disabled condition. Root guard protects a designated port against another device unexpectedly claiming a superior root. Neither should be enabled everywhere without understanding uplink roles and operational recovery.<\/p>\n A common error is applying an edge-port protection setting to a genuine downstream switch uplink. The resulting block may be misdiagnosed as a defective cable. Conversely, removing every protection because a new unmanaged switch appears can expose the network to a real loop or unintended root election. Determine where a host should connect, where a legitimate bridge is expected, and who may change the topology; then choose the appropriate guard, warning, and recovery process.<\/p>\n Imagine two distribution switches joined by a bundled trunk. After maintenance, VLAN 210 loses application reachability while VLAN 20 remains healthy. First verify the exact affected path and default gateway. On both ends of the channel, compare the port-channel allowed VLANs and member interfaces, LACP bundle state, and spanning-tree forwarding state for the relevant VLAN or MST instance. Then validate the far endpoint’s VLAN and Layer 3 handoff.<\/p>\n If the channel itself is healthy but one VLAN is absent, repair the allowed-VLAN or VLAN-definition mismatch using a reviewed change. If one physical member is suspended, reconcile its configuration with the bundle rather than moving the entire port channel into an unprotected mode. If spanning tree blocked an unexpected path, establish the current root and MST region state. After the fix, demonstrate that both members rejoin normally, that the affected VLAN passes traffic, and that a controlled single-member failure does not interrupt service beyond the intended tolerance.<\/p>\n Layer 2 changes can have a large blast radius because a bad aggregation or spanning-tree setting can affect many VLANs simultaneously. Stage changes with a dependency plan: configure the intended port-channel and peer characteristics, verify channel formation, then adjust VLAN carriage or root priorities with explicit review. Coordinate both ends of critical links. Store the original interface and spanning-tree configuration and plan a way to regain management if the active path changes.<\/p>\nEstablish a baseline for each link and VLAN<\/h2>\n
show interfaces trunk<\/code>, show interfaces switchport<\/code>, show vlan brief<\/code>, and the platform’s interface counters in a safe read-only session. Confirm the intended VLAN exists and is active at both ends; compare native VLAN configuration and any dynamic trunking state. Avoid changing access or trunk modes blindly across a production port channel. One inconsistent member can trigger an EtherChannel suspension or create separate forwarding behavior that is easy to mistake for a routing outage.<\/p>\nUnderstand static and dynamic trunk negotiation<\/h2>\n
Treat EtherChannel as one logical interface only when members agree<\/h2>\n
on<\/code> mode, which provides no negotiation safeguard against a peer mismatch. The local and remote device must agree on essential operational characteristics such as trunk mode, relevant VLAN settings, speed or duplex constraints, and channel-group behavior supported by the platform.<\/p>\nshow etherchannel summary<\/code>, show lacp neighbor<\/code>, interface state, and the port-channel configuration. Identify whether each member is bundled, suspended, standalone, or down rather than assuming two visible physical links both forward within the channel. If a member was removed by consistency checks, examine the exact mismatch before forcing it back. The CCNA EtherChannel specialist<\/a> covers basic LACP and PAgP behavior; ENCOR troubleshooting adds platform consistency, failover impact, and service-specific observations.<\/p>\nIdentify the actual root bridge and active topology<\/h2>\n
show spanning-tree<\/code> and MST-specific read-only commands to identify bridge priorities, root-port selection, designated versus alternate paths, edge settings, and instance topology. If the intended distribution switch is not the root, root path cost and topology may be different from the diagram even when the network is not fully down. The spanning-tree root bridge design<\/a> discussion helps establish the basic election model; ENCOR requires proving how current roles and MST region settings actually influence production traffic.<\/p>\nApply BPDU guard and root guard to the right boundary<\/h2>\n
Walk through an EtherChannel outage without guessing<\/h2>\n
Manage change order and rollback carefully<\/h2>\n