VLAN Config Consistency Checker

Introduction:

Most VLAN problems are not caused by one bad number. They appear when several places in the switching design tell different stories about the same VLAN. A port may use VLAN 120 for phones, a trunk may allow only VLANs 10 through 40, the VLAN database may omit VLAN 120, and the native VLAN may still be VLAN 1 on one side of the link. Each statement can look reasonable by itself, while the combined configuration drops traffic, leaks a default segment, or turns a planned change into a troubleshooting window.

A virtual LAN, or VLAN, is a logical Layer 2 segment identified by a numeric VLAN ID. Access ports usually place untagged endpoint traffic into one VLAN. Voice VLAN settings add a second VLAN for phones on the same edge port. A switched virtual interface, or SVI, gives a VLAN a Layer 3 gateway. Trunk ports carry multiple VLANs between switches, routers, hypervisors, firewalls, and wireless controllers. Native VLAN handling adds one more wrinkle because untagged traffic on an 802.1Q trunk is associated with a specific VLAN according to platform behavior and local standard.

Change windows, site turnups, trunk pruning, and voice network moves all depend on this agreement. Missing a service VLAN from one uplink can break only a few floors, which makes the fault look like DHCP, call-control, or wireless trouble. Allowing a reserved VLAN can expose a quarantine, parking, or fabric-internal segment. Leaving VLAN 1 in the wrong place can conflict with a security standard even when no user is deliberately assigned to it.

The common mistake is treating one list as the whole truth. An allowed list can include VLANs that should be blocked. A VLAN database can show an ID as active while one uplink omits it. A native VLAN can be configured locally and still fail because the peer trunk uses another value. A sound review asks whether each VLAN is used, carried, declared, allowed by policy, and safe to expose.

Text evidence can catch contradictions before a change is pushed, but it cannot replace live peer checks. VLAN consistency is a configuration review, not proof that spanning tree is healthy, the neighbor device agrees, DHCP is reachable, or user traffic is flowing.

How to Use This Tool:

Start with the evidence you trust, then describe the policy that evidence should match.

1. Paste sanitized switch text into Switch VLAN evidence. Interface blocks, show interfaces trunk sections, show vlan brief rows, and simple vlan command lines can all contribute evidence.
2. Add intended access, voice, SVI, or service VLANs in Used VLANs. IDs and ranges such as 10,20,30-40,120 are accepted.
3. Set Expected trunk allowed VLANs to the policy every checked trunk should follow. Use IDs, ranges, all, or none when those match the intended standard.
4. Enter Expected native VLAN, then fill Declared active VLANs and Reserved or blocked VLANs when you have database or policy evidence.
5. Choose Native VLAN rule to match the platform or local convention, and set VLAN 1 policy to warn, block, or allow VLAN 1 exposure.
6. If Review VLAN input appears, fix ignored tokens or VLAN IDs outside 1-4094 before using the findings.
7. Review Findings Register for the action list, Consistency Ledger for per-VLAN detail, Interface Trunk Matrix for per-trunk drift, and VLAN Consistency Map for category counts.

The sample buttons are useful for learning the workflow: Mixed trunk sample shows drift and missing coverage, while Clean sample shows the expected shape of an aligned review.

Interpreting Results:

Blocker findings should stop or slow a change until the VLAN policy is corrected. They can appear when a used VLAN is missing from the expected trunk allowed list, appears in the reserved or blocked list, is inactive, or violates a blocking VLAN 1 policy. Warning findings usually call out native VLAN policy issues, undeclared VLAN evidence, or VLAN 1 exposure under a warn policy. Notice rows are lower-severity cues, such as extra allowed VLANs or missing trunk evidence.

A clean result means the pasted evidence and policy fields did not trigger the supported checks. It does not prove that peer trunks match, that every switch has the same VLAN database, or that traffic is passing. Use a clean ledger as a configuration-evidence checkpoint, then confirm neighbor trunks and live device state through normal operations.

Technical Details:

IEEE 802.1Q tagging identifies VLAN membership on Ethernet frames so one trunk link can carry multiple Layer 2 segments. In ordinary switch configuration, the valid VLAN ID range checked here is 1-4094. Trunk policy decides which tagged VLANs are permitted, while native VLAN behavior decides how untagged trunk traffic is classified.

Consistency is a set comparison with a few policy rules layered on top. Used VLANs come from explicit user input and recognized access, voice, SVI, and native VLAN evidence. Allowed VLANs come from the expected trunk policy and parsed trunk statements. Declared active state comes from explicit database input plus recognized VLAN rows or VLAN declarations. Reserved or blocked IDs are treated as policy exceptions that should not be used or carried unless deliberately removed from the blocked list.

Rule Core:

Input Bounds and List Semantics:

Native VLAN Rules:

The category chart counts clean used/native VLANs and findings for missing trunks, native policy, reserved IDs, inactive or undeclared state, and VLAN 1 exposure. It is a summary of the same rules, so a high bar in one category should be traced back to the exact rows in Findings Register and Consistency Ledger.

Accuracy Notes:

The checker reviews submitted text and policy fields. It does not log in to switches, poll neighbors, run packet tests, or verify that both ends of a trunk agree in real time.

• Paste only the configuration or command output needed for the review. Full running configurations, credentials, keys, and management addresses are not needed.
• Check the address bar before sharing a populated page. Current values may be kept in the browser URL for reload or sharing behavior.
• Confirm vendor-specific trunk semantics, native VLAN handling, and platform-reserved VLANs against the devices being changed.
• Use live commands or network monitoring to confirm forwarding state before approving a production change.

Advanced Tips:

• Keep Used VLANs as the intended service list, not merely the VLANs already seen in pasted evidence. That catches stale trunks before the interface parser has enough context.
• Use Expected trunk allowed VLANs as the policy baseline for every trunk in the review. Intentional exceptions should be documented separately so Interface Trunk Matrix drift stays meaningful.
• Fill Declared active VLANs when database state matters. Leaving it blank avoids undeclared checks, while complete evidence lets inactive or missing VLANs surface as findings.
• Adjust Reserved or blocked VLANs to match the platform and local standard before treating a reserved finding as a production blocker.
• Change Native VLAN rule only after confirming how the devices handle untagged trunk traffic. The same native VLAN can be correct under one rule and a warning under another.
• Raise VLAN 1 policy from warn to block when the review is enforcing a hard data-trunk standard, then trace any finding back to the exact ledger or trunk row.

Worked Examples:

Voice VLAN missing from the trunk

Evidence includes switchport voice vlan 120, and Used VLANs includes 120. If Expected trunk allowed VLANs is 10,20,30,40, Consistency Ledger marks VLAN 120 as target missing, and Findings Register reports a Blocker. The practical fix is to carry VLAN 120 on required trunks or remove the stale voice VLAN reference.

Native VLAN policy changes the warning

A site uses native VLAN 999. With Native VLAN rule set to Cisco-style native must be carried, the expected allowed list should include 999. If the same review changes to Native separate from tagged VLAN list, VLAN 999 appearing in the allowed list becomes a Warning instead.

No trunk evidence limits confidence

Suppose Used VLANs, Expected trunk allowed VLANs, and Declared active VLANs all include 10,20,30, but no trunk text is pasted. The ledger can still look clean, while Interface Trunk Matrix shows No trunk evidence and a notice-level action. The next step is to paste trunk evidence or verify the trunk on the device.

Invalid IDs stop the review from being trustworthy

If Reserved or blocked VLANs contains 0,4095, Review VLAN input reports that those tokens are outside VLAN 1-4094. Fix the list before acting on VLAN Consistency Map counts or exported rows.

FAQ:

Glossary:

VLAN

A logical Layer 2 segment identified by a VLAN ID.

Trunk

A switch link that carries multiple VLANs between devices.

Allowed VLAN list

The VLAN IDs a trunk is permitted to carry by policy or interface configuration.

Native VLAN

The VLAN associated with untagged traffic on a trunk according to platform behavior.

SVI

A switched virtual interface, often written as interface VlanX, that gives a VLAN a Layer 3 gateway.

Declared active VLAN

A VLAN ID shown or entered as present in the local VLAN database.

VLAN 1 exposure

Use or trunk allowance of VLAN 1 when local policy expects it to be warned or blocked.

References:

• IEEE 802.1Q Bridges and Bridged Networks, IEEE 802.1 Working Group.
• 802.1Q VLAN IDs and Ethernet Interface Types, Juniper Networks, October 8, 2025.
• Configuring VLAN Trunks, Cisco.