Multicast Overview
IP has three fundamental types of addresses: unicast, broadcast, and multicast. A unicast address is used to send a packet to a single destination. A broadcast address is used to send a packet to an entire local subnet. A multicast address is used to send a datagram to a set of hosts that can be on different subnets and that are configured as members of a multicast group.
Individual hosts can join or leave a multicast group at any time. There are no restrictions on the physical location or the number of members in a multicast group. A host can be a member of more than one multicast group at any time. A host does not have to belong to a group to send packets to members of a group.
Routers use a group membership protocol (IGMP) to learn about the presence of group members on directly attached networks. When a host joins a multicast group, it transmits a group membership protocol message for the group or groups that it wants to receive and sets its IP process and network interface card to receive frames addressed to the multicast group.
The routers in the IP multicast network, which has exactly the same topology as the unicast network it is based on, use a multicast routing protocol to build a distribution tree that connects receivers to sources.
In multicast terminology, the distribution tree is rooted at the source (the root of the distribution tree is the source). The interface on the routing device leading toward the source is the upstream interface.
To keep bandwidth use to a minimum, it is best for only one upstream interface on the routing device to receive multicast packets. The interface on the routing device leading toward the receivers is the downstream interface. There can be 0 to N–1 downstream interfaces on a router, where N is the number of logical interfaces on the routing device.
To prevent looping, the upstream interface must never receive copies of downstream multicast packets.
RPF Loop Prevention
In RPF, every multicast packet received must pass an RPF check before it can be replicated or forwarded on any interface. When it receives a multicast packet on an interface, the routing device verifies that the source address in the multicast IP packet is the destination address for a unicast IP packet back to the source.
If the outgoing interface found in the unicast routing table is the same interface that the multicast packet was received on, the packet passes the RPF check. Multicast packets that fail the RPF check are dropped, because the incoming interface is not on the shortest path back to the source.
PIM Dense Mode
In this mode of PIM, the assumption is that almost all possible subnets have at least one receiver wanting to receive the multicast traffic from a source, so the network is flooded with traffic on all possible branches, then pruned back when branches do not express an interest in receiving the packets.
PIM dense mode allows a router to use any unicast routing protocol and performs RPF checks using the unicast routing table. PIM dense mode has an implicit join message, so routers use the flood-and-prune method to deliver traffic everywhere and then determine where the uninterested receivers are.
PIM dense mode uses source-based distribution trees in the form (S,G)
PIM Dense mode in a nutshell
- PIM dense mode implements flood-and-prune mechanism.
- Flooding occurs periodically. It is used to refresh state information, such as the source IP address and multicast group pair (S , G)
- If the routing device has no interested receivers for the data, and the OIL (Outgoing Interface List) becomes empty, the routing device sends a prune message upstream to stop delivery of multicast traffic
- PIM dense mode uses the routing table populated by any underlying unicast routing protocol to perform reverse-path-forwarding (RPF) checks.
- PIM Dense Mode builds the Shortest Path Tree (SPT) from the source to the receiver.
Diagram
Configuration
Step -1 Configure interfaces and OSPF
set system host-name vMX1
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.5/30
set interfaces ge-0/0/1 unit 0 family inet address 192.168.1.1/30
set interfaces ge-0/0/2 unit 0 family inet address 10.1.1.1/24
set routing-options router-id 1.1.1.1
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set system host-name vMX2
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.6/30
set interfaces ge-0/0/1 unit 0 family inet address 192.168.1.9/30
set interfaces ge-0/0/2 unit 0 family inet address 10.1.2.1/24
set routing-options router-id 2.2.2.2
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set system host-name vMX3
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.13/30
set interfaces ge-0/0/1 unit 0 family inet address 192.168.1.2/30
set interfaces ge-0/0/2 unit 0 family inet address 10.1.3.1/24
set routing-options router-id 3.3.3.3
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set system host-name vMX4
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.14/30
set interfaces ge-0/0/1 unit 0 family inet address 192.168.1.10/30
set interfaces ge-0/0/2 unit 0 family inet address 10.1.4.1/24
set routing-options router-id 4.4.4.4
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0Step -2 Enable PIM on the interfaces
vMX1 vMX2 vMX3 vMX4
set protocols pim interface ge-0/0/0 mode dense
set protocols pim interface ge-0/0/1 mode dense
set protocols pim interface ge-0/0/2 mode denseEnabling PIM would aslo enable IGMPv2 on that interface. IGMP is required between the router and the receiver.
Let's verify on vMX2, we should be able to see two PIM neighbors. (vMX1 & vMX4)
root@vMX2> show pim neighbors
B = Bidirectional Capable, G = Generation Identifier
H = Hello Option Holdtime, L = Hello Option LAN Prune Delay,
P = Hello Option DR Priority, T = Tracking Bit,
A = Hello Option Join Attribute
Instance: PIM.master
Interface IP V Mode Option Uptime Neighbor addr
ge-0/0/0.0 4 2 HPLGA 00:17:46 192.168.1.5
ge-0/0/1.0 4 2 HPLGA 00:08:13 192.168.1.10 Verification
Let's send some multicast traffic from the source connected to vMX1. Since we are running PIM Dense, the traffic should be flooded into the network and arrives at vMX4. I have disabled interface ge-0/0/1 on vMX4 so, we know for sure the only path to reach the source is vMX4 > vMX3 > vMX1
SOURCE#ping 239.10.10.100 repeat 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 239.10.10.100, timeout is 2 seconds:
...We can use show multicast route and show pim join commands for verification
root@vMX4> show multicast route extensive
Instance: master Family: INET
Group: 239.10.10.100
Source: 10.1.1.10/32
Upstream interface: ge-0/0/0.0
Number of outgoing interfaces: 0 <<<<<<<<<<<<
Session description: Organisational Local Scope
Statistics: 0 kBps, 0 pps, 2 packets
Next-hop ID: 0
Upstream protocol: PIM
Route state: Active
Forwarding state: Pruned <<<<<<<<<<<<
Cache lifetime/timeout: 341 seconds
Wrong incoming interface notifications: 0
Uptime: 00:00:22- Group - Multicast group address of 239.10.10.100
- Upstream interface - The interface we would use to reach the source
- Number of OI - Since we don't have any listeners, the number is zero
- Forwarding state - Since we don't have any listeners, the state is set to
Pruned
root@vMX4> show pim join extensive
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Group: 239.10.10.100
Source: 10.1.1.10
Flags: dense
Upstream interface: ge-0/0/0.0
Upstream neighbor: 192.168.1.13
Prune Sent Upstream: ge-0/0/0.0 timeout 271
Uptime: 00:00:28
Downstream interfaces:
Number of downstream interfaces: 0 <<<<<<<<<<<<<<
Instance: PIM.master Family: INET6
R = Rendezvous Point Tree, S = Sparse, W = Wildcard- Group - Multicast group address
- Source - IP address of the source
- Upstream interface - The interface we would use to reach the source
- Upstream Neighbor - IP address of the PIM neighbor
We can also see that the Prune message is sent to the PIM neighbor because we don't have any listeners.
224.0.0.13 is the PIM Neighbor Discovery multicast address
Let's configure a listener and check the output again.
Note - I'm just simulating Cisco routers on both side as source and listener.
LISTENER(config)#interface gi0/0
LISTENER(config-if)#ip igmp join-group 239.10.10.100
SOURCE#ping 239.10.10.100 repeat 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 239.10.10.100, timeout is 2 seconds:
.
Reply to request 1 from 10.1.4.10, 1189 ms
Reply to request 2 from 10.1.4.10, 8 msvMX4 will not send a prune for the group now because now we have a listener.
root@vMX4> show multicast route extensive
Instance: master Family: INET
Group: 239.10.10.100
Source: 10.1.1.10/32
Upstream interface: ge-0/0/0.0
Downstream interface list: <<<<<<<<<<<<
ge-0/0/2.0
Number of outgoing interfaces: 1
Session description: Organisational Local Scope
Statistics: 0 kBps, 0 pps, 2 packets
Next-hop ID: 1048575
Upstream protocol: PIM
Route state: Active
Forwarding state: Forwarding <<<<<<<<<<<<<
Cache lifetime/timeout: 360 seconds
Wrong incoming interface notifications: 0
Uptime: 00:00:06
root@vMX4> show pim join extensive
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Group: 239.10.10.100
Source: 10.1.1.10
Flags: dense
Upstream interface: ge-0/0/0.0
Upstream neighbor: 192.168.1.13
Uptime: 00:00:12
Downstream interfaces: <<<<<<<<<<<<<<
ge-0/0/2.0
Number of downstream interfaces: 1
R = Rendezvous Point Tree, S = Sparse, W = WildcardAs you can see above, now we have Downstream interface list and the Forwarding state is active
RPF check
You can also use show multicast rpf x.x.x.x to check the outgoing interface towards the source. Let's re-enable the ge-0/0/1 interface on vMX4.
Now, from the IGP point of view we have two paths to reach the source. One via vMX2 and the other one via vMX3. However, multicast route table chooses the path via vMX2 as you can see below.
root@vMX4# delete interfaces ge-0/0/1 disable
root@vMX4> show multicast rpf 10.1.1.10
Multicast RPF table: inet.0 , 15 entries
10.1.1.0/24
Protocol: OSPF
Interface: ge-0/0/1.0
Neighbor: 192.168.1.9
The traffic should now flow via vMX4 > vMX2 > vMX1. The multicast traffic from 10.1.1.10 arrives on vMX4 ge-0/0/0 interface will be dropped as per PRF checks.
Reference
https://www.juniper.net/documentation/en_US/junos/topics/concept/multicast-ip-overview.html
Thanks for reading
As always, your feedback and comments are more than welcome.
