Introduction to Multicast Routing

Brian Edwards
Juniper Networks
Tech Support
[email protected]
February 20, 2001
Several protocols are required to enable IP multicast over multiple domains. These protocols, as
well as their documentation, have been developed independently, and each has its own set of
specific terms. The multiplicity of protocol development makes it difficult to create a workable,
integrated multicast implementation.
Thus, the point of this chapter is to resolve the difficulty of implementation using these several
protocols, and to provide a working-level illustration of an interdomain multicast routing system,
end to end across multiple domains.
Figure 2-1 shows a simple network, and will serve as a reference for subsequent discussion in this
chapter. The diagram shows two interconnected autonomous systems (AS) with fully functional
unicast routing.
Each autonomous system is controlled by an independent organization and has its own IGP.
Based on information gained from the independent IGPs, Router-C and Router-D, in the diagram,
each run an EBGP session to exchange routing information with Router-E and Router-F.
 Figure 2-1. Base Internetwork

We take the reader step-by-step, showing how to enable these two autonomous systems to route
multicast traffic between them. Each step will concentrate on a portion of this diagram and
describe the mechanisms that need to be put in place for operational multicast routing.
Specifically, the focus will be on allowing Host-B to receive multicast traffic from Server-A.

Receiving Multicast Traffic:

IGMP from the Perspective of the Host
A host must run the Internet Group Management Protocol (IGMP) in order to receive multicast
packets. Currently, three versions of IGMP exist:
1) Version 1: Described in RFC 1112.
2) Version 2: Described in RFC 2236.
3) Version 3: Described (at time of publication) in an IETF Internet draft created and
maintained by the Interdomain Multicast Routing working group.
Hosts use IGMP to express their interest in specific multicast groups. A properly configured
host performs two tasks to join a multicast group :
1) Begins listening on the layer-2 address that maps to the IP multicast group address
(ref. Chapter 1 for a discussion of layer-3 to layer-2 multicast address mappings), and
2) Responds—for each group in which it is interested—to IGMP Host Membership Query
messages received from a router on its (the host’s) directly attached subnet with a Host
Membership Report message.
Note: Multiple hosts on the same subnet may be interested in the same group, but it is
only necessary for one host to respond to the IGMP query in order for the router to
forward traffic destined to the group onto the subnet.

To avoid a condition in which all hosts bombard the local network with redundant information,
two strategies are used:
1) When a query is received, a host waits a random amount of time to respond for each group
in which it is interested.
2) The host, in its IGMP report message responses, sets the destination address to the group
address being reported. If a host receives a report from a different host on the subnet, it
suppresses the sending of its own report for that group.
IGMP version 2, with addition of a leave-group message, enables hosts to report they are no
longer interested in a group. The router responds to this message with a group-specific query
message to determine if any other hosts are still interested in the group.
IGMP version 3 enables hosts to participate in source-specific multicast routing (SSM).
Source-specific multicast routing is described in Chapter 8.

Detecting Multicast Receivers:

IGMP from the Perspective of the Router
IGMP query messages are sent to the ALL-SYSTEMS multicast group (224.0.0.1) with an IP
time-to-live (TTL) value set to 1. If more than one router exists on a subnet, the router whose
query messages contain the lowest-numbered IP source address is elected as the active querier
for the subnet. Other routers on the subnet suppress sending of IGMP queries, but still listen to
and cache the information included in all IGMP messages.
For each interface on the router that is running IGMP, the IGMP group cache is a simple table
that keeps track of the following information:
1) A list of all groups that have interested hosts
2) The IP address of the host that last reported interest for each group
3) The timeout value for each entry in the table
The timeout is the amount of time remaining for each group before the router determines no
more members of a group exist on the interface. This timer is reset each time receives a
Membership Report for that group on that interface. The value to which the timer is reset is
called the Group Membership Interval and is calculated as follows:
GMI = (Robustness Variable x Query Interval) + Query Response Interval
The Query Interval is the interval between general queries sent by the querier. Its default value
is 125 seconds. By varying the Query Interval, an administrator may tune the number of IGMP
messages on the network; larger values cause IGMP Queries to be sent less frequently.
The Query Response Interval is the amount of time hosts have to respond to a IGMP query. A
10-second default value is encoded in the query message, which provides a time limit for the
host’s initial response. The host then randomly selects a response time between zero and this
maximum, as described in the previous section.
The Robustness Variable defines the number of queries that can be sent without receiving a
response, before the cache entry times out. Increasing the Robustness Variable from its default
of 2 safeguards against packet loss, but increases the amount of time before the router detects
that additional interested hosts truly do not exist.

Generating Multicast Traffic

Generating multicast traffic requires no additional protocols. Server-A simply starts sending
traffic to a multicast group address. Some server applications provide a choice between
operating in unicast or multicast mode. In unicast mode, the server waits to generate packets
until it receives requests from the client; the server maintains a separate session with each client
and replicates its data into a separate packet for each client. If the information sent to each
client is identical, this mode is inefficient.
In multicast mode, the server sends to a specific group address in the 224.0.0.0/4 range. The
routers throughout the network are responsible for delivering a copy of each packet sent by the
server to all interested clients.

Detecting Multicast Sources

Routers recognize multicast packets sent by directly connected sources by examining the source
and destination addresses of the packet as well as the TTL. If the following conditions exist:
1) Destination address in the Class D range
2) Source address part of a directly connected subnet, and
3) TTL greater than 1
Under these conditions, the router knows it is the first-hop router for the multicast source and
acts appropriately as described in the following discussion on Protocol Independent Multicast
(PIM) traffic.
 Routing Multicast Traffic Within a Domain Using PIM-SM
The first step is to get multicast routing up and running within a single domain. Protocol
Independent Multicast–Sparse Mode (PIM–SM or PIM) is the multicast routing protocol most
suited to this task. We define a ‘domain,’ i.e. a domain in the context of PIM-SM.
Figure 1 shows two separate domains. PIM domains can usually be mapped to BGP
autonomous systems, which are generally defined in BGP as a portion of the Internet that is
owned and operated by a specific organization. By identifying a separate autonomous system
for each organization, we enable the network architects of those organizations to enforce their
own routing policies on their own piece of the Internet.
The reason for having separate PIM domains for different organizations is slightly different:
Mainly, we do not want routing of our own network’s local traffic to depend on the availability
of equipment in someone else’s network.
At the core of the PIM-SM protocol is a router that serves a very special role, known as the
rendezvous point (RP). A PIM domain is defined as the collection of PIM-speaking routers
who agree their RP is located at the same IP address. Although it is possible for a different RP
to exist for each multicast group, in general the forgoing definition for PIM domain is
sufficient.
Multicast routing centers on the building of distribution trees. Unlike unicast routing, each
router may have multiple interfaces out of which it forwards packets on behalf of a particular
multicast group. Packets do not traverse the network in a straight line path, instead there is a
multifingered distribution tree rooted at one router with various branches heading toward each
interested receiver.
The RP serves as the “well-known meeting place” for multicast sources and interested listeners.
Distribution trees rooted at the RP are known as rendezvous point trees (RPTs) or shared trees.
Distribution trees rooted at the source are called shortest path trees (SPTs). PIM-SM requires
the following three major phases to deliver multicast packets from a source to a receiver:
1) Build the RPT that delivers packets from the RP to interested listeners
2) Build the distribution tree that delivers packets from the source to the RP
3) Build the SPT that delivers packets directly from the source to the interested listeners
These phases occur for each source-receiver pair, and the distribution trees for different sources
and groups may have reached different phases at any given point of time, depending on the
existence of a source and interested listeners for that group.
The order of operation is not strict. Multicast sources can be created before receivers are
created, and PIM still enables delivery of multicast packets to any newly appearing receivers.
Likewise, for a given multicast group, PIM handles the condition in which a listener emerges
after the SPT has already been built from the source to other receivers.
At this point it is best to walk through the simplest example to explain the operation of the
protocol, using a single source and single receiver.
 Phase 1:
Building the RPT that Delivers Packets from RP to Interested Listeners
Traffic flow of the RPT starts at the RP and flows to all hosts interested in receiving on the
multicast group. The RPT is constructed in the opposite direction to traffic flow, that is,
starting at the receivers and building hop-by-hop toward the RP.
When a multicast router receives an IGMP Host Membership Report from a host on a directly
attached subnet, the router is responsible for initiating the creation of the RPT for the specific
group of interest. If more than one router is connected to the subnet, then PIM elects a
Designated Router (DR) to initiate RPT creation. This avoids duplicating delivery of the
same multicast packet to the subnet.
The DR sends a PIM JOIN message to its Reverse Path Forwarding (RPF) neighbor for the
RP’s IP address. An RPF neighbor is defined as the next-hop address in the RPF table for a
specific IP address. The RPF table is the unicast routing table used for multicast routing
protocols, and it is possible for the RPF table to be the same routing table used for unicast
packet forwarding.1
The PIM JOIN message is multicast hop-by-hop to the ALL-PIM-ROUTERS group
(224.0.0.13) out each router’s RPF interface until it reaches the RP forming the RPT. The
message is sent with an IP TTL of 1, and each router along the way generates its own PIM
JOIN message based on the information it received. Each router uses its own RPF table to
determine its RPF neighbor for the RP address.
JOIN messages are sent to 224.0.0.13, so all routers on a multi-access network will accept
and process the packet. The address of the RPF neighbor is encoded in the message. Only
the router that owns the address encoded in the packet will generate its own PIM JOIN
towards its RPF neighbor.
Phase 1 on the Example Network
AS 100 of the example network is used to demonstrate the three phases of PIM. The first
step is to choose an RP. The placement of an RP in a real network is an important decision.
The RP is must be accessible for PIM-SM to work. Techniques for providing RP fail-over
and redundancy are discussed in later chapters. For the sake of this demonstration, I will
choose Router-B as the RP. This makes the demonstration more interesting because the SPT
and RPT for Host-A will be different paths.
To start phase 1 Host-A advertises its interest in a group (for this example it happens to be
interested in group 230.1.1.1) to Router-C via IGMP. This triggers Router-C to add its
Ethernet interface to the outbound interface list for the 230.1.1.1 group. Router-C proceeds
to forward a (*, 230.1.1.1) JOIN to its RPF neighbor for the RP address.
In this case the RPF neighbor happens to be the PR itself, Router-B. Router-B receives the
JOIN and adds the interface it came in on to its outbound interface list for 230.1.1.1. Router-
B realizes that it is the RP and therefore the root of the RPT, so there is no need to forward a
(*, 230.1.1.1) JOIN message.

1
In reality, there is no such thing as a PIM JOIN message. It is officially named a Join/Prune
message, because the same message can hold information for joining and pruning various
distribution trees. But for clarity, we will refer to Join/Prune messages as either “Join” or “Prune,”
depending on the function of the message in a given instance.
The process of building the RPT for 230.1.1.1 is illustrated in the following diagram.

Figure 2.2: Building the RPT

It is easy to see the meaning of Reverse Path Forwarding with this example. The JOIN
messages are forwarded in the reverse direction of the path from the RP to Host-A. The
inbound interface of a JOIN message is added to the outbound interface list for forwarding
multicast data packets.
At this point no traffic is flowing, because Server-A has yet to start sending data packets to
the 230.1.1.1 group. In phase 2, the distribution tree is built to deliver packets from the
source to the RP.

Phase 2:
Building the Distribution Tree That Delivers Packets from Source to RP
Once the RPT is built, it remains in place even if no active sources exist to generate traffic to
the group. As soon as a source emerges, its traffic is instantly delivered to the receivers
although no end-to-end distribution tree exists from the source to all receivers.
This is accomplished as the PIM DR directly connected to the source encapsulates the data in
PIM REGISTER messages, and sends these PIM REGISTER messages via unicast routing to
the RP address. The PIM DR connected to the source sends a REGISTER message each time
it receives a multicast packet from the source. If an RP receives a PIM REGISTER message
for a group for which it has set up an existing RPT, then it does two things:
1) Delivers the encapsulated multicast packet down the RPT to the receivers
2) Sends a PIM JOIN message towards the source to create a distribution tree
When the distribution tree is set up, the RP begins to receive duplicate multicast packets.
One copy is delivered via multicast routing down the newly created distribution tree, and the
other is decapsulated from the REGISTER messages sent by the PIM DR.
As soon as the RP receives the first native multicast packet for the source-group pair, it sends
a REGISTER-STOP message to the PIM DR. When the PIM DR receives the REGISTER-
STOP messages, it stops sending REGISTER messages for the source-group pair.
Phase 2 on the Example Network
Phase 2 begins when Server-A starts sending data packets with a destination address of
230.1.1.1. Router-A recognizes these packets as being sent by a directly connected source on
a LAN that Router-A is serving as the PIM DR. Router-A notes that this is the first packet
received from this source for the group, because it has no existing (Server-A, 230.1.1.1) state.
Router-A creates this state, adding its Ethernet interface as the upstream interface for the
source-group pair. It then unicasts a PIM REGISTER message to the RP. The REGISTER
message has the data packet encapsulated within it. Router-A sends a separate REGISTER
message to Router-B for every data packet from Server-A to 230.1.1.1 until it receives a
REGISTER-STOP message from Router-B.
Router-B receives each REGISTER message, decapsulates the data packet, and sends it down
the RPT (which was set up in Phase 1). The initial REGISTER message received by Router-
B causes it to send a JOIN message to its RPF neighbor for Server-A. In this case Router-A
is that RPF neighbor. Router-A adds its interface towards Router-B to its outbound interface
list for the source-group pair.
At this point each packet sent from Server-A to 230.1.1.1 is sent two times to the RP. It is
both encapsulated in a REGISTER message and sent directly out the interface in the
outbound interface list. Another way to describe this is that the outbound interface list has
two entries; (1) the point-to-point interface connecting Router-B and (2) the virtual interface
formed by encapsulating data in REGISTERs.
Once Router-B starts receiving the data packets natively (i.e. not encapsulated in REGISTER
messages) it sends a REGISTER-STOP message to Router-A. When Router-A receives the
REGISTER-STOP is removes the virtual interface formed by encapsulating data in
REGISTERs from it outbound interface list and only forwards the packets natively.
The following diagram illustrates Phase 2.
 Figure 2.3. Phase 2

When Phase 1 and 2 are completed the packets sent to 230.1.1.1 by Server-A are traveling to
Host-A via the RP. The packets are delivered successfully, but the shortest path through the
network is not being used. Phase 3 allows for these packets to be shortcut directly from
Router-A to Router-C.

Phase 3:
Building the SPT that Delivers Packets Directly from the Source to the
Interested Listeners
This is the final phase. The benefit of creating the SPT is that the path taken via the RP to
initially deliver traffic may not be the optimum path from the source to each receiver.
Once a PIM DR for a subnet with one or more interested listeners starts receiving multicast
packets from a particular source, it initiates the creation of the SPT by sending a PIM JOIN
message to its RPF neighbor for the source’s IP address.
When the SPT is formed, the PIM DR will start receiving two copies of each packet sent by
the source. One copy is received via the newly created SPT and the other is delivered via the
RPT. To avoid this redundancy, the PIM DR sends a PIM PRUNE message toward the RP.
This informs the RP that it is no longer necessary to for multicast packets for this source-
group pair down the RPT.
At this point as long as the sources and receivers remain static, PIM’s task of setting up the
optimal delivery of packets from the source to all receivers for the multicast group is finished.
Remember, the mechanisms discussed in this section only work if the sources and receivers
are all in the same PIM domain: the PIM DRs for all sources and receivers agree on the same
IP address for the RP of the multicast group.
Phase 3 on the Example Network
Phase 3 on the example network starts when Router-C receives the initial data packet for the
source-group pair, (Server-A, 230.1.1.1). Router-C knows that it received this packet down
the RPT and on its RPF interface for the RP. Router-C initiates the creation of the SPT, by
forwarding a (Server-A, 230.1.1.1) JOIN message to its RPF neighbor for Server-A. Its RPF
neighbor for Server-A is Router-A.
Router-A adds the interface connecting it to Router-C to its outbound interface list for
(Server-A, 230.1.1.1). At this point Router-A forwards the data packets out both of its point-
to-point interfaces. Router-C receives the packets twice; once directly from Router-A down
the SPT, and secondly down the RPT from Router-B.
When Router-C receives the first packet down the SPT, it sends a (Server-A, 230.1.1.1, RPT)
PRUNE message to its RPF neighbor for the RP. Its RPF neighbor for the RP is Router-B.
When Router-B receives this PRUNE message, it removes its point-to-point interface
connecting to Router-C from its outbound interface list for (*, 230.1.1.1).
Because Router-B now has no interfaces on this outbound interface list, it sends a (Server-A,
230.1.1.1) PRUNE message to its RPF neighbor for Server-A (Router-A). Router-A receives
the PRUNE message and removes its interface connecting Router-B from its outbound
interface list for (Server-A, 230.1.1.1).
The following diagram illustrates the control messages for phase 3.

Figure 2.4. Control Messages for Phase 3

 At the end of Phase 3 data packets are delivered from Server-A to Host-A via the shortest
path. It is important to realize that new hosts can report their interest in group 230.1.1.1 and
these phases will take place again. The end result is a single SPT, rooted at Server-A with
branches down the shortest path to each receiver.
At this point the reader should have a basic understanding of multicast routing within a single
PIM-SM domain. The next two sections introduce two protocols that enable the
interconnection of PIM domains. These are MSDP and MBGP.

Routing Multicast Traffic Across Multiple Domains with MSDP

The PIM protocol in itself does not have a mechanism to enable multicast packets from a
source in one PIM domain to reach a receiver in another domain. The reason is that the PIM
DR for the source sends its REGISTER messages to the RP in its own domain, while the PIM
DR for the receiver sends JOIN messages toward the RP in its own domain.
The delivery of multicast packets from the source to the RP in the source’s domain is
disconnected from the RPT in the receiver’s domain. Thus, the following two requirements
exist for transporting multicast traffic across multiple PIM domains:
1) The RP in domains that have receivers must have knowledge of the IP address of active
sources
2) All routers along the path from the source to the receivers must have a route to the source’s
IP address in their RPF table
The first requirement is accomplished by using Multicast Source Discovery Protocol (MSDP).
MSDP provides a way to connect multiple PIM-SM domains without one domain depending on
the availability of the other. Each domain relies on its own routers to serve as RP.
MSDP sessions ride over TCP and can be multihop. MSDP sessions are formed between the
RPs of various domains, MSDP-speaking RPs send MSDP SOURCE-ACTIVE (SA) messages
to notify the RPs in other domains of active sources. An RP constructs an SA message each
time it receives a PIM REGISTER message from a PIM DR advertising a source. SOURCE-
ACTIVE messages include the multicast data packet encapsulated in the REGISTER message.
When an RP receives an SA message for a group for which interested receivers exist, the RP
delivers the encapsulated data down the RPT to all the receivers in its domain. When the PIM
DR receives the multicast packets down the RPT, it will join the SPT directly to the source.
The second requirement is usually not a concern, because most networks have any-to-any
connectivity for unicast traffic, even for addresses in other autonomous systems. Keep in mind
the multicast RPF table need not be the same routing table used for unicast routing. In this
case, the dedicated multicast RPF table must have routes for all potential multicast sources.
MBGP is used to populate such an RPF table and is discussed in the next section.

MSDP in the Example Network

To show the functionality of MSDP in the example network, we will pick up where we left
off in the previous section. The data packets are being delivered from Server-A to Host-A via
the SPT. Now Host-B in AS 200 reports its interest in the 230.1.1.1 group by sending an
IGMP Report message to Router-G.
Router-G adds its Ethernet interface to the outbound interface list for (*, 230.1.1.1). Router-
G has been chosen to serve as the RP for the PIM domain of AS 200, so the formation of the
RPT is trivial. The RPT is simply Router-G’s Ethernet interface.
At this point no data packets for the 230.1.1.1 group are delivered to Host-B, because Router-
G has no idea that Server-A is sending to that group. In order to get this information to
Router-G, Router-B and Router-G are configured as MSDP peers. The problem is that
Router-B no longer knows that Server-A is sending to 230.1.1.1, because it has sent a PRUNE
message to Router-A for (Server-A, 230.1.1.1).
This is not truly a problem, because Router-A periodically sends NULL-REGISTER
messages (a REGISTER message without encapsulated data) to the RP. The primary purpose
of the NULL-REGISTER is to test to see if the RP has any new interested listeners in its
domain that have formed an RPT. If so the 3 phases in the previous section are repeated.
In this case though, Router-B has no knowledge of Host-B’s interest in 230.1.1.1, because
Host-B is in a different PIM domain. That is to say, its directly connected PIM DR sends its
(*,G) JOINs towards a different RP than Router-B. As previously noted, in this case Router-
G happens to be serving as both the DR and RP.
The saving factor is that Router-B forms a MSDP SOURCE-ACTIVE message for each
REGISTER it receives (NULL-REGISTER or normal REGISTER) and forwards it to all its
MSDP peers. This is how Router-G discovers that Server-A is sending to 230.1.1.1. Router-
G then sends a PIM JOIN message for (Server-A, 230.1.1.1) to its RPF neighbor for Server-
A.
Router-E is that RPF neighbor. Router-E adds its interface connecting Router-G to its
outbound interface list for (Server-A, 230.1.1.1) and sends a PIM JOIN towards Server-A.
Router-C receives this JOIN and adds its interface connecting Router-E to its outbound
interface list for (Server-A, 230.1.1.1).
It is important to note that in order for this to take place, PIM-SM must be enabled on the
interfaces connecting the two PIM domains. The following diagram illustrates the process.
 Figure 2.5.

At this point Router-C has two interfaces in its outbound interface list for (Server-A,
230.1.1.1). Those are its Ethernet interface and its point-to-point interface connecting
Router-E. The SPT for the source-group pair successfully delivers data packets from Server-
A to both Host-A and Host-B.

Populating a Routing Table Dedicated to RPF Checks with

MBGP
The previous sections describe how a mechanism known as Reverse Path Forwarding (RPF)
uses information learned from a unicast routing table to determine the path a multicast
distribution tree takes. It is possible to use the same routing table for forwarding unicast traffic
as the RPF table.
By taking this approach, unicast and multicast traffic will follow the same path, but in opposing
directions. For example, a multicast packet traveling from Server-A to Host-B would traverse
all the same routers and links, but in the exact opposite order, as a unicast packet traveling from
Host-B to Server-A.
Some situations make such congruent routing of unicast and multicast traffic less than optimal.
The following diagram illustrates an example where it is beneficial to have multicast and
unicast traffic travel separate paths.
 Figure 2-6. Unicast and Multicast Path Illustration

Based on fewest AS hops, the optimal path for unicast traffic traveling from AS 100 to AS 500
is through AS 400. The problem, however, is AS 400 does not support multicast routing. If the
same unicast routing table used to forward unicast traffic is used for the RPF table in all routers
and multicast traffic must flow from AS 500 to AS 100, the AS 100 is compelled to use
suboptimal routing for its unicast traffic destined for AS 500. Unicast traffic from AS 100
destined for AS 500 would be forced to traverse the path across AS 200 and AS 300.
To circumvent this limitation, a table other than the one used for unicast forwarding must be
used for multicast RPF. The question is how to populate such a table: How are unicast routes
introduced into a separate RPF table, with next-hop information different from the table used
for unicast forwarding?
One solution is to configure static routes specifically for the RPF table. Note that static routing
for multicast RPF faces the same scalability limitations as static routing for unicast forwarding.
Those limitations being: lack of dynamic fail-over and maintenance burden because changes to
topology are not automatically updated.
In real networks, it is desirable to update the entries in the RPF table dynamically. The RPF
table consists of unicast routes, so there is no need to invent a new routing protocol. Instead the
need is to somehow differentiate between route-control information intended to be used in the
unicast-forwarding routing table and the multicast RPF table.
Theoretically this differentiation could be implemented by modifying any of the existing
unicast routing protocols. The structure of some protocols, however, facilitates expanded
functionality. From the perspective of software developers, BGP is one of the easiest protocols
to which to add such functionality.
Within the BGP protocol, a capabilities negotiation occurs between peers when they first
establish a session. Rules have also been defined for handling BGP-learned routes with path
attributes that are not understood. In general, the BGP4 specification, RFC1771, is written with
expansion of the protocol’s capabilities in mind., for example, the Community attribute. (Note,
the Community attribute is not part of the BGP4 specification. It is defined in a later document,
RFC1997.)
Currently BGP is the only dynamic routing protocol that can differentiate between multiple
types of routing information. This capability is designated Multiprotocol Extensions for BGP
(MBGP) and is defined in RFC2283. MBGP works identically to BGP in all respects; it simply
adds functionality to BGP, such as the capability for BGP updates to tag routing information as
belonging to a specific protocol or function within that protocol.
When using MBGP for updating dedicated multicast RPF tables, two sets of routes are
exchanged in the MBGP updates:
! IPv4 unicast routes
! IPv4 multicast RPF routes
Each set will most likely have duplicated prefixes, but the path information for the same prefix
in each set can be different. Not only can multicast RPF routes have different BGP next-hops
(and therefore potentially different recursive next-hops), they can also have different
information in any of the BGP path attributes.
From the AS 100 perspective in the Figure 2-2 above, MBGP allows for destinations in AS 500
to be learned through the connection to both AS 200 and AS 400. The path through AS 400
will be preferred for unicast packet forwarding, with the path through AS 200 and AS 300
serving as backup. Meanwhile, path selection for multicast RPF routes, will be limited to the
path through AS 200 and AS 300.

MBGP in the Example Network

To show the functionality of MBGP in the example network, we will pick up where we left off
in the last section. Multicast packets to group 230.1.1.1 are delivered from Server-A to both
Host-A and Host-B via the SPT.
To make things interesting, let’s pretend that our boss has mandated that the link between
Router-C and Router-E not be used to carry any multicast data traffic unless the link between
Router-D and Router-F fails. Additionally, unicast traffic flowing between AS 100 and AS 200
must use the Router-C/Router-E link if it is available.
The way to accomplish this is by using MBGP. Essentially Router-G’s RPF neighbor for
Server-A must change from being Router-E to Router-F. This will cause Router-G to send its
PIM JOIN messages for (Server-A, 230.1.1.1) to Router-F rather than Router-E. Therefore the
SPT will be built across the Router-D/Router-F link instead of the Router-C/Router-E link.
Two steps are needed to make this scheme work
(1) Configure the routers in AS 200 to use a dedicated RPF table instead of the unicast
forwarding table,
(2) Manipulate the path attributes in the MBGP updates for the Multicast RPF routes to prefer
the Router-D/Router-F link.
MBGP allows separate routing policy for each address family. For instance the MED value
could be set for all prefixes learned from both AS 100 routers. For routes learned from Router-
C, unicast routes could be set to MED = 50, and multicast RPF routes could be set to MED =
100. For routes learned from Router-D, the opposite values would be used to achieve the
desired effect; unicast routes assigned MED = 100 and multicast RPF routes assigned MED =
50.
This is just one example of a routing policy that would give the desired effect. The following
diagram illustrates the use of MBGP to achieve incongruent paths for unicast and multicast
routing.

Figure 2.7. Incongruent Paths for Multicast and Unicast Routing