Cisco & Meraki specialists. Across the UK.
+44 203 196 6566 · option 1sales@proxar.co.uk

Connect. Secure. Manage.

WAN Outage Investigation

Investigate recurring WAN outages using network telemetry, provider records and application symptoms, producing a clear evidence trail for remediation.

Cisco Partner since 2009 Projects & ongoing support

Illustrative enterprise Cisco network rack in a modern office environment
Your network. Properly considered.Design · Implementation · Support
1,000+

Devices supported
across the UK

20+

Client locations
supported

Nearly 8 Tbps

Traffic handled
at peak time

3 min

Average
response time

Average response is not a resolution time or a contractual guarantee. Support scope and response commitments are agreed for each engagement.

WAN outage investigation checks why a connection failed, the period of impact and what could prevent a repeat. We compare Cisco and Meraki device evidence with provider records and app symptoms. Findings distinguish proven causes from possible explanations. A closed carrier ticket alone may not answer the questions needed to plan the right fix.

01

The whole path

Understand how sites, providers, cloud networks and security controls fit together.

02

Resilience that can be tested

Separate a second circuit from genuine end-to-end service resilience.

03

Provider coordination

Keep addressing, routing and escalation ownership clear across organisations.

Establish the incident timeline first

We start with the earliest reliable symptom and the point at which service was demonstrably restored. User reports, monitoring alerts, interface logs and app records often describe different moments. An app may detect missing traffic after the loss began, then spend extra time reconnecting. Its recovery interval should not automatically be described as the duration of the network outage.

Time zones and clock accuracy are checked before records are compared. We preserve original timestamps and document any conversion used to create the common timeline. A gap between two observations can limit the precision of the conclusion. We state that uncertainty rather than inventing an exact failure time. This matters when evidence is used in supplier discussions or a formal incident review.

Illustrative Cisco and Meraki network rack in a modern office
01The office network: switching, uplinks and structured cabling.
Cisco PartnerCisco Partner
Cisco MerakiCisco Meraki
ISO 9001Quality management
ISO 27001Information security
Cyber EssentialsCyber Essentials
Cyber Essentials PlusCyber Essentials Plus

MCI Network Services is operated by Proxar Ltd. Certifications apply to the certified legal entity and the scope of its certificates. View accreditation information

Identify the affected service paths

A reported WAN outage may affect one site, one app, one direction or only traffic using a particular tunnel. We map the affected source and destination networks and compare them with services that continued working. This narrows the investigation and helps separate local access, routing, security and external-provider dependencies.

For a Cisco or Meraki edge, we examine the active uplinks, routes, tunnels and relevant policies during the event. The current topology may differ from the incident state because failover or emergency changes have already occurred. We use setup history and retained telemetry where available, and label gaps in the historical record. Present-day success does not disprove an earlier fault.

Illustrative Cisco and Meraki fibre network rack with structured cabling
02Fibre, switching and the physical path behind the service.

A useful starting point

Not sure where to start?

Bring the requirement. We will help you define the engineering work.

Talk to a specialist

Correlate physical and control-plane evidence

Interface errors, optical measurements, link transitions and power events can identify a local physical problem. Routing-neighbour resets, route withdrawals and tunnel re-establishment point to different mechanisms. We compare these observations rather than assuming the first visible alarm is the root cause. Several alarms can be consequences of one upstream failure.

Provider evidence is requested with precise circuit references, timestamps and test results. We distinguish the customer’s handoff from the carrier’s wider path and ask which part was actually tested. A supplier’s successful loopback test may show one segment without proving the end-to-end app route. Clear evidence reduces repeated generic troubleshooting and makes escalation more productive for both teams.

Illustrative Cisco and Meraki network operations centre with monitoring displays
03Visibility, monitoring and operational control.

Use packet evidence proportionately

Where authorised captures are available, we analyse the relevant traffic rather than collecting indiscriminately. Sequence information, retransmissions, tunnel packets and timing may help determine where communication changed. A capture taken at one interface cannot prove what happened on every upstream link; observation points and capture limitations are recorded alongside the findings.

Sensitive payloads are handled within an agreed scope. We can work with filtered or redacted evidence where it answers the question and restrict access to the material used for the investigation. For financial-market services, network loss, feed-handler detection and app resynchronisation are considered separately. A long recovery process is not, by itself, evidence of equally long transport loss.

Illustrative Cisco and Meraki equipment in a modern data-centre aisle
04Resilient infrastructure from rack to service path.

Examine the recovery and the failed safeguards

The investigation considers why resilience did or did not work. A backup route may have been unavailable, a tracking target may have stayed reachable through the wrong path or the surviving circuit may have become congested. We also review whether a stateful firewall or changed public address prevented apps from recovering after routing had converged.

Operational actions are assessed without assuming that every intervention helped. Restarting equipment can restore service while destroying useful evidence. Multiple simultaneous changes make attribution harder. We document the observed effect of each action and recommend a more controlled sequence for future incidents. The aim is a repeatable response, not a retrospective search for someone to blame.

Illustrative Cisco and Meraki data-centre network infrastructure
05Network infrastructure designed around the workloads it carries.

Deliver findings with an actionable level of confidence

The report separates confirmed cause, contributing conditions and unresolved hypotheses. Supporting evidence accompanies each important conclusion. Recommendations are prioritised by recurrence risk and business impact, with owners and verification steps. Where more observation is needed, we specify the missing telemetry or test rather than calling the investigation complete without sufficient evidence.

MCI can investigate a single serious event or a recurring pattern across UK sites. Subsequent work may include WAN recovery runbooks, monitoring changes or controlled failover tests. For an initial discussion, provide the affected services, approximate incident window and available records. Avoid making further disruptive changes solely to gather evidence unless they are properly authorised and necessary.

Illustrative enterprise Cisco network rack in a modern office environment
06Enterprise switching and routing, built to be operated.

Talk to a specialist

What does your network need next?

Tell us what you are planning, changing or trying to improve. We will help define a practical next step and the engineering scope.

+44 203 196 6566

Choose option 1

sales@proxar.co.uk

UK-wide service.
Most of our engineers are based in Kent, with a focus on London, Sussex, Essex and Berkshire.

Existing customers should use their agreed support and escalation channels. This form is for service enquiries, not a monitored emergency ticket.

Tell us what you need.

A short outline is enough. Please do not include passwords or sensitive network details.

Thank you. Your enquiry has been submitted.

We’ll use these details to respond to your enquiry. Please leave out passwords and sensitive network information. Read our privacy notice.