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

Connect. Secure. Manage.

Network Performance Assessment

Investigate how a Cisco or Meraki network behaves under real demand, separating capacity problems from routing, wireless and application issues.

Cisco Partner since 2009 Projects & ongoing support

Illustrative Cisco Meraki wireless access point in a modern office
Look beyond the alarm.Evidence first. Controlled next steps.
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.

A network performance assessment investigates where the network may be affecting application experience and what the evidence actually shows. MCI examines Cisco and Meraki environments using the reported symptoms, traffic paths and available measurements. The objective is to distinguish a genuine network constraint from an application, endpoint or external-service issue before changes are made.

“Slow” can mean several things: delayed connection establishment, poor throughput, intermittent loss or an application that pauses at a particular step. Those differences matter. A useful assessment begins by describing the behaviour precisely enough to investigate it.

01

A clear requirement

Turn the business need into a practical network scope with visible dependencies.

02

A controlled delivery

Plan implementation, testing and rollback before production changes begin.

03

A supportable result

Leave useful records, ownership and escalation routes behind.

Define the symptom and the conditions around it

We establish who is affected, which applications are involved, when the issue occurs and whether it can be reproduced. Comparisons between affected and unaffected users, sites or paths can help narrow the scope.

Recent changes are relevant, but timing alone does not prove causation. We review the evidence without assuming that the last configuration change must be responsible or that a problem described as “the network” necessarily originates there.

The business context also matters. A small delay in a background transfer and an interruption to a critical interactive service may require different investigation priorities and observation methods.

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

Trace the application path through the environment

The assessment follows the route between the client and the service, including relevant switching, routing, security inspection and provider connections. It identifies where measurements can usefully separate one part of the path from another.

For Cisco and Meraki infrastructure, we use the management and diagnostic information appropriate to the platform. The available evidence may differ between devices and features, so the method is selected for the actual environment rather than a fixed tool preference.

Dependencies such as name resolution, authentication and application hosting are considered where they affect the observed behaviour. A healthy link does not establish that every service needed to complete a user action is responding as intended.

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

A useful starting point

Tell us what is happening.

A short description of the problem is enough for an initial discussion.

Talk to a specialist

Measure the characteristics that relate to the complaint

Latency, loss, retransmissions, utilisation and device resources can each be relevant, but none should be interpreted without context. An average may hide a short burst, and a single test may not represent the period when users experience the issue.

We examine the collection method and its limitations. Measurements should identify where they were taken, what traffic or application they represent and how they relate to the reported symptom.

Where packet-level evidence is needed, network packet analysis can provide a more detailed view. Captures are targeted and handled appropriately, rather than collected indiscriminately from a live business environment.

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

Distinguish capacity from other causes

A bandwidth upgrade is one possible response, not the default conclusion. Performance can also be affected by policy, path selection, interface problems, application behaviour or an external dependency.

If capacity is the material issue, capacity planning can assess the required resources and growth assumptions. If the evidence points elsewhere, the report identifies the relevant owner and next investigation step rather than recommending more bandwidth to make the assessment appear conclusive.

Where a provider is involved, a concise evidence package helps the escalation. It should describe the affected service, timing and observations without claiming visibility into parts of the provider’s infrastructure that were not examined.

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

Recommend changes that can be validated

The output separates confirmed findings from working hypotheses and remaining information gaps. Proposed actions are linked to the evidence and the expected effect on the service.

A controlled test or configuration change may be needed to confirm the cause. The method, potential impact and rollback are agreed before execution. Several simultaneous changes can make it difficult to know which one affected the result.

After remediation, representative measurements and application checks establish whether the original problem has improved. The assessment should leave an understandable record that supports future diagnosis, not merely a statement that the network appeared healthy during the engineer’s visit.

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

Performance assessment questions

Can you investigate intermittent problems?

Yes. The approach may need a longer observation period, better event records or targeted collection when the symptom occurs. We explain what evidence is missing rather than declaring the issue resolved because it did not appear during a short test.

Will you need access to application servers?

Not always, but application-owner information can be important. The network assessment identifies where its visibility ends and where another team needs to provide evidence. Responsibility for the application itself remains separate unless explicitly included.

Can you prove that the internet provider is at fault?

Only where the evidence supports that conclusion. We can isolate observations at the service boundary and coordinate an escalation, but we do not infer a provider fault solely because internal devices appear healthy.

How do we start?

Record a few examples with approximate times, affected users and the activity being attempted. Arrange a network performance assessment so the investigation can target a clear symptom rather than a general impression of slowness.

Talk to a specialist

Need a specialist view?

Tell us what is affected, what changed and what your team has already checked. A short outline is enough to start.

+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.