Today we delve into the foundational architecture of MSDP with BGP IPv4 Multicast address-family. While initially published in 2011, the core principles of inter-Autonomous System (AS) multicast routing remain critical for understanding modern network designs. This updated post revisits the classic setup, highlights its enduring relevance for specific use cases, and introduces how these concepts have evolved into more scalable solutions like BGP Multicast VPNs (MVPNs).
The original topology, demonstrated in a lab environment (likely GNS3 at the time), provides a clear illustration of how Multicast Source Discovery Protocol (MSDP) and BGP IPv4 Multicast work together. Our goal, as before, is to move multicast traffic from R1 in BGP AS 1 to R5 in BGP AS 5, traversing an intermediate AS 64511 (confederation 243) consisting of R2, R3, and R4. We utilize Multicast Sparse-mode with PIM Bootstrap Router (BSR), and each router’s loopback0 interface joins a group 234.0.0.R (where R is the router number).
Understanding this classic configuration provides a robust foundation for grasping more advanced multicast routing strategies. The sample diagram of the GNS3 setup is shown below:
Topology and Core IGP/BGP Overview
The topology maintains simplicity to focus on the core multicast mechanisms:
- We use OSPF Area 0 as the Interior Gateway Protocol (IGP) between R2, R3, and R4. This ensures reachability within the confederation.
- Default routes pointing towards EBGP peers on R1 and R5 (towards R2 and R3 respectively) are used for back-route purposes.
- R4 acts as a Route Reflector within the confederation, a common BGP scaling technique.
- Loopback0 interfaces of R1, R4, and R5 are advertised into both the BGP IPv4 unicast and IPv4 multicast address-families, making their loopbacks reachable for BGP and multicast purposes.
Configuring Inter-AS Multicast with MSDP and BGP
Here are the detailed steps to configure this inter-AS multicast solution, using the principles from a classic Cisco IOS environment:
1. Enable Multicast Routing Globally
Ensure multicast routing is globally enabled on all participating routers:
ip multicast-routing2. Configure PIM Sparse-Mode on Interfaces
Enable PIM sparse-mode on every interface that will participate in multicast routing. This includes physical interfaces connecting PIM neighbors and loopback interfaces for RP/BSR configuration:
interface GigabitEthernet0/0
ip pim sparse-mode3. Join Multicast Groups (Receivers)
For testing, we simulate receivers by having loopback0 interfaces join specific IGMP multicast groups. This is crucial for PIM sparse-mode to build its multicast distribution trees:
interface Loopback0
ip igmp join-group 234.0.0.R (where R is the router number)4. Designate PIM RPs and BSRs
A PIM Rendezvous Point (RP) is essential for PIM sparse-mode to register sources and discover active groups. The Bootstrap Router (BSR) is responsible for advertising RP information within a PIM domain.
- AS 1: R1 Loopback0 is configured as both PIM RP and BSR for its domain.
- AS 243 (Confederation): R4 Loopback0 is the PIM RP, and R2 Loopback0 is the PIM BSR.
- AS 5: R5 Loopback0 serves as both PIM RP and BSR for its domain.
5. Define PIM BSR Borders
To prevent RP information from leaking between AS boundaries and ensure each AS manages its own RP discovery, PIM BSR borders are configured:
interface Serial0/0 (on R2 and R3 towards external AS)
ip pim bsr-border6. Establish MSDP Peering
MSDP (Multicast Source Discovery Protocol) is used to exchange information about active multicast sources between different PIM sparse-mode domains. It achieves this by exchanging Source-Active (SA) messages. MSDP peers are typically established between the RPs of different PIM domains:
ip msdp peer <RP_address_of_remote_AS> connect-source Loopback0 remote-as <remote_AS_number>In our topology, MSDP peers are established between R1 (AS 1 RP) and R4 (AS 243 RP), and between R5 (AS 5 RP) and R4 (AS 243 RP). This ensures that SA messages from AS 1 can reach AS 5 via AS 243, and vice-versa.
We can verify the MSDP peering status:
R4#sh run | i msdp
ip msdp peer 1.1.1.1 connect-source Loopback0 remote-as 1
ip msdp peer 5.5.5.5 connect-source Loopback0 remote-as 5
R4#sh ip msdp summ
MSDP Peer Status Summary
Peer Address AS State Uptime/ Reset SA Peer Name
Downtime Count Count
1.1.1.1 1 Up 00:19:59 1 0 ?
5.5.5.5 5 Up 00:26:02 0 0 ?7. Enable BGP IPv4 Multicast Address-Family
The BGP IPv4 Multicast address-family is essential for carrying multicast-specific routing information (e.g., reverse path forwarding (RPF) information for inter-AS multicast) between BGP peers. It runs in parallel with the unicast address-family.
router bgp 64511
bgp log-neighbor-changes
bgp confederation identifier 243
neighbor 4.4.4.4 remote-as 64511
neighbor 4.4.4.4 update-source Loopback0
neighbor 12.12.12.1 remote-as 1
!
address-family ipv4
neighbor 4.4.4.4 activate
neighbor 4.4.4.4 next-hop-self
neighbor 12.12.12.1 activate
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 multicast
neighbor 4.4.4.4 activate
neighbor 12.12.12.1 activate
no auto-summary
no synchronization
exit-address-family
!Note: It’s crucial NOT to set “next-hop-self” for BGP IPv4 multicast sessions between R2-R4 and R3-R4 (within the confederation). This ensures the correct RPF path can be determined across AS boundaries.
Verification of the Classic Setup
Once the configuration is applied, we can use various show commands to verify the state of MSDP, BGP IPv4 Multicast, and PIM.
R1#sh ip msdp summ
MSDP Peer Status Summary
Peer Address AS State Uptime/ Reset SA Peer Name
Downtime Count Count
4.4.4.4 243 Up 00:02:53 0 1 ?
R1#sh ip bgp ipv4 multicast
BGP table version is 4, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 4.4.4.4/32 12.12.12.2 0 243 i
*> 5.5.5.5/32 12.12.12.2 0 243 5 i
R1#sh ip pim rp mapp
PIM Group-to-RP Mappings
This system is a candidate RP (v2)
This system is the Bootstrap Router (v2)
Group(s) 224.0.0.0/4
RP 1.1.1.1 (?), v2
Info source: 1.1.1.1 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:12:19, expires: 00:02:07
R1#sh ip pim int
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
1.1.1.1 Loopback0 v2/S 0 30 1 1.1.1.1
12.12.12.1 Serial0/0 v2/S 1 30 1 0.0.0.0
R1#sh ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
S - State Refresh Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
12.12.12.2 Serial0/0 00:52:30/00:01:39 v2 1 / S
R1#sh ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
234.0.0.1 Loopback0 00:55:15 00:02:35 1.1.1.1
224.0.1.40 Loopback0 00:55:15 00:02:33 1.1.1.1
Similar verification commands would be run on R5 to confirm its healthy configuration and connectivity. These outputs confirm that MSDP peers are up, BGP IPv4 Multicast routes are being exchanged, and PIM is operating correctly within the respective domains.
Testing Multicast Connectivity
The ultimate test is to verify that multicast traffic can flow end-to-end. We use an ICMP echo (ping) to a multicast group address from R1, expecting a reply from a receiver in R5’s domain. This simulates a source sending to the group and a receiver receiving it.
R1#ping 234.0.0.5
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 234.0.0.5, timeout is 2 seconds:
Reply to request 0 from 35.35.35.5, 52 ms
Reply to request 0 from 35.35.35.5, 88 msThe successful replies indicate that multicast traffic from R1 is indeed reaching R5. Performing the same test from R5 to R1 confirms bidirectional connectivity:
R5#ping 234.0.0.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 234.0.0.1, timeout is 2 seconds:
Reply to request 0 from 12.12.12.1, 148 ms
Reply to request 0 from 12.12.12.1, 192 msAgain, successful pings confirm the operational status of our inter-AS multicast configuration.
Evolving Inter-AS Multicast: The Rise of BGP Multicast VPNs (MVPNs)
While MSDP remains a viable solution for connecting distinct PIM-SM domains, especially in simpler, non-VPN environments, larger enterprises and service providers have largely adopted BGP Multicast VPNs (MVPNs) for inter-AS multicast within MPLS VPN deployments.
BGP MVPNs (Next-Generation MVPNs, RFC 6513/6514) offer a more scalable and feature-rich approach. Instead of relying on MSDP to exchange Source-Active messages, MVPNs leverage BGP to distribute all necessary multicast routing information, including multicast source and group details (similar to how BGP distributes unicast VPN routes). This allows for greater control, better integration with unicast VPNs, and enhanced scalability across complex MPLS backbones.
Key advantages of BGP MVPNs over traditional MSDP include:
- Integrated Control Plane: BGP handles both unicast and multicast VPN route distribution.
- Scalability: Designed for larger deployments with many multicast groups and sources.
- Security: Multicast traffic stays within its designated VPN, enhancing isolation and security.
- Efficiency: Various data plane encapsulation methods like mLDP (Multipoint LDP) or P2MP TE (Point-to-Multipoint Traffic Engineering) can be used for optimized multicast forwarding.
This classic MSDP setup provides fundamental knowledge, but awareness of BGP MVPNs is essential for understanding modern inter-AS multicast architectures.
Modern Deployment & Automation Considerations
Today, even configurations for foundational protocols like MSDP, PIM, and BGP are increasingly managed through automation. This improves consistency, reduces errors, and accelerates deployment.
Network Virtualization and Lab Environments
Beyond GNS3, popular choices for lab environments include:
- EVE-NG: A robust multi-vendor network emulator supporting a wide range of virtual appliances.
- Cisco Modeling Labs (CML): Cisco’s official virtualization platform, offering a highly accurate representation of Cisco devices.
These platforms allow engineers to design, test, and validate complex multicast solutions before production deployment.
Automation and Infrastructure as Code (IaC)
For deploying and managing network configurations, tools for Infrastructure as Code (IaC) are standard:
- Ansible: A popular automation engine for configuration management, orchestration, and task automation.
- Python: With libraries like Netmiko, NAPALM, or Scrapli, Python allows for programmatic interaction with network devices, enabling custom automation scripts and data gathering.
For example, a simple Python script using Netmiko could gather the MSDP summary from multiple routers:
from netmiko import ConnectHandler
device = {
"device_type": "cisco_ios",
"host": "R4_IP_ADDRESS",
"username": "admin",
"password": "cisco",
}
with ConnectHandler(**device) as net_connect:
output = net_connect.send_command("show ip msdp summary")
print(output)
Observability and Telemetry
Modern networks rely on real-time data for monitoring and troubleshooting. While traditional show commands are still invaluable, streaming telemetry protocols like gNMI and gRPC provide continuous, high-fidelity data streams from devices. This allows for proactive monitoring of multicast states, traffic patterns, and quicker identification of issues compared to periodic polling.
Conclusion
The configuration of MSDP with BGP IPv4 Multicast remains a cornerstone for understanding inter-AS multicast routing. It demonstrates how disparate PIM domains can exchange source information and how BGP can be extended to carry multicast routing paths. As networks evolve, so do the solutions. While MSDP is foundational, BGP Multicast VPNs (MVPNs) have emerged as the preferred architecture for scalable, integrated inter-AS multicast within MPLS environments.
Today’s network engineers must not only grasp these fundamental protocols but also be proficient in using modern lab environments, automation tools, and observability platforms to design, deploy, and manage complex multicast solutions efficiently and reliably.
- How to Configure a Secure Site-to-Site VPN on Cisco Firepower Complete Guide - December 3, 2025
- Jobs for Network Engineers: Roles, Skills & Pay - December 3, 2025
- How to Change WiFi Password on Any Router : The Last Guide You Need - December 1, 2025