Connect. Secure. Manage.
Multicast Troubleshooting
Investigate missing or duplicated multicast traffic across Cisco networks, tracing receiver membership, routing state and actual forwarding behaviour.
Devices supported
across the UK
Client locations
supported
Traffic handled
at peak time
Average
response time
Average response is not a resolution time or a contractual guarantee. Support scope and response commitments are agreed for each engagement.
Multicast troubleshooting starts by identifying exactly which source, group and receiver are affected, and when the evidence shows a problem. A healthy interface or routing session does not prove that the requested stream reaches the application. MCI Network Services investigates Cisco multicast faults through the control plane, forwarding path and receiver boundary, helping customers separate upstream delivery problems from local network loss or host-side behaviour.
Cisco-focused engineering
Design around the platform, traffic and failure behaviour you actually operate.
Change with evidence
Use pre-checks, acceptance criteria and a documented route back.
Operational handover
Keep the configuration, diagrams and responsibilities understandable after delivery.
Establish a precise incident scope
We collect the source address, group address, transport port, receiver interface and the application’s description of the failure. We also ask whether other receivers or redundant feeds were affected. Those distinctions help narrow the investigation before changes are made to a shared network.
Time is particularly important. The moment an application detects a sequence gap may be later than the first lost packet, and its recovery can continue after network delivery has resumed. We record time zones, clock accuracy and the meaning of each timestamp. This prevents an application resynchronisation interval from being incorrectly reported as a continuous network outage.
Standards & partnerships
Confidence in the team behind your network.
Cisco Partner
Cisco Meraki
Cyber Essentials
Cyber Essentials PlusMCI Network Services is operated by Proxar Ltd. Certifications apply to the certified legal entity and the scope of its certificates. View accreditation information
Check whether the receiver asked for the service
We examine membership reports, host configuration and the relevant switch state. A process may have joined on the wrong interface, requested the wrong source or stopped renewing membership. Conversely, a valid request may not have reached the device responsible for maintaining the receiver segment.
We review IGMP version and querier behaviour where applicable, including the effect of multiple receivers behind one port. A multicast service that fails after a predictable interval may point toward ageing or membership handling, but timing alone is not proof. We compare the hypothesis with actual reports and forwarding entries.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Follow the routing state toward the source
The investigation checks PIM neighbours, RP mapping where relevant, incoming interfaces and outgoing interface lists. Reverse-path expectations are compared with the actual packet arrival path. A change to ordinary routing can affect multicast acceptance even where source reachability still appears valid.
We also inspect boundaries such as firewalls, VRFs and provider handoffs. The supported forwarding behaviour depends on the platform and configuration. We avoid assuming that an appliance forwards multicast simply because it permits similar unicast traffic or because a BGP session to the provider remains established.
Different environments. The same care.
Built around the work
your network supports.
Finance, banking and the wider private sector. We start with the systems and people that depend on your connections.
Finance & banking
Market-data paths, routing and provider coordination on clients’ behalf.
Financial-market services ↗Offices & multi-site teams
Reliable access between people, workplaces and business applications.
Office network design ↗Data centres & cloud
Network boundaries, workload connections and operational ownership.
Data centre networks ↗Compare packets at useful observation points
A capture near the provider handoff and another near the receiver can help locate where a stream changes or disappears. The capture method matters: a mirror port may drop traffic under load, and a host capture may not represent every packet seen on the wire. We record capture limits and interface conditions before drawing conclusions.
Where addresses are translated or traffic passes through virtual networking, we map the observed addresses to the original service. Filters should match the traffic at the actual capture point. We limit collection to the authorised investigation and protect packet data that may contain sensitive customer or provider information.
Look beyond average utilisation
Short bursts, queue pressure, interface errors and replication limits can cause loss even when average bandwidth looks comfortable. We inspect relevant counters and hardware-specific evidence, taking care to distinguish a current event from a cumulative counter recorded long before the incident.
Receiver resources can also matter. Socket buffering, application processing, driver behaviour and virtualisation may affect whether an arriving packet becomes usable application data. We coordinate with the host or application team rather than label every sequence gap a switch fault or dismiss it because network monitoring shows no sustained outage.
Make changes against a specific hypothesis
An investigation should identify what a proposed change is expected to prove or correct. Disabling snooping, resetting routing or broadening multicast forwarding may temporarily restore one receiver while disrupting others or hiding the original cause. We agree the affected scope, verification and rollback before changing production behaviour.
When another provider owns part of the path, we prepare a concise evidence package: service identifiers, timestamps, observations and the specific question that needs answering. For financial-market multicast, that supports client-side coordination without implying that MCI controls the exchange’s delivery systems or application entitlement process.
Close with evidence and prevention
The incident report separates confirmed findings, likely explanations and unresolved gaps. It records the remediation, tests and any monitoring or documentation improvements needed. Where the event could not be captured directly, we do not turn an absence of evidence into a definitive root-cause claim.
MCI can assist with a persistent multicast fault, a post-change failure or an intermittent loss that requires coordinated observation. The objective is to establish where delivery fails and what should change, while preserving the evidence and keeping unrelated production services protected.
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 6566Choose option 1
sales@proxar.co.ukUK-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.
Please check your name, email and message, then try again.
Your form session expired. Please try again.
Please wait a minute before sending another enquiry.
We could not submit your enquiry. Please call or email us instead.