Verification compares intended, configured, and operational state
Network verification exists because a correct design, a correct-looking configuration, and working behavior are not automatically the same thing. A switch port can be configured for VLAN 20 but shut down. A trunk can be up while one required VLAN is missing. A firewall rule can exist but never match because an earlier rule shadows it. Strong verification proves each layer separately.
For a focused configuration diagnostic, use the AP Networking NAT and PAT Troubleshooting Practice Test to compare a published service with the actual translated destination and listener. Test externally, trace the response, and confirm prohibited management access remains blocked rather than treating the presence of a port-forward entry as completion.
Every verification task needs a predicted result
“VLAN 20 should work” is too vague. A stronger requirement is: “Student clients in VLAN 20 receive 10.20.0.0/24 addresses, use 10.20.0.1 as the gateway, reach the Internet, and cannot reach the management subnet.” That statement creates testable claims.
Now verification can be tied to access-port assignment, trunk carriage, DHCP scope, gateway state, routing/NAT, firewall policy, and both positive and negative traffic tests.
Administrative up is not operational up
Inspect administrative state, physical/link state, negotiated speed and duplex, errors, and description. An interface can be enabled in configuration but physically down. It can be operational at the wrong speed. It can pass traffic while accumulating CRC errors or drops.
Prove existence, membership, and end-to-end presence
Confirm that the VLAN exists where required and that endpoint ports are assigned to the intended VLAN. Then prove that infrastructure links carry the VLAN across the path. A client receiving the wrong DHCP subnet can be indirect evidence of wrong VLAN placement.
A trunk can work while one required VLAN fails
Compare both sides of the trunk and verify whether the required VLAN is allowed and active. If VLANs 10 and 20 work across the same uplink while VLAN 30 fails, the shared physical path is proven to a useful degree.
Every field should match the intended segment design
Inspect the IPv4 address, prefix, default gateway, DNS, and DHCP state. Calculate whether the gateway is actually local. Compare with the documented segment rather than checking only that every field contains a value.
The Layer 3 boundary must exist and be reachable
Verify the gateway interface or SVI is operational with the intended address and prefix. From the client, test gateway reachability. On the gateway, verify the connected route for the client subnet.
Client view
Gateway value is local and reachable.
Gateway view
SVI/interface is operational with intended IP.
Routing view
Connected route exists for the client subnet.
A matching route still needs a usable next step
Inspect the routing table for the actual destination. The longest matching prefix wins. Then verify the next hop is reachable or the outgoing interface is operational. A default route is useful only when no more-specific route matches.
Test a fresh lease, not only the server configuration screen
Confirm scope network, mask, gateway option, DNS option, available addresses, reservations, and exclusions. Then renew or connect a test client and inspect the actual lease.
Investigate VLAN placement, relay/helper behavior, rogue DHCP, stale lease, or wrong server selection.
Ask the intended resolver a specific question
Verify which DNS server the client is actually configured to use. Query that resolver directly and inspect the answer. For internal names, compare with the intended authoritative/internal result. For failures, distinguish timeout, NXDOMAIN, and an incorrect returned address.
Rule order, counters, and logs connect policy to live traffic
Identify which rule should match the test flow. Generate the flow and inspect counters or logs. Test both an allowed source and a denied source.
A rule existing in the configuration is not proof that it controls the packet.
Use the same measurement on both sides of a change
Before editing a trunk, record VLAN status and a representative connectivity test. Afterward, repeat the same checks. Before changing a route, record the route table and traffic path. Afterward, verify the intended route is installed and traffic follows it.
Live state can slowly move away from documented design
Emergency changes, device replacements, resets, copied configurations, and temporary troubleshooting rules can create drift. Periodic verification compares the live network with the known-good baseline.
Configuration evidence and behavioral evidence answer different questions
A show/status command can prove a port is configured for VLAN 20. A client receiving the VLAN 20 DHCP scope and reaching the VLAN 20 gateway proves behavior beyond the configuration line. A firewall config can show an allow rule; a controlled TCP test and matching log prove the flow actually uses it.
Configuration
What should the device do?
Operational artifact
What state does the device report?
Behavior
What does the end-to-end test prove?
Define failure before making the change
If a trunk change should add VLAN 40 without affecting VLANs 10 and 20, define success in advance: VLAN 40 becomes operational and 10/20 continue carrying required traffic. If existing VLANs fail, restore the previous configuration while investigating.
Turn each design statement into four columns of evidence
| Requirement | Configured state | Operational artifact | Behavioral test |
|---|---|---|---|
| Port 7 belongs to VLAN 20 | Access VLAN 20 configured | VLAN/MAC evidence | Client receives expected subnet |
| Staff reaches AppServer:443 | Route + firewall allow | Route/firewall counters | TCP/HTTPS succeeds |
| Guests cannot reach management | Segmentation deny | Deny counter/log | Guest test fails |
Swipe horizontally to see the worksheet.
One requirement may need several independent proofs
Requirement: VLAN 40 server at 10.40.0.50 should accept HTTPS from Staff VLAN 10 but not Guest VLAN 70. Verify VLAN 40 membership, server IP/gateway, gateway state, routing from both sources, firewall rule order, server listener state, and return path.
Recovery after a change does not automatically prove the cause
If a service returns after a switch reboot, the reboot correlated with recovery but did not identify the failed mechanism. If connectivity returns after entering a VLAN command, verify the operational state before claiming the command fixed the issue.
Verify a new VLAN from client access port all the way to policy
Assume VLAN 60 is intended for lab devices using 10.60.0.0/24 with gateway 10.60.0.1. Confirm the endpoint access port is operational and assigned to VLAN 60. Confirm the VLAN exists. Confirm every required trunk carries it. Confirm the gateway interface/SVI is operational with 10.60.0.1/24 and the connected route appears.
Then test services. A fresh client should receive an address from the VLAN 60 scope, the correct /24 mask, the intended gateway, and intended DNS servers. The client should reach its gateway. If policy allows Internet but denies management, verify both outcomes.
Move from local configuration toward the service without skipping dependencies
This order is not rigid, but it prevents higher-layer testing from hiding a lower-layer mismatch.
A configured object can exist but still be operationally irrelevant
A VLAN can exist but have no active member ports. A firewall rule can exist but never match. A route can exist but point to an unreachable next hop. A DHCP scope can exist but be exhausted. A DNS server can be configured but unreachable. Verification should always ask whether the configured object is participating in the live path.
Exists
Configuration present.
Operational
Live state active.
Effective
Actually influences the tested traffic.
VLAN 60 client gets the wrong subnet and cannot reach the intended service
Correct the relay/scope path, renew the client lease, then verify 10.60.0.0/24 addressing, gateway reachability, required remote access, and any denied management path. This is exactly why verification must compare intended, configured, operational, and behavioral state instead of stopping at one show command.
Pair configuration evidence with operational evidence before drawing a conclusion
A single configuration artifact rarely proves the full requirement. A switch configuration can show that a port is assigned to VLAN 20, but the VLAN table, MAC learning, DHCP lease, and client behavior determine whether VLAN 20 is actually operational for that endpoint. A route table can show a path exists, but ARP or neighbor state can reveal whether the next hop is usable. A firewall configuration can show an allow rule, while counters and logs show whether that rule actually controls the tested flow.
Configuration evidence
What the device has been told to do.
Operational evidence
What state the device reports right now.
Behavioral evidence
What the user-facing test proves end to end.
Strong verification uses at least two of those layers when the requirement matters.
Verification is incomplete if you test only what should be allowed
Security and segmentation requirements often have two sides. If Staff should reach AppServer on HTTPS and Guest should not, verifying only Staff success does not prove the boundary. A broad firewall rule could allow both. The negative test proves the restriction survived the change.
This is one of the clearest ways to separate a network that merely “works” from a network that matches the design.
Use verification to catch configuration that still works but no longer matches policy
Configuration drift is not always an outage. A temporary trunk VLAN may still be allowed months later. A firewall exception may continue permitting traffic after the original need is gone. A replacement switch may contain a copied access-port template that works for users but violates current segmentation requirements. Periodic verification should therefore compare live state with the approved baseline, not only respond to failures.
Verify one service path from endpoint to application and back
This capstone demonstrates the core Topic 3.3 idea: configuration, operational state, and behavior all have to agree before the requirement is considered verified.
24 Network Configuration & Verification digital flashcards
Practice intended/configured/operational state, interfaces, VLANs, trunks, addressing, gateways, routes, DHCP, DNS, firewall policy, baselines, rollback, drift, and verification worksheets.