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

Connect. Secure. Manage.

SD-Access Troubleshooting

Investigate Cisco SD-Access endpoint, fabric and policy faults using evidence from the underlay, control plane and affected application paths.

Cisco Partner since 2009 Projects & ongoing support

Illustrative Cisco and Meraki data-centre network infrastructure
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.

SD-Access troubleshooting needs to follow the client journey through identity, access, fabric forwarding and external services. A green device icon does not prove that every part of that journey works. MCI Network Services investigates Cisco fabric faults using evidence from Catalyst Center, network devices and the relevant identity or application systems, helping teams distinguish the failing component before making changes.

01

Cisco-focused engineering

Design around the platform, traffic and failure behaviour you actually operate.

02

Change with evidence

Use pre-checks, acceptance criteria and a documented route back.

03

Operational handover

Keep the configuration, diagrams and responsibilities understandable after delivery.

Establish the affected client and destination

We begin with a specific example: the endpoint, its location, the application or destination and the time of the failure. Whether the issue affects one client, one group, one fabric edge or an entire site changes the investigation. We also record recent policy, software and topology changes without assuming that the most recent change must be the cause.

The user’s symptom is translated into testable stages. Can the device connect to the access port or wireless network? Does it authenticate, receive an address and reach its local gateway? Can it reach a destination in the same virtual network or only fail when leaving the fabric? Those distinctions prevent unnecessary work on a healthy part of the system.

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

Separate identity from connectivity

Authentication and authorisation are checked against the intended endpoint policy. We examine the result from the relevant identity service and the actual group or virtual-network assignment. A successful authentication event can still be followed by the wrong access decision, and a cached endpoint state can complicate interpretation after a change.

We compare the affected device with a working example only when their intended policy is genuinely comparable. Two laptops in the same room may belong to different groups or use different authentication methods. The investigation records that context rather than treating physical proximity as proof that they should behave identically.

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

A useful starting point

Not sure where to start?

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

Talk to a specialist

Verify the underlay before blaming the overlay

Fabric transport depends on underlying reachability. We inspect the relevant links, routes, interface health and MTU behaviour, concentrating on the path between the affected nodes. A physical or routed-path fault can present as a fabric problem while the controller remains reachable through another route.

Tests are chosen with awareness of virtual routing contexts and distributed gateway behaviour. A ping sourced from a fabric device may not follow the same path as client traffic. We therefore use the right source and observation points and avoid interpreting a single successful device-originated test as proof of end-to-end client connectivity.

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

Trace endpoint information and forwarding

For a suspected overlay fault, we follow the endpoint’s registration, mapping and forwarding state on the relevant devices. The purpose is to establish whether the network knows where the endpoint is and whether packets are being sent to the expected location. Stale or missing state is compared with the intended topology and recent events.

We also review policy enforcement along the path. A packet discarded by an intended access rule is not a transport failure, although the policy itself may be wrong for the business requirement. The investigation separates these outcomes so the corrective action is approved by the right owner rather than bypassing security to make a test succeed.

Illustrative Cisco and Meraki equipment in organised data-centre racks
04Data-centre connectivity with clear physical and logical boundaries.

Investigate the fabric boundary

When internal communication works but external services fail, border handoffs, route exchange and return paths become the focus. Shared DNS, DHCP and authentication services can be affected differently from application traffic. We coordinate with the external network or security team and provide specific evidence for the boundary under investigation.

The fault may sit outside the fabric. A firewall policy, missing return route or unavailable application can produce the same user complaint as a fabric failure. We make the boundary of the evidence clear and do not assign blame to a provider merely because the last visible hop belongs to it.

Illustrative Cisco and Meraki industrial network equipment in a plant environment
05Network engineering for operational and industrial environments.

Use telemetry carefully

Catalyst Center Assurance and device telemetry can help correlate events and identify affected clients. Their usefulness depends on data being collected correctly and clocks being aligned. We check whether an apparent absence of activity is a real service condition or a gap in telemetry.

Automated issue suggestions are treated as investigation leads, not final proof. We validate them against device state and representative traffic. This is particularly important when several symptoms share one underlying dependency or when a recent controller change affects visibility without interrupting forwarding.

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

Restore service and document the cause

Any remedial change has an approved scope and a way to verify its effect. In an urgent incident, a temporary workaround is recorded with a review or removal condition. Broad fabric reprovisioning or protocol resets are not used casually because they can affect healthy services and destroy useful evidence.

MCI’s findings distinguish the confirmed cause, contributing factors and unresolved questions. Recommendations may cover policy, configuration, monitoring or operating procedures. For recurring incidents, a wider readiness and design review can identify structural issues. Our objective is a supported recovery and a clearer explanation of the network, not simply a dashboard that has returned to green.

Illustrative Cisco and Meraki network rack in a modern office
07The office network: switching, uplinks and structured cabling.

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.