Skip to content

Intro to Multicast (for IPv4)

Estimated time to read: 32 minutes

  • Originally Written: April, 2024

Note

This post is a multicast introduction of some of the concepts I've been learning. It doesn't cover everything but I've tried to include additional resources where it makes sense

Some key points to note

  • Unicast = 1 device to 1 device
  • Broadcast = 1 device to all devices
  • Multicast = 1 device to some devices
  • Multicast is a protocol used to send data from one source to multiple destinations simultaneously and one common example is in video or media streaming (e.g. one source streams a video to many screens in a digital signage environment)
  • Relies upon the underlying unicast routing table to send traffic (i.e. first setup routing using static or dynamic routing protocols to ensure the sources can talk to the receivers)
  • Two main multicast protocols covered in this post
    • IGMP - functions within a VLAN to deliver a multicast stream. Hosts can send IGMP membership requests to join a multicast group
    • PIM - used for multicast routing to send traffic from one or more sources to one or more receivers across multiple subnets
  • This post covers PIM Sparse Mode which includes PIM Source Specific Multicast (SSM) and PIM Any Source Multicast (ASM)
    • A Rendezvous Point (RP) is required for ASM and this can either be statically configured on each PIM router or dynamically selected with a protocol such as BSR
  • Multicast is sent as UDP traffic as seen in the packet capture below (this stream was created by running iperf -c 239.1.1.10 -u -T 10 -t 1000 -i 1 on the source. The source port, 38608 was selected by the operating system and 5001 is the default port used by iperf)

Common terminology

  • FHR (First-Hop Router)
    • the router that is directly connected to the multicast source and responsible for receiving the original multicast data from the source and injecting it into the multicast network
  • LHR (Last-Hop Router)
    • the router that is directly connected to the multicast receivers (host devices)
  • Multicast distribution tree
    • structure formed by multicast-enabled routers to efficiently route data from sources to multicast group members.
  • Shared tree
    • multicast distribution tree that has a single common root (often a Rendezvous Point, RP) used by all sources and receivers of a multicast group. The tree is not optimal for all source-receiver pairs in terms of path length, but it is efficient in terms of state maintained in the routers. It is also known as a Rendezvous Point Tree (RPT)
  • SPT (Shortest Path Tree)
    • it's also known as a source tree and is a type of multicast distribution tree where the path from the source to each receiver is the shortest possible path within the network. Each source has its own SPT, which can lead to more trees in the network but provides the most efficient path between the source and the receivers. In PIM, receivers may initially join a shared tree and then switch to an SPT if it's more efficient
  • Reverse Path Forwarding (RPF) check
    • multicast routing technique used to ensure a loop free topology
    • RPF checks whether an incoming multicast packet is received on the interface that the router would use to send unicast packets back to the source
    • if not, the packet is dropped
  • IGMP (Internet Group Management Protocol)
    • used by hosts to report their multicast group memberships to routers
  • IGMP snooping
    • used by switches to forward multicast traffic only to ports with interested receivers
  • PIM (Protocol Independent Multicast)
    • used for multicast routing to send traffic from one or more sources to one or more receivers across multiple subnets
  • SSM (Source-Specific Multicast)
    • receiver specifies both the source address and the multicast group address. Does not require a Rendezvous Point (RP)
  • ASM (Any-Source Multicast)
    • receivers specifies only the multicast group address and can receive traffic from any source sending to that group. Requires a Rendezvous Point (RP)
  • Mroute table (Multicast Routing Table)
    • table maintained by a router to keep track of active multicast sources, groups, and the interfaces on which multicast traffic should be forwarded
  • (S,G) (Source, Group)
    • notation used in multicast to represent the flow of packets from a specific source (S) to a specific multicast group (G). You might hear it referred to as S comma G
  • (*,G) (Wildcard, Group)
    • notation used in multicast to indicate any source (*) sending to a specific multicast group (G). You might hear it referred to as star comma G
  • Incoming interface
    • network interface on a router that receives multicast traffic from the source or from another multicast router
  • OIL (Outgoing Interface List)
    • list maintained by a multicast router that specifies the interfaces through which multicast packets should be forwarded for a given multicast group
  • RP (Rendezvous Point)
    • router in a multicast network that acts as a common meeting point for sources and receivers of multicast traffic
  • Auto-RP (Automatic Rendezvous Point)
    • Cisco proprietary protocol used in multicast to simplify the configuration of the RP in large networks. With Auto-RP the RP is dynamically advertised and discovered by multicast routers
  • BSR (Bootstrap Router)
  • Multicast Source Discovery Protocol (MSDP)
    • Used to interconnect multiple PIM-SM domains or to create an anycast RP

Common multicast addresses

  • These are some of the common multicast addresses you might see. You would typically use the 232/8 range for Source Specific Multicast and the 239/8 range for Any Source Multicast
  • You may also see other multicast addresses in use when looking at packet captures with Wireshark or tcpdump. For example 224.0.05 is used by OSPF to send hello packets to any OSPF enabled routers on a segment

Multicast address blocks

Block Addresses Usecase
224.0.0.0/24 224.0.0.0 - 224.0.0.255 Local Network Control Block e.g. used by routing protocols for control plane. Not routable
224.0.1.0/24 224.0.1.0 - 224.0.1.255 Internetwork Control Block e.g. used by NTP. Routable
232.0.0.0/8 232.0.0.0 - 232.255.255.255 Used by Source Specific Multicast. Routable
239.0.0.0/8 239.0.0.0 - 239.255.255.255 Administratively Scoped Block. e.g. this would be the multicast group range you could use in your private network. Routable

Multicast addresses you might sometimes see in a packet capture

Address Purpose and Use Case
224.0.0.1 All systems on this subnet (e.g. IGMPv2 to communicate with all multicast-capable hosts)
224.0.0.2 All routers on this subnet (e.g. used as the destination address by HSRPv1 to send hello packets between routers in a segment )
224.0.0.5 OSPF routers (used to send hello packets to all OSPF routers on a segment. You might also see this as ospf-all.mcast.net)
224.0.0.6 OSPF designated routers (used to send OSPF routing information to designated routers on a segment)
224.0.0.9 RIPv2 routers (used by RIPv2 routers to exchange routing information)
224.0.0.10 EIGRP routers (used to send routing information to all EIGRP routers on a segment)
224.0.0.13 PIMv3 routers (used by PIM for hello messages. You might also see this as pim-routers.mcast.net)
224.0.0.18 VRRP (used for assigning virtual IP addresses to available routers)
224.0.0.22 IGMPv3 (used by an IGMPv3 router to report its multicast group memberships)
224.0.0.102 HSRPv2 (used as the destination address to send hello packets between routers in a segment. Note that this has changed from HSRPv1 which uses the "all routers" multicast group")
224.0.0.251 Multicast DNS (e.g. Apple Bonjour)
224.0.1.40 PIM Auto-RP Discovery (used for RP discovery with PIM Sparse Mode. You can disable this on IOS-XE with the no ip pim autorp if you're using BSR or static RPs)



High level multicast flow (example using ASM)

  1. Receiver signals an interest
    • Hosts on a network that want to receive multicast traffic for a specific group address will send an IGMP Report message to their local router indicating they wish to join the group
  2. Routers track the interest from receivers
    • When a router receives an IGMP report from a host for a multicast group, it will add that host's network interface to the outgoing interface list for that multicast group (*,G entry) in its multicast routing (mroute) table
  3. Routers send PIM Join to RP
    • The local router will send a PIM Join message towards the Rendezvous Point (RP) for the specific multicast group (,G), indicating that there are local receivers interested in joining the multicast stream. (,G) is used as the receiver may not yet know which sources, if any, are available
  4. Source sends multicast traffic
    • The multicast source begins transmitting data to the multicast group address. The first-hop router (FHR) closest to the source will receive this traffic on its interface connected to the source
  5. Routers learns of multicast sources
    • When a router receives a multicast packet from a source, it will add an entry to its mroute table for that source and group (S,G entry in the mroute table). The incoming interface for this entry is the interface on which the packet was received
  6. FHR forwards multicast traffic to RP
    • The FHR encapsulates the multicast traffic and sends it towards the Rendezvous Point (RP) (if the network is using PIM Sparse Mode and a shared tree is being used). The FHR creates an (S,G) state in its mroute table, with the outgoing interface pointing towards the RP.
  7. RP builds shared tree and redistributes multicast traffic
    • When multicast traffic is received from the FHR, the RP creates or updates its own (*,G) and (S,G) mroute entries. The RP then forwards the multicast packets down the shared tree towards all downstream routers that have signaled interest through PIM Joins
  8. Routers switch to SPT (if applicable)
    • Routers may initiate a switch from the shared tree to a shortest path tree (SPT) for more efficient routing. They do this by sending PIM Join messages towards the source of the multicast traffic, creating an (S,G) entry in the mroute table for the shortest path from the source to the receiver
  9. Multicast traffic reaches receivers
    • The last-hop router (LHR) receives the multicast traffic from the multicast distribution tree (either shared tree or SPT) and forwards it onto the local network segment where the interested receivers are located (using the IGMP membership information to only deliver to the interfaces where interested receivers are connected)

Intermediate routers

Reverse Path Forwarding (RPF) Check

RPF checks whether an incoming multicast packet is received on the interface that the router would use to send unicast packets back to the source

Multicast protocols

  • Internet Group Management Protocol (IGMP)

    • functions within a VLAN to deliver a multicast stream. Hosts can send IGMP membership requests to join a multicast group

  • Protocol Independent Multicast (PIM)

    • used for multicast routing to send traffic from one or more sources to one or more receivers across multiple subnets

IGMP

  • IGMP is sent in an L3 packet and uses protocol
  • Messages are carried with IP protocol number 2 (Not an L4 segment so not TCP or UDP header sent)
Feature IGMPv1 IGMPv2 IGMPv3
Membership Report Hosts send reports to signal group membership Hosts send reports to signal group membership and can send a Leave Group message when leaving a group Hosts send reports to signal membership in multiple groups. Also supports source-specific multicast (SSM) through membership reports
Query Messages General Query only; routers query hosts to check group membership. Includes General and Group-Specific Queries, allowing routers to query for specific group membership Includes General, Group-Specific, and Group-and-Source-Specific Queries, allowing filtering on source addresses
Leave Messages Not supported Leave Group messages added to signal intent to leave a group, with routers confirming if other hosts are still interested through Group-Specific Queries IGMPv2 Leave Group message is still used, but immediate leave is signaled through membership reports with INCLUDE/EXCLUDE lists
Membership Timing Hosts periodically send membership reports to stay in a group, with long leave latency Hosts periodically send membership reports, with faster leave response due to Leave Group messages and Group-Specific Queries Hosts periodically send membership reports, supporting immediate leave through Group-and-Source-Specific Queries
Robustness Basic, with no mechanism to handle lost messages Improved robustness with retransmission of Leave Group messages and Group-Specific Queries Further robustness with the ability to specify the number of retransmissions for queries and reports
Backward Compatibility N/A (first version) Compatible with IGMPv1, allowing interoperation with older versions Compatible with IGMPv1 and IGMPv2, with routers responding to all versions accordingly

IGMP Snooping

As mentioned above, IGMP messages are carried within an L3 packet and therefore L2 switches won't look at the the IP header. Without IGMP snooping, an L2 switch will treat multicast traffic like broadcast traffic. This means that multicast packets will be forwarded to all ports regardless of whether the attached devices have joined the multicast group or not.

You can avoid this by enabling IGMP snooping which allows the L2 switch to look at the L3 header and identify multicast group memberships. It can then send the multicast packets out only the ports which contain receivers for the multicast group.

PIM

  • Used for multicast routing to send traffic from one or more sources to one or more receivers across multiple subnets
  • Does not have a topology discovery mechanism or build it's own routing table. PIM relies on the unicast routing table (used for reverse path forwarding)
  • Uses Reverse Path Forwarding to ensure a loop free topology
  • A PIM Designated Router (DR) is used in multi-access network segments (i.e. contains multiple multicast routers in a LAN segment)
    • One DR is elected per segment and the DR is responsible for sending PIM join/prune messages
    • It is also responsible for forwarding multicast traffic from the source into the PIM network
    • If the DR fails, another PIM router on the segment will automatically take over as the new DR
    • The router with the highest priority configured on an interface will be elected as the DR
      • If the priority is the same on multiple routers, then the router with the highest IP address configured on an interface will be elected as the DR
    • Default priority is 1

PIM Sparse vs PIM Dense Mode

Feature/Mode PIM Sparse Mode (PIM-SM) PIM Dense Mode (PIM-DM)
Traffic Distribution Pull Model (receiver requests from source) Push model (stream from source is flooded through network and pruned where no receivers exit)
Sub-categories ASM, SSM, PIM Bidir
Rendezvous Point (RP) Required (ASM, Bidir); Not required (SSM) Not used
Join/Prune Mechanism Explicit Join/Prune Implicit Join, Explicit Prune
State in the Network State maintained only where needed State initially everywhere, pruned as needed
Source Registration PIM Register messages to RP (ASM); Not applicable (SSM, Bidir) Not applicable

PIM-SM Delivery Modes (SSM, ASM, and BiDir)

Feature/Mode PIM SSM PIM ASM PIM Bidir
Traffic Distribution Only from specific sources to interested receivers (S,G) From any source to interested receivers using shared tree (*,G) initially and can switch to SPT (S,G) Always uses a shared tree (*,G) and sends multicast traffic from sources to receivers without switching to SPT
Receiver Distribution Sparse Sparse Sparse
Rendezvous Point (RP) Not required Required Required
Join/Prune Mechanism Explicit Join directed toward specific sources Explicit Join/Prune for shared tree; can switch to direct SPT joins Explicit Join/Prune without switching to SPT
Source Registration Not applicable PIM Register messages sent from first-hop router to RP Not applicable
Multicast Model Source-Specific Multicast (SSM) Any-Source Multicast (ASM) ASM with bidirectional shared tree
Use Case Applications requiring data from known sources, e.g., video streaming General multicast applications where sources are not known in advance e.g., collaborative tools Scenarios with bidirectional traffic patterns, e.g., financial data feeds

Any Source Multicast RP configuration optionsx

  • Static RP
    • Manually configured RPs on all routers within the multicast network
    • Works well in a small environment but might be challenging in a larger fabric
    • Redundancy could be achieved through an anycast RP with MSDP (not covered in this post)
  • AutoRP
    • Cisco proprietary protocol
    • Dynamically discovers and advertises RPs
    • Uses two types of messages: discovery messages from RPs and announcement messages from mapping agents
    • Uses 224.0.1.39 and 224.0.1.40 to announce RP information
    • RPs advertise their availability to mapping agents using 224.0.1.39 (RP-Discovery group)
    • Mapping agents then advertise RP information to the rest of the network using 224.0.1.40 (RP-Announce group)
    • Supports redundancy and load sharing through the use of multiple RPs
    • A prerequisite is that all interfaces within the multicast domain must be configured in sparse-dense mode
  • BSR (Bootstrap Router)
    • Standards based protocol
    • Also dynamically discovers and advertises RPs
    • Uses bootstrap messages to share RP information
    • Doesn't use specific multicast addresses like Auto-RP
    • Relies on the standard PIM messages sent to 224.0.0.13 for operation
    • Best candidates are selected based on priority or the highest IP address
    • Supports redundancy by allowing multiple candidate RPs and a backup BSR

Info

Normally you would think a statically configured resource would take priority over a dynamically learnt resource. This is not the case with ASM RP configuration on Cisco devices. If you configure a static RP but the router receives an AutoRP or BSR update from another multicast router advertising an RP, the dynamically learnt RP will take priority over the static.

Cisco IOS "show" commands

  • show ip route
    • Confirm you have reachability between endpoints (192.168.101.10 and 192.168.102.10 in this example)
    • Confirm you can reach the RP (1.1.1.239 in this example)
  • show ip igmp groups
    • This would be on the devices connected to the receivers
  • show ip pim interface
    • PIM should be configured on all interfaces that send or receive multicast traffic including ones connected to the sources/receivers, and the loopback if you have a static RP configured
  • show ip pim neighbor
    • Confirm the neighbor adjacencies are setup and working
  • show ip pim rp
    • Confirm the group has been mapped to the correct group
  • show ip mroute
    • Confirm the incoming and outgoing interfaces have been populated for the group
    • Confirm a source (S,G) has been added to the mroute table

Setting up your own tests

You can use iperf to test multicast between devices. For this post I used two Ubuntu VMs, one for a client and one for a receiver (it probably also makes sense to have more than one receiver if you're testing multicast). The following commands are run on the VMs:

  • Source: iperf -c 239.1.1.10 -u -T 3 -t 1000 -i 1

    • -c 239.1.1.10: Iperf client mode. 239.1.1.10 is the multicast group
    • -u: Send the multicast stream as UDP instead of TCP (the default)
    • -T 3: Sets the IP Time to Live for outgoing multicast packets to 3. ACI decrements the TTL on ingress and egress leaf switches and therefore if you leave this flag out and use the default TTL of 1 the packets will be dropped.
    • -t 1000: Specify the transmission time in seconds
    • -i 1: Prints to the screen every second

  • Receivers: iperf -s -u -B 239.1.1.10 -i 1

    • -s: This option tells iperf to operate in server mode.
    • -u: Use UDP instead of TCP (the default)
    • -B 239.1.1.10: Bind to the 239.1.1.10 stream
    • -i 1: Prints to the screen every second

Multiple interfaces

If you have multiple interfaces as I do, you may need to add a new route to your VMs which sends the multicast traffic to the correct interface. In my case ens192 is for management traffic and ens224 is for the multicast stream. I create a route on the source and receivers such that all multicast traffic for the 239.1.1.10 subnet will use the ens224 interface.

iperf vs iperf3

It seems like iperf3 does not support multicast traffic.

Example configuration

Note

These configuration examples are using static RPs for simplicity

Three node topology with one source one receiver

Containerlab YAML configuration 
name: intro-to-multicast

topology:
nodes:
    csr-r1:
    kind: cisco_csr1000v
    image: conmurphy/vr-csr:17.03.04
    startup-config: configs/csr-r1
    csr-r2:
    kind: cisco_csr1000v
    image: conmurphy/vr-csr:17.03.04
    env:
        BOOT_DELAY: 30
    startup-config: configs/csr-r2
    csr-r3:
    kind: cisco_csr1000v
    image: conmurphy/vr-csr:17.03.04
    env:
        BOOT_DELAY: 60
    startup-config: configs/csr-r3
    source:
    kind: linux
    image: nicolaka/netshoot
    group: server
    binds:
        - configs/source-interfaces:/etc/network/interfaces
    receiver-1:
    kind: linux
    image: nicolaka/netshoot
    group: server
    binds:
        - configs/receiver-interfaces:/etc/network/interfaces

links:
    - endpoints: ["csr-r1:eth1", "csr-r2:eth1"]
    - endpoints: ["csr-r2:eth2", "csr-r3:eth1"]

    - endpoints: ["csr-r1:eth3", "source:eth1"]
    - endpoints: ["csr-r3:eth3", "receiver-1:eth1"]
  • I've added the following configs to a folder called configs/ in my containerlab directory

CSR 1000v configuration

csr-1 
hostname csr-r1
!
ip multicast-routing distributed
!
!
interface GigabitEthernet2
description Connected to csr-2-eth2
ip address 192.168.201.1 255.255.255.0
ip pim sparse-mode
ip ospf network point-to-point
no shut
!

interface GigabitEthernet4
description Connected to source
ip address 192.168.101.254 255.255.255.0
ip pim sparse-mode
no shut
!
router ospf 1
router-id 1.1.1.1
network 192.168.201.0 0.0.0.255 area 0
network 192.168.101.0 0.0.0.255 area 0
!
ip pim rp-address 1.1.1.239
!
no ip pim autorp
!
end
csr-2 
!
hostname csr-r2
!
ip multicast-routing distributed
!
interface Loopback0
ip address 1.1.1.239 255.255.255.0
ip pim sparse-mode
!
interface GigabitEthernet2
description Connected to csr-1-eth2
ip address 192.168.201.2 255.255.255.0
ip pim sparse-mode
ip ospf network point-to-point
no shut
!
interface GigabitEthernet3
description Connected to csr-3-eth3
ip address 192.168.202.1 255.255.255.0
ip pim sparse-mode
ip ospf network point-to-point
no shut
!
router ospf 1
router-id 1.1.1.2
network 192.168.201.0 0.0.0.255 area 0
network 192.168.202.0 0.0.0.255 area 0
network 1.1.1.239 0.0.0.0 area 0

!
ip pim rp-address 1.1.1.239
!
no ip pim autorp
!
end
csr-3 
hostname csr-r3
!
ip multicast-routing distributed
!
!
interface GigabitEthernet2
description Connected to csr-2-eth2
ip address 192.168.202.2 255.255.255.0
ip pim sparse-mode
ip ospf network point-to-point
no shut
!
interface GigabitEthernet4
description Connected to receiver-1
ip address 192.168.102.254 255.255.255.0
ip pim sparse-mode
no shut
!
router ospf 1
router-id 1.1.1.3
network 192.168.202.0 0.0.0.255 area 0
network 192.168.102.0 0.0.0.255 area 0
!
ip pim rp-address 1.1.1.239
!
no ip pim autorp
!
end
source-interfaces 
auto eth1
iface eth1 inet static
    address 192.168.101.10
    netmask 255.255.255.0
    up ip route add 192.168.102.0/24 via 192.168.101.254
    up ip route add 239.0.0.0/8 dev eth1
receiver-interfaces 
auto eth1
iface eth1 inet static
    address 192.168.102.10
    netmask 255.255.255.0
    up ip route add 192.168.101.0/24 dev eth1
    up ip route add 239.0.0.0/8 dev eth1

Nexus 9000 configuration

n9kv-1 
!Command: show running-config
!Running configuration last done at: Thu Mar 21 09:25:49 2024
!Time: Thu Mar 21 10:08:49 2024

version 9.3(8) Bios:version

feature ospf
feature pim


ip pim rp-address 1.1.1.239

interface Ethernet1/1
no switchport
ip address 192.168.101.254/24
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
ip pim sparse-mode
no shutdown

interface Ethernet1/2
no switchport
ip address 192.168.201.1/24
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
ip pim sparse-mode
no shutdown

router ospf 1
router-id 1.1.1.1
n9kv-2 
!Command: show running-config
!Running configuration last done at: Thu Mar 21 09:25:54 2024
!Time: Thu Mar 21 10:09:26 2024

version 9.3(8) Bios:version

feature ospf
feature pim

ip pim rp-address 1.1.1.239

interface Ethernet1/2
no switchport
ip address 192.168.201.2/24
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
ip pim sparse-mode
no shutdown

interface Ethernet1/3
no switchport
ip address 192.168.202.1/24
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
ip pim sparse-mode
no shutdown

interface loopback0
ip address 1.1.1.239/32
ip router ospf 1 area 0.0.0.0
ip pim sparse-mode

router ospf 1
router-id 1.1.1.2
n9kv-3 
!Command: show running-config
!Running configuration last done at: Thu Mar 21 09:25:56 2024
!Time: Thu Mar 21 10:09:56 2024

version 9.3(8) Bios:version

feature ospf
feature pim

ip pim rp-address 1.1.1.239

interface Ethernet1/1
no switchport
ip address 192.168.102.254/24
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
ip pim sparse-mode
no shutdown

interface Ethernet1/2
no switchport
ip address 192.168.202.2/24
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
ip pim sparse-mode
no shutdown

router ospf 1
router-id 1.1.1.3
Containerlab YAML configuration - Adds the csr-r1 to csr-r3 configuration 
name: intro-to-multicast

topology:
nodes:
    csr-r1:
    kind: cisco_csr1000v
    image: conmurphy/vr-csr:17.03.04
    startup-config: configs/csr-r1
    csr-r2:
    kind: cisco_csr1000v
    image: conmurphy/vr-csr:17.03.04
    env:
        BOOT_DELAY: 30
    startup-config: configs/csr-r2
    csr-r3:
    kind: cisco_csr1000v
    image: conmurphy/vr-csr:17.03.04
    env:
        BOOT_DELAY: 60
    startup-config: configs/csr-r3
    source:
    kind: linux
    image: nicolaka/netshoot
    group: server
    binds:
        - configs/source-interfaces:/etc/network/interfaces
    receiver-1:
    kind: linux
    image: nicolaka/netshoot
    group: server
    binds:
        - configs/receiver-interfaces:/etc/network/interfaces

links:
    - endpoints: ["csr-r1:eth1", "csr-r2:eth1"]
    - endpoints: ["csr-r2:eth2", "csr-r3:eth1"]
    - endpoints: ["csr-r1:eth2", "csr-r3:eth2"]

    - endpoints: ["csr-r1:eth3", "source:eth1"]
    - endpoints: ["csr-r3:eth3", "receiver-1:eth1"]
  • For this example just update the csr-1 and csr-3 gig3 interfaces
csr-1 additional configuration 
!
interface GigabitEthernet3
description Connected to csr-3-gig3
ip address 192.168.203.1 255.255.255.0
ip pim sparse-mode
ip ospf network point-to-point
no shut
!
csr-3 additional configuration 
!
interface GigabitEthernet3
description Connected to csr-1-gig3
ip address 192.168.203.2 255.255.255.0
ip pim sparse-mode
ip ospf network point-to-point
no shut
!

Verify it's working

  • Receiver joins group
  • Router sends PIM join towards RP
  • RP (csr-2) receives the join adds to the mroute table
  • Source starts sending
  • FHR sends PIM register towards RP
  • Receiver starts to receive the stream
  • Receiver sends prune message to stop traffic going through RP and to go direct from FHR to LHR

Resources

Comments