<Course Title>

Introduction to Multicast

LY
N
O
SE
U
AL
N
R
TE
IN
Introduction to Multicast

LY
N
O
SE
U
AL

Address Types
N

In IP networking three types of addressing are typically used for the communication between hosts:
R

• Unicast addressing: Unicast addresses are used when a host wants to send traffic to
another specific host. Each host requires its own unique IP address for this type of
traffic.
TE

• Broadcast addressing: Broadcast addresses are used when a host wants to send traffic
to all hosts on a given subnet. Each subnet has its own broadcast IP address. Traffic to
the broadcast address is typically not forwarded by the router. Some types of broadcast
traffic (for example, DHCP) might need to be forwarded to other parts of the network.
IN

• Multicast addressing: Multicast addresses are used when a host wants to communicate
with a group of hosts that are interested in that specific traffic. Different types of
multicast applications exist, such as where one host sends traffic to many interested
receivers (one to many), and other applications that send traffic between all the
interested hosts (many to many).
Continued on next page.

2 www.juniper.net
 Introduction to Multicast
Address Types (contd.)
A more recent type of addressing that is used in IP networking is the Anycast address. The concept of
Anycast addressing is that a group of receivers all share the same address. When traffic must be
delivered to the Anycast address, it is delivered to the nearest member of the group. An example of
where Anycast addressing is used is Domain Name System (DNS) Anycast. In multicast it is also used
in a feature called Anycast RP. An advantage of Anycast addressing is that it provides a very fast
convergence in case one of the members of the group disappears.

LY
N
O
SE
U
AL
N
R
TE
IN

www.juniper.net 3
Introduction to Multicast

LY
N
O
SE
U
AL

Advantages of Multicast
N

The use of multicast applications has multiple benefits when compared to the more commonly used
unicast applications. Unicast applications must send duplicate traffic streams to communicate with
R

multiple hosts. This duplication results in inefficient use of resources on the source host as well as
on the network. Multicast applications are much more efficient for the source host because the host
TE

must send traffic only once. From a network resource point of view, multicast applications are also
more efficient because only a single stream is forwarded throughout parts of the network. The
network typically replicates the multicast traffic only at routers closest to the receivers.
Another important advantage of multicast applications is the ability to communicate with interested
IN

hosts of which the source is unaware. The network uses different multicast protocols to deliver the
traffic from the source to the receiver without the source needing to know the receivers.
Continued on next page.

4 www.juniper.net
 Introduction to Multicast
Disadvantages of Multicast
The main disadvantage of multicast applications is that they primarily use User Datagram Protocol
(UDP) based traffic. In other words, multicast traffic streams use an unreliable best-effort delivery
mechanism, compared to unicast applications that mainly use TCP as a reliable transport delivery
system.
A multicast application also makes implementing class of service (CoS) harder in the network,
because the traffic is typically sensitive to jitter and delay. Some CoS tools do not work well with UDP
traffic, such as weighted random early detection (WRED).
Multicast applications also add complexity to the network, because multicast protocols must
deployed in the network. The use of multicast in the network is a trade-off between the more
efficient use of forwarding plane resources (bandwidth) and the increased use of control plane
resources to keep track of the multicast forwarding state information.

LY
N
O
SE
U
AL
N
R
TE
IN

www.juniper.net 5
Introduction to Multicast

LY
N
O
SE
U
AL

Multicast Components: Part 1

N

The slide describes some of the common terms used in multicast:

R

• Source: A multicast source is any device that originates multicast IP packets.

• Multicast IP packet: A multicast packet is any IP packet that is destined to a multicast
TE

group address. The same packet should have a unicast source address. Generally, a
multicast packet uses UDP, the Real-Time Transport Protocol (RTP), or both as its
transport protocols. No guarantees exist that packets will be received by all members of
a group. One protocol, the Pragmatic General Multicast (PGM) protocol, has been
developed to add loss detection and retransmission capabilities to multicast.
IN

• Group address: A multicast group address is an IP address in the range of 224/4.

• Receivers: A multicast receiver is any host that is interested in receiving multicast
packets. A receiver uses IGMP to inform the directly connected router of its desire to
receive multicast packets.
• Designated router (DR): The DR is the router closest to the source that forwards
multicast packets into the network. If two or more routers are attached to the source,
only one ever becomes the DR based on an election algorithm that depends on the
multicast routing protocol in use.

6 www.juniper.net
 Introduction to Multicast

LY
N
O
SE
U
AL

Multicast Components: Part 2

N

The following list continues the list of the common terms used in multicast from the previous page:
R

• Group membership protocol: Receivers use a group membership protocol to inform the
directly connected router of their interest in receiving packets for one or more multicast
group addresses. That is, the host is informing the router of its desire to become a
TE

member of a multicast group. IGMP is used by IP version 4 (IPv4) hosts and routers for
this purpose. Thismaterial focuses on IPv4 multicast.
• Multicast routing protocol: A multicast routing protocol is used between routers to build
and maintain the multicast forwarding trees between source and receiver. The following
IN

slides describe the basic functionality of a multicast routing protocol. The two most
common multicast routing protocols are Protocol Independent Multicast (PIM) and the
Distance Vector Multicast Routing Protocol (DVMRP).

www.juniper.net 7
Introduction to Multicast

LY
N
O
SE
U
AL

Service Models
N

We use the following terminology for multicast service models:

R

• Any-source multicast (ASM): This delivery model was designed into the original
specifications for multicast in RFC 1112. The model supports both one-to-many
applications like Internet Protocol Television (IPTV), as well as many-to-many
TE

applications like whiteboarding or videoconferencing.

ASM gets its name from receivers being able to join a group without specifying from
which source they want to receive traffic, so they accept it from any source.
IN

• Source-specific multicast (SSM): In SSM, the receiver specifies the sources from which
it wants to receive the traffic. It can also specify from which sources it does not want to
receive traffic. So for SSM to work, the source information must be known.
SSM makes deployment of multicast less complex and also makes allocating multicast
addresses easier.
Continued on next page.

8 www.juniper.net
 Introduction to Multicast
Distribution Modes
We use the following terminology for multicast distrubution modes:
• Dense mode: In dense mode, traffic is forwarded to all parts of the network (which is
known as flooding). The parts of the network that are not interested in receiving the
traffic send prune messages to their neighboring routers asking them to stop
forwarding traffic. In case a receiver subscribes after sending the prune, the router
sends a graft message asking for the traffic to be forwarded again.
• Sparse mode: In sparse mode, traffic is forwarded only into parts of the network with
interested receivers. The routers send join messages to indicate their willingness to
receive traffic. If a receiver is no longer interested, the router sends prune messages to
the neighbor asking it to stop forwarding the traffic.

LY
N
O
SE
U
AL
N
R
TE
IN

www.juniper.net 9
Introduction to Multicast

LY
N
O
SE
U
AL

Distribution Trees
N

We use the following terminology for multicast distribution trees:

R

• Source tree or shortest-path tree (SPT): A source tree is the forwarding path for the
traffic from a specific source all the way up to the router that is closest to the receiver. A
source tree is the shortest path between source and receiver and can only be used
TE

when the router next to the receiver knows about the source. The routers keep the
forwarding path from the receiver to the source in the following state: S, G (S comma G).
S indicates source address and G indicates group address. In dense mode a source tree
is always used. In sparse mode a source tree is used after the receiver router learns
IN

about the source.

• Shared tree or rendezvous point tree: If the source is not known, a source tree cannot
yet be built. In the ASM model, the receivers subscribe to a group address using IGMP.
In the subscription request they do not indicate the source. The routers must build a
tree toward an unknown source. The solution to this problem is to have a meeting point
for sources and receivers in the network. This meeting point is called a rendezvous
point (RP). The tree built from the receiver to the RP in the network is called a shared
tree (because it is shared by all sources). The routers keep the forwarding path from the
receiver router to the RP in the following state: *,G (* comma G). The * indicates any
source and the G indicates the group address.
Continued on next page.

10 www.juniper.net
 Introduction to Multicast
Multicast Forwarding
In multicast forwarding, the path between source and receiver is called a tree. The source is the root
of the tree. The tree branches out into the network, and at the end of the branches are the receivers
(or leaves). The source is considered upstream and the receivers are downstream. Branches of the
tree are created when receivers join, and are torn down when receivers leave.
In the case of a shared tree, the RP is considered upstream and the root of the tree.

LY
N
O
SE
U
AL
N
R
TE
IN

www.juniper.net 11
Introduction to Multicast

LY
N
O
SE
U
AL

Source Tree
N

The source tree or shortest-path tree builds the forwarding path from source directly toward the
receiver. The forwarding state kept in the routers between source and receiver uses the S,G notation.
R

In dense mode the shortest tree is always used between the source and any router in the network
during the flooding process. Any part of the network that does not have receivers prunes the
TE

distribution tree. The result is a source tree with branches to the parts of the network that actually
have receivers.
To join a shortest-path tree in sparse mode, S,G join messages are exchanged. In case a receiver is
no longer interested in receiving traffic from the source, S,G prune messages are sent by the router
IN

closest to the receiver.

Continued on next page.

12 www.juniper.net
 Introduction to Multicast
Multicast Rendezvous-Point Tree Shared Tree
The shared tree is used if the source address is not known. In that case the only option is to enable
the forwarding state up to the RP. The forwarding state toward the rendezvous point uses the *,G
notation.
Once the source starts sending traffic, the router closest to the source sends the traffic to the RP,
and from there it can be sent to the receiver. All routers in the network must agree on which router is
the RP, so source and receivers can be connected in the network.
The advantage of using a shared tree is that they typically generate less state information in the
network, because it is not necessary to create a unique source tree for each session in the network.
The disadvantage is that the path between source and receiver across a shared tree is often not
optimal. This issue is especially important for delay-sensitive traffic.

LY
N
O
SE
U
AL
N
R
TE
IN

www.juniper.net 13
Introduction to Multicast

LY
N
O
SE
U
AL

Multicast Routing
N

For multicast routing to work, the whole network between source and receiver must be multicast
enabled. This enablement is typically easily accomplished in your own network by deploying your
R

choice of multicast protocols like IGMP, and PIM.

On the Internet, where multiple administrative domains connect across multiple service providers,
TE

the network is often not end-to-end enabled for multicast applications, which limits the usage of
multicast applications across the Internet.
IN

14 www.juniper.net
 Introduction to Multicast
Automatic Multicast Tunneling
One mechanism to make the deployment of multicast applications easier across the Internet is
called Automatic Multicast Tunneling (AMT). It allows multicast traffic across islands of unicast-only
connectivity by automating tunnel setup to transport multicast traffic. Such connectivity enables
service providers, content providers, and their customers to participate in delivering multicast traffic,
even if they lack end-to-end multicast connectivity.
AMT allows any host to receive multicast. On the client end is an AMT gateway that is a single host.
Once the gateway has located an AMT relay, which might be a host but is more typically a router, it
periodically sends IGMP messages over a dynamically created UDP tunnel to the relay. AMT relays
and gateways cooperate to transmit multicast traffic sourced within the multicast network to
end-user sites. AMT relays receive the traffic natively and unicast-encapsulate it to gateways, which
allows anyone on the Internet to create a dynamic tunnel to download multicast data streams.

LY
Consult the latest technical documentation to determine whether AMT is supported on your specific
hardware platform and deployed software version.

N
O
SE
U
AL
N
R
TE
IN

www.juniper.net 15
Introduction to Multicast

LY
N
O
SE
U
AL

IP Multicast Addressing
N

The class D range of IP addresses is reserved for the use of multicast addresses. The range is
224.0.0.0 up to 239.255.255.255 (224/4). The addresses from that range should be used only as
R

destination addresses; they should never be used as the source of any packet.
The Internet Assigned Numbers Authority (IANA) maintains a list of registered IP multicast groups.
TE

The base address 224.0.0.0 is reserved and cannot be assigned to any group.
The block of multicast addresses from 224.0.0.1 through 224.0.0.255 is reserved for local wire use.
These addresses are used by applications that must communicate on the local network. The traffic
in this range should never be forwarded to any other part of the network. Typically the time-to-live
IN

(TTL) value is set to 1 to accomplish this. Examples are routing protocols like OSPF, RIP, and
multicast routing protocols like PIM and DVMRP.
The 234.0.0.0/8 address range allocation is described in RFC 6034. Each organization with a public
unicast address range is provided with a global multicast address space. This assignment of space
solves some of the limitations of GLOP, because it only provides for 2-byte AS numbers. If an
organization is assigned the 192.0.2.0/24 unicast address space, the global multicast address
234.192.0.2/32 is available for the organization’s exclusive use. If a larger address space is
available, multiple global addresses are available for the organization’s use.
Continued on next page.

16 www.juniper.net
 Introduction to Multicast
Address Allocation
In RFC 5771 the allocation of multicast addresses is described in detail. Because a limited amount
of addresses exist, you must choose carefully what address to use for your multicast deployments.
When allocating multicast addresses, the goal is to prevent usage of the same addresses by multiple
applications inside the same network. The reason for this is that it might result in additional
multicast flows in the network and thereby might waste precious bandwidth.
For ASM multicast applications, multicast address allocation is more of an issue because ASM
multicast applications allow traffic from any source, so the multicast address itself should be unique
for each application. To select unique addresses for ASM applications, the administratively scoped
address, GLOP, and Session Announcement Protocol (SAP)/Session Description Protocol (SDP)
address ranges were developed.
For SSM multicast applications, the combination of source address and multicast address

LY
determines its uniqueness, which means that the same multicast address can be reused by SSM
applications as long as the source address is different. The 232/8 range is exclusively available for
SSM applications.

N
O
SE
U
AL
N
R
TE
IN

www.juniper.net 17
Introduction to Multicast

LY
N
O
SE
U
AL

Reserved Ranges
N

The following address ranges are reserved:

R

• Scoped range: The range 239.0.0.0/8 through 239.255.255.255/8 is reserved for

administratively scoped addresses. The idea of administrative scoping is to limit the use
of multicast traffic to specific parts of the network. This limiting the use of multicast
TE

traffic to specific parts of the network allows addresses to be reused in those parts
because traffic from other parts using the same addressing will be blocked by the
administrators. In the Junos OS you have two ways of scoping: named scopes and
scoping policies.
IN

• GLOP addressing: The range of 233.0.0.0/8 is a statically assigned range of multicast

addresses based on a networks autonomous system (AS) number. For each AS, 255
unique multicast addresses are available for that AS’ global use.
GLOP is not an acronym but it describes a way to use your 16-bit AS number as basis for
the multicast addresses you can use. The address range that can be used can be
calculated as follows: 233. [first byte of AS]. [second byte of AS].0/24. The 16-bit AS
number must be converted to hexadecimal to accomplish this. For example if you had
AS 15000, the GLOP address range would be 233.3A.98/24. When converted back into
decimal format, it is 233.58.152/24. The new 32-bit AS numbers cannot use the GLOP
range.
Continued on next page.

18 www.juniper.net
 Introduction to Multicast
Reserved Ranges (contd.)
• Source Specific Multicast (SSM) addressing: The range of 232.0.0.0/8 is dedicated for
use with SSM.
• SDP)/SAP addressing: The range of 224.2.0.0/16 is used to send and receive
multimedia session announcements. The Session Directory tool (SDR) is a common
application that uses SDP/SAP.
The SAP/SDP applications try to find unused addresses in the range allocated for them,
which works reasonably well in small networks, but it does not scale very well. We
recommend not using SAP/SDP on the Internet because it is also vulnerable to denial of
service (DoS) attacks.

LY
N
O
SE
U
AL
N
R
TE
IN

www.juniper.net 19
Introduction to Multicast

LY
N
O
SE
U
AL

Multicast MAC Addresses

N

On Ethernet segments, an additional step is required for a host to receive multicast traffic. In unicast
delivery on Ethernet segments, traffic is sent to the unique MAC address of each host. The router
R

learns about its MAC address by using the Address Resolution Protocol (ARP).
For multicast traffic, the delivery mechanism is different. The IP multicast address must be mapped
TE

to a specific MAC address that is programmed into the network interface card (NIC) of each receiver
that wants to receive this traffic. Unfortunately, fewer MAC addresses are available for multicast
usage than there are IP multicast addresses. Only 23 bits of MAC address space is available for
mapping 28 bits of unique IP multicast address space, which results in a 32:1 ratio of IP multicast
IN

addresses to multicast MAC addresses.

20 www.juniper.net
 Introduction to Multicast

LY
N
O
SE
U
AL

IP Multicast-to-Ethernet Mapping Example

N

The base MAC address for multicast is 25 bits (00000001-00000000-0101111-0). To calculate the
mapping of a given IP multicast address you must convert the last 23 bits of the IP address into
R

hexadecimal. Look at the following example: 224.10.8.5, the last 23 bits are
0001010.00001000.00000101. Converting them to hexadecimal is 0A.08.05. So the complete
TE

MAC address then becomes 01-00-5E-0A-08-05.

The issues to watch for with the IP multicast address-to-MAC address mapping is the possible
overlap between IP group addresses and their MAC addresses. For example the following groups
maps to the exact same MAC address as 224.10.8.5: any 22x.10.8.5 multicast address
IN

(15 duplicates) but also any 22x.138.8.5 multicast address (16 duplicates). You might want to think
about the overlap when assigning multicast addresses to your applications.

www.juniper.net 21
Introduction to Multicast

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 see what the best route back to the source is. 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.

22 www.juniper.net
 Introduction to Multicast

LY
N
O
SE
U
AL

The RPF Check: Part 1

N

In the example on the slide, a packet arrives at R1’s interface ge-0/0/1.0 from Source 1. R1 checks
the existing unicast routing table and determines that this interface is not on the reverse path back
R

to the source. Thus, the packet is discarded.

TE
IN

www.juniper.net 23
Introduction to Multicast

LY
N
O
SE
U
AL

The RPF Check: Part 2

N

In this example, R1 receives a packet from Source 1 on its ge-0/0/4.125 interface and, once again,
performs an RPF check. R1 determines that the packet is coming in on an interface that is on the
R

reverse path back to the source. Thus, the RPF check succeeds, and the packet is forwarded to all
interfaces on the outgoing interface list. Initially, all interfaces other than ge-0/0/4.125 will be on
TE

the outgoing interface list.

IN

24 www.juniper.net
 Introduction to Multicast

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 interface to the upstream router nearest to
the source.
The receipt of IGMP or PIM join messages moves those interfaces to the OIL, so packets
are forwarded to these interfaces toward the receivers.

www.juniper.net 25
Introduction to Multicast

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
IN

this separate topology by changing the table the RPF check uses. Therefore, instead of
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.

26 www.juniper.net
 Introduction to Multicast

LY
N
O
SE
U
AL

Alternate Multicast Topology

N

The slide shows the use of multiprotocol BGP to create two separate topologies. The two separate
topologies allow a form of load-sharing across links between unicast traffic and multicast traffic. On
R

the slide, routes for the same prefixes are exchanged twice: once for unicast routing (inet.0) and
once for multicast routing (inet.2).
TE

When AS 65013 sends unicast traffic toward AS 65011, it prefers the bottom link. For the multicast
traffic coming from AS 65011, the RPF check prefers the top link. If the multicast and unicast
topologies had been identical, the multicast RPF check would have also preferred the bottom link.
IN

www.juniper.net 27
Introduction to Multicast

LY
N
O
SE
U
AL

RIB Groups
N

The Junos OS provides a simple method for placing routing information in multiple tables
simultaneously. This method uses a RIB group. Once defined within the [edit
R

routing-options] portion of the configuration hierarchy, you can apply a RIB group in other
sections of the configuration.
TE

In a multicast environment, you might want unicast and multicast traffic to use different network
links. These separate forwarding topologies require separate routing tables. The inet.2 table
specific for multicast forwarding might require routes from the unicast topology (inet.0), for
example, to make M-BGP next-hops reachable. To place interface or IGP routes from inet.0 into
IN

inet.2, RIB groups are required.

28 www.juniper.net
 Introduction to Multicast

LY
N
O
SE
U
AL

Defining a RIB Group

N

You assign the name of the RIB group within the [edit routing-options] configuration
hierarchy. Within the RIB group configuration, two main configuration options exist. The
R

import-rib statement can list multiple routing tables and informs the software where to place
incoming route information. The export-rib statement can list only a single routing table and
TE

informs the software where to extract route information. The import-rib statement must list the
primary routing table first within the configuration. The primary routing table is considered to be the
routing table where the routing information would ordinarily be placed without the presence of a RIB
group. Because you can list only a single routing table within the export-rib statement, and that
single routing table must be the primary RIB, the export-rib statement is frequently omitted from
IN

the configuration.

Applying a RIB Group

Once you create a RIB group, you can apply it to other sections of the configuration. Potential
applications of a RIB group include interface routes, static routes, OSPF, IS-IS, RIP, BGP, Physical
Interface Modules (PIMs), and Multicast Source Discovery Protocol (MSDP).

www.juniper.net 29
Introduction to Multicast

LY
N
O
SE
U
AL

RIB Groups Application for Alternate RPF Table

N

Besides filling the inet.2 table with routes, to build up the alternate topology, RIB groups are
required to redirect the multicast routing protocols to actually use inet.2 for RPF check purposes.
R

In the example on the slide, the RIB group inet2-rpf is applied to both PIM and MSDP. You can
see the result of the application of the RIB group by using the command show multicast rpf
TE

summary. Before applying the RIB group, the RPF table was inet.0, and afterwards, it indicates
that the RPF check is now performed on table inet.2.
IN

30 www.juniper.net
 Introduction to Multicast

LY
N
O
SE
U
AL

Internet Group Management Protocol

N

IGMP is the protocol that is used between the receivers and the multicast routers. The goal of IGMP
is to let the receivers indicate their interest in receiving traffic from certain multicast groups.
R

At this time, three versions of IMGP are defined as RFCs:

TE

• IGMP version 1: Original version defined in RFC 1112. It supports only the ASM model.
• IGMP version 2: IGMP version 2 is defined in RFC2236. It also only supports the ASM
model. The biggest improvements of IGMP version 2 over IGMP version 1 is in the time
it takes to stop sending traffic on a segment once the receiver is no longer interested in
IN

that traffic.
• IGMP version 3: IGMP version 3 is defined in RFC 3376. It supports the ASM model and
is mandatory for the SSM model.

www.juniper.net 31
Introduction to Multicast

LY
N
O
SE
U
AL

Group Membership Protocols Versus Multicast Routing Protocols

N

Multicast routing protocols work in conjunction with IGMP. IGMP allows hosts to join and leave
multicast groups; multicast routing protocols allow multicast traffic to flow between networks.
R

Common multicast routing protocols are DVMRP and PIM.

Normally, you do not have to run IGMP between routers because routers normally do not join
TE

multicast groups.
IN

32 www.juniper.net
 Introduction to Multicast

LY
N
O
SE
U
AL

IGMP Join Process

N

IGMP hosts interested in receiving traffic send an IGMP report message to the router. The
destination address of the report message is the multicast address of the requested group. After
R

joining a group, the host now also must respond to the router’s IGMP query message to indicate that
it is still interested in receiving traffic for that group.
TE

When the host wants to receive traffic for a given group, it must also start listening for the
corresponding MAC address.
The routers on the segment cache the IGMP report information to keep track of the receivers on that
segment per multicast group address.
IN

www.juniper.net 33
Introduction to Multicast

LY
N
O
SE
U
AL

IGMP Query-Response Process

N

For a given group the multicast router puts an interface in its outgoing interface list if it received an
IGMP report message from at least one host. Thus, if more hosts are on a segment that are
R

interested in receiving the same group traffic, the router still only forwards one time.
The router must keep track of the receivers to make sure at least one receiver remains on any of the
TE

outgoing interfaces because it is wasting resources if it is forwarding traffic to interfaces without

downstream receivers. To check if the receivers are still interested, the router sends periodic IGMP
query messages asking if interested receivers still exist. The IGMP query message is sent to
224.0.0.1 (all systems). The goal of the query message is to receive a solicited report message back
IN

from at least one receiver per group. Therefore, it is not useful if more than one receiver responds
per group as the router only needs one to keep the interface in the outgoing interface list.
To avoid duplicate answers to the query message, the response from the receivers is controlled by a
randomized timer mechanism. Each host waits a random time before sending a report message as
an answer. In case another receiver in your group already answered (shorter timer), the other
receivers in that group suppress their responses. This mechanism results in one report answer per
group to the query message from the router.
If more than one router exists on a given segment, the routers elect one active querier router. Each
router starts out thinking it must start querying, but as soon as it sees queries from another router
with a lower IP address, it stops. These non-querier routers that lose the querier election still keep
track of the IGMP cache.

34 www.juniper.net
 Introduction to Multicast

LY
N
O
SE
U
AL

IGMP Leave Process

N

In IGMP version 1, no explicit leave process exists for clients to indicate that they are no longer
interested in receiving traffic. When a IGMP version 1 client is no longer interested, it stops
R

responding to the router’s query message. Therefore, the router must time-out receivers before it
can stop forwarding out of that interface, which results in a long leave latency.
TE

In IGMP version 2, this problem is solved by having a specific IGMP leave message that a host should
send when it is no longer interested in traffic for a specific group. The leave group message is sent to
the group’s multicast address. When a router receives a leave message, it sends a group-specific
query to find out if other receivers for that group are still on the interface. The remaining receivers
IN

should respond to the group-specific query to indicate that there is at least one receiver remaining
on the interface. The advantage of this method is that the leave latency is greatly reduced because
the timers in use are much lower.

www.juniper.net 35
Introduction to Multicast

LY
N
O
SE
U
AL

Layer 2 Switches and Multicast

N

In most Layer 2 networks, Layer 2 switches are located between the hosts and the routers. The
Layer 2 switches microsegment the edge interfaces on the network. By default, most Layer 2
R

switches treat multicast traffic in the same manner as they treat broadcast traffic: They forward the
traffic to all ports in a given VLAN. This system is not an efficient use of bandwidth for ports that do
TE

not have receivers for the forwarded traffic.

IGMP Snooping
IGMP snooping was developed to prevent multicast traffic from being forwarded to all ports in a
IN

given VLAN, thereby avoiding the potential waste of bandwidth on multiple ports. The principle of
IGMP snooping is that the Layer 2 switch actively monitors the IGMP traffic between the hosts and
the multicast router. By inspecting the IGMP messages, the Layer 2 switch can make informed
decisions because it can learn the locations of receivers that are interested in certain multicast
traffic. The link-local block of of 224/8 addresses is an exception, because these addresses must
always be forwarded to all ports in a given VLAN.

36 www.juniper.net
 Introduction to Multicast

LY
N
O
SE
U
AL

IGMP Snooping
N

With IGMP snooping, Layer 2 switches divide ports into two categories: multicast-router interfaces
and host-side interfaces. Multicast-router interfaces are either statically configured as such, or they
R

become so by receiving IGMP query messages. From both types of interfaces, any IGMP protocol
packets received are sent to the Routing Engine for inspection, so that group membership
TE

information for each interface can be learned.

The forwarding of multicast traffic depends on the category of the interface. All traffic is sent to the
multicast-router interfaces. However, multicast traffic is sent to the host-side interface only if the
Layer 2 switch learned about a receiver on that interface through the IGMP snooping process. If a
IN

Layer 2 switch does not learn of a receiver on an interface, it does not forward unnecessary traffic to
that interface. As noted previously, the 224/8 destination address in an exception, because it must
be forwarded to all ports, including host-side interfaces.

www.juniper.net 37
Introduction to Multicast

LY
N
O
SE
U
AL

IGMP Snooping: Standard Implementation

N

The standard implementation of IGMP snooping is to inspect only incoming messages from the
router (a query) and from the receivers (reports, and leave messages). The Layer 2 switch does not
R

create or generate any IGMP messages, nor does it limit the number of messages seen by the
multicast router.
TE

IGMP Snooping: Proxy

An additional feature of IGMP snooping can be enabled, in which the Layer 2 switch actually
participates in the IGMP protocol exchange. When this feature is enabled, the Layer 2 acts as a proxy
IN

between the router and the receivers: It behaves as a multicast router toward the receivers by
generating IGMP queries, and it acts as a receiver by sending IGMP membership reports toward the
multicast router. By acting as a proxy, the Layer 2 switch reduces the number of report messages a
router sees, because it is acting on behalf of all of the receivers on the segment.

38 www.juniper.net
 Introduction to Multicast

LY
N
O
SE
U
AL

IGMP Snooping Configuration

N

The slide shows the basic configuration for IGMP snooping for both MX Series and EX Series
platforms. As illustrated on the slide, you can statically configure interfaces for
R

multicast-router-interface mode or for host-only-interface mode. In addition, you can configure static
groups on interfaces if no receiver is capable of sending IGMP reports on that interface for that
TE

group. Both platforms have the option to configure the IGMP snooping proxy feature by using the
proxy keyword.
Refer to your platform’s technical documentation for additional IGMP snooping configuration
options.
IN

www.juniper.net 39
Introduction to Multicast

LY
N
O
SE
U
AL

IGMP Version 1
N

IGMP version 1 uses report messages to indicate interest in receiving traffic for a given group. No
formal leave mechanism exists; hosts stop responding to the query messages from the router. Thus,
R

the router must time out receivers on an interface before removing it from the outgoing interface list.
The time it takes to remove the interface from the outgoing interface list is called the IGMP
TE

Membership Timeout. It equals the following: (IGMP query interval * Robustness Count) + (1 * IGMP
Query Response Interval):
• IGMP Query Interval: Time between routers query messages (125 seconds);
IN

• Robustness Count: Indication of reliability of link (2); and

• IGMP Query Response Interval: Maximum time for hosts to respond to query message
(10 seconds).
By default, the IGMP Membership Timeout results in a 260 seconds timeout value.
IGMP version 1 does not have its own querier election mechanism; it relies on the multicast routing
protocol to elect a querier on each segment.

40 www.juniper.net
 Introduction to Multicast

LY
N
O
SE
U
AL

IGMP Version 1 Packet Format

N

The basic packet format for IGMP version 1 is shown on the slide. The following fields are defined:
R

• Protocol version: Set to 1;

• Type: Indicates the type of message:
TE

– 1: Host membership query; or

– 2: Host membership report.
• Unused: Unused field, zeroed when sent, ignored when received;
IN

• Checksum: The standard IP checksum value for the entire IGMP message; and
• Group address:
– Host membership query: is zeroed when sent, ignored when received; and
– Host membership report: group address of the group being reported.

www.juniper.net 41
Introduction to Multicast

LY
N
O
SE
U
AL

IGMP Version 2
N

IGMP version 2 adds multiple improvements upon version 1. Hosts that leave the group send a
leave-group message so that the router can stop forwarding traffic to interfaces much more quickly.
R

The leave timeout is (IGMP Last Member Query Interval * Robustness Count) and is equal to two
seconds by default.
TE

IGMP version 2 also includes its own querier election mechanism so that the router with the lowest
IP address on the segment is always the active querier. Non-querier routers keep a copy of the IGMP
cache, and they also monitor the active querier. In case the active querier leaves, the non-querier
router becomes active again. This timeout is called the IGMP Other Querier Present Timeout. It is
IN

defined as (IGMP Query Interval * Robustness Count) + (0.5 * IGMP Query Response Interval), or
255 seconds.

42 www.juniper.net
 Introduction to Multicast

LY
N
O
SE
U
AL

IGMP Version 2 Packet Format

N

The IGMP version 2 packet format is shown on the slide. The following fields are defined:
R

• Type: Indicate what type of message:

– 0x11 Membership Query—General Query (224.0.0.1) and Group Specific Query
TE

(group address) subtypes;

– 0x16 Version 2 Membership Report;
– 0x17 Leave Group; and
IN

– 0x12 Version 1 Membership Report (for backward compatibility).

• Max Response Time: Maximum time to respond to membership query;
• Checksum: The standard IP checksum value for the entire IGMP message; and
• Group address:
– General Query: Zeroed;
– Group-Specific Query: Group address;
– Report message: Group address; and
– Leave-Group message: Group address.

www.juniper.net 43
Introduction to Multicast

LY
N
O
SE
U
AL

IGMP Version 3
N

IGMP version 3 is special because it enables SSM as well as supporting ASM. IGMP version 3 has all
the improvements of IGMP version 2, but also adds new capabilities to include source information in
R

the messages. This source information has two basic forms: sources can be included or sources can
be excluded.
TE

The SSM model is ideal for one-to-any multicast applications because it is less complex to deploy
and it creates less address allocation issues.
IGMP sends its report messages to the multicast address 224.0.0.22 instead of to the group-specific
address.
IN

44 www.juniper.net
 Introduction to Multicast

LY
N
O
SE
U
AL

IGMP Configuration
N

IGMP version 2 is automatically enabled on all interfaces that are configured under the [edit
protocols pim] hierarchy. To change the default settings for IGMP, configure global or interface
R

settings under the [edit protocols igmp] hierarchy.

When a router is attached to a LAN that has only IGMP-speaking hosts (that is, no other
TE

PIM-speaking routers), that interface must also run PIM for IGMP to work properly. If you explicitly
enable IGMP on an interface but fail to also run PIM, the IGMP interface status shows the up state,
but that interface is omitted from the output of a show igmp group command.
IN

www.juniper.net 45
Introduction to Multicast

LY
N
O
SE
U
AL

Modifying Default IGMP Settings

N

You can customize IGMP settings on a protocol or interface basis. The IGMP timers are configured
globally for the protocol. You can specify the IGMP version on a per-interface basis.
R

The default version of IGMP in the Junos OS is version 2. IGMP versions 2 and 3 are
backward-compatible with version 1, but we advise using the same version of IGMP for all
TE

participants (hosts and routers) on each individual network segment.

You can use a static IGMP join in case the receiver is not capable of sending IGMP messages, which
is also useful for testing multicast deployments when receivers are not connected to the network yet.
A static join does not cause the router to send IGMP joins, but it does put the corresponding
IN

interface in the outgoing interface list, as if it had received an IGMP join from a real receiver.
You can perform ASM joins (group only) or SSM joins (group and source information). For SSM joins,
the IGMP version must be set to version 3.

46 www.juniper.net
 Introduction to Multicast

LY
N
O
SE
U
AL

Monitoring IGMP Interfaces

N

Using the show igmp interface command shows you the details of the IGMP settings on a
per-interface basis. It displays the version, the elected querier, and the number of groups on an
R

interface. It also shows the different timers used by IGMP.

TE
IN

www.juniper.net 47
 Introduction to Multicast
I

LY
N
O
SE
U
AL

Monitoring IGMP Groups

N

The show igmp group command displays the groups discovered on the interfaces. It also
includes timeout values, type (static versus dynamic) and the source that last reported this group on
R

the interface.
TE
IN

48 www.juniper.net
 Introduction to Multicast

LY
N
O
SE
U
AL

Monitoring IGMP Statistics

N

If you want to see the detailed statistics of the IGMP protocol, you can use the show igmp
statistics command. It displays the different IGMP message types (query, report, or leave) as
R

well as some other statistics.

TE
IN

www.juniper.net 49
Introduction to Multicast

LY
N
O
SE
U
AL

IGMP Traceoptions
N

If you want to troubleshoot the IGMP protocol, you can enable traceoptions under the [edit
protocols igmp] hierarchy. By monitoring the traceoptions file, you can see the IGMP protocol
R

exchanges in real time.

In the output example on the slide, you can see the router sending an IGMP v2 General Query
TE

message on interface ge-1/0/0.0. It then receives an IGMP v2 Report from receiver 10.0.117.2.
IN

50 www.juniper.net
 <Course Title>
Multicast Routing Protocols

LY
N
O
SE
U
AL
N
R
TE
IN
Multicast Routing Protocols

LY
N
O
SE
U
AL

Functionality of Multicast Routing Protocols

N

Multicast routing protocols perform the following functions:

R

• Perform RPF check on multicast traffic: The RPF check is needed to make sure
multicast data is sent only downstream toward the receivers. The source can be
checked using existing routing information or the multicast routing protocol can
TE

exchange specific routing information to accomplish this.

• Setup multicast forwarding state in router: Routers participating in multicast forwarding
must keep state information about sources and receivers. The source address can be
compared to the existing route information in the unicast route table. Alternatively, the
IN

multicast routing protocol can build its own routing table by exchanging route
information between its neighbors. The router also keeps track of the outgoing interface
list (OIL) that indicates on which interfaces downstream or directly connected receivers
exist for each group. Traffic is forwarded to the interfaces in the OIL if the packet arrived
on the incoming interface (IIF).
• Exchange multicast forwarding state with other routers: Unless the source and the
receiver are on the same router, there is a need for routers to exchange their willingness
to receive traffic between each other. If traffic should be forwarded from Router A to
Router B, Router B must signal its willingness to receive traffic by sending a PIM join
message to Router A. If Router B does not want traffic anymore, it sends a PIM prune
message.

2 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

Dense Mode Protocols

N

Dense mode protocols have the following characteristics:

R

• They assume dense distribution of the receivers: Dense-mode protocols are designed
for multicast deployments where receivers are distributed across all network segments.
TE

• They use an implicit join model, which means flooding and pruning: All routers are
assumed to be implicitly interested in all multicast traffic;, therefore, traffic is forwarded
to every router in the network (flooding). Routers that have no downstream receivers do
not need to receive the traffic and signal their upstream neighbors to stop sending the
traffic (prune message).
IN

• Source-based trees are always used: As traffic is forwarded from the source to all
routers, each router in the network will receive the multicast traffic through the optimal
shortest path between source and receiver. Thus, dense mode will always use
source-based trees to forward traffic.
• All routers in the network will have state information about all multicast flows: All
routers receive the multicast traffic from all sources in the network. Therefore, they
must keep track of all of these multicast flows. For each source, the router must keep
track if traffic is required (receivers) or not required (no receivers).
Thus, if there are a lot of multicast flows in the network, this will become a control plane
scaling issue.

www.juniper.net 3
Multicast Routing Protocols

LY
N
O
SE
U
AL

Sparse Mode Protocols

N

Sparse mode protocols have the following characteristics:

R

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

receive it.
• Uses an explicit join model: In sparse mode, routers near the designated router (DR)
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.
IN

Continued on next page.

4 www.juniper.net
 Multicast Routing Protocols
Sparse Mode Protocols (contd.)
The following is a continuation of sparse mode protocol characteristics:
• Complicated source discovery mechanism is required: The main complication with
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 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 an RP in any-source multicast (ASM) deployments, where the source will
announce itself when it becomes active. Now the receiver DR can join a shared
tree towards this RP so that it will receive multicast traffic once the source traffic
arrives at the RP.

LY
– Letting the receiver signal the source from which it wants to receive traffic, which
is called source-specific multicast (SSM). The source discovery now becomes an
application issue because it must let the receiver know what sources to use.

N
IGMPv3 is required for SSM support.

O
SE
U
AL
N
R
TE
IN

www.juniper.net 5
Multicast Routing Protocols

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: 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 so that initial traffic can now flow between the source and receiver. The
TE

path 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. It
should be obvious that in SSM deployments only source-based trees are used because
the source is always known.
The state for source-based tree is described as an S,G state. S indicates the specific
source, and G indicates the group.
Sparse-mode protocols are considered to scale better than dense-mode protocols, even though
sparse mode uses a more complicated mechanism to enable traffic to flow from source to the
receiver. The reason for the increased scalability of sparse-mode protocols is that not all routers
must keep forwarding state for all multicast flows because receivers are much more dispersed in
real-life scenarios.

6 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode Shared Tree and Source-Based Tree

N

In the slide you can see the shared tree that is established between the receiver’s DR router (R6)
and the RP (R3) in the network. You can also see the state information described by the *.G
R

information.
The source-based tree is also seen between the source DR (R1) and the receiver DR (R6).
TE

Later, we discuss in detail how the shared path is used initially to learn about the source, but once
the source is known, the source-based tree is used because it is a more optimal path.
IN

www.juniper.net 7
Multicast Routing Protocols

LY
N
O
SE
U
AL

Distance Vector Multicast Routing Protocol

N

The Distance Vector Multicast Routing Protocol (DVMRP) was the first widely implemented multicast
routing protocol, and it was used in the initial multicast deployments on the Internet. The Mbone
R

backbone was used to test multicast deployments across the Internet, but it has been replaced by
better interdomain multicast solutions. Institutions like universities connected to the Mbone through
TE

tunnels over which DVMRP was run.

DVMRP is a dense-mode protocol implementation so it uses a flood-and-prune model to send
multicast traffic. The implementation of DVMRP into the Junos operating system is described in the
expired draft, draft-ietf-idmr-dvmrp-v3-11.
IN

DVMRP does not use the existing unicast route information, but it instead exchanges its own routing
information that is the basis for the RPF check it performs.

8 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

Protocol Independent Multicast

N

PIM is the dominant multicast routing protocol in use today. It is called protocol independent
because it uses any unicast routing information available to perform its RPF check. Therefore,
R

unicast routing information can be learned through any interior gateway protocol (IGP), BGP, or both.
PIM has two different implementations that can be used in Junos devices:
TE

• PIM dense mode (RFC 3973); and

• PIM sparse mode (RFC 4601). PIM sparse mode is the de facto standard for most
multicast deployments today, and it has two delivery mode options: ASM and SSM.
IN

Two versions of the PIM protocol exist:

• Version 1: PIM messages are encapsulated inside IGMP and sent to 224.0.0.2
(All-Routers) with a TTL of 1.
• Version 2: PIM messages are encapsulated inside protocol 103 and sent to 224.0.0.13
(All-PIMv2-routers) with a TTL of 1. Version 2 also adds some new message types
related to RP discovery.

www.juniper.net 9
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Dense Mode Message Types

N

PIM dense mode uses the following message types:

R

• Hello messages: Hello messages are exchanged between PIM neighbors to discover
and maintain neighbors. PIM signaling about traffic interest or lack thereof can only be
exchanged with other PIM-capable routers.
TE

• Join/prune messages: In dense mode, prune information is primarily exchanged, but

both join and prune information is carried in the same message type, and as a result,
the message is called a join/prune message.
IN

In dense mode, prunes are sent to upstream routers from which traffic is no longer
requested.
• Graft and graft-ack messages: Graft and graft-ack messages are used to request traffic
from an upstream router where previously a prune message has been sent. A graft is
basically a renewed request to join the source tree. A graft is needed when a receiver
joins after the source started sending. Without graft messages, the join delay for
receivers would be much higher. The graft-ack is the only reliable signalling message
type that PIM uses.
• Assert messages: Assert messages are used to elect a single router to forward traffic on
a multi-access segment with multiple routers (> 2). This router is called the designated
forwarder (DF). It improves the efficiency of multicast forwarding by sending traffic onto
a multi-access segment only once.

10 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Version 2 Message Header Format

N

The slide shows the PIM v2 message header. It contains the following fields:
R

• Version: 1 or 2—Version 2 is the default version in the Junos OS;

• Type:
TE

– 0 = Hello message;
– 1 = Register message (sparse mode only);
– 2 = Register-Stop message (sparse mode only);
IN

– 3 = Join/Prune message;
– 4 = Bootstrap message (sparse mode only);
– 5 = Assert message;
– 6 = Graft message (dense mode only);
– 7 = Graft-Ack message (dense mode only); or
– 8 = Candidate-RP-Advertisement message (sparse mode only);
• Reserved: 0x00; and
• Checksum: The standard IP checksum over the PIM packet.

www.juniper.net 11
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Version 2 Hello Message Format

N

The slide shows the PIM v2 hello message format. It contains the following fields:
R

• Version: 2;
• Type: 1 (Hello message);
TE

• Reserved: set to 0x00;

• Checksum: The standard IP checksum value for entire PIM packet;
• Option type:
IN

– 1 = Holdtime—indicates how long a neighbor is reachable;

– 2 = LAN Prune Delay—indicates the timers for the prune delay on multi-access
segments;
– 19 = DR priority—value to influence DR election (higher is preferred); or
– 20= Generation ID—random 32-bit value sent when PIM forwarding activates or
restarts;
• Option length; and
• Option value.
The last three fields (option type, option length, and option value) can repeated depending on how
many options are supported in the PIM implementation.

12 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Version 2 Join/Prune Message Format

N

The slide shows the PIM v2 join/prune message format. It contains the following fields:
• Version: 2;
R

• Type: 3;
TE

• Reserved: 0x00;
• Checksum: The standard IP checksum value for entire PIM packet;
• Upstream neighbor address (Encoded-Unicast format): The IP address of RPF neighbor;
• Reserved: All zeroes;
IN

• Number of groups: The number of multicast group sets contained in the message;
• Holdtime: The time to keep the join/prune state alive;
• Multicast group address 1 (Encoded-Group format): Multicast group address;
• Number of joined sources: The number of joined sources for group address 1;
• Number of pruned sources: The number of pruned sources for group address 1;
• Joined source address (Encoded-Source format): The joined source for group
address 1; and
• Pruned source address (Encoded-Source format): The pruned source for group
address 1.
For each multicast group, the last five fields are repeated. The last two fields can also be repeated
multiple times within each group.

www.juniper.net 13
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Version 2 Graft/Graft-Ack Format

N

The slide shows the PIM v2 graft/graft-ack message format. It contains the exact same fields as the
join/prune message from the previous slide. The only difference is the type value (6 for graft and 7
R

for graft-ack).
Graft-ack messages are sent in unicast to the router sending the graft message.
TE
IN

14 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

Encoded Unicast Address Format

N

The slide shows the encoded unicast address field format. It contains the following sub-fields:
• Address family: IANA assigns the values 0–127 for Internet address families. It is 1 for
R

IP version 4 (IPv4).
The values 128–250 are reserved for PIM-specific address families, and the values
TE

251–255 are for private use.

• Encoding type: The type of encoding for the specific address family. This type is set to 0.
• Unicast address: This field is the unicast address in its native format. For IPv4 it will be
IN

a 4-byte address.

www.juniper.net 15
Multicast Routing Protocols

LY
N
O
SE
U
AL

Encoded Group Address Format

N

The slide shows the encoded group address field format. It contains the following sub-fields:
• Address family: Type of address family (1=IPv4).
R

• Encoding type: Encoding used within specifc address family.

TE

• B-bit: Indicates support for Bidirectional PIM. For normal PIM dense mode and sparse
mode, it is set to 0.
• Reserved: Set to all zeroes.
• Z-bit: Indicates if group range is an admin scope zone used by the PIM sparse mode
IN

bootstrap mechanism. Otherwise, it is set 0 for dense and sparse modes.

• Mask length: Indicates mask for group range.
• Group multicast address: Contains group address.

16 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

Encoded Source Address Format

N

The slide shows the encoded source address field format. It contains the following sub-fields:
• Address family: Type of address family (1=IPv4);
R

• Encoding type: The encoding used with specific address families;

TE

• Reserved: Set to all zeroes;

• S-bit: Sparse bit, set to 1 for PIM sparse mode for PIMv1 compatibility;
• WC-bit: Set for Join/Prune messages for the *,G items in PIM sparse mode;
IN

• R-bit: The RP tree bit to indicate shared tree join messages;

• Mask length: The mask for the source (/32 for IPv4); and
• Source address: The source address.

www.juniper.net 17
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Version 2 Assert Message Format

N

The slide shows the PIMv2 assert message format. It contains the following fields:
• Version: 2;
R

• Type: 5;
TE

• Reserved: 0x00;
• Checksum: The standard IP checksum value for entire PIM packet;
• Group address (encoded-group format): The group address;
IN

• Source address (encoded-source format): The source address;

• R-bit: Indicates whether assert is for source-based tree (0) or shared-tree (1;)
• Metric preference: The preference value of the routing protocol that provides the RPF
route to the source (or the RP); and
• Metric: The cost of the RPF route back to the source (or the RP).

18 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Neighbor Discovery

N

Routers with PIM-enabled interfaces start sending PIM hello messages on those interfaces. The
hello messages are used to discover and maintain PIM neighbors. It is essential for PIM to discover
R

neighbors because the RPF interface must be associated with a PIM upstream neighbor. If no PIM
neighbor exists on the RPF interface, the RPF check fails.
TE

Depending on the PIM version in use, the hello messages are sent to 224.0.0.13 (PIM version 2) or
to 224.0.0.2 (PM version 1). In PIM version 1, the hello message is often called the PIM query.
The hello message can include the holdtime information, which indicates how long the neighbor is
up without receiving any new hellos. In the Junos OS, the default hello holdtime field is set to 0 to
IN

indicate that the local hello holdtime should be used. In the Junos OS, the local hello holdtime is
3.5 * hello interval (30 seconds) and, therefore, equals 105 seconds.
Continued on next page.

www.juniper.net 19
Multicast Routing Protocols
PIM Designated Router Election
The hello message is used on multi-access segments to elect one DR for the segment. In PIM dense
mode, the DR does not have a specific use. In PIM sparse mode, the DR has specific uses both on
the receiver segment and on the source segment.
The DR election is based on the DR priority field in the hello messages. In the Junos OS, the value is
set to 1 as the default. In case you want to influence the election, you can increase the value using
the set protocols pim interface interface-name priority command. When the
DR priorities are equal, the highest IP address is used as a tiebreaker.
To comply with the latest PIM drafts, you can enable DR election on all interfaces, both multi-access
(default on) and point-to-point interfaces (default off). To enable DR elections on point-to-point
interfaces use the set protocols pim dr-election-on-p2p command.
If IGMP version 1 is used, the PIM DR election is also used to elect the IGMP querier router, because

LY
IGMP version 1 does not have its own election mechanism.

N
O
SE
U
AL
N
R
TE
IN

20 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Dense Mode: Operation

N

PIM dense mode uses shortest-path trees to deliver multicast traffic and assumes that there is at
least one receiver of the multicast traffic on every subnet in the network. Traffic is initially flooded to
R

all points in the network. Traffic is always flooded on a source-based tree in dense-mode protocol
implementations.
TE

Each router running PIM dense mode creates an (S,G) state entry for each source and group pairing.
The slide shows an example of an (S,G) state entry. The slide shows the S,G state on R1, where
S = 192.168.100.10, G =224.7.7.7, which indicates the traffic is coming from the source
192.168.100.10, and it is sending to the multicast group 224.7.7.7. The state entry also includes the
IN

IIF towards the source A, and the OIL, to where traffic must be forwarded. Because this is dense
mode, it will initially forward the traffic to all neighbors.
Routers without locally attached receivers must prune themselves periodically from the SPT to avoid
the reception of unwanted multicast traffic.

www.juniper.net 21
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Dense Mode: Pruning

N

Because PIM dense mode sends traffic to all network segments, routers send prune messages back
up the source distribution tree to shut off unwanted multicast traffic when they have no locally
R

attached receivers, and also upon receiving a prune from their downstream neighbors.
The prune state eventually times out, so routers must reissue their prune messages periodically to
TE

once again stem the flow of unwanted multicast traffic. This mechanism is the core of the scalability
problem PIM dense mode has, because all routers must keep state information about flows in which
they are not interested.
IN

22 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Dense Mode: State After Pruning

N

When all the prune messages have been sent, the network will have multicast traffic flowing only
across routers that have downstream receivers. On the slide, you can see that R1 has S,G state
R

information, indicating that it is willing to receive traffic because it has members in the OIL. On R2 no
members are in the OIL, and that means it has no interest in receiving traffic from its upstream
TE

neighbors.
Because receivers might come and go, the state information must be refreshed on a regular basis. In
the Junos OS, the PIM dense-mode state information is kept for 3 minutes. When a new receiver
joins or a receiver disappears, PIM does not have to wait for these timers to expire to make a change
IN

in the topology.

www.juniper.net 23
Multicast Routing Protocols

LY
N
O
SE
U
AL

Source-Based Tree
N

A source distribution tree is an SPT between the sender and a given receiver. Dense-mode protocols
have the benefit of using SPTs between all sources and receivers. Dense-mode protocols solve the
R

issue of how source and receivers meet by flooding the source traffic to all parts of the network,
thereby ensuring that the receivers will learn about the sources. This flooding results in optimal
TE

traffic paths but also results in state information in all routers in the network.
IN

24 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Pruning on Multi-Access Networks

N

On multi-access networks some added complexity exists when sending prune messages to the
upstream router. On the slide, R2 has no interested receivers and therefore sends a prune to the
R

router near the source. If that router would act upon this prune directly upon receiving it, the traffic
flow down to R1, which has receivers, would also be stopped. To avoid this situation, the router near
TE

the source waits before acting upon the received prune, giving the other router (upstream to R1)
time to overrule the prune from R2 because it wants to receive traffic on the multi-access segment.
IN

www.juniper.net 25
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Prune Delay on Multi-Access Networks

N

A PIM prune-delay timer gives other routers time to react to prune messages on multi-access
networks. To overrule a prune message from R2, the other router on the segment has a maximum of
R

2 seconds (the Junos OS default) to send a join message.

In the example in the slide, this delay ensures that the traffic toward R1 will not be stopped by the
TE

prune sent by R2. The router near the source received the prune from R2, but because the other
router sent a join within the prune-delay interval, traffic keeps being sent out of the multi-access
interface. R2 will just not forward this traffic downstream.
IN

26 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Dense Mode: Grafting

N

The slide shows what happens when a new receiver joins the multicast group after the SPT has been
established. R3 receives an IGMP report from the new receiver advertising its membership to the
R

224.7.7.7 group. R3 and every router along the SPT between the source and receiver, in turn, sends
a graft message upstream toward the source. Graft messages are reliable because they require a
TE

graft-ack message from the upstream router. The graft mechanism allows receivers to be quickly
added to an existing source tree without having to wait for the prune state to timeout.
For R3 and all of the other routers to send the graft message toward the source, they must somehow
know the IP address of the source. Note that the new receiver did not specify the source’s IP address
IN

(192.168.100.10) in its IGMP join. Any ideas?

www.juniper.net 27
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Dense Mode: Forwarding on New Shortest Path Tree

N

Because we are using a dense-mode protocol, every router is aware of every source and group
combination that is being used in the network and stores that information as part of the (S,G) state.
R

R3 looks over all of its (S,G) entries and finds the S = 192.168.100.10 and G = 224.7.7.7 entry. This
entry does not have any members in the OIL and indicates a prune has been sent to the upstream
TE

neighbor. To override the prune, the graft mechanism is used. The graft message contains both the
source (192.168.100.10) and the group (224.7.7.7). The OIL will now also be updated with the
receiver interface because of the IGMP report that was received.
IN

28 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Assert Mechanism: Part 1

N

On multi-access segments, more than one router can possibly start sending traffic to downstream
routers. Because receiving the same traffic twice is not useful, a mechanism must exists to
R

determine which router should send traffic and which other routers should stop sending the
duplicate traffic. This mechanism is called the PIM assert.
TE

The PIM assert mechanism is triggered when a router receives traffic on an interface that is in its
own OIL for that specific type of traffic. The assert mechanism elects a specific router that is allowed
to keep forwarding to downstream routers. This router is called the DF. The other routers that lost the
DF election will stop sending traffic.
IN

www.juniper.net 29
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Assert Mechanism: Part 2

N

On the slide, R1 and R2 are electing the DF for the multi-access segment so that only one of the
them will send the traffic toward R3 and its receiver. The assert messages contain information about
R

the best path back to the source from each router. R1 has a route back to the source
(192.168.100.10) with a metric preference of 10 and a metric of 10. R2’s values are metric
TE

preference of 10 and a metric of 20. The lowest values are the best, so in this case R1 would win the
DF election and continues to forward the traffic.
The details of the assert mechanism are a bit more complex. R2 lost the election and prunes the
interface as expected. However, R1 also sends a prune on the interface to stop sending traffic on it.
IN

As discussed before, a prune delay exists in multi-access interfaces, and R3 uses this delay to
overrule the prune message from R1 with its own join message. This process ensures that traffic
keeps flowing toward R3 and its receiver.

30 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Dense Mode: Minimum Configuration

N

To configure PIM in dense mode, you must include all the required interfaces under the [edit
protocols pim] hierarchy, and additionally, enable them for dense mode because, by default,
R

the mode is sparse. The default version of PIM in the Junos OS is version 2.
As mentioned before, make sure you enable PIM on interfaces that have been enabled for IGMP,
TE

because otherwise IGMP does not work properly.

IN

www.juniper.net 31
Multicast Routing Protocols

LY
N
O
SE
U
AL

Sample Configuration: PIM Dense Mode

N

On the slide, you can see some optional settings that you might use to customize the PIM
dense-mode configuration. The values given are the same as the defaults.
R
TE
IN

32 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

Monitoring PIM Interfaces

N

To verify which interfaces are enabled for PIM and the settings the interfaces have, use the show
pim interfaces command. The output shows information about the state, the IP version, the DR
R

state, neighbor counts, join counts (both *,G and S,G), and the DR addresses on the interfaces.
TE
IN

www.juniper.net 33
Multicast Routing Protocols

LY
N
O
SE
U
AL

Monitoring PIM Neighbors

N

To see PIM neighbor information, use the show pim neighbors command. It shows the
discovered neighbor and the options supported for each interface.
R
TE
IN

34 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

Monitoring PIM Neighbor Details

N

To see detailed information regarding the PIM neighbors, use the show pim neighbors detail
command. It shows information about options supported, joins, and assert results for each neighbor.
R
TE
IN

www.juniper.net 35
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Join/Prune State

N

To look at the detailed information regarding the PIM state of multicast traffic, use the show pim
join extensive command.
R

On the slide, you can see the S,G entry, where S=10.0.107.2, G = 224.7.7.7, and the flag indicates it
is used in dense mode. The upstream interface is ge-1/1/9.57, and the OIL has one member:
TE

ge-1/0/7.807.
IN

36 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

Multicast Source Information

N

To determine whether the router has learned about any multicast sources, use the show pim
source detail command. It shows the source IP address, the source route prefix, the upstream
R

interface, the upstream neighbor’s IP address, and the active groups for each source.
TE

Multicast Source RPF Information

To check the RPF result for a given source, use the show multicast rpf source-address
command. It provides information about the route toward the source, the protocol from which it was
learned, the upstream interface, and the upstream neighbor’s IP address.
IN

www.juniper.net 37
Multicast Routing Protocols

LY
N
O
SE
U
AL

Multicast Route Information

N

To view the multicast route information, use the show multicast route extensive
command. It provides information about the source, the group, the upstream interface, the
R

downstream interface list, session description (SDP sessions), traffic statistics, next-hop ID,
multicast protocol used, state of the route, forwarding state, cache lifetime/timeout, and any wrong
TE

incoming interface notifications.

To look at the cached information in the inet.1 table, use the show route table inet.1
command.
IN

38 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

Multicast Next-Hop Information

N

If needed, you can find next-hop information related to a multicast entry in inet.1 by using both the
show route table inet.1 extensive and the show multicast next-hops
R

commands.
On the slide, you can see that for the 224.7.7.7.10.0.107.2/64 entry, the next-hop index is 1048575.
TE

This next hop is associated with downstream interface ge-1/0/7.807.

The preceding three slides and this slide show the same basic information about the multicast route
state in different ways. The main items are the source and group, the incoming interface (RPF
check), and the OIL (toward receivers). You typically do not need to look at all these variants of the
IN

same information.

www.juniper.net 39
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM and Multicast Traffic Statistics

N

To view PIM protocol messages, use the show pim statistics command. It shows a long list of
statistics. The slide only shows the normal protocol operation message statistics, but the output also
R

includes error statistics (see the next slide).

To determine whether multicast traffic is being received on a router, use the show multicast
TE

usage command. It shows the traffic per group as well as per source.
IN

40 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Error Statistics

N

To view the error statistics of PIM, use the show pim statistics command and look to the
bottom of the output.
R
TE
IN

www.juniper.net 41
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Traceoptions
N

To troubleshoot PIM signalling issues, you can enable traceoptions under the [edit protocols
pim] hierarchy.
R

On the slide, you can see the discovery of a new PIM neighbor, 10.0.117.6, on interface
ge-1/0/7.807.
TE

The assert message contains information about the pref 0x0000000a (=10) and a metric of 5 for
the router toward 10.1.107.2. The hello message contains the default values for LAN prune delay, DR
priority, as well as the unique generation ID.
IN

42 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

Multicast Traceroute
N

Similar to the unicast traceroute displaying the path a packet travels through the network between
source and destination, the multicast mtrace command can show the path between source and
R

receiver. However, the mechanism is different. mtrace sends a trace query packet to the router
nearest to the receiver. The last-hop router builds a trace response packet—filled with information
TE

about this hop (hop IP address, TTL, and traffic statistics)—and forwards the trace response packet
upstream to the next router in the path toward the source. Each router in the path between receiver
and source repeats this process until the router nearest the source is reached. The first-hop router
sends the report back to the router that issued the mtrace command.
IN

On the slide, you can see the result of the mtrace command for group 224.7.7.7 from source
10.0.107.1. It shows the path between the receiver (10.1.70.7) and the source. The information
includes the required TTL and the packet statistics.
The mtrace command on the slide includes an optional TTL value. (The default is 127, but it is 1 for
traces sent to group 224.0.0.2.)

www.juniper.net 43
Multicast Routing Protocols

LY
N
O
SE
U
AL

Generating Test Multicast Traffic

N

Using the standard Junos CLI to enable sources and receivers is an efficient method for verifying a
multicast network deployment that does not yet include an active source.
R

To send multicast traffic from any Junos router, use the ping command. You must remember some
key things when trying to generate multicast traffic with the ping tool. The obvious one is to use a
TE

multicast address as the destination address (225.1.2.3), but you must also include a time-to-live
(TTL) value (10), the outgoing interface (ge-1/0/4.12), and you must use the bypass-routing
keyword.
Pinging to multicast addresses could put an additional strain on the network because multiple
IN

routers might respond and thus multiple replies could be generated. You can disable routers to
respond to multicast pings using the set system no-multicast-echo command.
To emulate receivers on any Junos router you have two options. The first option is to enable static
IGMP joins on interfaces. Doing so creates the signalling state in the network like a real receiver
would (PIM joins, and so forth). However IGMP static joins do not respond to ping requests and
therefore cannot be used in a scenario where you have only ping to verify that traffic is correctly
delivered.
To enable routers to respond to multicast ping requests, you can configure the routers to listen to the
desired group using the set protocols sap listen group_address command. On the
slide, the same group address is used as that for which the multicast ping is sent to 225.1.2.3.

44 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode Message Types

N

PIM sparse mode uses the following message types:

R

• Hello messages: Hello messages are used in sparse mode to discover neighbors and to
elect DR routers on multi-access segments. Both the source segment DR and the
receiver segment DR perform specific functions in sparse mode.
TE

• Join/prune messages: In sparse mode traffic only flows toward routers that explicitly
joined the distribution tree. Thus, routers with receivers send join messages to their
upstream neighbors. When a receiver leaves, the router prunes itself from the tree.
IN

• Assert messages: Assert messages are used to elect DFs for multi-access segments.
• Register and register-stop messages: Register messages are sent from the source DR
toward the RP. The register message contains the multicast packet encapsulated in a
unicast header.
The register-stop message is sent from the RP toward the source DR to indicate it
should stop sending register messages.
• Bootstrap and candidate-RP advertisement messages: In sparse mode, the source and
receiver must meet each other at the RP. In PIM version 2, a way exists to learn about
the RP using the bootstrap mechanism. The routers that want to be the RP announce it
in candidate-RP advertisement messages. The bootstrap message is sent by the
bootstrap router and it contains the result of the RP election, so every router learns
about the RP in the network.

www.juniper.net 45
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Version 2 Register Message Format

N

The slide shows the PIM v2 register message format. It contains the following fields:
• Version: 2;
R

• Type: 1;
TE

• Reserved: 0x00;
• Checksum: The standard IP checksum value for entire PIM packet, except for the data
portion of the register message;
• B-bit: Border bit:
IN

– Set to 0 if from the DR directly connected to source; or

– Set to 1 if from the PIM Multicast Border Router (PMBR);
• N-bit: Null-register bit:
– Set to 0 normally; or
– Set to 1 by the DR to check whether the RP wants to receive traffic;
• Reserved: Set to all zeroes;
• Multicast data packet: Contains the multicast data packet originally from the source.
For the null-register message, the data packet contains only a dummy header with
source address and group address; the data length is zero.

46 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Version 2 Register-Stop Message Format

N

The slide shows the PIM v2 register-stop message format. It contains the following fields:
• Version: 2;
R

• Type: 2;
TE

• Reserved: 0x00;
• Checksum: The standard IP checksum value for entire PIM packet;
• Group address (encoded-group format): The group address; and
IN

• Source-address (encoded-unicast format): The source address.

www.juniper.net 47
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Version 2 Bootstrap Message Format

N

The slide shows the PIM v2 bootstrap message format. It contains the following fields:
• Version: 2;
R

• Type: 4;
TE

• N-bit: No-forward bit indicates the bootstrap message is not to be forwarded;

• Reserved: All zeroes;
• Checksum: The standard IP checksum value for entire PIM packet;
IN

• Fragment: A random generated number to identify to which bootstrap message it

belongs;
• Hash mask length: The mask length to be used in the hashing function (/30 is advised);
• BSR priority: The priority for bootstrap router (BSR) election (higher is preferred);
• BSR address (encoded-unicast format): The address of the bootstrap router;
• Group address 1 (encoded-group format): The group address range; and
• RP count 1: The number of RP addresses for group address range 1.
Continued on next page.

48 www.juniper.net
 Multicast Routing Protocols
PIM Version 2 Bootstrap Message Format (contd.)
The following is a continuation of the PIM v2 bootstrap message format fields:
• Frag RP count 1: The number of RP addresses for group address range 1 in this
fragment;
• Reserved: All zeroes;
• RP1 address (encoded unicast format): The address of RP 1 for group 1;
• RP1 holdtime: RP1 holdtime in seconds;
• RP1 priority: The priority of RP1 as received in the candidate-RP advertisement from
RP1; and
• Reserved: All zeroes.

LY
N
O
SE
U
AL
N
R
TE
IN

www.juniper.net 49
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Version 2 Candidate-RP-Advertisement Message Format

N

The slide shows the PIM v2 Candidate-RP-Advertisement message format. It contains the following
fields:
R

• Version: 2;
• Type: 8;
TE

• Reserved: 0x00;
• Checksum: The standard IP checksum value for entire PIM packet;
• Prefix count: The number of group address ranges the candidate RP is advertising;
IN

• Priority: The candidate RP priority (lower is better);

• Holdtime: The time in seconds the advertisement is valid;
• RP address (encoded-unicast format): The address of the interface advertised as
candidate RP;
• Group address 1 (encoded-group format): The group address 1; and
• Group address n (encoded-group format): The group address n.
The candidate RP can advertise multiple group ranges for which it wants to be RP.

50 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode: Rendezvous Point Tree Operation

N

In sparse mode, traffic is forwarded only to routers that explicitly requested to join the distribution
tree. In other words, routers must send join messages up the distribution tree.
R

On the slide, the receiver sends an IGMP join for any source (*) for group 224.7.7.7 to R6. R6 must
signal to its upstream neighbor that it is interested in receiving traffic for 224.7.7.7. The question now
TE

is which router is the upstream neighbor? In dense mode, this question was easy, because it always
is the router upstream toward the source, but in sparse mode we initially do not know the source.
Thus, R6 has a problem because it does not know the location of the source.
To solve this unknown source problem, sparse mode uses a meeting point where any new source in
IN

the network can be learned. This meeting point is called the rendezvous point (RP). All routers must
know the RP, for example by static configuration. Therefore, because R6 does not know where the
source is, it sends its join toward the upstream router in the direction of the RP (10.1.1.1). This join
message is in the form of a *, G join. The resulting state can be seen in the slide and is called the
rendezvous point tree or shared tree.
The result of the *.G join of R6 toward the RP (R3) is a multicast-enabled forwarding path from R3
toward R6 for traffic from any source to group 224.7.7.7.

www.juniper.net 51
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode: Register Message Operation

N

On the slide, the source (192.168.100.10) starts sending multicast traffic to group 224.7.7.7. Its DR
(R1) has no multicast forwarding path to any other router yet (no join messages were received on
R

R1). Similar to the previous slide where the receiver DR (R6) did not know where the source was, R1
does not know where the receivers are. Again, the RP solves this issue. The source DR encapsulates
TE

the multicast traffic in a PIM register message and unicasts it to the RP (R3).
When the register message arrives, R3 de-encapsulates the message and it forwards the multicast
traffic to interfaces that indicated interest in receiving traffic for group 224.7.7. Traffic starts flowing
toward R5 and flows all the way down to the receiver on R6.
IN

The initial traffic flow from source to receiver is a bit more complicated than a simple source-based
tree. The multicast packets are first encapsulated in register messages sent as unicast, and from the
RP the forwarding is along the *,G shared tree.

52 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode: Source-Based Tree between the RP and the Source DR
N

As soon as the first register message arrives at the RP (R3), the source (192.168.100.10) is now
known. With this information, a source-based tree—also called a shortest-path tree—can be set up
R

between the RP and the source DR. To set up this source-based tree, the RP starts sending S,G join
messages in the direction of the source DR.
TE

When R1 receives the S,G message from R2, it now has a native multicast-enabled path toward the
RP and it can forward multicast traffic toward the RP using this path.
IN

www.juniper.net 53
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode: Register-Stop Message Operation

N

When R1 is forwarding the multicast traffic using the source-based tree toward the RP (R3), it is also
still sending the same multicast traffic in the register messages. In other words, R3 briefly receives
R

the same traffic twice, which is not useful. Once the native multicast source-based tree is delivering
the multicast traffic at R3, it has no need for the register message traffic anymore. It signals to the
TE

source DR to stop sending these register messages using the register-stop message.
R1 stops sending the registering message after receiving the register-stop message. The traffic from
the source (192.168.100.10) will be sent down only the source-based tree toward R3.
Should a new source appear at R1, for example 192.168.100.11, the whole scenario would repeat
IN

itself with first register messages, then the S,G join from R3, and then the register stop message.
Yet another scenario is possible, where the source starts sending before any receivers are active in
the network. In that case, the source DR sends the register message to the RP. The RP checks its
forwarding state for the traffic inside the register message and finds no information for this group.
Because it has no receivers, it has no need for the multicast traffic. It sends a register stop message
to the source to tell it to stop sending register messages for that source and group combination.

54 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode: SPT Switchover: Part 1

N

Traffic from the source arrives through the RP on R6 as discussed in previous slides. The arrival of
the first packet at R6 allows it to learn about the source of the traffic. Once the source is known, a
R

more optimal source-based tree is established by default. R6 sends an S,G join message towards the
source DR to allow traffic to flow along this path.
TE
IN

www.juniper.net 55
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode: SPT Switchover: Part 2

N

When the source-based tree between the source DR (R1) and the receiver DR (R6) is established,
multicast traffic can flow toward the receiver. For a brief moment R6 receives duplicate traffic down
R

the source-based tree through R1, and down the shared tree through R3. This situation is not an
efficient use of bandwidth and therefore must be fixed.
TE
IN

56 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode: STP Switchover: Part 3

N

To stop the traffic coming down the shared tree, the receiver DR (R6) prunes itself from the shared
tree for this specific source. Remember, the shared tree was required to learn about unknown
R

sources but is no longer needed once a source is known.

The receiver DR (R6) starts sending S,G prune messages to its upstream neighbor toward the RP.
TE

Once the RP receives the S,G prunes, it no longer has other receivers for this specific S,G entry in
this scenario. Because the RP no longer has any receivers for source 192.168.100.10 and group
224.7.7.7, it has no need anymore for the source-based tree from the source DR. It will prune itself
from this tree by sending S,G prune messages toward the source DR.
IN

www.juniper.net 57
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode: SPT Switchover: Part 4

N

The result in the scenario on the slide is that the traffic from source 192.168.100.10 is forwarded
down only the source-based tree to R6 and its receiver.
R

The control state in the routers is a bit more complex. On the receiver DR (R6), two entries relate to
group 224.7.7.7:
TE

• S,G state: The S,G state provides information about the requested path for traffic from
the specific source, 192.168.100.10, to the group 224.7.7.7. The upstream state shows
two messages regarding this state. The join-to-source indicates that traffic is requested
on the source-based tree, from R6 up to R1. The prune to RP is sent up the shared tree,
IN

from R6 up to R3, to signal that traffic for this specific source should no longer be sent
down the shared-tree.
• *,G state: The *,G state provides information about the requested path for traffic from
any source to group 224.7.7.7. The upstream state shows the join to RP message that is
sent over the shared tree, from R6 up to R3, to signal that traffic from any source
should be sent down the shared tree. Note that the S,G entry is more specific for source
192.168.100.10, and it overrules the *,G entry for traffic from this specific source.
The state on the RP indicates that it is not interested in receiving traffic from source 192.168.100.10
for group 224.7.7.7 (Prune to source). The RP still has a *.G state for any other sources to group
224.7.7.7, which it forwards in the direction of the receiver DR (R6).

58 www.juniper.net
 Multicast Routing Protocols

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 regard 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 us this
might require additional hardware.

www.juniper.net 59
Multicast Routing Protocols

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

• 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

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

60 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode: Auto-RP Operation

N

Static configured RP information has one major drawback: the convergence time if the RP fails is
very high because it requires manual intervention. To overcome this problem, two dynamic discovery
R

mechanisms were developed.

Auto-RP is the first solution, which uses a proprietary method that can be used with PIM version 1
TE

and version 2. It allows convergence when an RP fails, but it does not allow for automatic load
balancing between RPs that want to serve the same group range. The distribution of the RP
information is typically flooded in the network using dense mode.
The components of auto-RP are:
IN

• Candidate RPs: Each router that wants to act as an RP in the network can announce its
RP candidacy for a group range over group 224.0.1.39 (announce). If there are multiple
routers wanting to become RP for a group range, an election must occur.
• Mapping agent: The auto-RP mapping agent is basically the election commission that
decides which candidate RP wins the election. They listen to the announce address to
learn about candidate RPs. After determining the results of the RP election (highest IP
address), the mapping agent lets all routers know to which RP they can group map. This
information is sent to group 224.0.1.40 (discovery), to which all auto-RP routers listen.
All routers learn about the RP from the mapping agent. In case of an RP failure, the
mapping agent elects a new RP and informs each router about it. The failover time is
not very fast (minutes).

www.juniper.net 61
Multicast Routing Protocols

LY
N
O
SE
U
AL

Electing an RP
N

The slide shows how the mapping agent learns of all the C-RPs, performs the RP election, and then
R

informs all of the routers in the network of the elected RP.

TE
IN

62 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode: BSR Operation

N

When PIM version 2 was developed, it included a new dynamic RP discovery mechanism—the BSR.
The BSR is standardized but only works with PIM version 2. It allows for RP failover but also allows
R

automatic load sharing between candidate RPs for the same group range. For each multicast
address, still only one RP exists, but load sharing is possible on a per-group basis.
TE

BSR uses the following components:

• Candidate RPs: Every candidate RP announces its candidacy to the BSR using unicast
candidate-RP advertisement messages. In the case of multiple candidate RPs, the BSR
performs the election.
IN

• Bootstrap router: The BSR mechanism must first elect the BSR. The BSR is elected
based on the highest BSR priority in the bootstrap message and uses the highest IP
address as the tiebreaker. Once the BSR is known, the candidate RP can start sending
its advertisements. The BSR determines the RP and group mappings and sends this
information to all routers using the bootstrap message, which is forwarded between PIM
neighbors on a hop-by-hop basis. The result of the RP election is called the RP set.

www.juniper.net 63
Multicast Routing Protocols

LY
N
O
SE
U
AL

RP Election Using BSR

N

The slide shows how the BSR learns of all of the C-RPs, generates the C-RP-set BSR message, and
sends the message to all of the routers in the network. A noticeable difference between auto-RP and
R

BSR is that, in BSR, each individual PIM-SM router performs its own elections of RPs.
TE
IN

64 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode: Bootstrap Terminology

N

In the BSR method, the first step is to determine the BSR. Each router assumes it is the BSR until it
receives bootstrap messages with a better priority or from a higher IP address. Only the winner of the
R

BSR election keeps sending the bootstrap message; the other routers forward the BSR’s message to
their neighbors. This way every router ultimately learns the identity of the bootstrap router for the
TE

domain.
Once the BSR is known, the candidate RPs can start sending their candidacy information to it. The
candidate RP sends candidate-RP messages to the BSR as unicast.
The BSR performs an election to select the RP and group mapping information, which is called the
IN

RP set. If two or more candidate RPs are available for the same group range, the BSR can load share
between them. Some groups from the range are assigned to RP1, and other groups from the range
are assigned to RP2. Each group still has only one RP, but between groups, load sharing is now
possible.
The resulting RP set is included in the bootstrap message and is forwarded between PIM neighbors
on a hop-by-hop basis. The result is that all routers learn about the RP and group mapping.

www.juniper.net 65
Multicast Routing Protocols

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.
Therefore, we cover configuration details for each RP discovery mechanism separately.
R

The RP mechanism determines the mode for which the interfaces must be configured:
TE

• Static RP: Sparse mode;

• Auto-RP: Sparse mode or dense mode; or
• BSR: Sparse mode.
IN

Each RP discovery mechanism also has its own RP-specific configuration items:
• 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 must be 2 to allow bootstrap and candidate-RP messages to be
forwarded.

66 www.juniper.net
 Multicast Routing Protocols

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. The slide shows how to add 1-Gigabit per second tunneling capacity
IN

on a 10*1g line card in slot 1, pic 1. Different MX line cards might have different capabilities, so
please 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.

www.juniper.net 67
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode: Static RP Example

N

The slide shows R3 (10.1.1.1) to be the RP for the network. The configuration slide that follows uses
this topology as an example.
R
TE
IN

68 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode: Static RP Configuration

N

For static RP, the RP routers must be configured as follows:

R

• RP candidacy: Enables RP functionality:

set protocols pim rp local 10.1.1.1
TE

• Interface mode sparse:

set protocols pim interface all mode sparse
set protocols pim interface fxp0.0 disable
IN

The non-RP routers must be configured as follows:

• RP static location:
set protocols pim rp static 10.1.1.1
• Interface mode sparse:
set protocols pim interface all mode sparse
set protocols pim interface fxp0.0 disable

www.juniper.net 69
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode Auto-RP Example

N

The slide shows that R3 is both the mapping agent and the RP candidate for the configuration
example shown on the next slide.
R
TE
IN

70 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode: Auto-RP Configuration

N

The slide shows R3 configured as both the mapping agent and the RP candidate. You can split these
functions between two routers. To configure a router to act only as the auto-RP RP candidate, use the
R

set protocols pim rp auto-rp announce command. To configure a router to act only as
the auto-RP mapping agent, use the set protocols pim rp auto-rp mapping command.
TE

The RP and mapping agent router must be configured as follows:

• RP candidacy:
set protocols pim rp local address 10.1.1.1
IN

• Auto-RP mapping agent role: Performs election of RPs:

set protocols pim rp auto rp mapping
• Dense mode flooding for announce/discovery groups
set protocols pim dense-groups 224.0.1.39
set protocols pim dense-groups 224.0.1.40
• Interface mode sparse-dense:
set protocols pim interface all mode sparse-dense
set protocols pim interface fxp0.0 disable
Continued on next page.

www.juniper.net 71
Multicast Routing Protocols
PIM Sparse Mode: Auto-RP Configuration (contd.)
The other routers must be configured as follows:
• Auto-RP discovery role: Listen to election results:
set protocols pim rp auto rp discovery
• Dense mode flooding for announce/discovery groups:
set protocols pim dense-groups 224.0.1.39
set protocols pim dense-groups 224.0.1.40
• Interface mode sparse-dense:
set protocols pim interface all mode sparse-dense

LY
set protocols pim interface fxp0.0 disable

N
O
SE
U
AL
N
R
TE
IN

72 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode: BSR Example

N

The slide shows R3 to be the RP candidate and the bootstrap router.

R
TE
IN

www.juniper.net 73
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode: BSR Configuration

N

The bootstrap and RP router must be configured as follows:

R

• RP candidacy:
set protocols pim rp local address 10.1.1.1
TE

• Bootstrap candidacy: Higher priority value to become bootstrap router:

set protocols pim rp bootstrap priority 200
• Interface mode sparse:
IN

set protocols pim interface all mode sparse

set protocols pim interface fxp0.0. disable
All other routers need only PIM version 2 (default) in sparse mode enabled on the interfaces:
set protocols pim interface all mode sparse
set protocols pim interface fxp0 disable

74 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode: Optional Configuration: Part 1

N

The slide shows the configuration needed to keep traffic on the shared path. By default, traffic
moves to the source-based tree as soon as the first packet arrives and the source is known. Using a
R

policy, allowing traffic to stay on the shared path is possible.

In the example on the slide, the policy called rpt-always-policy allows traffic from source
TE

10.1.1.1/32 to group 224.7.7.7 to 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.
For some multicast applications, it might not be strictly necessary to use a shortest path because
they are not delay sensitive.
IN

www.juniper.net 75
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode: Optional Configuration: Part 2

N

In PIM sparse mode, it is possible to load-balance PIM joins between equal-cost next hops. Without
the command set protocols pim join-load-balance, only one interface is used as the
R

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.
TE

Suppose a source (192.168.100.10) sends traffic to two groups: 224.7.7.7 and 224.8.8.8. 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.7.7.7 and to the upstream router on interface B for
IN

group 224.8.8.8.

76 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode: Optional Configuration: Part 3

N

By default, the join/prune timeout on Junos devices is 210 seconds. The set protocols pim
join-prune-timeout value command allows you to change this timeout value.
R

In multi-access segments, it is not really needed to receive a join message from each individual
downstream router. Upon the receiving of one join message, the multi-access interface must be
TE

added to the outgoing interface list and traffic can be forwarded out of the interface.
Routers on the multi-access segment can monitor the join messages, and if they see at least one
join, they can suppress their own join messages because they would be redundant. This suppression
can limit the amount of signalling toward an upstream router significantly.
IN

To configure join suppression, use the set protocols pim reset-tracking-bit

command, which sets the tracking bit field in the LAN prune-delay option in the PIM hello message,
indicating that join suppression is supported on the interface. Two additional timers are involved:
• propagation-delay: Sets a value in milliseconds for a prune pending timer, which
specifies how long to wait before executing a prune on an upstream router. During this
time, the router waits for any prune override join messages from other routers that are
currently suppressing their joins. The period for the prune pending timer is the sum of
the override interval value and the value specified for the propagation delay.
• override-interval: Sets the maximum time in milliseconds to delay sending
override join messages. In case a prune message is seen on the multi-access segment,
this timer ensures that not all downstream routers react at the same time with a join
message.

www.juniper.net 77
Multicast Routing Protocols

LY
N
O
SE
U
AL

General PIM and Multicast Information

N

Most of the commands discussed with PIM dense mode are also valuable for monitoring PIM
sparse-mode deployments.
R

We look at specific PIM sparse mode details on the following slides.

TE
IN

78 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

Monitoring PIM Sparse Mode: Neighbor Details

N

In PIM sparse mode the output of the show pim neighbors detail command also includes
information about the PIM join messages received from specific neighbors.
R

On the slide, you can see that the neighbor 10.1.70.7 has sent the following joins to the local router:
TE

• *,G:
– *, 225.1.2.3; and
– *, 224.7.7.7;
IN

• S,G:
– 10.0.107.2, 224.7.7.7.

www.juniper.net 79
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Shared Tree: State Details

N

To view the local router’s state, use the show pim join extensive command. On the slide, we
illustrate a *,G entry.
R

The information for a *,G entry shows the following fields:

TE

• Group: 224.7.7.7;
• Source: * (any source);
• RP: 10.1.1.1;
IN

• Flags:
– (S) Sparse: sparse mode is used;
– (R) rptree: shared tree is used; and
– (W) Wildcard: indicates *,G entry;
• Upstream interface: ge-1/1/8.45 (toward RP);
• Upstream neighbor: 10.1.40.4 (toward RP);
• Upstream state: Join to RP (receive traffic on shared path); and
• Downstream neighbors:
– Interface ge-1/0/9.57 (downstream interface); and
– 10.1.70.7 (downstream neighbor) State: join flags: SRW timeout 206.

80 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Source Tree (S,G) State Details After SPT Switchover

N

The slide shows the details of an S,G state entry after issuing the show pim join extensive
command. The example is taken from the router where the source-based tree and the shared tree
R

diverge.
The details of the entry are the following:
TE

• Group: 224.7.7.7.
• Source: 10.0.107.2.
• Flags:
IN

– Sparse; and
– spt.
• Upstream interface: ge-1/1/8.54 (towards source).
• Upstream neighbor: 10.1.50.4 (towards source).
• Upstream state: Join to source, prune to RP.
This shows that the SPT switchover took place on this router. The prune-to-RP state
ensures that traffic from source 10.0.107.2 is delivered over the source-based tree only.
Continued on next page.

www.juniper.net 81
Multicast Routing Protocols
PIM Source Tree (S,G) State Details After SPT Switchover (contd.)
The following list continues the description of the details of an S,G state entry after issuing the show
pim join extensive command:
• Keepalive timeout: 358.
• Downstream neighbors:
– Interface ge-1/0/9.57 (downstream interfaces); and
– 10.1.70.7 State: Join flags: S timeout: 206.

LY
N
O
SE
U
AL
N
R
TE
IN

82 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM Sparse Mode Source Information

N

In PIM sparse mode when issuing the show pim source detail command, you can see two
types of entries. The upper entry on the slide shows the information from a specific source
R

10.0.107.2. The lower entry shows the RP as the source for the traffic on the shared tree.
TE
IN

www.juniper.net 83
Multicast Routing Protocols

LY
N
O
SE
U
AL

PIM multicast Source RPF Results

N

On the previous slide, we showed two sources known by the local router—one for the specific source
and one for the RP. PIM join messages are sent to the upstream router toward the specific source for
R

S,G entries, and towards the RP for the *,G entries.

To check the RPF interface or neighbor for the specific source or RP you can use the show
TE

multicast rpf ip_address command.

On the slide, the upper entry shows the RPF information for the 10.0.107.2 source. The lower entry
shows the RPF information for the RP 10.1.1.1. This information is the same upstream interface
information we saw on the previous slides with *,G and S,G details.
IN

84 www.juniper.net
 Multicast Routing Protocols

LY
N
O
SE
U
AL

Rendezvous Point Details

N

In sparse mode it is essential to learn about the RP for each group. To see the learned RP, use the
show pim rps extensive command.
R

The output shows the following information:

TE

• RP: 10.1.1.1;
• Method learned: Learned from 10.170.5 using bootstrap;
• Time Active: 01:04:51;
IN

• Holdtime: 150 with 99 remaining;

• Device Index: 159;
• Subunit: 32769;
• Interface: pe-1/1/10.32769 (interface providing tunneling capabilities);
• Group Ranges: 224.0.0.4/4, 99s remaining; and
• Active Groups using RP: 224.7.7.7 and 225.1.2.3 (groups with receivers,
sources, or both).

www.juniper.net 85
Multicast Routing Protocols

LY
N
O
SE
U
AL

Multiple RP Discovery Mechanisms Used Simultaneously

N

If multiple RP discovery mechanisms are used at the same time for the same groups, it is possible to
learn RP information multiple times. In such a case, BSR is preferred over auto-RP and, lastly, the
R

static RP information is used. On the slide, the show pim rps output shows that the RP 10.1.1.1 is
learned by all three RP discovery mechanisms.
TE

Bootstrap Router Information

When the BSR is used, all routers must know the BSR before the candidate RPs can advertise their
information to it, and eventually learn the identity of the elected RP. To see which router is elected as
IN

the BSR, use the show pim bootstrap command.

86 www.juniper.net
 <Course Title>
MSDP

LY
N
O
SE
U
AL
N
R
TE
IN
MSDP

LY
N
O
SE
U
AL

Need for MSDP

N

MSDP was developed as part of the current interdomain multicast solution. Service providers were
unhappy with older solutions delivering interdomain multicast traffic. Earlier solutions used shared
R

rendezvous points (RPs) at exchange points. This solution was not flexible enough, though, because
it limited the RP placement within each service provider.
TE

The current interdomain multicast solution is an extension of the intradomain PIM-SM (PIM sparse
mode) model. Thus, each service provider can choose where to place its RPs within its own domain.
Between domains, Border Gateway Protocol (BGP) is used to exchange routing information for the
reverse path forwarding (RPF) check. If the unicast and multicast topologies should be similar, the
IN

RPF check is performed on the basis of the unicast inet.0 table. In cases where there is a need for
different unicast and multicast topology, multiprotocol Border Gateway Protocol (MBGP) can be used
to exchange multicast-specific source address information, and the RPF check can now be
performed on the alternate inet.2 table.
The piece that was missing from the earlier interdomain multicast solution was how the source in
Domain 1 and the receiver in Domain 2 would meet because they of course communicate with
different RPs. The solution to that problem was the Multicast Source Discovery Protocol (MSDP),
which exchanges source information from one RP to other. The MSDP process enables all RPs with
receivers to learn about the sources, and thereby allows sources and receivers to connect.
The result of the current interdomain multicast solution is that sources and receivers learn about
each other and that the receiver’s designated router (DR) will set up a S,G source tree toward each
source for the specific group of receivers.

2 www.juniper.net
 MSDP

LY
N
O
SE
U
AL

Interdomain Multicast Problem

N

When each Internet service provider (ISP) uses its own RP, it creates a problem when using PIM-SM.
If the source of AS65001 sends register messages to its RP, that RP has no knowledge of the
R

receivers in AS65002. The RP in AS65002 will know about its local receivers, but it has no way of
learning about the source in AS65001. So without any help, the source and receiver will never meet,
TE

and traffic will not flow between them.

IN

www.juniper.net 3
MSDP

LY
N
O
SE
U
AL

Interdomain Multicast Solution

N

MSDP solves this problem by exchanging source information between RPs in these different
domains. When the RP in AS65001 learns about the source in its local domain by receiving a register
R

message, it sends source-active messages to its MSDP peers. In this way, the RP in AS65002 learns
about source 192.168.100.10 for group 224.7.7.7 and the source and receiver can connect.
TE

Typically, there are less sources in the network than receivers, which is why the solution is to share
source information and rather than receiver information.
IN

4 www.juniper.net
 MSDP

LY
N
O
SE
U
AL

Communicates Information About Active Sources

N

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.

Configured on PIM-SM RP Routers

MSDP is typically configured on PIM-SM RPs, although it is possible to configure MSDP on non-RP
IN

routers as well. In the interdomain multicast setup, there might also be domains 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. The first part
will go across the source tree between the source and the RP; the second part will go down the
shared tree toward the receiver.
Upon arrival of the first multicast data packet on the receiver’s DR router, the router normally starts
signalling its own source tree back to the source, which is exactly the same behavior as in a single
PIM-SM domain.
Continued on next page.

www.juniper.net 5
MSDP
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.

LY
N
O
SE
U
AL
N
R
TE
IN

6 www.juniper.net
 MSDP

LY
N
O
SE
U
AL

MSDP Peers
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 connnection 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 7
MSDP

LY
N
O
SE
U
AL

MSDP SA Message Format

N

The MSDP SA message format is shown on the slide. The following fields are defined:
R

• Type: For SA messages, the type = 1.

• Length
TE

• Entry count: Count of entries that follow the RP address, which allows multiple sources
to be sent in one SA message. Typically, the entry count = 1.
• RP address: The RP address of the RP with which the source registered.
IN

• Reserved
• Source prefix length: Route prefix length associated with the source (must be /32).
• Group address: Group address to which the active source sent data.
Continued on next page.

8 www.juniper.net
 MSDP
MSDP SA Message Format (contd.)
• Source address: IP address of the active source.
• Encapsulated data (optional): Multicast data packet from the source can be included in
SA message. In the Junos OS, this is default-enabled, but it can be disabled by using the
command set protocols msdp data-encapsulation disable.

LY
N
O
SE
U
AL
N
R
TE
IN

www.juniper.net 9
MSDP

LY
N
O
SE
U
AL

MSDP Between Autonomous Systems: Part 1

N

The example on the slide shows multiple service providers, each with their own independent PIM-SM
domain. Each PIM-SM domain has its own RP, which works for intradomain multicast.
R

To enable interdomain multicast MSDP, sessions are established between the RPs of the different
autonomous systems (ASs).
TE

There is a source 192.168.100.10 for group 224.7.7.7 in AS65012, which registers itself at RP
192.168.1.1. In AS65014, the receiver is using its own separate RP, and the *.G shared tree is
established between the receiver’s DR and the RP.
IN

For the source and receiver to meet, the RP 192.168.1.1 sends SA messages to all its peers, letting
them know about the source and group information. The SA message will have information about the
originating RP (192.168.1.1), the source (192.168.100.10), and the group (224.7.7.7). The MSDP
peers in AS 65011 and AS65013 perform a peer-RPF check on the SA message and, if successful,
forward the message to the other peers. The result is that the RP in AS65014 learns about the active
source 192.168.100.10 for group 224.7.7.7.

10 www.juniper.net
 MSDP

LY
N
O
SE
U
AL

MSDP Between Autonomous Systems: Part 2

N

The RP in AS65014, on arrival of the SA message, checks its local PIM state information to see if any
receivers exist for the 224.7.7.7 group learned in the SA message. As a receiver, DR has set up a
R

*,224.7.7.7 shared tree toward the RP, and the RP starts sending PIM join message
(192.168.100.10, 224.7.7.7) in the direction of the source. This process establishes a source tree
TE

between the RP in AS65014 and the source in AS65012. Once this source tree is established, native
multicast traffic can flow in the direction of the RP in AS65014.
IN

www.juniper.net 11
MSDP

LY
N
O
SE
U
AL

MSDP Between Autonomous Systems: Part 3

N

Multicast traffic arriving over the source tree on the RP in AS65014 is forwarded down the shared
tree toward the receiver. Thus, the initial packet uses a source tree to get to the RP, and the last part
R

of the path is the shared tree from the RP toward the receiver.
Upon arrival of the first packet at the receiver’s DR router, the DR router typically starts its own
TE

source-tree signalling to set up an optimal shortest-path tree. Once the shortest-path tree is
established, native multicast packets flow down the source tree from source 192.168.100.10 toward
the receiver in AS65014.
IN

12 www.juniper.net
 MSDP

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 toward the originating RP carried in the SA
IN

message. The concept is similar to the general multicast RPF check in which traffic is forwarded only
away from the source; with MSDP, SA messages are only forwarded away from the originating RP.
There are multiple peer-RPF rules, as we will see in the next slide.

www.juniper.net 13
MSDP

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. As an example, if the route is learned
IN

through an internal path-vector protocol (i-BGP/RIP), or it is the next hop towards

the originating RP learned through a link-state protocol.
– The advertising MSDP peer belongs to the last AS listed in the BGP route’s path
toward the originating RP; then the SA message is accepted. If there are multiple
peers from that last AS, SA messages from only the one with the highest IP
address will be accepted.
Continued on next page.

14 www.juniper.net
 MSDP
Peer-RPF Rules Are Not Used
Two exceptions exist for when the peer-RPF check is not performed, and the SA messages will always
be accepted. The exceptions are the following:
• SA messages received from an MSDP peer configured in a mesh group.
• SA messages received from the configured default MSDP peer. For stub domains that
need only a single MSDP peer, it is essential that all of the received SA messages are
accepted.

LY
N
O
SE
U
AL
N
R
TE
IN

www.juniper.net 15
MSDP

LY
N
O
SE
U
AL

MSDP Mesh Groups

N

With highly meshed MSDP peerings, it might not be useful to forward SA message to all peers
because this process results in inefficient use of resources. If peers are fully meshed with MSDP,
R

received SA messages from mesh members do not need to be forwarded to other members of the
mesh because they have already received them from the originating member.
TE

MSDP mesh groups are often used, especially for intradomain multicast, because SA messages from
members are implicitly accepted and, therefore, avoid the complicated peer-RPF check.
The flooding rules for mesh groups are as follows:
IN

• SA messages received from members of a configured mesh group are not forwarded to
other members of that mesh group. The messages are accepted and flooded to all
other peers that are not members of that mesh group.
• SA messages received from peers that are not configured in a mesh group are subject
to the normal RPF-peer rules. If SA messages passes the check, it is flooded to all other
peers (mesh group members and other peers).

16 www.juniper.net
 MSDP

LY
N
O
SE
U
AL

MSDP Mesh Group Operation: Part 1

N

The example in the slide shows the forwarding of SA messages that are received from a member of a
configured mesh group. In this case, an SA message is received from a router from the configured
R

MSDP mesh group AS65001. The message is accepted and forwarded only to peers that do not
belong to the mesh group AS65001. It is forwarded to peers not in any mesh group, but also to peers
TE

in a different mesh group (65002).

IN

www.juniper.net 17
MSDP

LY
N
O
SE
U
AL

MSDP Mesh Group Operation: Part 2

N

This slide shows the forwarding of SA messages received from peers not belonging to a mesh group.
The SA message is received from a peer that does not belong to a mesh group. Thus, the normal
R

peer-RPF rules apply, and if successful, the message will be forwarded to all peers except the peer
from which the message was received.
TE
IN

18 www.juniper.net
 MSDP

LY
N
O
SE
U
AL

MSDP Example
N

The slide above shows the topology that is used in the configuration and monitoring slides.
R
TE
IN

www.juniper.net 19
MSDP

LY
N
O
SE
U
AL

MSDP Configuration
N

The configuration on the slide shows the basic MSDP configurations.

R

MSDP neighbors can be configured directly or through peer groups. If mesh-group functionality is
required, the peers must be configured using peer groups. The source address for the session can
be hard-coded using the local-address command.
TE

On router R4, the default-peer command is used to ensure that all SA messages are accepted
from this peer.
IN

20 www.juniper.net
 MSDP

LY
N
O
SE
U
AL

Monitoring MSDP Sessions

N

The show msdp command shows information about the configured peers, the local address used,
the state, the peer-group name, and the SA messages received and accepted. To see more details,
R

you can look at peers in detail.

TE
IN

www.juniper.net 21
MSDP

LY
N
O
SE
U
AL

MSDP SA Cache
N

You can view the SA cache on the MSDP router by using the show msdp source-active
command. The Flags field displays whether the SA message was accepted, rejected, or filtered.
R

Another way to look at the SA cache is by looking at table inet.4.

TE
IN

22 www.juniper.net
 MSDP

LY
N
O
SE
U
AL

MSDP Statistics
N

The show msdp statistics command shows you information about MSDP SA messaging, peer
sessions, and RPF-peer failures.
R
TE
IN

www.juniper.net 23
MSDP

LY
N
O
SE
U
AL

MSDP Traceoptions
N

To troubleshoot MSDP issues, you can enable traceoptions under the [edit protocols msdp]
hierarchy. By monitoring the file, you can look at detailed protocol exchanges.
R

The example in the slide shows an MSDP session being established and an SA message being
accepted.
TE
IN

24 www.juniper.net
 MSDP

LY
N
O
SE
U
AL

Single RP for Each Multicast Group

N

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

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 balancing in case of
high volume groups.
TE

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.
The concept of anycast, in general, is to have multiple devices performing the exact same role in the
IN

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)
has converged, the clients can connect to the (new) nearest anycast device.
Anycast-RP allows for multiple RPs in the network that share the unicast address that every router
associates with the RP role. Each local DR 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 now have redundant RPs per group, and that in
case of failures, the convergence time is much lower.

www.juniper.net 25
MSDP

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 anycast-PIM 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 there is no need for MSDP in a IPv4 environment (no interdomain multicast).

26 www.juniper.net
 MSDP

LY
N
O
SE
U
AL

Anycast-RP Example
N

The slide shows three RPs inside a PIM-SM domain. The anycast-RP address is 10.100.254.1 and is
shared by all RPs. Each RP also has its own unique address; otherwise, other routing functions would
R

not work correctly (because of duplicate router IDs).

TE
IN

www.juniper.net 27
MSDP

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 keyword can added to the address. Another way 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 using
TE

the set routing-options router-id command.

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

second address is 10.100.254.1/32.

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 bootstrap router (BSR)—but typically, static RP is
used. Static RP is simple, and, with the addition of anycast-RP, is now also redundant.

28 www.juniper.net
 MSDP

LY
N
O
SE
U
AL

Anycast-RP with MSDP Configuration

N

The slide shows the configuration of one of the RPs.

R

Three steps are needed to configuring anycast-RP on the RPs:

1. Configure the IP addresses on the loopback interface (both the unique address,
TE

10.100.1.1, and the anycast address, 10.100.254.1).

2. Configure the local RP candidacy. This configuration is performed with the set
protocols pim rp local command.
3. Enable MSDP mesh group peering with the other anycast-RP routers.
IN

www.juniper.net 29
MSDP

LY
N
O
SE
U
AL

Anycast-RP with Anycast-PIM Configuration

N

The slide shows the configuration of one of the RPs.

R

Three steps are needed to configuring anycast-RP on the RPs:

1. Configure the IP addresses on the loopback interface (both the unique address,
TE

10.100.1.1, and the anycast address, 10.100.254.1).

2. Configure the local RP candidacy. This configuration is performed with the set
protocols pim rp local command.
3. Enable anycast-PIM between the other anycast-RP routers. This enabling is performed
IN

with the set protocols pim rp anycast-pim rp-set command.

30 www.juniper.net
 <Course Title> Multicast
Source-Specific

LY
N
O
SE
U
AL
N
R
TE
IN
Source-Specific Multicast

LY
N
O
SE
U
AL

Source Discovery is Function of the Network

N

In ASM the network is responsible for source discovery so that multicast traffic can be forwarded
between source and receiver.
R

In Protocol Independent Multicast dense mode (PIM-DM) the receiver routers learn about the source
through the flooding mechanism. This process is a simple way of learning sources, but it results in an
TE

increase of S,G state information in the control plane of all routers. Because of this increase, the
scalability of dense-mode deployments is limited.
In PIM-SM each source registers itself at the rendezvous point (RP) router. From the RP router the
traffic is forwarded to the receiver router using the shared tree. After the receiver-designated router
IN

(DR) learns about the source, it establishes a source-based tree for optimal performance. Source
discovery in sparse mode adds complexity, but it improves the scalability because not all routers
must keep state for all flows.
For interdomain multicast routing, the Multicast Source Discovery Protocol (MSDP) peers exchange
information about sources between different domains. This exchange results in source-based trees
across domains. MSDP adds another layer of complexity to the network because you must ensure
that both PIM-SM and MSDP operations are functioning properly.
Continued on next page.

2 www.juniper.net
 Source-Specific Multicast
Multicast Application Support
ASM supports both types of multicast applications:
• Many to many; and
• One to many.

Address Allocation
In ASM deployments, the group address must be unique, which makes allocation of addresses more
complex. For this reason, multiple solutions for address allocation have been developed, each with
its own reserved ranges—Session Description Protocol (SDP)/Session Announcement Protocol (SAP),
GLOP, and Admin scoped.

LY
N
O
SE
U
AL
N
R
TE
IN

www.juniper.net 3
Source-Specific Multicast

LY
N
O
SE
U
AL

Source Discovery Becomes the Application Function

N

SSM, which is defined in RFC 4607, moves the source discovery function out of the network, and
makes it an application issue. Through an out-of-band method such as a URL from a website, the
R

receiver learns about the source address for a specific group address. The receiver signals the router
its interest in a multicast channel (source and group) using IGMPv3.
TE

Subset of PIM-SM Functionality

Upon receiving an IGMP subscribe message for a multicast channel, the router sends PIM (S,G) joins
directly toward the source. This step eliminates the complexity of involving the RP and setting up
IN

shared trees before switching over to the source-based tree. It also make interdomain multicast
simpler because MSDP is no longer needed.

Multicast Application Support

SSM was developed to support mostly one-to-many applications. These radio and television types of
applications, in which a single source sends traffic to many receivers, are the most viable
applications for interdomain deployment.
Continued on next page.

4 www.juniper.net
 Source-Specific Multicast
Address Allocation
One significant advantage of SSM is that the unique addressing entity is no longer just the group
address. Instead, it is a combination of source address and group address. As a result, the same
group address can be reused by anyone in the Internet as long as the source address is different.
This address reuse makes address allocation relatively simple, and only one small range has been
reserved for SSM applications (232.0.0.0/8). An added benefit of SSM is that denial-of-service (DoS)
attacks are also harder to perform because channels are source specific, whereas groups allow any
source traffic.

LY
N
O
SE
U
AL
N
R
TE
IN

www.juniper.net 5
Source-Specific Multicast

LY
N
O
SE
U
AL

ASM Versus SSM Terminology

N

The table on the slide shows the new SSM terminology, which was developed so that SSM and ASM
operations can be easily differentiated. The actual protocol messages (with the exception of IGMP)
R

are actually not that different.

TE
IN

6 www.juniper.net
 Source-Specific Multicast

LY
N
O
SE
U
AL

SSM Operation
N

The example on the slide shows the simplified operation of SSM. The basic steps of SSM operation
are as follows:
R

1. The receiver learns about source and group through an out-of-band method, such as a
website.
TE

2. The receiver subscribes to a channel (192.168.100.10, 232.7.7.7) using an IGMPv3

membership report (Include mode).
3. The DR on the receiver segment starts building a source-based tree by issuing a PIM
IN

(S,G) join message (192.168.100.10, 232.7.7.7).

4. Once PIM (S,G) joins reaches the source segment DR, the traffic from the source can
flow down the shortest-path tree (SPT) toward the receiver.

www.juniper.net 7
Source-Specific Multicast

LY
N
O
SE
U
AL

Multicast Addresses for ASM and SSM

N

The 224.0.0.0/4 range was originally assigned for ASM use. When SSM was introduced, the
232.0.0.0/8 range was reserved for SSM use only. Thus, ASM-specific operations are no longer
R

allowed for addresses in the SSM range. SSM operations do not support any messaging related to
shared trees (*,G).
TE

Junos OS Software Options

By default, the 232/8 is the only range reserved for SSM operation in Junos operating system. This
default behavior can be changed in two ways:
IN

• Add address ranges for SSM-only operations in addition to the default 232/8 range:
set routing-options multicast ssm-groups 227.0.0.0/24
• Allow ASM use in SSM ranges. This step allows both ASM and SSM operations in the
dedicated SSM ranges:
set routing-options multicast asm-override-ssm

8 www.juniper.net
 Source-Specific Multicast

LY
N
O
SE
U
AL

IGMP Protocol Versions

N

Three versions of IGMP exist; we discuss version 3 in detail on the next slides. A breakdown of the
IGMP versions used in each mode follows:
R

• ASM receivers: IGMP v1/v2 and IGMPv3 in exclude mode.

TE

For ASM groups, the IGMP joins do not specify a single source, but rather specify any
source. IGMPv3 provides the option to specify any source except certain specific
sources (exclude mode).
• SSM receivers: IGMPv3 in Include mode.
IN

For SSM channels, the IGMP subscription must specify both the source address and the
group address. Only IGMPv3 in include mode can provide this functionality.

IGMPv3
IGMPv3 adds new filtering options in the membership reports:
• Include mode: This mode allows IGMPv3 to specify a particular source for a group,
thereby creating a channel subscription. This mode enables SSM operations.
• Exclude mode: This mode allows IGMPv3 to exclude certain sources from the join
message for any source for a group, which allows IGMPv3 to support ASM mode.

www.juniper.net 9
Source-Specific Multicast

LY
N
O
SE
U
AL

IGMPv3 Receiver Operations

N

Receivers send version 3 membership reports to signal their interest in receiving traffic from a group
(ASM) or from a channel (SSM). All membership reports are sent to the IGMPv3-specific multicast
R

address of 224.0.0.22, which makes IGMPv3 snooping simpler for Layer 2 switches because they
must listen only to this address.
TE

IGMPv3 membership reports contain group record types that indicate which kind of operation is
involves. The three main type of records are the following:
• Current-state records: Sent in response to a v3 membership query;
IN

– Type 1: MODE_IS_INCLUDE; and

– Type 2: MODE_IS_EXCLUDE;
• Filter-mode-change records: Sent when change in filter mode occurs;
– Type 3: CHANGE_TO_INCLUDE_MODE; and
– Type 4: CHANGE_TO_EXCLUDE_MODE;
• Source-list-change records: Sent when subscribing or unsubscribing to a channel;
– Type 5: ALLOW_NEW_SOURCES; and
– Type 6: BLOCK_OLD_SOURCES.
Continued on next page.

10 www.juniper.net
 Source-Specific Multicast
IGMPv3 Receiver Operations (contd.)
For the SSM model only three operations are relevant:
• Subscribe: Uses ALLOW_NEW_SOURCES record type;
• Maintain subscription: Uses MODE_IS_INCLUDE record type; and
• Unsubscribe: Uses BLOCK_OLD_SOURCES record type.

LY
N
O
SE
U
AL
N
R
TE
IN

www.juniper.net 11
Source-Specific Multicast

LY
N
O
SE
U
AL

IGMPv3 Membership Report Format

N

The slide shows the IGMPv3 membership report message format. It contains the following fields.
R

• Type: 0x22;
• Reserved (two fields): All zeroes;
TE

• Checksum: Standard IP checksum for the whole IGMP message;

• Number of group records: Number of group records present in the report; and
• Group record: Block of fields with information for a single group’s membership
IN

information.

12 www.juniper.net
 Source-Specific Multicast

LY
N
O
SE
U
AL

IGMPv3 Membership Report Group Record Format

N

The slide shows the IGMPv3 membership report group record field format. It contains the following
fields:
R

• Record type:
TE

Current-state records: send to response of a v3 membership query;

– Type 1: MODE_IS_INCLUDE; and
– Type 2: MODE_IS_EXCLUDE;
IN

Filter-mode-change records: sent when change in filter mode occurs;

– Type 3: CHANGE_TO_INCLUDE_MODE; and
– Type 4: CHANGE_TO_EXCLUDE_MODE;
Source-list-change records: Sent when subscribing or unsubscribing to a channel;
– Type 5: ALLOW_NEW_SOURCES; and
– Type 6: BLOCK_OLD_SOURCES.
Continued on next page.

www.juniper.net 13
Source-Specific Multicast
IGMPv3 Membership Report Group Record Format (contd.)
• Aux data length: Length of auxiliary data;
• Number of sources: How many source address for this group;
• Multicast address: Group address;
• Source address: Source address; and
• Auxiliary data: Data is ignored except for checksum calculation.

LY
N
O
SE
U
AL
N
R
TE
IN

14 www.juniper.net
 Source-Specific Multicast

LY
N
O
SE
U
AL

IGMPv3 Membership Query Format

N

The slide shows the IGMPv3 membership query format. It contains the following fields:
R

• Type: 0x11.
• Max Resp Code: Maximum time allowed before sending a responding report.
TE

• Checksum: Standard IP checksum for the whole IGMP message.

• Group address:
– General query: 0.0.0.0; and
IN

– Group-specific query and group-source-specific query: Group address.

• Resv: All zeroes.
• S: Suppresses router-side processing, indicates to routers to suppress the normal timer
update upon hearing a query. Does not suppress querier election nor the
host-processing of queries.
• QRV: Querier’s robustness variable.
• QQIC: Querier’s query interval code.
• Number of sources: number of sources.
• Source address: Source addresses.
Continued on next page.

www.juniper.net 15
Source-Specific Multicast
IGMPv3 Membership Query Format (contd.)
Three types of membership queries exist:
• General query: Sent to 224.0.0.1 to learn any IGMP receiver state on interface;
• Group-specific query: Sent to group address to learn state information for that group;
and
• Group-source-specific query: Sent to group address to learn state information for
group/source combination.

LY
N
O
SE
U
AL
N
R
TE
IN

16 www.juniper.net
 Source-Specific Multicast

LY
N
O
SE
U
AL

PIM-SM and SSM

N

SSM is a simplified form of PIM sparse mode, and therefore uses only a subset of its features.
Ranges reserved for SSM operations (the default is 232/8) do not support any shared-tree
R

messaging; only source-based tree messaging is allowed.

In SSM ranges, the following actions should be taken:
TE

• Receiver segment DR:

– Ignore any IGMP joins for *,G; and
– Must not send PIM *,G joins to upstream routers;
IN

• Source segment DR:

– Must not send register message to RP when source traffic is received;
• RP router:
– Ignore register messages from source DRs; and
– Ignore MSDP source-active messages from MSDP peers;
• Other routers:
– Ignore PIM *,G joins from downstream routers.
Continued on next page.

www.juniper.net 17
Source-Specific Multicast
PIM-SM and SSM (contd.)
Deploying PIM-SM in the network allows for concurrent use of ASM and SSM. Depending on the
receiver messaging and configured SSM ranges, the DR router either sets up a shared tree toward
the RP for ASM mode or directly starts with a source-based tree for SSM mode. As mentioned
previously, the Junos OS even allows you to mix ASM and SSM within the reserved SSM ranges.

LY
N
O
SE
U
AL
N
R
TE
IN

18 www.juniper.net
 Source-Specific Multicast

LY
N
O
SE
U
AL

SSM Basic Configuration Steps

N

Because SSM uses a subset of PIM-SM functionality, it is not surprising that the configuration and
monitoring of SSM are so similar to normal PIM-SM. In the following slides we look only at the
R

SSM-specific options.
The main requirement for standard SSM deployment is to enable the receiver-side interface on all
TE

routers for IGMPv3. When IGMPv3 is configured, it allows backward compatibility with IGMP v1/v2
hosts on a per-group basis. Thus, for ASM hosts, IGMP v1/v2 can still be used as long as the hosts
do not join 232/8 groups. SSM hosts must signal IGMPv3 membership reports in the 232/8 range.
Router configuration in the network is determined by the requirements of a specific network:
IN

• ASM and SSM must both be supported in the network: In this case, you should follow
the normal PIM-SM configuration guidelines, depending on which RP discovery
mechanism should be used (static RP, Auto-RP, BSR).
• SSM-only support is required in the network: In this case the PIM-SM configuration
becomes very easy because the only requirement is that all interfaces are configured
for sparse mode.

www.juniper.net 19
Source-Specific Multicast

LY
N
O
SE
U
AL

SSM Optional Configuration: Part 1

N

The slide shows the Junos OS options to overrule the standard SSM protocol behavior. It allows you
to add other ranges for SSM only use, which allows you to add new ranges in case the SSM range
R

changes in the future. The Junos OS also allows you to mix both ASM and SSM operations in the SSM
ranges.
TE
IN

20 www.juniper.net
 Source-Specific Multicast

LY
N
O
SE
U
AL

SSM Optional Configuration: Part 2

N

As discussed, IGMPv3 is required for standard SSM deployment. Most operating systems now
support IGMPv3 client software. If hosts do not yet support IGMPv3, you can still let them operate in
R

SSM mode. The SSM mapping function allows IGMP v1/v2 joins to be converted into an IGMPv3
subscription.
TE

The slide shows the steps required to enable SSM mapping:

1. Configure a policy (on the slide, the policy name is ssm-mapping-policy) to select
the allowed group range for SSM mapping.
IN

2. Configure the SSM map (on the slide, the SSM map is named test). The SSM map
combines the group information from the policy with one or more sources to form the
channel information.
3. Apply the SSM map on the interfaces where the IGMP v1/v2 hosts are operating.

www.juniper.net 21
Source-Specific Multicast

LY
N
O
SE
U
AL

SSM Example
N

The slide shows SSM operation. We examine R6 in the following slides to see SSM-specific output.
R
TE
IN

22 www.juniper.net
 Source-Specific Multicast

LY
N
O
SE
U
AL

Monitoring IGMPv3 Information

N

Using the show igmp interface and show igmp group commands, you can verify whether
the interface toward the receiver on R6 is in IGMPv3 mode, and if any IGMPv3 membership reports
R

for group mode Include have been learned.

TE
IN

www.juniper.net 23
Source-Specific Multicast

LY
N
O
SE
U
AL

Monitoring S,G State Information

N

Because SSM supports only S,G information, you should expect only S,G entries for groups in the
SSM range. Using the show pim join extensive command, you can see that R6 has only an
R

S,G entry for channel 192.168.100.10, 232.7.7.7.

TE
IN

24 www.juniper.net
 <Course Title>
Multicast and Policy

LY
N
O
SE
U
AL
N
R
TE
IN
Multicast and Policy

LY
N
O
SE
U
AL

Multicast and Policy Overview: Part 1

N

The following signaling steps can take place in a PIM-SM network:

R

• Receiver signals interest in receiving traffic from a group or channel by sending IGMP
membership reports (join) to its local designated router (DR);
TE

• Receiver’s DR translates the IGMP join into the appropriate PIM join message to the
upstream router:
– *,G join: Sent toward the upstream router in the direction of the rendezvous
point (RP); and
IN

– S,G join: Sent toward the upstream router in the direction of the actual source;
• The source DR registers source traffic by means of a register message to the RP;
Continued on next page.

2 www.juniper.net
 Multicast and Policy
Multicast and Policy Overview: Part 1 (contd.)
• PIM-SM routers in any-source multicast (ASM) mode must learn about the RP for each
group:
– Static RP: No messaging involved;
– Auto-RP: Flooding of announce (224.0.1.39) and discovery (224.0.1.40) group
traffic in dense mode; and
– Bootstrap router (BSR): candidate-RPs send their advertisements through
unicast to the elected BSR; it sends the RP results to all other routers using PIM
v2 bootstrap messages; and
• For interdomain or anycast-RP deployments, the source information is exchanged
between MSDP peers using source-active messages.

LY
N
O
SE
U
AL
N
R
TE
IN

www.juniper.net 3
Multicast and Policy

LY
N
O
SE
U
AL

Multicast and Policy Overview: Part 2

N

By default, all PIM-SM messages are accepted as long as they pass some reverse path forwarding
(RPF) check, which leaves PIM-SM vulnerable to control-plane attacks or at least inefficient use of
R

network resources.
By controlling the PIM-SM message flow using policies, you can customize multicast operations to
TE

your specific requirements. This customization involves limiting control-plane operations but also
blocking the actual forwarding of multicast data traffic.
By fine-tuning your multicast deployments using mostly policy-based control tools, you can ensure
the following:
IN

• Efficient use of bandwidth: Using multicast scoping, you can limit traffic to certain parts
of your network.
• Prevention of multicast network problems: Using PIM filtering you can limit what
sources are allowed and which groups receivers can join, both of which can limit the
amount of state needed in the network. Using BSR filtering, you can prevent incorrect
BSR messages coming into parts of your domain, which otherwise could result in RP
issues.
• Prevention of multicast-based denial of service (DoS) attacks: Using PIM filtering and
MSDP source-active (SA) filtering, you can limit the amount of sources that can be
learned in the network. (Recall that in ASM mode, each source is allowed to send to a
group, which makes this model especially vulnerable to attack by malicious sources.)

4 www.juniper.net
 Multicast and Policy

LY
N
O
SE
U
AL

Controlling IGMP Joins

N

The PIM-SM operation from the receiver side starts with the IGMP membership reports sent between
the receiver and its local DR. If you want to limit to which multicast traffic your users have access,
R

this method is efficient because it prevents any other signaling from occurring.
Two options exist to limit the receiver to subscribe to multicast groups:
TE

• IGMP policy filtering: For both IGMPv2 and IGMPv3 you can block membership reports
at the interface level by using policies. The router compares the group against the
specified group policy and performs the action configured in the policy.
IN

The policy for matches on group addresses for IGMPv2, and for source and group
addresses for IGMPv3:
– Group address: route-filter statement; and
– Source address: source-address-filter (must /32 exact).
Continued on next page.

www.juniper.net 5
Multicast and Policy
Controlling IGMP Joins (contd.)
• IGMP group limit feature: Allows you to put a limit on the number of groups for each
logical interface; joins above the limit are rejected. When configuring IGMP group limits,
keep the following in mind:
– Each join counts as one group. Thus, a *,G and an S,G for the same group count
as two toward the limit.
– Each source is counted individually toward limit. Therefore, S1,G and S2,G are
again counted as two toward the limit.
– If you commit a limit that is lower than the number of groups already learned, the
result is the removal of all groups. The groups must then request to rejoin until
the limit is reached.

LY
N
O
SE
U
AL
N
R
TE
IN

6 www.juniper.net
 Multicast and Policy

LY
N
O
SE
U
AL

Controlling PIM-SM
N

There are multiple policy options to control the main PIM-SM messages, which allows for very
granular control over the multicast state in the network.
R

The following control options are available:

TE

• PIM neighbors: Using a policy, you can filter unwanted PIM neighbors from your
network.
• PIM join/prune messages:
– Incoming policies allow you to reject join/prune messages from downstream
IN

routers.
– Outgoing policies allow you to block join/prune messages toward upstream
routers.
• PIM register messages:
– From the source DR, you can prevent register messages from being sent toward
the RP. This action does not have an effect on SSM groups because they do not
need the RP to learn about the source.
– On the receiving RP, the source register messages can be rejected.
To monitor the PIM filtering options, you can look at the details of the PIM statistics. For join/prune
filtering, you can also look at PIM state at the specific routers.

www.juniper.net 7
Multicast and Policy

LY
N
O
SE
U
AL

PIM-SM Neighbor Policy

N

The slide shows the application of a PIM-SM neighbor policy to block unwanted routers from
becoming a PIM neighbor. This policy provides a very basic control to influence the routers with which
R

you want to exchange multicast. Remember that only interfaces with PIM neighbors can be used as
the incoming interface for RPF checks.
TE

The address in the policy is compared with received neighbor IP address. If the address matches the
policy address, the hello packet is dropped. If the neighbor was already established before the policy
was applied, the adjacency remains up until the holdtime expires.
The policy checks for the source address of the PIM hello using the route-filter statement;
IN

alternatively, a prefix list can be used if multiple neighbors must be verified. Use /32 for matching.

8 www.juniper.net
 Multicast and Policy

LY
N
O
SE
U
AL

PIM Join/Prune Import Policy

N

The slide shows an example of using an import policy to block PIM join/prune messages from being
accepted by router R2.
R

PIM join/prune import policies use four main criteria to control the receipt of join/prune messages:
TE

• neighbor: The source IP address of the received PIM message. Because these
messages are transmitted host to host, this address is the physical link address of the
neighbor.
• interface: The incoming logical interface on which the PIM message was received.
IN

• route-filter: The address specified attempts to match the multicast group

supplied in the join/prune message.
• source-route-filter: The address specified for attempts to match the address
of the multicast source. If the join/prune message is for *,G state on the shared tree,
the address of the RP is used.
Use the show pim statistics command to verify that the PIM import policy works. The
Rx Joins/Prunes filtered field counter should increase.

www.juniper.net 9
Multicast and Policy

LY
N
O
SE
U
AL

PIM Join/Prune Export Policy

N

The slide shows an example of using an export policy to prevent R1 from sending PIM join/prune
messages toward R2.
R

PIM join/prune import policies use four main criteria to control the receipt of join/prune messages:
TE

• neighbor: The destination IP address of the PIM message. Because these messages
are transmitted host to host, this address is the physical link address of the neighbor.
• interface: The outgoing logical interface from which the PIM message will be sent.
• route-filter: The address specified for attempts to match the multicast group
IN

supplied in the join/prune message.

• source-route-filter: The address specified attempts to match the address of
the multicast source. If the join/prune message is for the *,G state on the shared tree,
the address of the RP is used.

Use the show pim statistics command to verify that the PIM export policy works. The
Tx Joins/Prunes filtered field counter should increase.

10 www.juniper.net
 Multicast and Policy

LY
N
O
SE
U
AL

PIM Register Policy at Source DR

N

The slide shows how to use a policy to control the sending of register messages at the source DR. It
prevents the source DR to send register messages when it receives multicast traffic from the source
R

192.168.100.10 for group 224.7.7.7 The result is that receivers in ASM mode are not able to receive
traffic, but if SSM mode is used, traffic can arrive at the receivers.
TE

Use the show pim statistics command to verify that the dr-register-policy works. The
Tx Register msgs filtering drop field counter should increase.
IN

www.juniper.net 11
Multicast and Policy

LY
N
O
SE
U
AL

PIM Register Policy at RP

N

The slide shows how to use a policy to block the reception of register messages at the RP. It prevents
the RP to accept register messages from the source DR. Once again, the result is that receivers in
R

ASM mode are not able to receive traffic. However, if SSM mode is used, traffic can arrive at the
receivers.
TE

Use the show pim statistics command to verify that the rp-register-policy works. The
Rx Register msgs filtering drop field counter should increase.
IN

12 www.juniper.net
 Multicast and Policy

LY
N
O
SE
U
AL

PIM-SM BRS Import / Export Policy

N

The slide shows how policies can control the incoming or outgoing BSR messages. The BSR message
is essential in the distribution of the RP information in the network if the BSR mechanism is used for
R

RP discovery. The example shows two BSR domains that share multicast across them. The filtering of
BSR messages can ensure that routers in Domain A will not accidentally use the RP information from
TE

Domain B.
Use the show pim statistics interface command to confirm that the BSR messages have
been sent on a border interface between the domains. Check the V2 Bootstrap counter field to
confirm this.
IN

Another way of ensuring that BSR messages cannot leave your domain is to configure PIM version 1
on your boundary interfaces. Because BSR requires PIM v2, these messages cannot be sent over
PIM v1 interfaces.

www.juniper.net 13
Multicast and Policy

LY
N
O
SE
U
AL

Controlling MSDP
N

Three options are available for controlling MSDP source-active messages between peers:
R

• MSDP source-active import policies: Limit messages received from peers;

• MSDP source-active export policies: Limit messages sent to peers; and
TE

• MSDP source-active limits: Limits total number of sources that can be learned:
– Default limit is 25000 SA, can be changed from 1 to 1,000,000.
– Active-source-limit at global, group and peer level.
IN

If multiple levels are configured, all are applied. You must specify the maximum
level and threshold when the random early detection (RED) profile starts
discarding some messages.
– Active-source-limit for source address range:
source 10.1.0.0/16 active-source-limit maximum 500
Per-source limits are tested first, then per-peer or per-group, and per-instance is
last. If any of the limits is reached, the matching SA is rejected. Therefore, if you
configure a 10,000 per-source limit but only 100 for the instance, it results in
only 100 SA messages being allowed from all sources.

14 www.juniper.net
 Multicast and Policy

LY
N
O
SE
U
AL

MSDP Source-Active Import Policy

N

The slide shows how you can use a policy to manage the incoming SA messages from a peer, which
allows you granular control over the specific source information learned in your multicast domain.
R

Messages that are rejected on import appear in the output of the show msdp source-active
detail command with the Filtered flag.
TE

The MSDP import policy uses the following criteria on which to match incoming SA messages:
• neighbor: The source IP address of the received MSDP message, this address is the
address of the remote peer;
IN

• interface: The incoming interface where the MSDP message are received;
• route-filter: The address specified matches the multicast group supplied in the
SA message; and
• source-route-filter: The address specified attempts to match the address of
the multicast source.
When you apply an MSDP import policy, only explicitly allowed SA messages are accepted. An
example is shown in the policy on the slide, where a second term is used with the accept action.

www.juniper.net 15
Multicast and Policy

LY
N
O
SE
U
AL

MSDP Source-Active Export Policy

N

The other option to control MSDP SA messages is shown in the slide. Here, RP2 controls the sending
of messages to its peer. This method ensures that source information that should stay local to your
R

domain does not leak to outside peers. On the receiving side you could verify that you do not receive
any SA messages by using the show msdp source-active detail command.
TE

The criteria for selecting SA messages for the export policy are the following:
• route-filter: The address specified matches the multicast group supplied in the
SA message; and
IN

• source-route-filter: The address specified attempts to match the address of

the multicast source.
When you apply an MSDP export policy, only explicitly allowed SA messages are allowed to be sent
out. An example is shown in the policy on the slide, where second term is used with the accept
action.

16 www.juniper.net
 Multicast and Policy

LY
N
O
SE
U
AL

Multicast Scoping Overview

N

The previous part of this material covered options for manipulating most of the PIM-SM control
plane.
R

A question remains: How we can control the actual multicast data traffic? The solution for blocking
actual traffic across links is defined in RFC 2365 and is called administrative scoping. Unlike the
TE

complex old method of using the TTL values of multicast data traffic as the basis for blocking traffic
across boundary interfaces, administrative scoping uses the actual group address on which to
match traffic. If the group is rejected it blocks the traffic to this group address but it also influences
the control plane for this group. In PIM-DM the interface is pruned for the blocked groups, for PIM-SM
IN

joins for the groups on that interface will be rejected.

Administrative scoping can be used within your own domain to prevent traffic leaking between
distinct regions of your network. Naturally, it is also useful to limit traffic between different domains.
In both cases the network admin must determine the boundary interfaces.
Two methods in the Junos OS exist to implement scoping:
• Named scopes: Simple but not flexible; and
• Scope policies: Flexible configuration options.

www.juniper.net 17
Multicast and Policy

LY
N
O
SE
U
AL

Well-Known Administrative Scopes

N

The following scopes are defined in RFC 2365:

R

• Site-local scope: 239.255.0.0/16.

The site-local scope represents the minimal scope size and cannot be further divided.
TE

Although the exact extent of a local scope is dependent on the site, locally scoped
regions must not span any other scope boundary. This scope is created and applied
automatically to any interface that has a manual scope configured.
• Organization-local scope: 239.192.0.0/14.
IN

The organizational-local scope can be used to allocate sub-ranges within this range for
private use within the network.
• Unassigned available ranges:
– 239.0.0.0/10;
– 239.64.0.0/10; and
– 239.128.0.0/10.
The unassigned ranges are currently unassigned and are available for future expansion
of the scoped space.
Continued on next page.

18 www.juniper.net
 Multicast and Policy
Well-Known Administrative Scopes (contd.)
• Link-local scope: 224.0.0.0/24.
The link-local scope limits traffic to the local link. Protocols such as OSPF, RIP, and PIM
use this address space to send control traffic between routers.

LY
N
O
SE
U
AL
N
R
TE
IN

www.juniper.net 19
Multicast and Policy

LY
N
O
SE
U
AL

Named Scoping Example

N

The slide shows how to configure named scopes. Each group range needs its own named scope,
although multiple interfaces can be assigned within a scope. This requirement limits the flexibility of
R

named scopes because you might need to configure lots of named scopes in a bigger network.
You can view the result of the named scopes in the output of the show multicast scope
TE

command. Note that the 239.255.0.0/16 is automatically added.

The example shows how to control auto-RP traffic between domains, which is to prevent usage of the
RP from another domain. The same solution can be used between regions within your own domain,
which gives auto-RP the same scoping functionality as the PIM BSR filtering option.
IN

20 www.juniper.net
 Multicast and Policy

LY
N
O
SE
U
AL

Scoping Policy Example

N

The more flexible approach to scoping is to use policies. In a single policy you can add multiple
groups and multiple interfaces. Using multiple terms, you can also select the specific interfaces for
R

which you want to configure scoping. With named scopes, this process would require a lot of
configuration.
TE

Scoping policies and named scoped are mutually exclusive; if you try to use both in the same
configuration, you will receive a commit error.
The criteria that can be used for scoping policies are the following:
IN

• route-filter: Selects the multicast group address; and

• interfaces: Selects the interface the scoping policy will affect.
Unlike the named scope, the site-local scope 239.255.0.0/16 is not automatically applied to an
interface if a scoping policy is referencing that interface, which is why we added the 239/8 range
manually in the policy.

www.juniper.net 21
 I<Course
Multicast
Title>

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

LY
N
O
SE
U
AL

IPv6 Multicast Overview

N

Many aspects of IPv6 multicast are very similar to those we discussed previously for IP version 4
(IPv4) multicast. Most of the same protocol mechanisms are used:
R

• Reverse path forwarding (RPF) check;

TE

• Protocol Independent Multicast dense mode (PIM-DM) and Protocol Independent

Multicast sparse mode (PIM-SM) for any-source multicast (ASM) deployments; and
• SSM.
IN

Differences Between IPv6 Multicast and IPv4 Multicast

There are some significant differences between IPv6 multicast and IPv4 multicast, including the
following:
• Addressing: IPv6 addressing has scoping information directly included into the address.
• MLD replaces IGMP as the membership protocol between hosts and router.
• IPv6 doe not support the Multicast Source Discovery Protocol (MSDP): MSDP is deemed
not scalable enough and therefore is not developed for IPv6. The alternative to MSDP
for IPv6 is to embed the rendezvous point (RP) information into the actual multicast
group address. This method allows for interdomain ASM deployments, where each
group address will have one unique RP provided by one domain for the entire Internet.

2 www.juniper.net
 IPv6 Multicast

LY
N
O
SE
U
AL

IPv6 Multicast Addresses Overview: Part 1

N

The general format for IPv6 multicast addresses (as defined in RFC 4291) is shown in the slide. The
format contains the following fields:
R

• Binary 11111111: Identifies the address as multicast address

TE

• Flgs: Set of 4 flags—0RPT

– 0 is reserved.
– R is defined in RFC 3956 describing embedded RP addressing.
IN

– P is defined in RFC 3306 describing unicast-prefix-based multicast addresses.

– T describes permanent addresses (T=0) or non-permanent addresses (T=1).
Continued on next page.

www.juniper.net 3
IPv6 Multicast
IPv6 Multicast Addresses Overview: Part 1 (contd.)
• Scop: 4-bit multicast scope value used to limit the scope of the multicast group.
– 1 = Interface-local
– 2 = Link-local
– 4 = Admin-local
– 5 = Site-local
– 8 = Organization-local
– E = Global
• Group ID: Defines the multicast group (either permanent or transient) within the given
scope.

LY
N
O
SE
U
AL
N
R
TE
IN

4 www.juniper.net
 IPv6 Multicast

LY
N
O
SE
U
AL

IPv6 Multicast Addresses Overview: Part 2

N

The slide shows the IPv6 multicast unicast-prefix-based address format. This extension to the
standard IPv6 multicast address format provides a simpler way of allocating multicast addresses
R

without the need for protocols such as the Multicast Address Allocation Protocol (AAP) and Multicast
Address-Set Claim (MASC).
TE

The new format uses some of the group ID bits for its additional functionality:
• P flag: If address is based on network prefix, then P=1, which implies that T=1.
• Plen: Indicates the actual number of bits in the network prefix field when P=1.
IN

• Network prefix: Network prefix of the unicast subnet owning this multicast address. All
nonsignificant bits of the network prefix field should be zero.
• Group ID: The group ID is a 32-bit group address.

www.juniper.net 5
IPv6 Multicast

LY
N
O
SE
U
AL

Well-Known Multicast Addresses

N

Similar to IPv4, there are well-known IPv6 multicast addresses. The slide shows the all nodes
addresses for IPv6 (IPv4 224.0.0.1), and the all routers addresses (IPv4 224.0.0.2). Similar
R

addresses are allocated for protocols such as OSPF, RIP, and PIM for IPv6.

Ethernet Addressing
TE

The base media access control (MAC) address for IPv6 multicast is 33:33:XX:XX:XX:XX, where
XX:XX:XX:XX is taken from the last 32 bits of the IPv6 multicast address. To avoid mapping different
IPv6 multicast addresses to the same MAC address, ensure that the last 32 bits of the IPv6
multicast addresses differ.
IN

6 www.juniper.net
 IPv6 Multicast

LY
N
O
SE
U
AL

MLD
N

MLD is the equivalent IPv6 protocol for IPv4’s IGMP. It is used between routers and hosts to signal
interest in receiving specific IPv6 multicast sessions.
R

MLD is a subfunction of the ICMPv6 protocol. Its messages are carried inside ICMPv6, and the
next-header value is 58. The source address for MLD is always a link-local IPv6 source address. The
TE

MLD packet has a time to live (TTL) of 1 and includes an IPv6 router alert header.
Two version of MLD are defined:
• MLDv1: Defined in RFC 2710, equivalent to IGMPv2 functionality
IN

• MLDv2: Defined in RFC 3810, equivalent to IGMPv3 functionality

Three types of MLD messages exist:
• Multicast listener query:
– General query
– Multicast address-specific query
– Multicast address and source-specific query (MLDv2)
• Multicast listener report
• Multicast listener done: Leave message, only used in MLDv1

www.juniper.net 7
IPv6 Multicast

LY
N
O
SE
U
AL

IPv6 ASM Options

N

When you compare IPv6 ASM deployment options with the ones discussed for IPv4, you can see that
many similar options are available.
R

IPv6 can use the following:

TE

• PIM-DM: Same scaling issues.

• PIM-SM: Preferred deployment option.
Within PIM-SM mode IPv6 can use the following options:
IN

• RP discovery methods:
– Static RP: Available; if used, it is best deployed using anycast-RP.
– Auto-RP: Not available.
– Bootstrap router (BSR): Available.
• RP redundancy:
– Anycast-RP with MSDP: Not available.
– Anycast-RP with anycast-PIM: Available.
Continued on next page.

8 www.juniper.net
 IPv6 Multicast
IPv6 ASM Options (contd.)
• Interdomain multicast:
– MSDP: Not available.
– Embedded RP: Allows interdomain multicast by including RP information into
group address. Details of address format are covered on the next page.

LY
N
O
SE
U
AL
N
R
TE
IN

www.juniper.net 9
IPv6 Multicast

LY
N
O
SE
U
AL

IPv6 Embedded RP Addressing

N

To allow interdomain IPv6 muticast using the ASM delivery model, the embedded RP solution was
developed. The idea behind this solution is to let all routers use a single RP to learn about sources
R

for that group. The domain owning the multicast address provides the RP information as part of the
complete IPv6 group address. This solution is defined in RFC 3956, and it can also be used for IPv6
TE

intradomain ASM with scoped multicast addresses.

RFC 3596 defines some new fields to the unicast-prefix-based address format. which we show on
the slide:
• Flgs: R bit, if set R =1 then embedded RP address is used. It also results in the P and T
IN

bit set to 1.
• RIID: The RP interface ID.
Refer to RFC 3956 for additional details.

10 www.juniper.net
 IPv6 Multicast

LY
N
O
SE
U
AL

IPv6 SSM
N

IPv6 also supports SSM, which initially was the only way to perform interdomain multicast.
R

The SSM address range is FF3X::/96, where X is the scoping value.

As with IPv4, SSM relies on IGMPv3. IPv6 SSM relies on MLDv2. As in IGMPv3, the Include mode
TE

operation of MLDv2 allows the hosts to signal the complete channel information of both source and
group.
IN

www.juniper.net 11