← CCNA: networking and production troubleshooting
03 / 7 · 32 MIN

VLANs, trunks, and access protection

Validate the L2 path and redundancy conditions.

Concept and mechanism

A VLAN created on both switches can still fail to cross a trunk if absent from the allowed list. Review both ends and preserve existing authorized VLANs when adding one. Native VLAN classifies untagged traffic according to configuration; different values at the ends can place it in different contexts. For EtherChannel, passive/passive does not initiate LACP. At least one active end can initiate negotiation while other compatibility requirements still apply. A physical link being up proves neither correct member aggregation nor passage of every required VLAN.

Guided application

STP selects the root by lowest bridge ID; priority and instance context matter before a tie-break. PortFast should match appropriate edge ports and does not replace loop prevention. If BPDU Guard blocks a port after a switch is connected, investigate topology before restoring access. For wireless, the visible SSID does not alone define security: compare authentication method and client profile. When accepting a change, test an existing service and the new one as well as collecting port state. This avoids approving a change that satisfies one requirement while breaking another.

IN PRACTICE

If a 20,30,40 list was replaced by 70, accepting the new VLAN does not prove continuity of old ones. Review the authorized union and rollback.

Common pitfalls

Unintentionally replacing lists; ignoring native VLAN; using on as LACP; removing BPDU Guard without correcting the connection.

Related topics: Routing, OSPF, and redundant gateways · DHCP, NAT, logs, and quality of service

Take this idea with you

Redundancy and segmentation need consistent endpoint configuration and functional checks.

Create account

Reference: VLAN trunks · 200-301 CCNA v1.1