<Course Title>

Multicast Implementation

LY
N
O
SE
U
AL
N
R
TE
IN
Multicast Implementation

LY
N
O
SE
U
AL

Multicast Forwarding
N

When forwarding unicast traffic, the router is primarily concerned with the destination address. The
goal of unicast forwarding is to send the packet in the direction of the destination. A route lookup is
R

performed to find the best route toward the destination, and the packet is sent in that direction.
Multicast forwarding is not initially concerned about the destination address of a multicast packet.
TE

Multicast forwarding bases its decisions primarily on the source address of the incoming packet. The
goals of multicast forwarding are to make sure traffic sent toward the receivers does not loop in the
network and also to avoid packet duplication. To make sure no loops or duplicated packets exist,
multicast routing sends only a single packet down each branch of the distribution tree.
IN

To determine which incoming packets are sent down the distribution tree, multicast forwarding uses
the reverse path forwarding (RPF) check. The RPF mechanism basically selects packets to forward
down the distribution tree only if the packet was received on the interface that is nearest to the
source.
The RPF check looks into the routing table to determine the best route back to the source. The
next-hop interface of that route must be the incoming interface of the multicast packet. If the
interfaces match, the packet passes the RPF check and can be forwarded down the tree. If the
incoming interface does not match the route back to the source, the RPF check fails and the packet
is discarded.

2 www.juniper.net
 Multicast Implementation

LY
N
O
SE
U
AL

Multicast Forwarding Terminology

N

The RPF check mechanism is essential in multicast routing. It is used in both the forwarding plane as
well as in the control plane:
R

• Forwarding plane: A successful RPF check allows traffic from an incoming interface to
be forwarded down the distribution tree. The incoming interface is considered the
TE

upstream interface because the source is upstream. The receivers are downstream on
the tree so the interfaces to which the traffic can be forwarded are called downstream
interfaces. The group of interfaces with downstream receivers is called the outgoing
interface list (OIL).
IN

The result of a successful RPF check is cached in table inet.1.

• Control plane: The RPF check is also used in the control plane. If a router must receive
traffic because of downstream receivers, it signals only to upstream routers on the
interface that would pass the RPF check. Therefore, join and prune messages are only
exchanged with neighboring routers on the upstream interface.
The receipt of an Internet Group Management Protocol (IGMP) or Protocol Independent
Multicast (PIM) join messages moves those interfaces to the OIL, so packets are forwarded to these
interfaces towards the receivers.

www.juniper.net 3
Multicast Implementation

LY
N
O
SE
U
AL

Route Tables for Multicast Routing

N

Multicast forwarding uses multiple route tables related to the RPF check process:
R

• inet.0: The default table used by the RPF check process is the same as the unicast
forwarding table: inet.0. Thus, the unicast topology and multicast topology are
identical.
TE

• inet.1: The results of successful RPF checks for forwarding traffic are cached in a
separate inet.1 table.
• inet.2: If you must have a separate topology for multicast forwarding, you can achieve
this separate topology by changing the table the RPF check uses. Therefore, instead of
IN

looking in the default inet.0 table, the RPF check can be directed to look in inet.2.
The inet.2 table must be filled with routing information to build the alternate topology
used by the RPF check:
– Routing protocols like multiprotocol BGP (M-BGP) and multi-topology IS-IS can
place routes into inet.2 directly; or
– Other protocols must use routing information base (RIB) groups to place routes
into inet.2.
To direct the multicast routing protocols to use inet.2 for the RPF check, RIB groups are required.

4 www.juniper.net
 Multicast Implementation

LY
N
O
SE
U
AL

Sparse Mode Protocol

N

Sparse mode protocols have the following characteristics:

R

• Assume sparse distribution of receivers: Typically, receivers are not distributed across
all network segments; therefore, all network segments will not need all multicast traffic.
Traffic should be sent only to segments that have specifically asked to receive it.
TE

• Uses an explicit join model: In sparse mode, routers must explicitly request their
upstream routers to forward traffic for a specific group, which is done by sending a join
message to the upstream router.
• Complicated source discovery mechanism is required: The main complication with
IN

sparse mode is that receivers might indicate interest in receiving traffic for a specific
group but they do not know who the sources will be. This complication makes it hard for
the designated router (DR) on the receiver segment to signal to the upstream router,
because it does not know the upstream router for an unknown source.
There are two solutions to this problem:
– Use of a rendezvous point (RP) in any-source multicast (ASM). The source will
announce itself when it becomes active. Now the receiver DR can join a shared
tree towards this RP.
– Let the receiver signal the source from which it wants to receive traffic, called
source-specific multicast (SSM). The source discovery now becomes an
application issue because it must inform the receiver which sources to use.

www.juniper.net 5
Multicast Implementation

LY
N
O
SE
U
AL

Sparse Mode Distribution Trees

N

In sparse mode, two types of distribution trees are used:

R

• Shared tree or rendezvous point tree (RPT): If the source and receiver do not know each
other’s identity, they cannot use the source-based tree. The only option is to meet each
other at the RP, where initial traffic can flow between the source and receiver. The path
TE

between the receiver and the RP is called a shared tree because it is shared for
meeting all sources of a multicast group.
The state for shared tree is described as a *,G state. The asterisk (*) indicates any
source, and G indicates the group.
IN

• Source-based tree or shortest path tree (SPT): Once the source is known at the
receiver’s DR, it can now set up a more optimal source-based tree toward the source.
The state for source-based tree is described as an S,G state. S indicates the specific
source, and G indicates the group.

6 www.juniper.net
 Multicast Implementation

LY
N
O
SE
U
AL

PIM Sparse Mode: RP Considerations

N

The RP is essential to the PIM sparse mode functionality, allowing sources and receivers to meet.
Multiple considerations exist with regards to the RP when using PIM sparse mode:
R

• RP placement: RPs should be located in central high-bandwidth areas of the network.

By default, RPs are used only during initial traffic flows; however, proper placement of
TE

RPs ensures the initial receiver and sources can join the multicast network quickly. The
placement of the RP is even more critical if group traffic flows do not switch to the
source-based tree. You can configure groups to remain on the shared tree to minimize
the state that will be created for those groups.
IN

• RP redundancy: Because the source and receiver must meet, they must both use the
same RP. Thus, only one RP can exist for each group, which creates a single point of
failure in the multicast network. Depending on the way the RP information is learned in
the network, different options exist to improve the failover options.
• RP hardware requirements: The source DR and the RP must encapsulate and
de-encapsulate the register messages. This packet manipulation is performed by using
the tunneling services of a Junos OS platform. Depending on the platform in use, this
might require additional hardware.

www.juniper.net 7
Multicast Implementation

LY
N
O
SE
U
AL

PIM Sparse Mode: RP Discovery

N

Routers can learn about the RP information in three ways:

R

• Static RP;
• Auto-RP; and
TE

• Bootstrap router (BSR).

It is possible to use multiple mechanisms to learn about RP at the same time. In case the RP is
learned from multiple mechanisms, the preferred order is BSR over auto-RP over static RP.
In the next section, we discuss the concept of anycast-RP, which allows enhanced RP redundancy
IN

features. Anycast-RP can work with any of the discovery methods listed but typically static RP is used
in combination with anycast-RP.

8 www.juniper.net
 Multicast Implementation

LY
N
O
SE
U
AL

PIM Sparse Mode: Configuration Basics

N

The PIM sparse mode configuration is very dependent on the RP discovery mechanism in use.
R

The RP mechanism determines the mode for which the interfaces must be configured:
• Static RP: Sparse mode;
TE

• Auto-RP: Sparse mode or dense mode; or

• BSR: Sparse mode.
Each RP discovery mechanism also has its own RP-specific configuration items:
IN

• Auto-RP:
– Mapping agent and candidate RP roles; and
– Dense flooding for 224.0.1.39 (announce) and 224.0.1.40 (discovery) groups;
• BSR:
– A bootstrap router and at least one candidate RP must be configured; and
– PIM version 2 must be configured to allow bootstrap and candidate RP messages
to be forwarded.

www.juniper.net 9
Multicast Implementation

LY
N
O
SE
U
AL

PIM Sparse Mode: Tunneling Requirements

N

The register message between the source DR and the RP requires the use of tunneling services on
Junos platforms. If no register message is necessary because the source DR is also the RP, then, of
R

course, no need exists for tunneling services.

Some Junos platforms might need additional hardware to be able to provide tunneling capabilities.
TE

For the latest information regarding your platform and tunneling capabilities, please check the
Juniper website or contact Juniper TAC.
MX Series line cards can be configured to provide tunneling capabilities by enabling the tunneling
services through configuration. Different MX Series line cards have different capabilities, so please
IN

check the Juniper website for your specific platform setup.

The software interfaces needed for source DR or RP functionality can be viewed with the show
interfaces terse | match “pd|pe” command.

10 www.juniper.net
 Multicast Implementation

LY
N
O
SE
U
AL

SPT Cutover Control

N

By default, traffic moves to the source-based tree as soon as the first packet arrives at the receiver
DR (last hop router) and the source is known. Using a policy allows traffic from a source to a group, to
R

stay on the shared tree. The reason for keeping traffic on the shared tree is to limit the additional
state that is created when a source-based tree is established, and to limit any possibility of traffic
TE

loss during the cutover. For some multicast applications, it might not be strictly necessary to use a
shortest path because they are not delay sensitive.

PIM Join Load Balancing

IN

In PIM sparse mode, it is possible to load-balance PIM joins between equal-cost next hops. Without
the set protocols pim join-load-balance command, only one interface is used as the
RPF interface towards a source (or RP). By adding this command, multiple equal-cost next hops can
be used on a per S,G-by-S,G basis.
Suppose a source (172.27.0.30) sends traffic to two groups: 224.1.1.1 and 224.3.3.3. If two
equal-cost paths exist back to the source, one group can be forwarded over Interface A, and the
other group can be forwarded over Interface B. The PIM join messages would be sent to the
upstream router on Interface A for group 224.1.1.1 and to the upstream router on Interface B for
group 224.3.3.3.

www.juniper.net 11
Multicast Implementation

LY
N
O
SE
U
AL

Communicates Information About Active Sources

N

Multicast Source Discovery Protocol (MSDP) shares multicast source information between RPs so
that sources and receivers can meet, even if they have associated with different RPs:
R

• Interdomain RPs: Enables multicast deployments between different service providers;

and
TE

• Intradomain RPs: Improves RP redundancy through anycast-RP feature.

Typically Runs on RP Routers

IN

MSDP is typically configured on RPs, although it is possible to configure MSDP on non-RP routers as
well. In the interdomain multicast setup, domains might exist that never have any sources but still
need MSDP to enable transit multicast traffic across their domain.
Once a remote source for a group is learned on an RP, the RP establishes a source tree back to the
source, assuming the RP has knowledge of the receivers for that group. When the source tree
between the source and the RP is established, traffic starts flowing toward the receiver.

MSDP Peering Uses TCP

The MSDP protocol is similar to BGP peering in that it uses TCP session between peers. The
configuration of MSDP peering sessions is also similar in that the peers must be manually
configured. Once the sessions are established, the source-active (SA) messages can be sent to any
MSDP peer.

12 www.juniper.net
 Multicast Implementation

LY
N
O
SE
U
AL

MSDP Peer State

N

Once the MSDP peers are manually configured, the peer router with the highest IP address remains
passive and listens only to connection attempts from the active peer on TCP port 639.
R

MSDP peers can go through different connection states. The active peer (lowest IP address) will
normally go into a connect state. In this state, the active peer is trying to set up the peering session
TE

by initiating a TCP three-way handshake. Once the TCP connection is established, the session state
becomes established.

SA Messages
IN

The SA message is sent by an RP with MSDP, when the RP becomes aware of a source through the
incoming register message. The SA message is sent to all the RP’s MSDP peers. The SA message is
sent every 60 seconds until the source stops sending multicast traffic.
The receiving MSDP peers store this information in their SA cache, if the message passes the
RPF-peer check. In the Junos operating system, this SA cache is stored in the inet.4 table. To clear
the MSDP cache information, use the clear msdp cache command.
Any SA message that passes the RPF-peer check is sent to all MSDP peers except the peer where the
SA was received.

www.juniper.net 13
Multicast Implementation

LY
N
O
SE
U
AL

MSDP SA Flooding
N

MSDP floods SA messages normally to all its peers except the peer from which it received the
message. Thus, peers can receive the same SA message from more than one peer. To prevent
R

unnecessary flooding or looping of these messages, MSDP uses a peer-RPF check.

TE

Peer-RPF Check
When an SA message is received, MSDP performs a peer-RPF check, and only messages that pass
this check can be used (cached locally and forwarded to other peers). The peer-RPF checks to
determine whether the sending peer is on the path towards the originating RP. The concept is similar
IN

to the general multicast RPF check in which traffic is forwarded only away from the source; with
MSDP, SA messages are forwarded only away from the originating RP.
Next, we look at multiple peer-RPF rules.

14 www.juniper.net
 Multicast Implementation

LY
N
O
SE
U
AL

MSDP Peer-RPF Rules

N

The peer-RPF rules are used in the order presented, and the first match determines the success:
R

• If the advertising MSDP peer is the actual originating RP, then SA message is accepted.
• If the advertising MSDP peer is not the actual originating RP, but:
TE

– The advertising MSDP peer is the BGP next hop for the originating RP address,
then the SA message is accepted.
– The advertising MSDP peer is the advertising router for the route towards the
originating RP, the SA message is accepted.
IN

– The advertising MSDP peer belongs to the last AS listed in the BGP route path
towards the originating RP; then the SA message is accepted. If multiple peers
exist from that last AS, SA messages from only the one with the highest IP
address will be accepted.

Peer-RPF Rules Are Not Used

The two exceptions for when the peer-RPF check is not performed, and the SA will be accepted:
• SA messages received from an MSDP peer configured in a mesh group.
• SA messages received from the configured default MSDP peer. For domains that only
have a single MSDP peer, it is essential that all of the received SA messages are
accepted.

www.juniper.net 15
Multicast Implementation

LY
N
O
SE
U
AL

Single RP for Each Multicast Group

N

The concept of an RP in PIM sparse mode is that there can be only one RP per multicast group in the
network. This requirement ensures that source and receiver always use the same RP so that they
R

can connect through it. A single RP per multicast group creates a single point of failure, which is
something to avoid in correctly designed networks. A single RP also limits the options for load
TE

balancing in case of high volume groups.

Anycast-RP Enables Multiple RPs for Each Multicast Group

To allow load balancing within a group and to increase network resiliency, anycast-RP was developed.
IN

The concept of anycast, in general, is to have multiple devices performing the exact same role in the
network, and with the exact same unicast address (anycast address). The clients connect to the
nearest device with the required anycast address. If the nearest device fails, the clients can connect
to other devices that have the same anycast address. As soon as the interior gateway protocol (IGP)
converged, the clients can connect to the (new) nearest anycast device.
Anycast-RP allows for multiple RPs in the network to share a unicast address that every router
associates with the RP. Each router communicates with the nearest RP about source or receiver
information. Of course, this creates a similar problem to the interdomain multicast setup: a source
connects to RP-A and the receiver to RP-B. To let the source and receiver connect across different
RPs, MSDP was originally used.
The main advantage of anycast-RP is that you can have redundant RPs per group, and the
convergence time is much lower in the case of failures.

16 www.juniper.net
 Multicast Implementation

LY
N
O
SE
U
AL

Source and Receiver on Different RPs

N

The anycast-RP features allows load sharing within a group, which can be useful for bigger
deployments.
R

To let the source and receiver connect to each other, there must be a way for the RPs to exchange
information about sources, the receivers, or both. As seen previously, MSDP can exchange source
TE

information between RPs and thus can be used for intradomain multicast designs. The
disadvantages of MSDP are that it only supports IP version 4 (IPv4) and that it requires additional
protocol configuration.
Another more recent option is to use PIM anycast for the exchange of source information. Therefore,
IN

no MSDP is needed for anycast-RP to function. This solution is useful if you must support IP version
6 (IPv6) or if MSDP is not needed in a IPv4 environment (no interdomain multicast).

www.juniper.net 17
Multicast Implementation

LY
N
O
SE
U
AL

Unique Host Address

N

Each RP needs its own unique IP address so that its other protocols function correctly (IGP/BGP). To
ensure that the unique address is used as the primary address on the loopback interface, the
R

primary option can be added to the address. Another method of ensuring that no duplicate router
IDs are created in the network is to hard-code the router ID on each router to the unique address
TE

using the set routing-options router-id command.

Anycast Address
On each of the RPs, a secondary IP address is used by all RPs to signal the RP role.
IN

Anycast-RP and RP Discovery

All routers must learn what the RP address is in the network. When using anycast-RP, all discovery
mechanisms are possible—static, auto-RP, and BSR—but typically, static RP is used. Static RP is
simple, and, with the addition of anycast-RP, is now also redundant.

18 www.juniper.net
 Multicast Implementation

LY
N
O
SE
U
AL

Sample Task and Topology

N

This slide displays the sample task and topology. We analyze this task in next set of slides.
R
TE
IN

www.juniper.net 19
Multicast Implementation

LY
N
O
SE
U
AL

Deciphering What Is Really Being Asked

N

By examining the sample task and topology, you can determine what the sample task is asking. The
items on the slide list what is required to complete the sample task.
R
TE
IN

20 www.juniper.net
 Multicast Implementation

LY
N
O
SE
U
AL

Configure PIM Sparse Mode

N

The slide displays the configuration for the non-RP routers. PIM sparse mode does not need to be
specifically configured because it is the default PIM mode.
R
TE
IN

www.juniper.net 21
Multicast Implementation

LY
N
O
SE
U
AL

RP Configuration
N

The slide displays the necessary configuration for PIM anycast-RP on R3. Similar configuration is
also needed on R1 (with the correct IP addresses) to complete this part of the task. Make sure to
R

configure the same secondary lo0 address on both R1 and R3, and to configure the unique lo0
address as primary (best practice to ensure it is used as the router ID). You will notice that the
TE

non-unique lo0 address is used as the local RP address, and the unique lo0 address is used for the
anycast configuration.
IN

22 www.juniper.net
 Multicast Implementation

LY
N
O
SE
U
AL

Policy Creation
N

The slide displays the required policy to keep group 224.1.1.1 from cutting over to the SPT. The policy
is then applied under PIM as a SPT threshold on the last hop router, R2. The SPT cutover threshold of
R

infinity applied to a source-group address pair means the last hop routing device never transitions to
a direct SPT.
TE
IN

www.juniper.net 23
Multicast Implementation

LY
N
O
SE
U
AL

Verify PIM Neighborship

N

The slide displays the expected PIM neighbors on R3 and R4. You should verify that each router has
the correct PIM neighbors.
R
TE
IN

24 www.juniper.net
 Multicast Implementation

LY
N
O
SE
U
AL

Verify PIM Anycast RP

N

The slide displays the status of the RPs. From this output you can determine that R3 is the other RP
(PIM rpset), that the group range is all multicast groups, and that R1 is learning about the group
R

224.1.1.1 from R3.

The status of the RPs on R3:
TE

lab@R3> show pim rps extensive

...
RP: 172.27.255.11
Learned via: static configuration
IN

...
Interface: ppd0.32769
Group Ranges:
224.0.0.0/4
Anycast PIM rpset:
172.27.255.1
Anycast PIM local address used: 172.27.255.3
Anycast PIM Register State:
Group Source Origin
224.1.1.1 172.27.0.38 DIRECT

www.juniper.net 25
Multicast Implementation

LY
N
O
SE
U
AL

Verify That the Policy Is Not Allowing the SPT Cutover

N

The slide displays that *,G (RPT) should be seen only for group 224.1.1.1 from the last hop router
(R2), upstream to the RP (R1).
R
TE
IN

26 www.juniper.net
 Multicast Implementation

LY
N
O
SE
U
AL

Multicast Traffic Is Flowing

N

The slide displays that the multicast traffic for group 224.1.1.1 is flowing towards Rec2.
R
TE
IN

www.juniper.net 27