Airport operations notices the luggage-handling VLAN no longer passes on a trunk after a maintenance window. CDP neighbors still appear. Which trunk check is the most likely next step?

An 802.1Q trunk forwards only VLANs present on its allowed list. After a maintenance window at airport operations, the luggage-handling VLAN can vanish from that list through manual pruning, VTP pruning (where used), or a template push, while the physical trunk and CDP neighbor relationship remain up. Because CDP can still run on the native or still-allowed control path, seeing CDP neighbors does not prove every service VLAN is permitted. Verifying that the luggage VLAN remains allowed on both ends is therefore the most likely next trunk check.

Matching HSRP priorities on both ends of the trunk addresses first-hop redundancy, not whether a VLAN is switched across the trunk. Confirming identical OSPF network types on a Layer-2 trunk misapplies a Layer-3 adjacency concept to an L2 allowed-list problem. Disabling spanning tree on both switches to restore the missing VLAN is dangerous and irrelevant; STP does not remove a VLAN from the trunk allowed list, and turning it off risks loops.

Exam caveat: also verify the VLAN exists in the VLAN database/VTP domain on both switches—an allowed VLAN that is not created locally still will not forward. Pruning and “switchport trunk allowed vlan remove” are easy to miss when CDP looks fine. Native VLAN issues can cause other oddities but present differently than a simply missing allowed VLAN.

Operational check: on both airport peers run show interfaces trunk and compare allowed/active VLANs for the luggage VLAN; restore the VLAN to the allowed list symmetrically; confirm MAC learning and end-to-end connectivity for luggage endpoints without disabling STP.