Enterprise Networks / WAN & site connectivity
WAN and site connectivity.A purpose for every path.
A second circuit is not yet a failure design. We plan the underlay, routing, SD-WAN overlay and transitions to data centre and cloud as one service, including what genuinely continues to work when a dependency fails.
Scope of service
What you receive.
This service fits new branches, carrier changes, MPLS replacement, an SD-WAN introduction, cloud connectivity or routing paths that are no longer understood. Business requirements become traffic paths, priorities and testable failure cases. Carrier services and platform functions stay separate so a dashboard status or contract label cannot imply availability that the technical design does not support.
A readable WAN architecture
Sites, carriers, internet edges, data centres, clouds, routing domains and security zones appear in one design. Primary and alternate paths are named together with their prerequisites and limitations.
Routing without surprises
Addressing, prefixes, BGP or static boundaries, summarisation and failover behaviour are designed deliberately. Legacy exceptions and asymmetric paths are found before cutover rather than during an incident.
SD-WAN with an operating model
Controllers, edge devices, policies, templates, access and vendor dependencies are considered together. Automation supports consistency but does not replace approval or application testing.
Tested failure cases
We define which circuits or components may be failed deliberately, which observations constitute success and when service is restored. Results and assumptions that cannot be tested are documented separately.
The delivery path
Three controlled steps.
- 01
Map traffic and dependencies
Review sites, applications, carriers, routing, bandwidth and current incident patterns. Identify critical paths and organisational ownership.
- 02
Design and pilot the architecture
Review underlay, overlay, security, policies and migration as one plan. Validate a representative branch, including selected failure scenarios.
- 03
Migrate sites deliberately
Confirm carrier readiness, execute changes in waves and accept reachability and applications. Handover and escalation paths become part of regular operations.
What we agree before starting
We can own the architecture and technical cutover, but we cannot promise carrier availability. Delivery dates, restoration, public networks, cloud services and local power remain external dependencies. SLAs, service hours, on-site work and active failover tests are agreed explicitly.
Good to know
Your questions. Clear answers.
Is SD-WAN always better than conventional routing?
No. SD-WAN can simplify standards, visibility and policy distribution, but it adds controllers, platform dependencies and an operating model. The choice follows the sites, applications, team and lifecycle rather than a product label.
Can a WAN migration be completed without interruption?
Parallel operation is sometimes possible, but a blanket promise would not be credible. Circuits, addressing, NAT, routing, DNS and applications determine the residual outage. We expose those conditions before a date is committed.
Do you test real circuit failures?
When the operator and carrier approve the test and a safe recovery path exists, we plan controlled failures. Where an active test is too risky, we document configuration, telemetry and remaining assumptions separately.
Let’s discuss your requirements
A few details are enough to begin.
You do not need a finished design. We establish the need, boundaries and a dependable next step.
Plan your site connectivityHelpful for the first conversation
- Sites, circuits and carrier contracts
- Critical applications and intended traffic paths
- Addressing, routing and security boundaries
- Maintenance windows, contacts and outage constraints
Please do not submit passwords, API keys or confidential network plans through the form.
Explore the technical detail
Why SD-WAN controllers belong in the risk modelTechnical background: Cisco Catalyst SD-WAN Design Guide