Multicast

Table of Contents
Table of Contents........................................................................................................ 2
I.

Crypto Map Based IPsec....................................................................................... 3

The Overview....................................................................................................... 3
How Crypto Maps Work........................................................................................ 3
Applying Crypto Maps.......................................................................................... 3
Crypto Maps Order of Operations.........................................................................3
Crypto Maps Order of Operations.........................................................................3
Defining Phase-1 ISAKMP Policy........................................................................... 4
Defining Phase-2 IPsec Policy...............................................................................4
Applying the Crypto Map...................................................................................... 4
Default Phase-1 & 2 Policies................................................................................. 4

I.

IPv4 Multicast Overview

Recommended Resources
1. Books
Routing TCP/IP Volume II

http://www.amazon.com/Routing-Volume-CCIE-ProfessionalDevelopment/dp/1578700892

Developing IP Multicast Networks

http://www.ciscopress.com/store/developing-ip-multicast-networks-volume-i9781578700776

Interdomain Multicast Routing: Pratical Juniper Networks and Cisco

Systems Solutions
http://www.amazon.com/Interdomain-Multicast-Routing-PracticalSolutions/dp/0201746123

2. Online Resources
Multicast Technology Documentation
http://www.cisco.com/c/en/us/tech/ip/ip-multicast/index.html

IP Multicast SRND
http://www.cisco.com/application/pdf/en/us/guest/tech/tk363/c1501/ccmigration_09186
a008015e7cc.pdf

IP Multicast Best Practices for Enterprise Customers

http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/multicastenterprise/whitepaper_c11-474791.html

What is Multicast

1. Multicast is data transmission to a group of destinations simultaneously

Ex: one to many transmission
2. As opposed to
Unicast one to one transmission
Broadcast one to all transmission
Anycast one to nearest transmission

Why Use Multicast

1. Main goal of multicast is reduce the load on
Sending server processing
Network bandwidth resources
Router forwarding processing
Receiving host processing
2. Common misconception
Multicast is not used in the internet
o Like youtube, ideally it must use multicast, but it is unicast
o Because: issue with end-to-end routing and how multicast tree
are built that limit the control plane scalability for large scale
application like internet
Most cases
o Multicast runs in the Enterprise, IPTV Service Provider.

Why Not Just Use Unicast?

1. Sender must generate one packet for each receiver
Called head-end replication, replication is done by application
With Multicast, replication is done by network devices
2. Sender must know addresses of all receivers
The server/sender need to know what is the IP and Port Address of the
client/receiver
With Multicast, The sender doesnt care who the receiver are, its up
to the network to figure it out.
o The application just blindly send the traffic out, it doesnt run
multicast routing; Its up to the network to figure out: once the
feed come in, who are the actual recipient that we want to get
the traffic towards.
3. Routers must process packets for each receiver separately
With Multicast, we can make the decision based on the group, control
plane eficiency
4. Bandwidth use is proportional to number of receivers
With Multicast, based on how many outgoing interfaces am I
forwarding towards (data plane)

Why Not Just Use Broadcast?

1. In bridged networks, broadcast packets are forwarded out all interfaces

except the one received on
With L2 Multicast, the switch become multicast aware and they able
to do forwarding one to many (not to all)
2. All end host process all packets even if they dont want them
3. Result is inefficient use of resources for uninterested receivers

How Multicast Saves Resources

1.
2.
3.
4.
5.

Source generates single data feed for all interested recipients

Source doesnt need to know who is receiving
Routers make a single forwarding decision for all recipients
Only one packet is replicated per interface, saving bandwidth
Uninterested hosts do not receive packets

Multicast Disadvantages
1. IP Multicast is UDP
2. Connectionless transmission implies
Best effor delivery, no acknowledgments
No congestion avoidance, no slow start
Possible duplicate packets, usually only during reconvergence
Possible out of order packets, no resequencing in UDP applications
3. Workaround for critical applications (financial, stock data)
Send multiple multicast feeds through different physical ports of the
network
o Primary multicast feed (A-Feed)
o Backup multicast feed (B-Feed)
And the application will receive both feeds in, and if there is
reconvergence event in A-Feed, we still have a backup copu from BFeed
Like in SAN (Storage Area Networking) terms: SAN-A, SAN-B

How Multicast Works

1. Source application sends UPD multicast traffic with group destination
address
Sending application server doesnt run multicast routing, and doesnt
participate in the multicast control plane
The server just blindly sending the multicast feeds out on the LAN
segment
And then, its up to the router on the LAN to pick up the application
data then sending it out to receiving clients via multicast routing.
2. Interested receivers join group address by signaling routers on the LAN
In case of IPTV, when changing channels, the set-top-box send the
IGMP join message (IGMP Report) to say I wanna receive traffic going
to particular group address, or I also wanna to specify who is the
source (sending server) address
3. Routers communicate to build loop free tree from sender to receivers
The big component of multicast
4. Portions of the network without receivers will not receive traffic for that group

Multicast Use Case Examples

1. Multimedia
IPTV
Videoconferencing
VoIP Music on Hold
2. Data distribution
Large scale datacenter replication
o Need error checking in the application level (cant rely on UDP)
3. Real-time applications
Stock tickers

IPv4 Multicast Components

1. Multicast can be broken down into three main components

2. Group Addressing
L3 addressing: IPv4, IPv6
L2 addressing: MAC address
3. Control Plane
IGMP, PIM, MSDP, MBGP
4. Data Plane
Reverse Path Forwarding (RPF)
Multicast Routing Table (MRIB/MFIB)

Multicast Group Addressing

1. Multicast group is an address agreed upon between the sender and

receivers for a particular feed
Source sends traffic to destination address of the group
Receivers listen for traffic going to group address
2. Traffic is always sent to a group, never from
3. Groups use both L3 and L2 addresses

IPv4 Multicast Addressing

1. IPv4 multicast uses Class D Addresses
224.0.0.0/4 (224.0.0.0 239.255.255.255)
2. Includes reserved ranges
Link-local Addresses (Routing Protocol, only between same broadcast
domain)
o 224.0.0.0/24 (224.0.0.0 224.0.0.255)
Source Specific Multicast (SSM)
o 232.0.0.0/8 (232.0.0.0 232.255.255.255)
Administratively Scoped
o 239.0.0.0/8 (239.0.0.0 239.255.255.255)

Layer 2 Multicast Addressing

1. IPv4 addresses map to MAC addresses to forward on the LAN

Allows L2 switches to forward multicast intelligently
E.g. dont forward multicast as broadcast
Making decision based on a group of receiver
Need special MAC address that can exist on the multiple ports at the
same time
In the case of Unicast, u cant have the same MAC address on the
multiple ports at the same time, only one-to-one basis
2. MAC address range is 01-00-5E-00-00-00 to 01-00-5E-7F-FF-FF
First 25 bits are fixed
Last 23 bits are mapped from IPv4 address
o but the range of IPv4 multicast address is /4
o There will be a bunch of overlap between addresses
3. Implies overlap between addresses
Last 23 bits must be unique to result in unique L2 flow

Layer 2 Multicast Address Conversion

1. Conversion shortcut
Convert IPv4 2nd octet to binary
Set the first bit to 0
Convert to hex
3rd and 4th octets convert directly to hex
2. Example conversions
224.0.0.1 = 01-00-5E-00-00-01
230.255.1.2 = 01-00-5E-7F-01-02
o 255 = 1111 1111
o 0111 1111 = 7F
o 1 = 0000 0001 = 01
o 2 = 0000 0010 = 02
239.127.1.2 = 01-00-5E-7F-01-02

Multicast Control Plane

1. Multicast control plane used to determine
Who is sending traffic and to what group(s)
Who is receiving traffic and for what group(s)
How traffic should be forwarded when it is received
o The Multicast Tree
2. Control plane is built with a combination of
Host to Router communication (IGMP)
Router to Router communication (PIM and MSDP)

Multicast Control Plane - IGMP

1. Internet Group Management Protocol (IGMP)
Used for receiver to signal routers on the LAN that it wants traffic for a
specific group
2. Three versions
RFC 1112 Host Extensions for IP Multicasting
RFC 2236 Internet Group Management Protocol Version 2
RFC 3337 Internet Group Management Protocol Version 3

IGMPv1

1. Uses two message types to signal group membership

Host Membership Report
Host Membership Query
2. Report used by client to join a group
3. Query used by router to see if members of the group still exist
Essentially an idle timer for the group
4. Legacy now, replaced by IGMPv2
But the core functionally still being carried by IGMPv2 and IGMPv3

IGMPv2
1. Enchances IGMPv1 by adding
Querier election
o If multiple routers on the segment, who sends queries?
Tunable timers
o Can speed up query response timeouts
Group specific queries
o Query sent to the group address instead of all multicast hosts
Explicit leave
o Speeds up convergence if no other hosts are joined to that group
2. Backwards compatible with IGMPv1
3. By default, IOS runs IGMPv2

IGMPv3

1. Used to support Source Specific Multicast (SSM)

IGMPv1/v2 only support group specific joins
o (*,G) join
IGMPv3 supports source specific joins
o (S,G) join
2. Implies IGMPv3 receiver must already know about the sender
More details on this later

Next Steps From IGMP

1. Router knows that host wants traffic for multicast group G

2. How does it tell the rest of the network to deliver traffic to it for G?
3. Multicast routing protocols now take over
PIM
o Used to build the tree
o Reason why multicast is not running on internet
1. PIM on a hop by hop basis on every single router from
sender to the receiver
2. As the multicast data plance scale, the control plane also
grow
3. Unicast control plane is fixed.
4. If you send an unicast packet, the control plane stay as is
5. But if you send a multicast packet, the control plane start
to build multicast state information
Not MBGP (Multiprotocol BGP) or MSDP (Multicast Source Discovery
Protocol)
o Are not replacement for PIM
o More on this later
DVMRP (Distance Vector Multicast Routing Protocol), MOSPF (Multicast
OSPF)
o Legacy and not implemented anymore

Multicast Control Plane - PIM

1. Protocol Independent Multicast (PIM)
Router to router communication used to build loop-free tree from
sender to receiver(s)
2. Considered protocol independent because it does not advertise its own
topology information
Implies IGP already runs in the network to build a loop-free topology
3. Two versions and two modes
PIMv1 & PIMv2
Dense Mode & Sparse Mode

PIM Modes

1. Dense Mode
Considered implicit join
All traffic unless you say you dont want it
Uses Flood & Prune behavior
2. Sparse Mode
Considered explicit join
No traffic unless you ask for it
Uses Rendezvous Point (RP) to process join requests
3. PIM modes control how the tree is built, and who receives what traffic
More detail later

Multicast Data Plane

1. Once the tree from sender to receiver(s) is built, traffic begins to flow
2. Because PIM cant quarantee its network are loop-free
3. Before forwarding, Data Plane checks occur
Reverse Path Forwardin (RPF) check
o Packet come inbound, check the source address of the sender
o Corelate this to Unicast routing table (route back to the sender)
o Was traffic received on the correct interface?
Multicast Routing Table (MRIB/MFIB)
o What interface(s) should I forward the packets out?

The RPF Check

1. If PIM does not exchange its own topology, how does it know the network is
loop free?
Multicast packet comes in, router looks at source IP address and
incoming interface
Unicast routing table (CEF table) is checked for the reverse path back
to source address
2. RPF logic is
If incoming multicast interface == outgoing unicast interface, RPF
check passed
If incoming multicast interface != outgoing unicast interface, RPF
check fails and packet is dropped

Why Use PRF?

1. Assume that IGP has built a loop-free unicast topology
If RPF check passes on multicast packets, we can assume the traffic
has not looped
If RPF check fails its possible a loop occurred, so traffic is dropped
2. RPF is very conservative, but always loop-free
If incoming multicast interface == outgoing unicast interface, RPF
check passed
If incoming multicast interface != outgoing unicast interface, RPF
check fails and packet is dropped

The Multicast Routing Table

1. During exchange of PIM messages, routers learn where sources and receivers
exist
Interface facing upstream towards source is the incoming interface
Downstream links to receivers are outgoing interface list or OIL
Split-horizon like behavior link cannot be in incoming and in OIL at
the same time
2. If RPF check passes
Packets flow from incoming interface to all interfaces in the OIL
3. More information at
Multicast Forwarding Information Base Overview
Verifying IPv4 Multicast Forwarding Using the MFIB

II.

PIM Dense Mode

Overview
1. RFC 3973 Protocol Independent Multicast Dense Mode (PIM-DM)
2. Uses push model or implicit join
Called flood and prune
All traffic flooded throughout entire network
Router that have no receivers prune (unjoin) unused links
3. Only suitable for small multicast implementations
Doesnt scale because of flooding and (S,G) State creation
Amount of source group information state, as a new sender come up to
the network, every PIM devices on the network are gonna know those
individual sources

PIM Dense Mode Operation

1. Discover PIM neighbors
224.0.0.13 (PIM) to find neighbors on attached links
2. Flood all multicast traffic
3. Prune unwanted traffic
4. Multicast table maintenance
Graft: If there is a new device that does signal they want to receive
packet, generate pim graft message
Assert: If there are multiple routers that have equal route to the source
and they both forwarding duplicate feed information on the link
State Refresh: Timer to make sure, routing table information doesnt
become stall

PIM Dense Mode Flooding

1. Router attached to LAN listens for senders

Sender does not communicate multicast control plane
2. Once traffic is received
Insert (*,G) and (S,G) into routing table
i. (*,G): Sparse Mode, Shared Tree (RPT)
ii. (S,G): Dense Mode, SPT, Shortest Path (SPT)
iii. Incoming interface is attached to sender
iv. OIL is all other PIM interface
Flood traffic to OIL
3. Next downstream router(s) continue the process
Flooding results in a Shortest Path Tree (SPT)

PIM Dense Mode Pruning

1. Prune used to tell upstream neighbor to stop sending traffic for (S,G)
2. Prune occurs if
Multicast feed fails RPF check
No downstream neighbors or receivers
Downstream neighbors have already sent prune
LAN Prune Override exception

3. Once prune occurs, traffic flow stops but (S,G) remains in the table
Even after prune, traffic is periodically re-flooded at a set interval
R(config)#ip multicast-routing <distributed>
! use distributed keyword if the platform running distributed cef for multicast
R(config-if)#ip pim dense-mode
R#show ip pim neighbor
! need to be checked both side
! DR - Designated Router in dense-mode is not used for anything
R#show ip mroute
R#show ip mfib
R#show ip mroute count
R#show ip mfib count
PIMv2 Hello, src: self, dst: 224.0.0.13, protocol: 103
IGMPv2 Query, src: self, dst: 224.0.0.1 (all host)
- Is anybody listening for particular multicast group?
- Client who still listen for multicast will answer with Report
IGMPv2 Report, src: self, dst: 224.0.1.40 (all host)
- (As soon as enable multicast routing and pim) The router by default,
generating its own IGP report
- Im a member of group 224.0.1.40 / become receiver for this group, for AutoRP feature
- To fix recursion logic problem in Auto-RP
o You have to know about RP before you join RP
o You cant join it unless you know it
o Always gonna receive traffic from the mapping-agent
2 diff
-

order:
Sender come 1st
Receiver come 1st
In the case dense-mode: isnt really matter, in sparse-mode it does

Sender:
R#ping 224.1.1.1 repeat 1000
PIM Router:
#show ip mroute 224.1.1.1
Incoming interface: Gi1.45, PRF nbr 155.1.45.4 (if 0.0.0.0, it means the source is
directly connected)
Outgoing interface list: Null
Flag: PT (Prune, SPT-bit)
Prune: meaning this route is being prune
SPT-bit: In case of sparse mode this is significant, in case of dense mode it always
set because its always (S,G) entry
Receiver:
R(config-subif)#ip igmp join-group 224.1.1.1 (IGMPv1 or IGMPv2)
When enable PIM, Default is IGMPv2 on
R(config-subif)#ip igmp join-group 224.1.1.1 (IGMPv3)
Enable the IGMPv3 on the interface of next-hop router toward receiver
R#show ip igmp membership

R#Show ip mroute

IGMPv2 Membership report group 224.1.1.1

IGMPv2 Graft
IGMPv2 Graft-Ack

PIM Dense Mode Graft

1. What happens if I have pruned an (S,G), but then I receive an IGMP join from
receiver?
2. Graft message used as dense mode join to unprune (S,g) from upstream
neighbor
Graft continues up reserve path back towards Source until tree is
rebuilt
Used to speed up convergence and not wait for periodic flooding
R#show ip mfib count

R#show ip mroute

RPF neighbor will only be one, mcast doesnt support load balancing per flow

PIM Dense Mode Assert

1. Used to prune duplicate multicast feed transmissions

Typically needed when multiple routers attach to the same multicast
enabled LAN
2. Triggered when (S,G) feed is receive in an interface already in the OIL
3. Assert winner determined by
Lowest metric to source
Highest IP address if metric is equal

PIM Dense Mode State Refresh

1. Normally once an (S,G) is pruned, traffic is reflooded about every 3 minutes
Limits scalability of dense mode
2. State refresh is a keepalive for prune state
Originated by root of the SPT
If downstream routers agree, traffic is not reflooded
Still doesnt fix (S,G) state information in the routing table

III.

PIM Sparse Mode

Overview
1. RFC 4601 Protocol Independent Multicast Sparse Mode (PIM-SM)
2. Uses pull model or explicit join
Traffic is not flooded unless you ask for it
3. Uses both Shared Trees / Rendezvous Point (RPT) / and Source Tree /
Shortest Path Trees (SPT) (assuming not running Source-Specific Multicast)
Dense mode uses only shortest path/source trees
More scalable than dense mode and usually the better design choice

Shared vs. Source Trees

1. Multicast tree determines how traffic is routed from sender to receivers
2. Source based trees
Uses shortest path from sender to receiver
Dense mode or sparse mode
3. Shared trees
Uses shortest path from sender to Rendezvous Point (RP), then shortest
path from RP to receiver
Sparse mode only
Used to eliminate flooding and pruning and make routing table more
scalable

PIM Sparse Mode Operation

1.
2.
3.
4.
5.
6.
7.

Discover PIM neighbors & elect DR

Discover RP
Tell RP about sources
Tell RP about receivers
Build shared tree from sender to receivers through RP
Join shortest path tree
Leave shared tree

Rendezvous Point Overview

1. RP is used as a reference point for the root of the shared tree

2. RP learns about sources through unicast PIM Register messages
Register tells the RP about an (S,G)
Accomplished by DR, learn about the sender and then tells the RP
about this sender and its group
3. RP learns about receivers through PIM Join messages
Tells the RP to add an interface to the OIL for (*,G)
Receiver (IGMP Report) IGMP Querier (turn IGMP Report to PIM
Join) RP
4. RP is used to merge the two trees together

Learning the RPs Address

1. Without the RP
Sources cant register
Joins cant be processed
2. All routers must agree on the same RP address on a per-group basis
Registers and joins are rejected for invalid RPs
3. RP address can be assigned
Statically
Dynamically
i. Auto-RP
ii. BSR

PIM Register Message

1. As the root of all shared trees, the RP must know about all sources
2. When the first-hop router connected to sender hears traffic, a unicast
Register message is sent to the RP
If multiple first-hop routes, only the DR registers
3. If RP accepts this message, it acknowledges with Register Stop and inserts
(S,G) into the table
4. At this point only DR and RP know (S,G)

PIM Join Message

1. As the root of all shared trees, the RP must know about all receivers
2. When a last-hop router receives an IGMP Report, a PIM Join is generated up
the reverse path tree towards the RP
3. All routers in the reverse path install (*,G) and forward the Join hop-by-hop to
the RP
4. At this point the RP and all downstream devices towards the receiver know
(*,G)

Merging the Trees

1. Once the RP knows about both sender and receiver

RP sends a PIM Join message up reverse path to source
2. All routers in the reverse path from the RP to the source install (*,G) with OIL
pointing towards RP
3. Once (S,G) begins to flow, the tree is built end-to-end through the RP

Joining the SPT

1. The shared tree is made up of two Shortest Path Trees

SPT from receiver to RP
SPT from RP to sender
2. SPT from receiver to sender may not be the same as the shared tree
Result is that Shared Tree is not optimal forwarding
It wont cause an infinite loop
3. To fix this, last-hop router
Joins SPT to source with (S,G) Join
Leaves the RPT by sending (*,G) Prune to RP
4. Can be modifed with #ip pim spt-threshold

Routing Table Maintenance

1. Like PIM Dense Mode, PIM Sparse Mode uses State Refresh to ensure that
feeds dont timeout
(*,G) join sent to RP or up SPT to refresh the OIL
2. Sparse Prune message can be used to speed up state information timeout if
IGMP Leave is heard from end host

PIM Sparse Mode Operation

1.
2.
3.
4.
5.
6.
7.
8.

Discover PIM neighbors & elect DR

Discover RP
Tell RP about sources
Tell RP about receivers
Build shared tree from sender to receivers through RP
Join shortest path tree
Leave shared tree
Multicast table maintenance

R(config)#ip multicast-routing <distributed>

R(config-if)#ip pim <dense | sparse | sd>
R(config-if)#ip pim rp address 1.2.3.4

RP
==
R1(config)#int lo0
R1(config-if)#ip pim sparse
R1(config-if)#exit
R1(config)#ip pim rp-address 150.1.1.1
PIM Routers
==========
R(config)#ip pim rp-address 150.1.1.1
Line protocol on Interface Tunnel0, changed state to up
R#show run int tunnel0
R#show ip pim tunnel
Tunnel0
Type : PIM Encap
RP
: 150.1.1.1
Source
: 155.1.146.6
Tunnel interface
For PIM register messages for encapsulating/decapsulating them
On the RP, gonna have 2 tunnels: 1 encap, 1 decap
Other, gonna have 1 tunnel, decap
Optimization to fix an order of operation problem based on who is the DR of the PIM
domain

Verify
R#show ip pim rp
Group: 224.0.1.40, RP: 150.1.1.1, uptime
R#show ip pim rp mapping
Group(s): 224.0.0.0/4, Static
RP: 150.1.1.1 (?)
(?) is for dns resolution, problem (timeout hang) if 150.1.1.1 is unresolvable
Fix with:
- #no ip domain-lookup
- #ip host ROUTER1 150.1.1.1 RP: 150.1.1.1 (ROUTER1)
Sender
======
R9#ping 224.3.3.3 repeat 10000
Result
-------R7(DR)#show ip mroute 224.3.3.3

R1(RP)#show ip mroute 224.3.3.3

R(Other)#show ip mroute 224.3.3.3

Group 224.3.3.3 not found

AAA

R8(config-if)#ip igmp join 224.4.4.4

IV.

Troubleshooting Multicast RPF Failures

Multicast RPF Check Review

1. PIM does not exchange its own topology
2. PIM relies on IGP for loop free path selection
3. RPF check is an extra data plane loop prevention technique

RPF check performed on all incoming multicast packets

1. If incoming multicast interface == outgoing unicast interface, RPF check

passed
2. If incoming multicast interface != outgoing unicast interface, RPF check fails
and packet is dropped

RPF Check & Tree Types

1. RPF check changes depending on tree type
2. Shortest Path Trees (SPT)
Perform RPF check against source
Used in (S,G) trees
i. PIM Dense Mode
ii. PIM Sparse Mode from RP to Source
iii. PIM Sparse Mode from Receiver to Source after SPTswitchover
(S-bit set)
iv. PIM Source Specific Multicast (SSM)
3. Shared Trees (RPT)
Perform RPF check againts RP
Used in (*,G) trees
i. PIM Sparse Mode from Receiver to RP before SPT switchover

RPF Check & Rendezvous Point

1. RPF check is also performed on RP against Register Messages

RP must have a route back to the source that is being registered
If no route, (S,G) state cannot be created
The Register Messages doesnt need to come in from RPF interface,
because there is a different between how (DR route to RP) vs (RP
building a RPF tree back to the DR)

Verifying & Troubleshooting RPF Check

1. Useful commands
Show ip mroute/mfib
Show ip mroute/mfib count
Show ip rpf
Mtrace
Debug ip pim
Debug ip mfib pak

Modifying the RPF Check

1. RPF is based on unicsat routing table
Implies changing unicast routing affects multicast routing
2. RPF can be modified
Manually with ip mroute
Dynamically with Multicast BGP

RPF Check & Rendezvous Point

1. RPF check is also performed on RP against Register Messages
RP must have a route back to the source that is being registered

RPF Check & PIM Join

1. RPF controls how tree must be built, not how it can be built
PIM Join is sent out RPF interface for both (*,G) and (S,G)
Changing RPF results in traffic engineering for multicast

V.

Auto-RP

PIM Sparse Mode Review

1.
2.
3.
4.
5.
6.

Traffic is not flooded unless you ask for it

Uses RP as the root of the Shared Tree
PIM DR hears sender and reports (S,G) to RP through PIM Register
Last-hop router hears IGMP Join and sends (*,G) PIM Join towards the RP
RP sends (S,G) PIM Join towards source to complete the shared tree
Last-hop router can initiate PIM SPT Join and Shared Tree Prune once feed is
end-to-end

Without the RP

1. Sources cant register

2. Joins cant be processed

All routers must agree on the same RP address on a per-group

basis
1. Registers and joins are rejected for invalid RPs

RP address can be assigned

1. Statically
2. Dynamically
Auto-RP
BSR

Auto-RP Review

1. Cisco proprietary method for dynamic RP advertisement

2. Uses two function roles
Candidate RP
i. Device(s) willing to be the RP
Mapping Agent
i. Chooses the RP among candidates and relays this information to
the rest of the PIM domain
3. Allows for redundancy of RPs

How Auto-RP Works

1. Candidate RPs send announcement with group range they are willing to
service
Uses group (S, 224.0.1.39) for announcement
2. Mapping agent discovers Candidate RPs and advertises their mappings to all
other routers
Joins (*, 224.0.1.39) to discover about Candidate RPs
Announces final RP advertisement with (S, 224.0.1.40)

Auto-RP Caveats
1. Dynamically learned RP mappings are preferred over statically configured
ones

2. Auto-RP control plane messages are subject to RPF check

SPT: Receivers Mapping Agent
Mapping Agent Candidate RP
Receivers Candidate RP
3. Routers must join (*, 224.0.1.39) for Candidate RP and (*, 224.0.1.40) for
Mapping Agent
4. In PIM Sparse Mode
Cannot join the Auto-RP groups without knowing where the RP is
Cannot know where the RP is without joining the Auto-RP groups
Recursive logic

Auto-RP Solutions
1. Default RP assignment
Assign a static RP for groups 224.0.1.39 and 224.0.1.40
Defeats the purpose of automatic assignment
2. PIM Sparse-Dense Mode
Dense for group without an RP
Sparse for all others
3. Auto-RP Listener feature
Dense for 224.0.1.39/224.0.1.40 only
Sparse for others

Auto-RP With Multiple Candidates

1. For redundancy and load distribution multiple Candidate RPs can be

configured
2. ACL applied on Candidate RP controls what groups they service
3. If multiple overlapping Candidate RPs, Mapping Agenst chooses highest RP
address

Auto-RP Listener feature

R1 (Mapping Agent)

R7 & R8 (RP Candidate)

R(config)#ip pim send-rp-announce lo0 scope 255

PIM Routers
R(config)#ip pim autorp listener
Default RP assignment
All PIM Routers (R2 150.1.2.2 as a Mapping Agent)
R(config)#no ip pim autorp listener

VI.

Bootstrap Router (BSR)

Bootstrap Router
1. RFC 5059 Bootstrap Router (BSR) Mechanism for Protocol Independent
Multicast (PIM)
Functionally similar to Auto-RP
2. Defines two roles in BSR domain
RP Candidate
i. Analogous to Candidate RP in Auto-RP
ii. Uses unicast PIM to advertise itself to the Bootstrap Router
Bootstrap Router (BSR)
i. Analogous to Mapping Agent in Auto-RP
ii. Advertises RP information to other routers with multicast PIM on
a hop-by-hop basis

Controlling Auto-RP and BSR Messages

1. By default Auto-RP and BSR messages are sent on all PIM enabled interfaces
2. For added security, these message should be filtered on network edge
Auto-RP via Multicast Boundary
BSR via BSR Border
3. Filtering can also occur based on TTL
Called administrative scoping
R(config)#ip pim rp-candidate
R(config)#ip pim bsr-candidate

Look bsr config reference

Ip pim bsr-candidate lo1 accept-rp-candidate 101