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

Connect. Secure. Manage.

Cisco Source-Specific Multicast

Assess and implement source-specific multicast on Cisco networks, checking receiver support, source addressing and the operational model.

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.

Cisco Source-Specific Multicast provides delivery for a receiver that requests a particular source and multicast group together. This source-and-group model can simplify distribution where applications know exactly which sender they need, but it depends on receiver support and correct source reachability. MCI Network Services assesses and implements source-specific multicast on supported Cisco networks, checking the complete application and forwarding path before treating it as an alternative to an existing multicast design.

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.

Confirm that the application can identify its source

A source-specific service needs more than a group address in a configuration sheet. We establish how receivers learn the source address, how they express the subscription and whether the address can change during failover. The application owner or provider must confirm those details because the network cannot infer an intended source from an ambiguous request.

For IPv4, IGMPv3 source-aware membership is relevant to native source-specific operation. A compatible operating system alone does not prove that the application uses the necessary subscription method. We review the actual receiver behaviour, including virtualised hosts and appliances whose interfaces expose only limited multicast settings.

Illustrative Cisco and Meraki fibre network rack with structured cabling
01Fibre, switching and the physical path behind the service.
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

Define the source-and-group register

We document each approved source, group, receiver population and transport service. The register should identify who owns the addressing and how changes are communicated. This is especially important for externally supplied feeds, where a source change can require coordination across network policy and application configuration.

The group range configured for source-specific treatment must match the agreed architecture. We avoid assuming that every existing multicast address can simply be reclassified without consequences. Other services may rely on any-source behaviour or a rendezvous point, and those dependencies need to remain intact during a staged deployment.

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

A useful starting point

Not sure where to start?

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

Talk to a specialist

Check the routed path to the source

Source-specific multicast builds distribution toward the selected source, so the network needs an appropriate route and reverse-path expectation. We review source reachability, PIM configuration where required, routing contexts and any policies that influence the incoming interface. Ordinary connectivity tests provide only part of that evidence.

A dual-provider or multi-site design needs particular attention. The preferred unicast route may change independently of the packet arrival path used by a provider. We document how those relationships are intended to behave and test approved failure scenarios rather than adding static routes without understanding the underlying asymmetry.

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

Handle legacy receivers explicitly

Some Cisco platforms offer mapping mechanisms that can associate a group-only request with a source. Such mechanisms may help with a specific legacy requirement, but they are not equivalent to an application natively selecting its source. We verify support and document where the mapping is maintained and who may change it.

A mapping also creates an operational dependency. If a source moves, the application may still appear correctly configured while the network continues requesting the old sender. We assess whether upgrading or reconfiguring the receiver would provide a clearer long-term solution instead of expanding an increasingly complicated set of exceptions.

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

Review boundaries and capacity

A source-specific subscription narrows the requested sender, but it does not replace access controls, provider entitlements or traffic boundaries. We define which sources and groups may enter the estate and which segments may receive them. Firewall and platform support must be checked along the complete path.

Capacity planning considers the number of source-and-group entries, replication points and stream rates. Two feeds sent to separate receivers can create different load from the same feeds replicated across many ports. We also examine the remaining capacity after a link or device failure, not just the normal operating state.

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

Prove subscription and delivery

Testing begins with the receiver’s actual membership request and follows the resulting forwarding state toward the source. We verify that the intended traffic arrives and that a different source using the same group is not mistaken for the required service. Captures and counters are interpreted with their location and limitations recorded.

The test plan includes starting and stopping receivers, source availability and any agreed redundancy behaviour. Application recovery remains a separate observation from network convergence. A packet stream may return promptly while a receiver requires replay, resynchronisation or another application-level action before useful service resumes.

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

Keep source changes controlled

The handover includes the source-and-group register, relevant configuration, mapping exceptions, tests and escalation contacts. New sources or address changes should pass through a documented process involving the provider or application owner. This avoids treating a deliberate source restriction as an unexplained network fault months later.

MCI can assess source-specific multicast readiness or implement it within a broader Cisco IP multicast service. We define which receivers are suitable, what network work is required and how the resulting delivery will be verified, without assuming that all existing multicast applications can use the same model.

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

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.