Cisco & Juniper Commissioning Guide

Commissioning Cisco and Juniper infrastructure is not simply the point at which equipment is powered on and connected. It is the controlled process that proves a new or changed network is correctly designed, securely configured, resilient under failure and ready to support live services.

That distinction matters. A switch can pass traffic while using the wrong spanning-tree priority. A firewall can permit an application while silently bypassing the intended inspection policy. A router can establish a BGP session while advertising routes that should never leave the organisation. An HA pair can appear healthy until the first real failover exposes an untested dependency.

Safe commissioning therefore combines engineering, security, change control and evidence. It should produce more than a working network: it should produce an understood, supportable and auditable service.

This guide explains how UK organisations can commission Cisco and Juniper switching, routing and security infrastructure methodically. It covers Catalyst, Nexus, Cisco routing and Secure Firewall environments alongside Juniper EX, QFX, MX and SRX platforms. It is intended for enterprise networks, data centres, branch estates and migration projects where downtime, security exposure or incomplete records would create material risk.

Important: This is a planning and assurance guide, not a substitute for a platform-specific method of procedure. Commands, licensing, supported software and high-availability behaviour vary by model and release. Engineers should use the current vendor documentation for the exact hardware and software being commissioned.

What safe network commissioning should achieve

A successful commissioning process should answer five questions with evidence:

Is the installed equipment the equipment that was approved?
Does the physical and logical implementation match the design?
Is the management, control and data plane secured appropriately?
Do normal operation, failure handling and rollback behave as expected?
Can the operations team support the service after the project team leaves?

If any answer depends on assumption rather than recorded evidence, commissioning is incomplete.

Commissioning is different from installation

Installation covers activities such as racking hardware, connecting power, fitting optics and patching cables. Configuration applies the intended network behaviour. Commissioning verifies the complete service under realistic conditions and formally transfers it into operation.

The distinction prevents a common failure: treating link lights and successful pings as proof of readiness. Those checks are useful, but they do not prove routing policy, security enforcement, monitoring, failover, capacity or operational ownership.

A strong commissioning plan includes:

design and dependency validation;
asset, software and licence verification;
physical installation inspection;
secure management-plane configuration;
switching, routing and security-policy validation;
resilience and controlled failure testing;
monitoring and backup integration;
rollback criteria;
evidence capture; and
operational acceptance.

Phase 1: define ownership, scope and acceptance

Before an engineer changes a live environment, establish what is being commissioned and who has authority to make decisions.

Create a commissioning scope

Record:

sites, racks and rooms in scope;
device hostnames, models, serial numbers and roles;
interfaces and circuits affected;
VLANs, VRFs, routing domains and security zones involved;
applications and business services that depend on the change;
third parties, carriers and cloud connections involved;
approved maintenance window;
expected user impact;
rollback threshold and deadline; and
named technical and business approvers.

This information should align with the low-level design, implementation plan and change record. Differences must be resolved rather than silently absorbed into the live configuration.

Define acceptance criteria before the change

Acceptance should be measurable. Examples include:

every planned device is reachable through the approved management path;
approved routing adjacencies are established and unexpected adjacencies are absent;
only authorised routes are learned and advertised;
redundant links, supervisors, power supplies and nodes fail over within the agreed service tolerance;
firewall rules and NAT behaviour match the approved policy;
logs, alerts, time synchronisation and configuration backups reach the correct systems;
no critical alarms, unsupported components or unresolved test failures remain; and
the operations team has accepted the evidence and support documentation.

Without written acceptance criteria, a project can drift from “commissioned” to “apparently working”.

Phase 2: validate the design and dependencies

Commissioning starts at the design, not at the console.

Review the high-level and low-level designs against the real environment. Confirm device roles, interface allocation, address plans, VLAN databases, routing policy, security zones, redundancy mechanisms, management services and monitoring integrations.

Pay particular attention to dependencies that sit outside the network device:

DNS and DHCP;
NTP or another approved time source;
TACACS+ or RADIUS;
certificate authorities and PKI;
syslog, SIEM and network monitoring;
configuration backup platforms;
IP address management and source-of-truth systems;
internet, WAN and cloud circuits;
application load balancers;
authentication and endpoint-control services; and
carrier demarcation and cross-connects.

A configuration may be correct but still fail because a certificate chain is incomplete, a firewall upstream blocks the management protocol or the monitoring platform has not been prepared for the new addresses.

Review failure domains

Identify which components share power, rack, patching, supervisor, line card, carrier, route reflector or management dependencies. Two devices are not truly redundant if both connect through the same power distribution unit, use the same physical fibre path or depend on one authentication server.

The design review should ask not just “Is there a second device?” but “Which failures can still affect both devices?”

Phase 3: verify hardware, software and provenance

Before staging, reconcile delivered equipment with the bill of materials and approved design.

Capture:

manufacturer, model and serial number;
chassis, supervisor, routing engine and line-card inventory;
power-supply and fan modules;
transceiver manufacturer, type and serial number where required;
installed memory and storage;
software image and boot variable;
licence or subscription status;
support entitlement and warranty; and
cryptographic hash of downloaded software where the vendor provides one.

Confirm that hardware and optics are supported in the intended combination and that the selected software release supports the required features. “Latest” is not automatically “correct”; the target should be an approved release supported on the exact platform and validated against known defects, security advisories and interoperability requirements.

Equipment should come through an approved supply chain. Inspect packaging, seals and chassis condition, and investigate unexplained serial-number differences or unexpected pre-existing configuration. Where supported, use the vendor’s integrity and authenticity capabilities as part of the assurance process.

Phase 4: stage the configuration away from production

Staging reduces the amount of uncertain work performed during the live window.

Build a controlled baseline from templates, automation or peer-reviewed configuration. Device-specific values—hostnames, management addresses, interface identifiers, routing IDs and cluster identities—must be generated and checked systematically.

During staging:

upgrade or standardise software where approved;
verify boot settings and image integrity;
apply the secure management baseline;
load interface, VLAN, VRF and routing configuration;
prepare firewall objects and policies;
validate syntax and platform feature support;
test authentication and logging from a controlled network;
store a dated configuration backup; and
record the configuration version intended for production.

Treat the configuration as controlled code

A production configuration should have an identifiable source, reviewer and version. Avoid copying an old device configuration wholesale. Historical configurations often contain unused accounts, obsolete SNMP communities, inherited access lists and workarounds whose purpose is no longer understood.

Use structured comparison to distinguish the approved baseline from the live result. Secrets must be handled through an approved credential process and should not be placed in project documents or ordinary source-control repositories.

Phase 5: inspect the physical installation

Physical faults regularly present as software faults, so inspect the installation before troubleshooting protocols.

Rack, power and environment

Check:

correct rack position and secure mounting;
chassis weight and rail compatibility;
required front-to-back or back-to-front airflow;
blanking panels and cable management;
ambient temperature and environmental alarms;
separate A and B power feeds where designed;
correct power-supply status and load distribution;
earthing or bonding requirements; and
unobstructed access to console, management and field-replaceable components.

Optics, fibre and copper

Validate:

fibre type, polarity and connector cleanliness;
optic type, wavelength and distance rating;
transmit and receive power against expected ranges;
speed, duplex and breakout configuration;
copper category and PoE requirements;
port labels at both ends; and
cross-connect references and carrier handoff details.

Do not accept an error-free interface immediately after connection as proof that the link is healthy. Record optical levels and interface counters, then recheck them during the soak period.

Out-of-band access

Console and out-of-band management should be available before production paths are changed. Test access from the authorised support location and confirm that it does not depend on the service being commissioned. A rollback plan that relies on the failed in-band network is not a robust rollback plan.

Phase 6: establish a secure baseline

Cisco’s hardening guidance organises security around the management, control and data planes. That is a useful commissioning model for both Cisco and Juniper environments.

Protect the management plane

Configure and test:

central AAA using TACACS+ or RADIUS where appropriate;
named administrative accounts rather than shared identities;
role-based privileges and least access;
a controlled, documented break-glass account;
SSH and other encrypted management protocols;
management access lists or security filters;
SNMPv3 where SNMP is required;
authenticated or otherwise trusted time synchronisation;
remote logging to resilient collectors;
login, configuration-change and authentication-failure auditing;
approved cryptographic algorithms and certificates;
inactivity timeouts and session controls; and
configuration backup and restore capability.

Disable or restrict services that are not required. Telnet, unauthenticated management protocols, legacy web interfaces and default credentials should not survive commissioning.

Management traffic should use a dedicated network, VRF or routing instance where the design supports it. Limit which sources can reach the management addresses and verify the restriction from both authorised and unauthorised test locations.

Protect the control plane

Control-plane protection should account for routing protocols, neighbour discovery, ARP or ND, first-hop redundancy, spanning tree and traffic addressed to the device itself.

Verify:

routing-neighbour authentication where supported and appropriate;
explicit neighbour definitions and passive interfaces;
prefix, route-policy and maximum-prefix controls;
control-plane policing or equivalent protection;
permitted ICMP and diagnostic behaviour;
spanning-tree protections on edge and inter-switch ports;
protection against rogue DHCP and address-resolution attacks where required; and
expected behaviour under malformed or excessive control traffic.

Protect the data plane

Confirm that traffic crosses only the intended interfaces, zones, VLANs, VRFs and policies. Test segmentation, anti-spoofing controls, quality of service, multicast behaviour and path MTU—not only basic reachability.

Phase 7: commission Cisco infrastructure

Cisco environments differ significantly across IOS XE, NX-OS, IOS XR and Secure Firewall platforms. Use the vendor guide for the exact release and hardware, but retain a common assurance structure.

Cisco Catalyst switching

For Catalyst campus or access switching, verify:

stack membership, priority and software consistency;
StackWise Virtual or equivalent peer relationships where used;
port-channel membership and LACP state;
trunk allowed-VLAN lists and native-VLAN handling;
access VLAN and voice VLAN assignment;
spanning-tree mode, root placement and protections;
gateway redundancy such as HSRP where designed;
DHCP snooping, dynamic ARP inspection and source protections where approved;
802.1X and MAB behaviour, including critical-authentication scenarios;
PoE budget and endpoint power negotiation;
storm control and err-disable recovery policy; and
uplink failure behaviour.

Test representative endpoints rather than assuming all port templates behave identically. Include corporate devices, voice endpoints, printers, wireless access points and any operational technology that follows a different authentication path.

Cisco Nexus data-centre switching

For Nexus infrastructure, verify:

vPC peer-link and keepalive independence;
vPC role, consistency and orphan-port handling;
port-channel and VLAN consistency;
management and control-plane reachability during a peer failure;
MTU across the complete path;
first-hop redundancy and anycast-gateway behaviour;
underlay adjacencies and route policy;
VXLAN EVPN VTEP, NVE and control-plane state where used;
endpoint learning and mobility;
fabric-extender relationships where present; and
supervisor or fabric-module redundancy on modular platforms.

Do not limit vPC testing to one cable pull. Test the failure modes identified in the design: peer-link failure, keepalive loss, member-link failure, peer reload and upstream isolation. The expected outcome must be documented before testing begins.

Cisco routing and WAN platforms

For ISR, ASR, Catalyst edge, NCS or related platforms, validate:

interface addressing and VRF membership;
BGP, OSPF or IS-IS adjacency and timers;
route maps, prefix lists and communities;
inbound and outbound route counts;
maximum-prefix and default-route behaviour;
route redistribution boundaries;
MPLS, segment-routing or SD-WAN control relationships where applicable;
QoS classification, marking, policing and shaping;
carrier circuit performance and path diversity; and
convergence when a circuit, neighbour or node fails.

Route validation should compare intended and observed prefixes. A green neighbour state alone does not prove safe routing.

Cisco Secure Firewall, ASA and FTD

For security platforms, verify:

management-controller registration and health;
HA peer state, state synchronisation and monitored interfaces;
interface names, zones and security levels;
routing and asymmetric-path risks;
network and port objects;
access-control policy order and default action;
NAT precedence and translation behaviour;
VPN peer identity, certificates and failover;
intrusion, malware and URL policies where licensed;
logging of both permitted and denied test traffic; and
a controlled policy-deployment and rollback method.

Use representative application tests. A successful TCP connection may not prove that authentication, file transfer, DNS dependencies or return-path routing works correctly.

Phase 8: commission Juniper infrastructure

Junos provides configuration comparison, rollback and confirmed-commit capabilities that are particularly useful during remote changes. A confirmed commit automatically returns to the previous configuration if it is not confirmed within the defined period. This is a safeguard, not a replacement for console access and a tested rollback plan.

After establishing a known-good baseline, create and protect an appropriate rescue configuration so the device can be returned to a known state if configuration files are damaged or a later change fails.

Juniper EX and QFX switching

For EX and QFX platforms, verify:

Virtual Chassis member identity, role and priority;
software consistency across members;
Virtual Chassis port state and topology;
aggregated Ethernet membership and LACP state;
VLAN and interface-mode assignment;
spanning-tree or EVPN multihoming behaviour;
MC-LAG inter-chassis control and data links where used;
PoE delivery and budget on access platforms;
storm control and loop protection;
underlay routing, VTEP and EVPN state on fabrics;
MTU consistency; and
management reachability after a member or uplink failure.

A Virtual Chassis is one logical management entity, but its physical members, VCPs, power feeds and uplinks still need individual failure testing. Confirm member roles and VCP operation using the relevant Juniper verification procedures.

Juniper MX routing

For MX routing infrastructure, validate:

Routing Engine and chassis health;
FPC, PIC and interface status;
graceful Routing Engine switchover, nonstop routing or nonstop active routing where designed and supported;
routing-instance and interface membership;
BGP, OSPF and IS-IS adjacencies;
import and export policy results;
accepted and advertised prefix counts;
MPLS, LDP, RSVP or segment-routing state where used;
class-of-service queues, schedulers and rewrite rules;
firewall filters and policers; and
convergence during link, peer, line-card and Routing Engine events.

The test plan should distinguish between control-plane continuity and data-plane continuity. A routing process remaining established does not necessarily mean traffic was unaffected.

Juniper SRX firewalls

For SRX environments, verify:

chassis-cluster node identity and status;
control and fabric-link health;
redundancy-group primary and secondary state;
interface and IP monitoring thresholds;
redundant Ethernet interfaces;
configuration and session synchronisation;
routing instances and route symmetry;
zone assignment and host-inbound services;
security-policy match and order;
source and destination NAT behaviour;
IPsec VPN negotiation and failover;
application services and logging; and
manual and failure-driven failover outcomes.

Juniper’s verification guidance includes cluster status, interfaces, control-plane statistics, data-plane statistics and redundancy-group state. Capture this evidence before and after failover so the result is demonstrable rather than anecdotal.

Phase 9: execute structured testing

Testing should trace requirements, not produce a collection of unrelated screenshots.

Management tests

Authorised administrators can authenticate through central AAA.
Unauthorised sources cannot reach management services.
Break-glass access works and is logged.
NTP, DNS, syslog, SNMP or telemetry and backups work.
Configuration changes are attributable to named identities.
The device remains manageable during an agreed failure scenario.

Layer 2 tests

Access and trunk ports carry only approved VLANs.
Port channels distribute traffic and survive member loss.
Spanning-tree root and blocked paths match the design.
Loop, BPDU and storm protections behave as intended.
MAC learning and endpoint admission work correctly.

Layer 3 tests

Connected, static and dynamic routes match the approved table.
No unintended routes are imported, exported or redistributed.
Forward and return paths are valid.
VRF or routing-instance separation is maintained.
Convergence meets the stated tolerance.

Security tests

Permitted business flows succeed.
Explicitly prohibited flows fail.
NAT uses the expected addresses and rule order.
Administrative access is restricted.
Logs contain enough detail for investigation.
HA failover preserves or predictably resets sessions according to the design.

Performance and capacity tests

Measure where risk justifies it:

latency, loss and jitter;
interface throughput;
CPU and memory;
buffer or queue drops;
firewall session and connection rates;
optical levels and physical errors; and
PoE consumption.

Testing should stay within an agreed safe load. Do not introduce uncontrolled stress into production simply to obtain a benchmark.

Phase 10: rehearse rollback and define go/no-go points

A rollback plan should identify:

the last safe decision point;
the exact symptoms that trigger rollback;
who can make the decision;
how configurations and cabling are restored;
how carrier or third-party changes are reversed;
how long rollback will take;
which tests prove restoration; and
how stakeholders will be informed.

For Cisco, the available recovery mechanism depends on platform and release and may include saved startup configuration, configuration replacement, checkpoints or orchestrator rollback. For Junos, rollback history, confirmed commits and rescue configurations can reduce recovery time. Every method must be prepared and tested on the relevant platform before it is relied upon.

Avoid an ambiguous “fix forward unless necessary” approach. Define a time at which the team stops troubleshooting and restores the previous service.

Phase 11: capture an auditable commissioning record

The evidence pack should allow another competent engineer to understand what was installed, how it was tested and what remains outstanding.

Include:

approved design and change reference;
final asset and serial-number register;
rack elevation and patching records;
software, firmware and licence inventory;
final sanitised configuration or controlled repository reference;
configuration hash or version identifier;
test plan with result, timestamp and tester;
pre-change and post-change health outputs;
routing, switching, HA and security verification;
screenshots only where structured text is not available;
known defects, deviations and accepted risks;
rollback outcome or confirmation that it was not invoked; and
formal operational acceptance.

Do not place passwords, private keys, shared secrets or full sensitive configurations in an unrestricted handover document.

Phase 12: monitor through a stabilisation period

Commissioning does not end at the first successful test. Observe the service for an agreed soak period and compare it with the baseline.

Monitor:

interface errors, discards and flaps;
routing-neighbour resets and route churn;
spanning-tree or topology changes;
vPC, Virtual Chassis, cluster and HA events;
CPU, memory and temperature;
power-supply, fan and environmental alarms;
authentication and policy failures;
unexpected firewall denies or session pressure;
application latency and user reports; and
configuration changes after handover.

The duration should reflect business risk. A small branch switch and a data-centre core require different levels of observation.

Phase 13: complete the operational handover

The receiving team needs more than a diagram and a login.

Provide:

current logical and physical diagrams;
device and circuit inventory;
approved configuration repository;
backup and restoration procedure;
monitoring and alert ownership;
software-maintenance and vulnerability process;
certificate and licence renewal dates;
support-contract and escalation details;
standard operating and troubleshooting procedures;
failover and recovery runbooks;
known limitations and accepted risks; and
training or knowledge-transfer records.

Confirm that the service desk and network operations team recognise the new device names, monitoring alerts and escalation path. A service is not operationally complete if only the project engineer knows how it works.

Master commissioning checklist

Governance

Scope, design and change are approved.
Business services and dependencies are identified.
Technical and business owners are named.
Acceptance and rollback criteria are agreed.

Hardware and software

Hardware matches the approved bill of materials.
Serial numbers and modules are recorded.
Software release is supported and approved.
Image integrity, licensing and support are verified.

Physical installation

Rack position, airflow and environment are correct.
A and B power paths are verified where required.
Cabling, optics, polarity and labels are checked.
Console and out-of-band access are tested.

Secure baseline

Central AAA and named accounts work.
Break-glass access is controlled and tested.
Insecure and unnecessary services are disabled.
Management access is source-restricted.
NTP, logging, monitoring and backups work.
Control-plane and data-plane protections are applied.

Network and security services

VLANs, VRFs and routing instances match the design.
Routing adjacencies and policies are validated.
Switching, port-channel and loop-prevention state is correct.
Firewall policy, NAT and VPN behaviour are tested.
Segmentation is validated with permitted and denied flows.

Resilience

Power, link, member, node and supervisor failures are tested as applicable.
Convergence and session impact meet acceptance criteria.
Management remains available or recovery access is proven.
Restoration to the preferred state is verified.

Handover

Test evidence and final configuration are retained.
Diagrams, inventory and runbooks are current.
Monitoring, backup and support ownership is accepted.
Outstanding risks have an owner and target date.
Formal service acceptance is recorded.

Common commissioning mistakes

Testing only reachability

Ping proves limited IP reachability. It does not prove application behaviour, route policy, security enforcement, quality of service, redundancy or monitoring.

Applying old configurations without understanding them

Legacy templates can carry weak cryptography, obsolete accounts, unused VLANs, permissive firewall rules and undocumented workarounds into a new platform.

Testing redundancy without testing restoration

A device may fail over successfully but fail to return cleanly, create split-brain behaviour or leave traffic on an unintended path. Test the complete operational cycle.

Treating vendor defaults as the security design

Defaults provide an initial state, not an organisation-specific secure baseline. Management exposure, logging, routing policy and access control need deliberate decisions.

Forgetting the management dependencies

A device that forwards traffic but cannot authenticate administrators, send logs, synchronise time or back up its configuration is not ready for service.

Closing the change with unresolved evidence

“Passed verbally” is not sufficient for a critical network. Results should be recorded against agreed acceptance criteria while the engineers and evidence are still available.

Questions to ask a commissioning partner

Before appointing a provider, ask:

Who owns the method of procedure and technical acceptance criteria?
How are configurations peer reviewed and version controlled?
Which Cisco and Juniper platforms has the engineering team commissioned?
How will management, control and data-plane security be validated?
Which failure modes will be tested, and what service impact is expected?
How will rollback work if central management or in-band access is lost?
What evidence will be supplied at handover?
How will credentials, configurations and serial-number data be protected?
Who owns monitoring, backup, licensing and vulnerability management after handover?
How are deviations from the design recorded and approved?

Specific answers indicate engineering control. Vague assurances indicate avoidable risk.

Why engineer-led commissioning matters

Network infrastructure sits underneath business applications, security controls, voice, cloud access and operational systems. Commissioning it safely requires engineers who can interpret both the design intent and the behaviour of the live platform.

From my experience commissioning network and security infrastructure, the difficult failures are rarely the obvious ones. They are mismatched route policies, hidden physical dependencies, untested return paths, inconsistent cluster state and management services that were assumed rather than verified. A disciplined commissioning process exposes those conditions before they become incidents.

Compritech combines Cisco and Juniper engineering experience with structured asset control, infrastructure deployment, decommissioning and technical documentation. That means a project can be managed across the equipment lifecycle—from installation and secure commissioning through future refresh, recovery and responsible disposition.

Final takeaway

Safe Cisco and Juniper commissioning is a controlled proof process. It verifies that the correct equipment is installed, the intended design is implemented, security controls work, failures are survivable and the service can be operated after handover.

The strongest commissioning projects share four characteristics:

they define measurable acceptance before the change;
they test management, control and data planes separately;
they prove resilience and rollback rather than assuming them; and
they leave an evidence pack that another engineer can follow.

When those disciplines are present, commissioning becomes more than turning up a network. It becomes the point at which infrastructure is shown to be secure, resilient and supportable.

Authoritative guidance and further reading

UK National Cyber Security Centre, Network security fundamentals: https://www.ncsc.gov.uk/guidance/network-security-fundamentals
UK National Cyber Security Centre, Cyber Essentials: Requirements for IT infrastructure: https://www.ncsc.gov.uk/cyberessentials/overview
Cisco, Cisco IOS XE Software Hardening Guide: https://www.cisco.com/c/en/us/support/docs/ip/access-lists/13608-21.html
Cisco, Cisco IOS XR Software Hardening Guide: https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-xr-software/222075-cisco-ios-xr-software-hardening-guide.html
Cisco, Cisco NX-OS Software Hardening Guide: https://www.cisco.com/c/en/us/support/docs/switches/nexus-9000-series-switches/216194-cisco-nx-os-software-hardening-guide.html
Cisco, Cisco Catalyst 9000 Resilient Infrastructure: https://www.cisco.com/c/en/us/support/docs/switches/catalyst-9000/222006-resilient-secure-infrastructure.html
Juniper Networks, Commit the Configuration: https://www.juniper.net/documentation/us/en/software/junos/cli/topics/topic-map/junos-configuration-commit.html
Juniper Networks, Rescue Configuration: https://www.juniper.net/documentation/us/en/software/junos/cli/topics/topic-map/junos-rescue-configuration.html
Juniper Networks, Virtual Chassis Overview for Switches: https://www.juniper.net/documentation/us/en/software/junos/virtual-chassis/topics/concept/virtual-chassis-switches-overview.html
Juniper Networks, Chassis Cluster User Guide for SRX Series Devices: https://www.juniper.net/documentation/us/en/software/junos/chassis-cluster-security-devices/index.html

Commissioning Cisco or Juniper infrastructure?

Compritech provides engineer-led commissioning, network and security integration, controlled testing, documentation and operational handover.

Explore network engineering Explore Smart Hands services Discuss your project

How to Commission Cisco and Juniper Infrastructure Safely