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.
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
Redundancy and segmentation need consistent endpoint configuration and functional checks.
Reference: VLAN trunks · 200-301 CCNA v1.1