Model the relevant path
Include the devices and links needed for the question. Record addressing, routes, and a successful or intentionally blocked connectivity check before changing anything.
TEST YOUR NETWORK ASSUMPTIONS
Give your design
a testable question.
Use nuLAB to investigate supported routing, addressing, and connectivity behavior before taking a design further. Build a small model, state your expectation, and compare the simulated result with it.
ONE CHANGE. TWO OBSERVATIONS.EXAMPLE
BaselineRecord routes and endpoint reachability.
ChangeRemove one required route in the lab.
InvestigateCompare the route table and the connectivity result.
A PRACTICAL VALIDATION WORKFLOW
Separate the assumption from the observation.
Start with one question: should these subnets communicate, which next hop should a router select, or what should happen when a required route is removed? A narrow question makes the configuration and the evidence easier to review.
Vary one condition
Apply one supported configuration change. Note the command and expected effect, then allow the simulated routing state to settle before inspecting the result.
Inspect both directions
Compare interface state, route selection, and endpoint reachability. Check the return path as well as the forward path, and record any unsupported part of the scenario.
MAKE THE EVIDENCE USEFUL
Choose checks that explain your result.
| Design question | Inspect in the lab | Record alongside it |
|---|---|---|
| Can two subnets communicate? | Interface addresses, connected and configured routes, gateway reachability, and end-to-end ping. | The expected source, destination, and return path. |
| Did the routing change take effect? | The relevant route and next hop before and after the change. | The device profile, exact configuration change, and state after convergence. |
| Is the segment connected as intended? | Port membership and supported VLAN or routing configuration along the path. | Which endpoints should communicate and which should remain separate. |
Do not treat a single successful ping as proof of the whole design. A useful review also explains which paths, failure conditions, and security requirements were not tested.
KNOW THE BOUNDARY
Simulation is one part of validation.
nuLAB models supported behavior; it does not run the original device operating system. A lab can help expose a mistaken assumption, explain a route, or prepare a review. It cannot certify a production deployment.
Check device compatibility, then verify the specific features needed for your scenario. Read the disclaimer for the platform’s scope.
Keep these in your wider test plan
- Exact appliance, software release, and command parity.
- Throughput, forwarding latency, resource limits, and scale.
- ASIC behavior, optics, cabling, and physical failure modes.
- Production security controls and operational rollout procedures.
BEFORE YOU START
A few useful answers.
Does a successful simulation mean a design is production-ready?
No. It is evidence about the supported behavior you exercised in that simulated lab. Production readiness also needs appropriate hardware or appliance testing, security review, capacity checks, and operational validation.
Can I use a lab to rehearse a configuration change?
Yes, where the required profiles, commands, and behavior are supported. Establish a baseline, apply one change, inspect the result, and document the differences between the simulated model and the target environment.
How do I check whether my scenario fits?
Start with the compatibility list and plan details. For a specific requirement, contact us with the protocols, device roles, and behavior you need to test.
TAKE THE NEXT STEP
Bring a question, not the whole network.
Describe the path, protocol, and expected behavior you want to investigate. We can discuss whether it fits the available simulation.
Discuss a validation lab