VLAN Config Consistency Checker

A VLAN can exist in one part of a switch configuration and still fail in operation. An access port may assign VLAN 20, the VLAN database may omit it, and an uplink trunk may carry only VLANs 10 and 30. Each line looks reasonable alone; the fault appears only when the evidence is compared as one forwarding path.

Access VLANs classify ordinary endpoint traffic. Voice VLANs add a second service VLAN on phone-facing ports. Switched virtual interfaces, or SVIs, provide a Layer 3 interface for a VLAN. Trunks carry multiple VLANs between devices, but their allowed lists decide which tagged traffic can cross each link.

The native VLAN deserves separate attention because platform behavior differs. Cisco-style trunks normally treat the native VLAN as part of the carried VLAN set even though its frames may leave untagged. Other policies model the native VLAN separately from the tagged allow list. Applying the wrong convention creates false drift reports; configuring different native VLANs at the two ends creates a real forwarding and security risk.

Reserved VLANs are local policy, not one universal list. A network may reserve IDs for parking, quarantine, fabric services, or platform defaults. VLAN 1 also needs an explicit decision: it can be allowed, reported as a warning, or treated as blocking when used or exposed on data trunks.

Consistency does not mean every trunk should carry every VLAN. Least-privilege trunking deliberately limits the allowed set to the services that cross that link. The useful comparison is between actual evidence and an approved target policy, including documented exceptions, not between every switch and a single oversized list.

Static configuration review is only one change gate. It cannot show live forwarding state, spanning-tree decisions, port-channel consistency, the far end of a trunk, or whether the intended service is actually reachable. Those checks still belong in the implementation and rollback plan.

How to Use This Tool:

Compare one frozen evidence set with the VLAN policy approved for the change.

1. Paste relevant interface configuration, VLAN declarations, show vlan brief rows, or trunk summary rows into Switch VLAN evidence.
2. Enter the service VLANs in Used VLANs and the intended carried set in Expected trunk allowed VLANs. Use comma-separated IDs or ranges; all and none are also accepted for the expected allowed set.
3. Set the Expected native VLAN and list Declared active VLANs when the pasted evidence does not contain the complete database view.
4. List Reserved or blocked VLANs, then choose the platform-appropriate Native VLAN handling and the approved VLAN 1 policy.
5. Add Approved exception VLANs only when the change record names the exception and its owner. Exceptions retain the finding and downgrade eligible VLAN-level warnings or blockers to Review.
6. Read the highest overall severity, then use the VLAN ledger and interface trunk matrix to locate the exact missing, extra, inactive, reserved, native, or VLAN 1 evidence.

Interpreting Results:

The overall status is the strongest finding: Critical outranks Warning, which outranks Review and Clean. Counts show the shape of the review, but one critical missing-carriage or reserved-use finding is enough to block the change.

• Critical identifies used reserved VLANs, missing required carriage, inactive required VLANs, blocked VLANs on a trunk, or VLAN 1 exposure under a block policy.
• Warning identifies missing database evidence, native membership or value mismatches, incomplete trunk coverage, and VLAN 1 exposure under a warn policy.
• Review covers extra carriage, incomplete evidence such as no parsed trunks, and eligible findings reduced by an approved exception.
• Clean means no configured rule found drift in the supplied evidence. Confirm the far end, active trunk state, spanning tree, and service path before implementation.

Technical Details:

VLAN identifiers are normalized to integer sets in the operational range 1 through 4094. Individual IDs and ranges may be separated by commas, semicolons, or whitespace. Reversed ranges are normalized to their lower and upper bounds, duplicates collapse, and output ranges are sorted and compressed.

Transformation Core:

The review turns mixed configuration text and policy fields into comparable sets before applying severity rules.

Recognized configuration includes interface blocks, access and voice VLAN commands, SVIs, VLAN declarations, trunk mode, native VLAN, and allowed VLAN replacement, add, or remove operations. Trunk summary rows for native VLANs and allowed sets are also parsed. Unrecognized lines are ignored, so vendor syntax outside these shapes may require explicit policy fields.

Rule Core:

Native VLAN Rules:

Configuration evidence is limited to 120,000 characters, and each policy list is limited to 24,000 characters. Invalid tokens or VLAN IDs outside 1 through 4094 stop evaluation rather than silently dropping questionable data.

Accuracy Notes:

The comparison uses only the pasted configuration and declared policy. Processing stays in the current browser, but copied configuration may still contain interface names, topology clues, descriptions, or other sensitive operational details.

• Unsupported vendor syntax may be ignored rather than parsed as evidence.
• An inherited target allowed list is used when a parsed trunk has no explicit allowed list in the supplied text.
• Approved exceptions preserve evidence and lower only eligible VLAN-level Critical or Warning findings to Review; they do not erase drift.
• Verify both trunk ends, active VLAN state, port-channel members, spanning tree, forwarding tables, and the approved rollback plan before applying a change.

References:

• IEEE 802.1Q Bridges and Bridged Networks, IEEE 802.1 Working Group.
• VLAN Configuration Guide: Configure VLAN Trunking, Cisco, July 17, 2026.