{{ summary.title }}
{{ summary.primary }}
{{ summary.line }}
{{ badge.label }}
Use this when you want interface-level proof beyond the explicit VLAN lists below.
Paste only public config snippets; secrets, keys, and management addresses are not needed.
Enter intended access, voice, SVI, or service VLANs to compare against trunk policy.
This is the policy list every checked trunk is expected to match.
Use an unused parking VLAN when that is your trunk standard.
VLAN
Leave blank only when you are checking allowed-list math without VLAN database evidence.
Include platform-reserved IDs plus local parking, quarantine, or fabric-internal VLANs.
Choose the interpretation that matches how your platform treats untagged trunk traffic.
Many environments remove VLAN 1 from data trunks; keep exceptions explicit.
VLAN Evidence Allowed coverage Declared state Verdict Action Copy
{{ row.vlan }} {{ row.evidence }} {{ row.coverage }} {{ row.declaredState }} {{ row.verdict }} {{ row.action }}
Interface Mode Allowed VLANs Native Target drift Verdict Copy
{{ row.name }} {{ row.mode }} {{ row.allowed }} {{ row.native }} {{ row.drift }} {{ row.verdict }}
Severity Scope Evidence Action Copy
{{ row.severityLabel }} {{ row.scope }} {{ row.evidence }} {{ row.action }}
Tags: Diagnostics, Networking
Export to PDF Fullscreen
Customize
Advanced
:

VLAN configuration consistency is the match between the VLANs a switch configuration appears to use and the VLANs the trunk policy is expected to carry. A VLAN can be present on access ports, voice ports, switched virtual interfaces, or native trunk settings, yet still fail in practice if the uplink allowed list omits it, the VLAN database does not declare it, or a blocked ID slips into a trunk.

This matters most during switch changes, site turnups, and cleanup reviews. One missing voice VLAN can make phones fail after a move. A trunk with the wrong native VLAN can pass untagged traffic into the wrong segment. A reserved or default VLAN can remain exposed because a copied allowed list was never compared against the local policy.

VLAN consistency sketch comparing used VLANs, trunk allowed lists, native VLAN policy, declared state, and findings.

A good consistency check keeps three ideas apart. A used VLAN is an ID referenced by ports or interfaces. An allowed VLAN is an ID permitted across a trunk. A declared VLAN is an ID that appears to exist in the VLAN database or in the active VLAN list. The safest change record shows all three lining up, with native VLAN handling and reserved IDs reviewed separately.

This kind of review does not prove that a device is reachable, that spanning tree is healthy, or that the peer switch is configured the same way. It is a text-based check for contradictions in the evidence you provide, useful before a trunk change is copied into a maintenance window.

Technical Details:

IEEE 802.1Q VLAN tagging identifies traffic with VLAN IDs in the practical range 1-4094. Trunk ports carry multiple VLANs over one Ethernet link by tagging most VLAN traffic and treating the native VLAN as the untagged VLAN according to the platform policy. On Cisco-style trunks, VLAN 1 is commonly the default native VLAN, and an allowed VLAN list can narrow which VLANs may traverse the trunk.

Consistency problems appear when those records disagree. A port can reference VLAN 120 as a voice VLAN while a trunk allows only 10,20,30,40. A native VLAN such as 999 can be configured on an interface but absent from the expected allowed list under Cisco-style rules. A VLAN can also be present in access evidence while missing from declared active VLAN evidence, which points to a stale port reference or an incomplete pasted VLAN database.

Rule Core:

The checker turns pasted evidence and explicit policy lists into sets of VLAN IDs, then compares those sets with ordered rules.

Input area What is recognized How it affects review
VLAN lists Comma, space, or semicolon separated IDs and ranges such as 10,20,30-40; expected allowed VLANs also accept all or none. IDs are deduplicated, sorted, and kept within 1-4094. Invalid tokens are reported in Review VLAN input.
Interface evidence switchport mode, access VLAN, voice VLAN, trunk allowed VLAN, trunk native VLAN, and interface VlanX lines. Access, voice, SVI, and native IDs become used VLAN evidence. Trunk allowed and native values feed the per-interface drift check.
Trunk table evidence Cisco-style show interfaces trunk sections for native VLANs and VLANs allowed on trunks. Parsed trunks are compared with the expected allowed list and expected native VLAN.
Declared VLAN evidence show vlan brief rows and vlan command lines. Declared IDs are marked active unless the row state indicates suspended or shutdown behavior, which is treated as inactive.

Finding Rules:

Condition Severity Reason to review
A used VLAN appears in Reserved or blocked VLANs. Blocker The service is using an ID that the local policy says should not be carried or referenced.
A used VLAN is absent from Expected trunk allowed VLANs. Blocker Traffic for that VLAN may not traverse trunks that follow the expected policy. Separate-native mode exempts the native VLAN from this tagged-list rule.
A used VLAN is not found in declared active VLAN evidence. Warning The port or interface reference may be stale, or the pasted VLAN database evidence may be incomplete.
A used VLAN appears suspended or inactive. Blocker The ID is referenced, but the VLAN state suggests traffic should not be trusted yet.
The parsed trunk native VLAN differs from Expected native VLAN. Warning Native VLAN mismatch can put untagged traffic into the wrong segment and should be aligned on both ends.
Native VLAN rule is Cisco-style and the native VLAN is not carried, or separate-native and the native VLAN appears in the tagged set. Warning The expected native handling does not match the allowed-list policy being reviewed.
VLAN 1 is used or allowed while VLAN 1 policy is warn or block. Warning or Blocker Default VLAN exposure is called out according to the selected local policy.
No trunk interface blocks or trunk table rows are parsed. Notice The expected allowed list can still be checked, but per-interface drift cannot be proven from the pasted text.

Result Surfaces:

Result area What it shows Best use
Consistency Ledger One row per relevant VLAN with evidence, allowed coverage, declared state, verdict, and action. Use it to explain why one VLAN is clean, missing, reserved, inactive, or native-related.
Interface Trunk Matrix Parsed trunks, mode, allowed VLANs, native VLAN, target drift, and verdict. Use it to find which trunk differs from the expected allowed list or native setting.
Findings Register Severity, scope, evidence, and recommended action for every finding. Use it as the compact change-review punch list.
VLAN Consistency Map Counts for clean, missing trunk, native policy, reserved, inactive, and VLAN 1 categories. Use it to see whether the review is mostly clean or dominated by one issue type.
JSON Parameters, summary counts, ledger rows, interface rows, findings, and chart counts. Use it when the review needs structured evidence for a ticket or repeat check.

Everyday Use & Decision Guide:

Start with a sanitized switch excerpt, not a full running configuration. The Switch VLAN evidence field is meant for interface blocks, show interfaces trunk output, show vlan brief rows, and short change snippets. Secrets, keys, and management addresses are not needed for this review.

Use the explicit list fields to state the policy you expect the pasted evidence to satisfy. Put access, voice, SVI, and service IDs in Used VLANs. Put the trunk standard in Expected trunk allowed VLANs. Add the known active database in Declared active VLANs when you have it, because that lets the checker distinguish a carried VLAN from one that appears missing or inactive.

  • Keep Expected native VLAN separate from the general used list so native handling stays visible.
  • Leave Native VLAN rule at Cisco-style native must be carried when your trunk policy expects the native VLAN to be available on the trunk.
  • Choose Native separate from tagged VLAN list only when your platform or local standard treats the native VLAN as untagged-only.
  • Put parking, quarantine, legacy default, and fabric-internal IDs in Reserved or blocked VLANs.
  • Set VLAN 1 policy to block when VLAN 1 exposure should stop a change, or allow when a documented exception is expected.

The best stop-and-verify cue is the summary badge. Blockers means a used VLAN is missing from the expected trunk policy, uses a blocked ID, is inactive, or violates a blocking VLAN 1 policy. Warnings usually point to native VLAN handling, missing declaration evidence, or interface drift that should be corrected or documented before approval.

A clean result is not a live forwarding test. After the ledger and findings look right, compare the peer trunk, the actual VLAN database, and the intended change ticket before applying configuration on devices.

Step-by-Step Guide:

Build the review from evidence first, then tighten the policy fields until the findings match the change you intend to approve.

  1. Paste interface blocks, trunk table output, VLAN database rows, or a short change excerpt into Switch VLAN evidence. Use Mixed trunk sample or Clean sample only when you want a known example to compare against your own text.
  2. Enter access, voice, SVI, and service IDs in Used VLANs. The Consistency Ledger expands those IDs with VLANs parsed from the evidence.
  3. Enter the intended trunk policy in Expected trunk allowed VLANs. Use comma-separated IDs, ranges, all, or none as the policy requires.
  4. Set Expected native VLAN, then fill Declared active VLANs and Reserved or blocked VLANs. The summary badge updates with the native ID and total VLAN rows checked.
  5. Choose Native VLAN rule and VLAN 1 policy. These controls decide whether native membership and VLAN 1 exposure become accepted, warning, or blocker findings.
  6. If Review VLAN input appears, fix ignored tokens or out-of-range IDs before trusting the ledger. VLAN IDs must stay within 1-4094.
  7. Read Findings Register for the action list. Each row names the severity, scope, evidence, and corrective action.
  8. Open Interface Trunk Matrix for per-trunk drift, VLAN Consistency Map for issue counts, and JSON when you need a structured copy of the review.

Interpreting Results:

Blocker is the result that should slow the change down. It means the supplied evidence or policy has a contradiction that can break VLAN reachability or violate a blocked-ID rule. Warning still deserves attention, especially for native VLAN mismatches and undeclared VLANs, because those issues often become outages only after a trunk is moved or pruned.

Do not treat No missing, reserved, native, inactive, or VLAN 1 policy findings were detected as proof that the network path works. It means the pasted evidence and policy fields did not trigger the rules above. Confirm the peer trunk, the live VLAN database, and the intended maintenance record before using the result as approval evidence.

Output cue Meaning Useful follow-up
target missing The VLAN is used or native-related but absent from the expected allowed policy. Add the VLAN to required trunks or remove the stale access, voice, SVI, or native reference.
not found in declared state The VLAN was used, but no active declaration was found when declaration evidence exists. Paste complete VLAN database evidence, create the VLAN, or remove the old reference.
Target drift A parsed trunk differs from Expected trunk allowed VLANs. Fix that trunk or document why it should intentionally differ from the policy list.
Native policy Native VLAN handling does not match the selected rule. Align both trunk ends and confirm whether native VLAN membership should be carried or separate.
VLAN 1 exposure VLAN 1 is used or allowed while the selected policy says to warn or block. Remove VLAN 1 from data trunks or record the control-plane exception.

Worked Examples:

Voice VLAN missing from a parsed trunk:

The mixed sample has access VLANs 20 and 30, voice VLAN 120, SVI VLAN 40, native VLAN 999, and a trunk that allows 10,20,30,40. With Expected trunk allowed VLANs set to 10,20,30,40,120, the Interface Trunk Matrix reports missing 120 in Target drift.

The Findings Register action is to align the interface allowed list with the expected trunk policy or document the exception. That is a warning rather than a blocker because the expected policy includes VLAN 120, but the parsed trunk evidence still disagrees with it.

Clean native and allowed policy:

The clean sample uses VLANs 10,20,30,40,120, native VLAN 999, and declared VLANs 10,20,30,40,120,999. Its trunk allowed list also includes 10,20,30,40,120,999. With Native VLAN rule set to Cisco-style, the Consistency Ledger can show each used or native ID as carried and declared.

That makes the summary read as aligned for the supplied text. The practical follow-up is still to confirm the other end of the trunk, because this review only checks the evidence entered on the page.

Blocked default VLAN exposure:

If Expected trunk allowed VLANs includes 1,10,20 and VLAN 1 policy is set to Treat VLAN 1 exposure as a blocker, the Consistency Ledger marks VLAN 1 with a blocker when it is used or allowed. The Findings Register action is to remove VLAN 1 from user or data trunks unless the exception is documented.

This is a policy result, not a universal platform rule. If the environment intentionally permits VLAN 1 for a specific control-plane reason, switch VLAN 1 policy to Allow VLAN 1 without a finding and keep the exception in the change record.

Bad VLAN token during review:

A pasted policy such as 10,20,4095 in Expected trunk allowed VLANs triggers Review VLAN input because 4095 is outside VLAN 1-4094. The in-range IDs can still be parsed, but the result should not be trusted until the invalid token is corrected.

The same recovery path applies to a mistyped range or stray text token. Fix the field named in the validation message, then reread Consistency Ledger and Findings Register.

FAQ:

Does this check my switches directly?

No. It checks the text and policy values you enter. Use Consistency Ledger, Interface Trunk Matrix, and Findings Register as review evidence, then verify the actual devices separately.

What VLAN list formats can I enter?

Use individual IDs and ranges such as 10,20,30-40. VLAN IDs must be within 1-4094. Expected trunk allowed VLANs also accepts all and none.

Why is there a notice about no trunk evidence?

No interface trunk block or trunk table row was parsed from Switch VLAN evidence. The checker can still compare used and expected IDs, but Interface Trunk Matrix cannot show per-interface drift until trunk evidence is pasted.

Should the native VLAN be in the allowed list?

That depends on the platform policy you are reviewing. Use Cisco-style native must be carried when the native VLAN should be available on trunks. Use Native separate from tagged VLAN list when the native VLAN should stay out of the tagged allowed set.

Why did a VLAN become inactive?

A parsed VLAN database row indicated a suspended or shutdown state. The Consistency Ledger then treats a used inactive VLAN as a blocker so the state can be fixed before the trunk is trusted.

Is it safe to paste a full running configuration?

Paste only the snippets needed for VLAN review. The input helper explicitly says secrets, keys, and management addresses are not needed, and shorter evidence makes the findings easier to audit.

Glossary:

Trunk
A switch link that carries traffic for multiple VLANs.
Allowed VLAN list
The VLAN IDs that a trunk policy permits across the link.
Native VLAN
The VLAN associated with untagged traffic on an IEEE 802.1Q trunk under the selected platform rule.
SVI
A switched virtual interface such as interface Vlan40, treated as used VLAN evidence.
Declared active VLAN
A VLAN ID found in the supplied VLAN database evidence without an inactive state.
Reserved or blocked VLAN
An ID the local policy says should not be used or carried.
Target drift
A difference between a parsed trunk allowed list and the expected trunk allowed policy.

References: