Rendezvous Points

Module 6

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/13/2001 11:12 AM

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

Module Objectives

Explain the basic operation of Auto-RP.

Explain the basic operation of PIMv2 BSR.
Explain how to configure RPs
How to use various IOS commands to tune
and control RP operation.

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

Module Agenda

Auto RP
PIMv2 BSR
Static RPs
Tuning RP Operations
Debugging RP Operation
Special Cases

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

Auto-RP Overview
All routers automatically learn RP address
No configuration necessary except on:
Candidate RPs
Mapping Agents

Makes use of Multicast to distribute info

Two specially IANA assigned Groups used
Cisco-Announce - [Link]
Cisco-Discovery - [Link]

Typically Dense mode is used forward these

groups

Permits backup RPs to be configured

Can be used with Admin-Scoping
Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Auto-RP Overview
Auto-RP allows all routers in the network to automatically learn Group-to-RP
mappings.
There are no special configuration steps that must be taken except on the
router(s) that are to function as:
Candidate RPs
Mapping Agents
Multicast is used to distribute Group-to-RP mapping information via two special,
IANA assigned multicast groups.
Cisco-Announce Group - [Link]
Cisco-Discovery Group - [Link]
Because multicast is used to distribute this information, a Chicken and Egg
situation can occur if the above groups operate in Sparse mode. (Routers would
have to know a priori what the address of the RP is before they can learn the
address of the RP(s) via Auto-RP messages.) Therefore, it is recommend that
these groups always run in Dense mode so that this information is flooded
throughout the network.
Multiple Candidate RPs may be defined so that in the case of an RP failure, the
other Candidate RP can assume the responsibility of RP.
Auto-RP can be configured to support Administratively Scoped zones. (BSR
cannot!) This can be important when trying to prevent high-rate group traffic
from leaving a campus and consuming too much bandwidth on WAN links.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

Auto-RP Fundamentals
Candidate RPs
Multicast RP-Announcement messages
Sent to Cisco-Announce ([Link]) group
Sent every rp-announce-interval (default: 60 sec)

RP-Announcements contain:
Group Range (default = [Link]/4)
Candidates RP address
Holdtime = 3 x <rp-announce-interval>

Configured via global config command

ip pim send-rp-announce <intfc> scope <ttl> [group-list acl]

Deny in group-list has variable meaning

Before 12.0(1.1) Deny = Im not C-RP for this group-range
After 12.0(1.1) Deny = Force group-range to always be
DM
Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Auto-RP Candidate RPs (C-RPs)

Multicast RP-Announcement messages to the Cisco-Announce ([Link])
group. These messages announce this router as being a Candidate for
selection as RP and are sent every 60 seconds by default.
RP-Announce messages contain:
Group Range (default is all multicast groups or [Link]/4)
The Candidates IP address
A holdtime which is used to detect when the C-RP has failed. This holdtime
is 3 times the announcement interval or 3x60 = 180 seconds = 3 minutes
C-RPs are configured using the (rather obtuse) command:
ip pim send-rp-announce <intfc> scope <ttl> [group-list <acl>]
The <intfc> specifies which IP address is used as the source address in the
RP-Announce messages that are sent out all multicast interfaces on the
router.
The <ttl> value controls the TTL of the RP -Announce message.
The optional group-list permits a group range other than the default to be
assigned.
This command may be configured more than once on a router so that the
router will function as C-RP for multiple group ranges.
Note: A deny in the group-list access-list has a different meaning beginning
with IOS release 12.0(1.1).
Before 12.0.(1.1): Deny means Im not the RP for this group range.
After 12.0.(1.1): Deny means Force this group range to always work in
Dense mode. Note: Only a single C-RP needs to deny this group range to
force this to happen. In other words, the deny overrides any other routers
permit advertisement.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

Auto-RP Fundamentals
Mapping agents
Receive RP-Announcements
Stored in Group-to-RP Mapping Cache with holdtimes
Elects highest C-RP IP address as RP for group range

Multicast RP-Discovery messages

Sent to Cisco-Discovery ([Link]) group
Sent every 60 seconds or when changes detected

RP-Discovery messages contain:

Elected RPs from MAs Group-to-RP Mapping Cache

Configured via global config command

ip pim send-rp-discovery [<interface>] scope <ttl>

Source address of packets set by <interface> (12.0)

If not specified, source address = output interface address
Results in the appearance of multiple MAs. (one/interface)
Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Auto-RP Mapping Agents (MAs)

Mapping Agents join the RP -Announce group ([Link]) in order to receive RP
Announcements sent by all Candidate RPs.
When they receive an Announcement they:
Save the Announcement in the Group-to-RP mapping cache
Select the C-RP with the highest IP address as RP for the group range
The holdtimes are used to timeout an entry in the cache if a C-RP fails and
is no longer sending periodic C-RP announcements.
Mapping Agents periodically send the elected RPs from their Group-to-RP
mapping cache to all routers in the network via RP Discovery messages.
RP Discovery messages are multicast to the Auto-RP Discovery group
[Link].
They are sent every 60 seconds or when a change to the information in the
Group-to-Mapping takes place.
MAs are configured using the (rather obtuse) command:
ip pim send-rp-discovery[ <intfc>] scope <ttl>
The optional <intfc> specifies which IP address is used as the source
address in the RP-Discovery messages that are sent out all multicast
interfaces on the router. (A Loopback interface is normally specified here.)
If this interface is not specified, the source address of each multicast
interface on the router is used.
Note: The reason that this is an optional clause is strictly to be backwards
compatible with IOS releases prior to 12.0 that did not allow the interface to
be specified. In practice, an interface should always be specified.
The <ttl> value controls the TTL of the RP -Discovery message.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

Auto-RP Fundamentals

All Cisco routers

Join Cisco-Discovery ([Link]) group
Automatic
No configuration necessary

Receive RP-Discovery messages

Stored in local Group-to-RP Mapping Cache
Information used to determine RP for group range

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

All Cisco Routers

Automatically join the Cisco-Discovery ([Link]) group in order to receive
Group-to-RP mapping information being multicast by the Mapping Agents in the
network.
No configuration is necessary!
Group-to-RP mapping information contained in the RP -Discovery messages is
stored in the routers local Group-to-RP mapping cache. This information is
used by the router to map a Group address to the IP address of the active RP
for the group.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

Simple Auto-RP Configuration

RP/Mapping Agent
A

PIM
Sparse Mode
C
RP/Mapping Agent

On each router:

ip multicast-routing

On each interface:

ip pim sparse-dense-mode

On routers B and C: ip pim send-rp-announce loopback0 scope 16

ip pim send-rp-discovery loopback0 scope 16

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Example Auto-RP Configuration

The above example network shows how to configure a network to run Sparse
mode using Auto-RP and two Candidate-RPs/Mapping Agents.
Note: A common practice is to combine the function of Candidate-RP and
Mapping Agent on the same router. This is done more as a configuration
convenience than for any operational requirement.
One every router in the network:
Configure the ip multicast-routing global command to enable multicast on
the router.
Configure the ip pim sparse-dense-mode interface command on EVERY
interface on each router. This allows the Auto-RP groups to function in
Dense mode and all other groups to operate in Sparse or Dense mode
depending on whether an RP has been configured for the group.
On the router(s) that are to function as Candidate-RPs, configure the ip pim
send-rp-announce Loopback0 scope <ttl> command. (Make sure the <ttl>
value is sufficient to allow the message to reach all Mapping Agents in the
network.)
On the router(s) that are to function as Mapping Agents, configure the ip
pim send-rp-discovery Loopback0 scope <ttl> command. (Make sure the
<ttl> value is sufficient to allow the message to reach all routers in the
network.)
No additional configuration is generally necessary. The network is now
completely enabled for IP Multicast!

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

C-RP
[Link]

C
C

Announce

MA
B
B
Announce

Announce

A
A

Announce

Announce

MA

D
D
Announce

Announce

Auto-RPFrom 10,000 Feet

Announce

C-RP
[Link]

RP- Announcements multicast to the

Cisco Announce ([Link]) group
Announce

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Auto-RP - The big picture

In this example, routers A and B have been configured as Mapping Agents while
routers C & D have been configured as Candidate RPs.
Step 1
The Candidate RPs begin multicasting their candidacy to be the RP via RP Announce messages which are sent via the Cisco-Announce group,
[Link].

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

MA

C-RP
[Link]

C
C

Dis
cov
ery

A
A

Disc
ove
ry

MA

Dis
cov
ery

B
B
Disc
ove
ry

Dis
cov
ery

Disc
ove
ry

Dis
cov
ery

Auto-RPFrom 10,000 Feet

Disc
ove
ry

D
D

C-RP
[Link]

RP-Discoveries multicast to the

Cisco Discovery ([Link]) group
Discovery

Module6. ppt

10
10

1998 2001, Cisco Systems, Inc. All rights reserved.

Auto-RP - The big picture

Step 2
The two Mapping Agents (routers A & B) receive the RP-Announce
messages from the two Candidate RPs (routers C & D).
Step 3
The C-RP with the highest IP address (in this case, router D) is stored in the
Group-to-Mapping cache of the Mapping Agents.
Step 4
The Mapping Agents both multicast the contents of their Group-to-RP
Mapping Cache to the Cisco-Discovery group, [Link].
Note: All Mapping Agents are transmitting this Group-to-RP Mapping
information simultaneously. The originally published specification on AutoRP implied that there was a Master-Slave relationship between Mapping
Agents and that only the Master would transmit while the Slave(s ) were
quiet until the Master failed. This specification is in error and this is not how
Auto-RP has been implemented. As long as both Mapping Agents are
transmitting identical information, there is no need to add the complexity of a
Master-Slave failover scheme.
Step 5
The RP Discovery messages are received via multicast by all routers in the
network. The Group-to-RP mapping information contained in these
messages is stored in the routers local Group-to-RP mapping cache. This
information is subsequently used by the router to determine the IP address
of the RP for a given group.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

10

Auto-RPA Closer Look

MA

C-RP
[Link]

Rtr -A# show ip pim rp mapping

This system is an RP -mapping agent

C-RP
[Link]

D
Initial Cache State in the Mapping Agent

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

11
11

Auto-RP Up Close
This is the same example that was presented in the previous slides. However,
in this case, we will examine the process in more detail at each step.
Step 1
At time zero, the Group-to-RP mapping caches in the Mapping Agents are
empty since no RP-Announcements have been received.
The output of the show ip pim rp mapping command shows that router A is
a Mapping Agent and that the Group-to-RP mapping cache is empty.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

11

Auto-RPA Closer Look

MA

A
0/4
.0.
4.0
2
=2
.1 ge ec
.1.1 Ran 80 s nce
1
- 1 ou
=
=
RP roup ime Ann
G oldt
H

R
G P=
Ho roup 2.2.2
ldt
im -R .2
e a
An = 1 nge
no 80 = 2
un sec 24
ce
.0.
0.0
/4

Rtr -A# show ip pim rp mapping

This system is an RP -mapping agent

C-RP
[Link]

Group(s) [Link]/4
RP [Link] (Rtr
(Rtr -D),
D), v2v1
Info source: [Link] (Rtr -D), via Auto-R P
Uptime: 00:00:03, expires: 00:02:57
RP [Link] (Rtr -C), v2v1
Info source: [Link] (Rtr -C), via Auto-R P
Uptime: 00:00:11, expires: 00:02:49

C-RP
[Link]

C-RP Information is Stored in MAs Group-to-RP Mapping Cache

Mapping Agent elects highest IP Address as RP
Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

12
12

Auto-RP Up Close
Step 2
Routers C and D begin sending their RP Announce messages advertising
themselves as a candidate to be RP for all multicast groups. (Note the
group range, the IP address of the C-RP and the holdtime in the message.)
Step 3
The Mapping Agent (router A) receives these RP Announcements and
stores this information in its Group-to-RP mapping cache.
The output of the show ip pim rp mapping command on the Mapping Agent
(router A) now shows both router C and D as candidates for group range
[Link]/4 (i.e. all multicast groups with the exception of the Auto-RP
groups).
The Mapping Agent then elects the C-RP with the highest IP address as the
active RP for the group range.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

12

Auto-RPA Closer Look

MA

R
G P=
Ho roup 2.2.2
ldt
.
im - R 2
e an
g
= e=
Di 180 224
sc se .0.
ov c 0.0
ery
/4

/4
.0.0
4.0
22 c
e= se
2.2 ng 80
.2. Ra =1 ry
=2 ve
RP roup ime isco
G oldt D
H

Mapping Agent advertises elected RP via Discovery messages

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

13
13

Auto-RP Up Close
Step 4
The Mapping Agent begins advertising the results of the RP election to the
rest of the network via Auto-RP Discovery messages.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

13

Auto-RPA Closer Look

All Mapping Agents Must

Have Consistent Data !

MA

MA

[Link]

[Link]

Rtr -A# show ip pim rp mapping

This system is an RP -mapping agent

Rtr -B# show ip pim rp mapping

This system is an RP -mapping agent

Group(s) [Link]/4
RP [Link] (Rtr
(Rtr -D), v2v1
Info source: [Link] (Rtr -D), via Auto-R P
Uptime: 00:00:03, expires: 00:02:57
RP [Link] (Rtr -C), v2v1
Info source: [Link] (Rtr -C), via Auto-R P
Uptime: 00:00:11, expires: 00:02:49

Group(s) [Link]/4
RP [Link] (Rtr
(Rtr -D), v2v1
Info source: [Link] (Rtr -D), via Auto-R P
Uptime: 00:00:03, expires: 00:02:57
RP [Link] (Rtr -C), v2v1
Info source: [Link] (Rtr -C), via Auto-R P
Uptime: 00:00:11, expires: 00:02:49

Module6. ppt

14
14

1998 2001, Cisco Systems, Inc. All rights reserved.

Auto-RP Up Close
It is critical that all Mapping Agents in the PIM-SM domain have identical
information in their Group-to-RP mapping caches. Note that in our example
network, they do.
If the information in the mapping caches are not identical, it can cause the
routers in the network to flip-flop between two different RPs.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

14

Auto-RPA Closer Look

Local Cache Initially Loaded from Router B
Rtr -X# show ip pim rp mapping

MA

B
[Link]

RP D
G = 2 isc
Ho roup .2.2 over
ldt -R .2 y
im a
e = ng
18 e =
0 s 22
ec 4.0
.0.0
/4

[Link]

MA

Group(s) [Link]/4
RP [Link] (Rtr -D), v2v1
Info source: [Link] ( Rtr -B), via Auto- RP
Uptime: 00:00:03, expires: 00:02:57

Module6. ppt

15
15

1998 2001, Cisco Systems, Inc. All rights reserved.

Auto-RP Up Close
Step 6
Assume that router B is the first MA to send its RP Discovery message
containing its Group-to-RP mapping cache contents.
Step 7
The routers in the network (router X in this example) all receive this RP
Discovery message and install the information in their local Group-to-RP
mapping cache.
The output of the show ip pim rp mapping command shows that router D is
currently selected as the RP for group range [Link]/4 (i.e. all multicast
groups with the exception of the Auto-RP groups) and that this information
was most recently received from router B.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

15

Auto-RPA Closer Look

Identical Info Received from Router A
Rtr -X# show ip pim rp mapping

MA

A
[Link]

MA

Group(s) [Link]/4
RP [Link] (Rtr -D), v2v1
Info source: [Link] ( Rtr -A ),
) via Auto- RP
Uptime: 00:00:03, expires: 00:02:57

B
[Link]

ry
.0/4
ve
co
.0.0
24
Dis
=2
2.2 e c
.2. ang se
= 2 - R 180
RP oup e =
Gr ldtim
Ho

Info source will

continue to flip-flop
between routers
A and B
No performance impact
X

Module6. ppt

16
16

1998 2001, Cisco Systems, Inc. All rights reserved.

Auto-RP Up Close
Step 8
Next, router A sends an RP Discovery message containing its Group-to-RP
mapping cache contents.
Step 9
The routers in the network (router X in this example) all receive this RP
Discovery message and update the information in their local Group-to-RP
mapping cache. Since both Mapping Agents are sending identical
information, the only thing that will change in the local Group-to-RP mapping
cache is the source of the information.
The output of the show ip pim rp mapping command shows that router D is
still selected as the RP for group range [Link]/4 (i.e. all multicast groups
with the exception of the Auto-RP groups). However, the data reflects that
this information was most recently received from router A.
The flip-flop of the information source in the routers local Group-to-RP
mapping cache has little or no performance impact on the router.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

16

Module Agenda

Auto RP
PIMv2 BSR
Static RPs
Tuning RP Operations
Debugging RP Operation
Special Cases

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Copyright ? ?1998-2001, Cisco Systems, Inc.

17
17

[Link]

17

PIMv2 BSR Overview

A single Bootstrap Router (BSR) is elected
Multiple Candidate BSRs (C-BSR) can be configured
Provides backup in case currently elected BSR fails

C-RPs send C-RP announcements to the BSR

C-RP announcements are sent via unicast
BSR stores ALL C-RP announcements in the RP-set

BSR periodically sends BSR messages to all routers

BSR Messages contain entire RP-set and IP address of
BSR
Messages are flooded hop-by-hop throughout the network
away from the BSR

All routers select the RP from the RP-set

All routers use the same selection algorithm; select same
RP

BSR cannot be used with Admin-Scoping

Module6. ppt

18
18

1998 2001, Cisco Systems, Inc. All rights reserved.

BSR Overview
Bootstrap Router (BSR)
A single router is elected as the BSR from a collection of Candidate BSRs.
If the current BSR fails, a new election is triggered.
The election mechanism is pre-emptive based on C-BSR priority.
Candidate RPs (C-RPs)
Send C-RP announcements directly to the BSR via unicast. (Note: C-RPs
learn the IP address of the BSR via periodic BSR messages.)
The BSR stores the complete collection of all received C-RP
announcements in a database called the RP -set.
The BSR periodically sends out BSR messages to all routers in the network to
let them know the BSR is still alive.
BSR messages are flooded hop-by-hop throughout the network.
Multicast to the All-PIM Routers group ([Link] ) with a TTL of 1.
BSR messages also contain:
The complete RP-set consisting of all C-RP announcements.
The IP Address of the BSR so that C-RPs know where to send their
announcements.
All routers receive the BSR messages being flooded throughout the network.
Select the active RP for each group range using a common hash algorithm
that is run against the RP-set. This results in all routers in the network
selecting the same RP for a given group-range.
BSR cannot be used with Admin-Scoping!
Admin scoping was not considered when BSR was designed. One problem
is that C-RP announcements that are unicast to the BSR cross multicast
boundaries. There are several other problems as well.
Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

18

PIMv2 BSR Fundamentals

Candidate RPs
Unicast PIMv2 C-RP messages to BSR
Learns IP address of BSR from BSR messages
Sent every rp-announce-interval (default: 60 sec)

C-RP messages contain:

Group Range (default = [Link]/4)
Candidates RP address
Holdtime = 3 x <rp-announce-interval>

Configured via global config command

ip pim rp-candidate <intfc> [group-list acl]

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

19
19

BSR Candidate RPs (C-RP)

C-RP Messages
Sent periodically (default: 60sec) directly to the BSR via unicast.
Messages contain the Group-range, C-RP address and a holdtime.
The IP address of the current BSR is learned from the periodic BSR
messages that are received by all routers in the network.
C-RPs are configured using the following command:
ip pim rp-candidate <intfc> [group-list <acl>]
The <intfc> parameter dictates the IP Address that is advertised in the C-RP
message. In most cases, a Loopback interface is used.
The optional group-list access-list can be used to specify a group-range
other than the default of [Link]/4 (i.e. all multicast groups)
This command may be configured more than once on a router so that the
router will function as C-RP for multiple group ranges.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

19

PIMv2 BSR Fundamentals

Bootstrap router (BSR)
Receive C-RP messages
Accepts and stores ALL C-RP messages
Stored in Group-to-RP Mapping Cache w/holdtimes

Originates BSR messages

Multicast to All-PIM-Routers ([Link]) group
(Sent with a TTL = 1)

Sent out all interfaces. Propagate hop-by-hop

Sent every 60 seconds or when changes detected

BSR messages contain:

Contents of BSRs Group-to-RP Mapping Cache
IP Address of active BSR
Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

20
20

Bootstrap Router
The primary purpose of the Bootstrap router is to collect all C-RP
announcements in to a database called the RP -set and to periodically send the
RP-set out to all other routers in the network inside of BSR messages.
BSR Messages
Sent periodically (default: 60 secs) by the BSR out all multicast interfaces.
BSR messages are multicast to the All-PIM-Routers ([Link]) group with
a TTL of 1. These messages are received by all PIM neighbors who
retransmit them (again with a TTL of 1) out all interfaces except the one in
which the messages was received. (An RPF check is done to insure the
BSR message came in on the correct interface in the direction of the BSR.)
BSR messages contain the RP-set and the IP address of the currently active
BSR. (This is how C-RPs know where to unicast their C-RP messages.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

20

PIMv2 BSR Fundamentals

Candidate bootstrap router (C-BSR)
C-BSR with highest priority elected BSR
C-BSR IP address used as tie-breaker
(Highest IP address wins)

The active BSR may be preempted

New router w/higher BSR priority forces new election

Configured via global config command

ip pim bsr-candidate <intfc> <hash-length> [priority <pri>]

<intfc>
Determines IP address

<hash-length>
Sets RP selection hash mask length

<pri>
Sets the C-BSR priority (default = 0)
Module6. ppt

21
21

1998 2001, Cisco Systems, Inc. All rights reserved.

Candidate Bootstrap Routers (C-BSRs)

C-BSRs participate in the BSR election mechanism.
The C-BSR with the highest priority is elected as the BSR.
The highest IP address of the C-BSRs is used as a tie-breaker.
The election mechanism is preemptive. If a new C-BSR with a higher
priority comes up, it triggers a new election.
C-BSRs are configured using the following command:
ip pim bsr-candidate <intfc> <hash-length> [priority <pri>]
The <intfc> parameter is used to specify the BSRs IP address which is
forwarded in BSR messages. (This is where C-RPs will send their
messages if the C-BSR is elected as BSR.)
The <hash-length> parameter specifies the number of bits in the hash. This
can be used to control RP load balancing across a group range where
different RPs are selected for different groups within a group range whose
size is defined by the hash-length in bits.
The optional <pri> value permits the C-BSR to be configured with a priority
other than the default of zero.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

21

PIMv2 BSR Fundamentals

BSR election mechanism
C-BSRs:
Begin in Candidate-BSR state
BSR-Timeout timer started (150 seconds)
If higher priority (preferred) BSR message received
Restart timer and forward BSR message
Copy info to local Group-to-RP mapping cache
Otherwise, discard BSR message

If timer expires, transition to Elected-BSR state

While in Elected-BSR state

Periodically originate own BSR messages
Include local Group-to-RP mapping cache in msg

Return to Candidate-BSR state if preferred BSR

message (higher priority) received
Module6. ppt

22
22

1998 2001, Cisco Systems, Inc. All rights reserved.

BSR Election
How and when routers in the network forward BSR messages plays a key role in
the BSR election mechanism. The algorithm used to decide whether to process
and forward an incoming BSR message depends on whether the router is a
Candidate BSR or not.

BSR Message forwarding by C-BSR routers

C-BSRs operate in one of two states, Candidate-BSR or Elected-BSR. Initially,
a C-BSR comes up in C-BSR state.

C-BSR State
A BSR-Timeout timer started with a period of 150 seconds. If this timer expires,
the router transitions to the Elected-BSR State.
If a BSR message is received with higher priority than the C-BSRs priority, then
the BSR (whose address is in the BSR message) is considered to be preferred
and the BSR message is processed as follows:
The BSR-Timeout timer is reset.
The BSR message is forwarded out all other interfaces.
The RP-set in the BSR message is copied into the local Group-to-RP
mapping cache.
If a BSR message is received with a priority less than the C-BSRs priority, the
BSR message is simply discarded.

Elected BSR State

The router has been elected as the BSR and periodically originates BSR
messages containing the current RP-set.
If a BSR message is received from another router with a higher priority, forward
the BSR message and transition back to C-BSR state; otherwise discard the
BSR message.
Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

22

PIMv2 BSR Fundamentals

BSR election mechanism

Non C-BSRs (i.e., all other routers):
Start in Accept-Any state
Accepts first BSR message received
Saves BSR info and forwards BSR message
Transitions to Accept-Preferred state

While in Accept-Preferred state

Starts BSR-Timeout timer
Only accept and forward preferred BSR messages
(i.e., BSR messages with priority > current BSR priority)

Otherwise, discard BSR message

Return to Accept-Any state if timer expires

Module6. ppt

23
23

1998 2001, Cisco Systems, Inc. All rights reserved.

BSR Message forwarding by Non C-BSRs

Non C-BSR routers operate in two states, Accept-Any state and AcceptPreferred state. When a non C-BSR router boots up, it starts in the AcceptAny state.

Accept-Any State
Accept the first BSR message received and process it as follows:
Copy the RP -Set into the local Group-to-RP mapping cache.
Save the current BSR priority and BSR address in the BSR message.
Transition to the Accept-Preferred state.

Accept-Preferred State
Start the BSR-Timeout timer with a period of 150 seconds. If this timer expires,
transition back to the Accept-Any state.
Accept only BSR messages that are preferred. (A preferred BSR message is
one with a priority greater than or equal to the current BSR priority.) The
accepted BSR message is then processed as follows:
The BSR-Timeout timer is reset.
The BSR message is forwarded out all other interfaces.
The RP-set in the BSR message is copied into the local Group-to-RP
mapping cache.
Save the current BSR priority and BSR address in the BSR message.
If a BSR message is received with a priority less than the C-BSRs priority, the
BSR message is simply discarded. (Remember, the IP address of the BSR is
used to break any ties with the winner being the C-BSR with the highest IP
address.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

23

PIMv2 BSR Fundamentals

All PIMv2 routers

Receive BSR messages
Stored in local Group-to-RP Mapping Cache
Information used to determine active BSR
address

Selects RP using Hash algorithm

Selected from local Group-to-RP Mapping Cache
All routers select same RP using same algorithm
Permits RP-load balancing across group range

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

24
24

All PIMv2 Routers

Accept BSR messages based on the rules described in the previous pages.
When a BSR message is accepted:
The RP-Set in the BSR message is stored in the local Group-to-RP mapping
cache.
The BSR message is forwarded out all other interfaces (except the one in
which it was received) on the router.
Selects RP using a Hash Algorithm
The RP for a group is selected from the set of C-RPs (stored in the Groupto-RP mapping cache) that have advertised their candidacy for a matching
group-range.
The same hashing algorithm is used by all routers to select the RP from the
set of C-RPs in the RP-set. Since all routers run the same algorithm on the
same RP-set (received from the BSR), all routers will select the same RP
for a given group.
The hashing algorithm permits multiple C-RPs to load balance the duties of
RP across a range of groups. Only one C-RP will be selected as RP for any
single group in the group range. However, the hash algorithm may select
other C-RPs as RP for another group within the group range.
For example, given a BSR hash length of 30 bits being used on IP v4 group
addresses, this results in a remainder of 2 bits of an IPv4 address or 4 group
addresses that a C-RP will serve as RP. In this scenario, if C-RP routers A
and B both advertise their candidacy for group-range [Link]/24 and the
hash algorithm selects router A as RP for [Link], the hash length of 28
bits will also cause router A to be selected as RP for groups [Link],
[Link] and [Link] (i.e. a contiguous group range of of 4 addresses.) If
the hash algorithm selects router B as RP for group [Link], it will also
select router B for groups [Link], [Link] and [Link].
Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

24

Basic PIMv2 BSR

G
BSR Msgs

PIMv2
Sparse Mode
BSR Msgs
nt
me
ise
ert t)
v
Ad as
RP (unic
C-

C-RP

A
BSR Msgs

BSR

F
BSR Msgs
CRP
Ad
v
(un ertise
ica me
st)
nt

C-RP

E
BSR Msgs Flooded Hop -by-Hop

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

25
25

BSR Example
Step 1
Candidate RPs unicast their C-RP messages to the previously elected
BSR. (The C-RPs learned the IP address of the BSR from the BSR
messages that are being flooded throughout the network.)
Step 2
The BSR receives and stores ALL C-RP information in a database called the
RP-Set (which is stored in the Group-to-RP mapping cache on Cisco
routers).
Step 3
The BSR periodically sends BSR messages containing the RP -set out all of
its interfaces. These BSR messages are forwarded hop-by -hop away from
the BSR by all routers in the network. The RP -set is used by all routers in
the network to calculate the RP for a group using a common hash algorithm.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

25

Module Agenda

Auto RP
PIMv2 BSR
Static RPs
Tuning RP Operations
Debugging RP Operation
Special Cases

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Copyright ? ?1998-2001, Cisco Systems, Inc.

26
26

[Link]

26

Static RPs
Hard-coded RP address
When used, must be configured on every router
All routers must have the same RP address
RP fail-over not possible
Exception: If Anycast RPs are used. (See MSDP module.)

Command
ip pim rp-address <address> [group-list <acl>] [override]

Optional group list specifies group range

Default: Range = [Link]/4 (Includes AutoAuto- RP Groups!!!!)

Override keyword overrides Auto-RP information

Default: Auto-RP learned info takes precedence

Module6. ppt

27
27

1998 2001, Cisco Systems, Inc. All rights reserved.

Hard-code RP Addresses
Requires every router in the network to be manually configured with the IP
address of a single RP.
If this RP fails, there is no way for routers to fail-over to a standby RP.
The exception to this rule is if Anycast-RPs are in use. This requires
MSDP to be running between each RP in the network.

Command
ip pim rp-address <address> [group-list <acl>] [override]
The group-list allows a group range to be specified.
The default is ALL multicast groups or [Link]/4
DANGER, WILL ROBINSON!!!
The default range includes the Auto-RP groups ([Link] and [Link])
which will cause this router to attempt to operate these groups in Sparse
mode. This is normally not desirable and can often lead to problems where
some routers in the network are trying to run these groups in Dense mode
(which is the normal method) while others are trying to use Sparse mode.
This will result in some routers in the network being starved of Auto-RP
information. This in turn, can result in members of some groups to not
receive multicast traffic.
The override keyword permits the statically defined RP address to take
precedence over Auto-RP learned Group-to-RP mapping information.
The default is that Auto-RP learned information has precedence.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

27

Module Agenda

Static RPs
Auto RP
PIMv2 BSR
Tuning RP Operations
Debugging RP Operation
Special Cases

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Copyright ? ?1998-2001, Cisco Systems, Inc.

28
28

[Link]

28

RP Placement

Q: Where do I put the RP?

A: Generally speaking, its not critical

SPTs are normally used by default

RP is a place for source and receivers to meet
Traffic does not normally flow through the RP
RP is therefore not a bottleneck

Exception: SPT-Threshold = Infinity

Traffic stays on the shared tree
RP could become a bottleneck

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

29
29

PIM MFAQ (Most Frequently Asked Question)

Q: Where should I put the RP?
A: Generally speaking, it is not critical.
The default behavior of PIM-SM is to switch to the Shortest-Path Tree (aka
the Source Tree) and bypass the RP as soon as a new source is detected.
This means that in most cases, multicast traffic does not flow through the
RP. Therefore, the RP does not become a point of congestion.
The default behavior can be overridden in Cisco routers by setting the SPTThreshold to Infinity. This prevents the Cisco router from joining the SPT
and keeps all group traffic flowing down the Shared Tree. In this case, the
RP could become a bottleneck.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

29

RP Performance Considerations
CPU load factors

RP must process Registers

RP must process Shared-tree Joins/Prunes
RP must send periodic SPT Joins toward source
PIM performs RPF recalculation every 5 seconds
Watch the total number of mroute table entries in the RP

Shared-tree forwarding
Only when spt-threshold = infinity is in use

Memory load factors

(*, G) entry ~ 380 bytes + OIL size
(S, G) entry ~ 220 bytes + OIL size
Outgoing interface list (OIL) size
Each oil entry ~ 150 bytes
Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

30
30

RP Performance Considerations
CPU Load Factors
The RP will receive all Register messages for any new sources in the
network. Although processing of Register messages is done at Process
Level, the impact on the router is usually small since the RP will immediately
send back a Register-Stop message.
The RP will receive and must process all Shared Tree Join/Prune messages
from downstream routers on the Shared Tree. Downstream routers
continue to send periodic (once a minute) Join/Prune messages up the
Shared Tree. The number of these Join/Prune messages is generally quite
small and therefore has little impact on the RP.
The RP must send periodic (once a minute) SPT Joins toward all sources
for which it has members active on a branch of the Shared Tree.
In order to detect a network topology change, ALL PIM routers perform an
RPF recalculation on every (*, G) and (S, G) entry in the mroute table every
5 seconds. The impact of this will grow as the total number of entries in the
mroute table increase and as the number of entries in the unicast routing
table increase. (The later is due to the fact that each RPF calculation
requires the route to the source to be looked up in the unicast routing table.
If this table is quite large, as would be the case for poorly aggregated
address space, the lookup can take more effort than when the number of
entries is kept small.) Except for the following load factor, this is the most
significant CPU load factor.
Any traffic that does have to flow through the RP requires it to replicate the
packets out all outgoing interfaces.
Memory Factors
The amount of memory consumed by PIM is primarily a function of the size
of the mroute table. (See the numbers in the slide for details.)
Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

30

Dealing with Overloaded RPs

Increase CPU horsepower

Increase memory
Use SPTs if not already
Split RP load across several RPs!

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

31
31

Dealing with overloaded RPs

If possible, increase the CPU horsepower of the RP. In some cases, this can be
accomplished by changing the RP or RSP card in the router.
If the multicast traffic in the network results in an extremely large number of
mroute table entries, it may be necessary to increase the amount of memory in
the router. This scenario is not likely to occur except in the cases where a lowend router with a minimal amount of memory is used in a network with a large
number of multicast sources.
If the RP is overloaded due to the multicast packet replication and forwarding
demands, insure that Shortest Path Trees are in use by making sure all routers
in the network have an SPT-Threshold set to the default value of zero.
If all else fails, split the RP load across several RPs by assigning different group
ranges to different RPs. (The Anycast-RP technique can be used in
conjunction with MSDP to allow more than on RP to be active for a single group
and to share the load.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

31

Auto-RP Announcement Scope

RP Announcements Leaking
Outside of Network

PIM
Sparse Mode
Network
scope 16

scope 16
C
Candidate-RP
A
Mapping
Agent

B
Mapping
Agent

RP Announcements Not
Reaching this Map Agent
Network Diameter = 32 Hops
Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

32
32

Auto-RP Announcement Scope

Care must be taken in the selection of the TTL scope of RP Announcement
messages that are sent by C-RPs to insure that the messages reach all
Mapping Agents in the network.

Example
In the diagram above, an arbitrary scope of 16 was used in the ip pim send-rpannounce command on the C-RP router. However, the maximum diameter of
the network is greater than 16 hops and in this case one Mapping Agent is
further away than 16 hops. As a result, this Mapping Agent does not receive the
RP Announcement messages from the C-RP. This can cause the two Mapping
Agents to have different information in their Group-to-RP mapping caches. If
this occurs, each Mapping Agent will advertise a different router as the RP for a
group which will have disastrous results.
Notice also, that the C-RP is fewer than 16 hops way from the edge of the
network. This can result in RP Announcement messages leaking into adjacent
networks and causing Auto-RP problems in those networks.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

32

Auto-RP Announcement Scope

RP Announcements ([Link]) Blocked
from Leaving/Entering the Network Using
ip multicast boundary Commands

scope 32

scope 32

PIM
Sparse Mode
Network

C
Candidate-RP
A
Mapping
Agent

B
Mapping
Agent

Both Mapping Agents Are

Now Receiving Announcements
from the Candidate RP
Network Diameter = 32 Hops
Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

33
33

Auto-RP Announcement Scope

The best way to avoid the problems on the preceding page is to use a
sufficiently large enough scope so that the RP Announcement messages reach
all Mapping Agents in the network.

Example
In the above diagram, the maximum network diameter is 32. Therefore by
setting the scope to 32 or greater, we are assured that the RP Announcements
will reach both Mapping Agents shown in the example network.
In order to prevent RP Announcement messages from leaking into adjacent
networks, a multicast boundary is defined for the Cisco-Announce ([Link])
multicast group on all border routers in the network. This not only stops RP
Announcement messages from leaking out, it more importantly, stops any from
leaking in from adjacent networks.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

33

Auto-RP Discovery Scope

RP Discovery Messages
Leaking Outside of Network
RP Discovery Messages
Not Reaching this Router
(Assumes All Groups
Are Dense Mode)
scope 16

scope 16
A
Mapping
Agent

PIM
Sparse Mode
Network

Network Diameter = 32 Hops

Module6. ppt

34
34

1998 2001, Cisco Systems, Inc. All rights reserved.

Auto-RP Discovery Scope

Care must be taken in the selection of the TTL scope of RP Discovery
messages that are sent by Mapping Agents to insure that the messages reach
all routers in the network.

Example
In the diagram above, an arbitrary scope of 16 was used in the ip pim send-rpdiscovery command on the Mapping Agent. However, the maximum diameter
of the network is greater than 16 hops and in this case, at least one router is
further away than 16 hops. As a result, this router does not receive the RP
Discovery messages from the MA. This can result in the router having no
Group-to-RP mapping information. If this occurs, the router will attempt operate
in Dense mode for all multicast groups while other routers in the network are
working in Sparse mode.
Notice also, that the MA is fewer than 16 hops way from the edge of the
network. This can result in RP Discovery messages leaking into adjacent
networks and causing Auto-RP problems in those networks.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

34

Auto-RP Discovery Scope

RP Discoveries ([Link]) Blocked
From Leaving/entering the Network Using
ip multicast boundary Commands

RP Discovery Messages
Now Reaching this Router

scope 32

scope 32
A
Mapping
Agent

PIM
Sparse Mode
Network

Network Diameter = 32 Hops

Module6. ppt

35
35

1998 2001, Cisco Systems, Inc. All rights reserved.

Auto-RP Discovery Scope

The best way to avoid the problems on the preceding page is to use a
sufficiently large enough scope so that the RP Discovery messages reach all
routers in the network.

Example
In the above diagram, the maximum network diameter is 32. Therefore by
setting the scope to 32 or greater, we are assured that the RP Discovery
messages will reach the farthest router in the network.
In order to prevent RP Discovery messages from leaking into adjacent networks,
a multicast boundary is defined for the Cisco-Discovery ([Link]) multicast
group on all border routers in the network. This not only stops RP Discovery
messages from leaking out, it more importantly, stops any from leaking in from
adjacent networks.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

35

Constraining Auto-RP Messages

Need to Block Auto-RP Discovery ([Link])
and Announcement ([Link]) Messages
from Entering/Leaving the Network

Boundary
Router
scope 32

scope 32

scope 32

C
Candidate-RP

Module6. ppt

S0

scope 32
A
Mapping
Agent
Interface S0
ip multicast boundary 10

PIM
Sparse Mode
Network

access-list 10 deny [Link]

access-list 10 deny [Link]
access-list 10 permit any

1998 2001, Cisco Systems, Inc. All rights reserved.

36
36

Constraining Auto-RP Messages

This example shows how to configure the multicast boundary on a border router
so that Auto-RP messages do not leak into or out of the network.
On the border interface (in this case, Serial0) the ip multicast boundary
command is used.
The access list associated with the ip multicast boundary command is as
follows:
access-list 10 deny [Link]
access-list 10 deny [Link]
access-list 10 permit any
The above access list stops the flow of multicast traffic for the two Auto-RP
groups ([Link] and [Link]) while allowing all other multicast traffic
to enter or exit via interface Serial 0.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

36

Constraining BSR Messages

Need to Block All
BSR Message from
Entering/Leaving
Network
Border
Router
S0

Neighboring
PIMv2 Domain

PIMv2
Sparse Mode
Network
BSR Msgs

Interface S0
.
.
ip pim bsr-border

Module6. ppt

Need to Block All

BSR Message from
Entering/Leaving
Network

BSR Msgs
BSR

Border
Router
B

S0

Neighboring
PIMv2 Domain

Interface S0
.
.
ip pim bsr-border

37
37

1998 2001, Cisco Systems, Inc. All rights reserved.

Constraining BSR Messages

Like Auto-RP, allowing BSR messages to leak into or out of a network can
cause problems both in the local network and in adjacent networks.
In order to block BSR messages from entering or exiting on a given interface,
the ip pim bsr-border interface command can be used.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

37

Controlling RP Acceptance
What really determines if a router is the RP
Any router will assume the duties of the RP if:
It receives a (*,G) Join that contains an RP address that is
the IP address of one of its interfaces AND
The interface is multicast enabled AND
The RP address matches the RP in the Group-to-RP
mapping cache OR
There is no entry in the Group-to-RP mapping cache.

Misconfigured routers could create multiple RPs in the

network
Each sends a (*,G) Join with a different RP address
Each (*,G) Join results in another RP for the same group

The Accept-RP command provides additional control

(insurance?) to prevent this.
Module6. ppt

38
38

1998 2001, Cisco Systems, Inc. All rights reserved.

By default, a router operates as an RP for a group if:

It receives a (*, G) Join containing one of its addresses as the RP or
It receives a (S, G) Register message.

Basic sanity check

Routers will perform a rudimentary sanity check to see if it actually should be the
RP for group G by searching the Group-to-RP mapping cache for an entry for
group G. If an entry is found and the RP for the group is not this router, then
the router will discard the (*, G) Join or (S,G) Register and will not become the
RP. Otherwise, it will assume that it is the RP for group G and assume duties
of the RP.

Extended sanity checking

In order to provide additional control and sanity checking over which router
should be accepted as the RP, the IOS command ip pim accept-rp was
created.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

38

Controlling RP Acceptance
Accept-RP Command
Global configuration commands
ip pim accept-rp <rp-address> [<acl>]
ip pim accept-rp Auto-rp [<acl>]
ip pim accept-rp [Link] [<acl>]

Multiple commands accepted

Command list sorted in order shown above
Only one Auto-RP and one [Link] (wildcard)
accepted
Omitting ACL implies [Link]/4 group range

Search Rules
Top down search
Stop on RP address matchApply ACL and exit
Exception: Auto-RP denies RP/Group
Apply [Link] (wildcard) entry (if it exists)
Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

39
39

Command format
ip pim accept-rp <rp-address> [<acl>]
ip pim accept-rp Auto-rp [<acl>]
ip pim accept-rp [Link] [<acl>]
The option <acl> is used to specify which groups are valid using standard permit
and deny clauses.
Omitting the <acl> assumes a permit [Link] [Link].
If more than one of the above commands is configured, they are sorted in the
order shown above.
The Auto-rp entry matches any RP address learned via Auto-RP.
(Note: This form has implied deny clauses for the Auto-RP groups, [Link]
and [Link], that cannot be overridden in the optional <acl>. This helps
prevent the Auto-RP groups from accidentally switching to Sparse mode.)
The [Link] (wildcard) matches any RP address.
While multiple ip pim accept-rp <rp-address> commands may be configured,
only a single Auto-rp and a single [Link] (wildcard) command is accepted.

Search Rules
The list of configured commands is searched from top down and stops at the
first entry that matches the RP address.
The <acl> is applies and the RP is either permitted or denied.
Exception: If an Auto-RP entry denies an RP and a [Link] entry exists, the
[Link] entry is also tried.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

39

Controlling RP Acceptance

Accept-RP Command Usage

Case 1 Controlling Group mode
Case 2 Accepting (*, G) joins
Case 3 Accepting PIM registers at the RP

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Copyright ? ?1998-2001, Cisco Systems, Inc.

40
40

[Link]

40

Accept-RPCase 1

Controlling Group Mode

Router Has No
State for Group G
IGMP Join (G)

Accept-RP
Filter List

Search

Group
Group Address
Address

Module6. ppt

Groupto-RP
Mapping
Cache

Group
Group Address,
Address,
RP
RP Address
Address

State Creation
Engine

Permit
Permit

1998 2001, Cisco Systems, Inc. All rights reserved.

Sparse
Sparse Mode
Mode

41
41

Case 1 - Controlling Group Mode

If a router has no (*, G) state when an IGMP Membership Report is received for
group G, the router will apply the configured Accept-RP rules to determine if
there is a valid RP for this group or not. If there isnt, the (*,G) entry is created
and set as a Dense mode group. If there is a valid RP, the (*,G) entry is set in
Sparse mode.
Step 1
The Group-to-RP mapping cache is searched for the group address in the
IGMP Join message. If an entry is not found, then the group is created in
Dense mode.
Step 2
If a matching entry is found in the Group-to-RP mapping cache, the Group
and RP addresses are run through the Accept-RP filters. If a permit is
returned, then the group is created in Sparse mode; otherwise the group is
created in Dense mode.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

41

Accept-RPCase 2

Accepting (*, G) Joins

A
A

(*, G) Join Messages

Contain the RP Address
(*, G) Join

B
B

Accept-RP
Filter List

Group
Group Address
Address
RP
RP Address
Address

Module6. ppt

Join Processing
Engine

RP
RP Address
Address

Process
Process Join
Join

1998 2001, Cisco Systems, Inc. All rights reserved.

42
42

Case 2 - Accepting (*, G) Joins

If a router receives (*, G) Join it will apply the configured Accept-RP rules to
determine if the RP address contained in the (*, G) Join is valid or not.
Step 1 (not shown)
The Group-to-RP mapping cache is searched for the group address in the
(*, G) Join message. If an entry is found and it is a negative entry
indicating that the group has been forced to always be in Dense mode, then
the (*, G) Join is not accepted and an error message is generated.
Step 2
The Group and RP addresses (contained in the (*, G) Join) are run through
the Accept-RP filters. If a permit is returned, then the (*, G) Join is
processed normally; otherwise the (*, G) Join is dropped and an error
message is generated.

Example
When Auto-RP is in use, it is normally the case that the two Auto-RP groups,
[Link] and [Link] should be operating in Dense mode. However, if a
downstream router is misconfigured with a static RP address, it will send (*, G)
Joins for these Auto-RP groups. The routers that receive these (*, G) Joins will
create a (*,G) entry in Sparse mode for these Auto-RP groups. This can result
in portions of the network trying to operate these groups in Dense mode while
other parts of the network are operating in Sparse mode. This will generally
cause the Auto-RP mechanisms to fail. The following Accept-RP command will
cause a router to reject any (*,G) Joins for the Auto-RP groups and prevent
these Joins from propagating.
ip pim accept-rp Auto-rp

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

42

Accept-RPCase 3

Accepting PIM Registers at the RP

Unicast to One of As
Interface Addresses

(S, G) Register

Source S

B
B

Accept-RP
Filter List

Group
Group Address,
Address,
Interface
Interface Address
Address

Module6. ppt

RP

A
A

Permit
Permit

RP Processing
Engine

RP

Accept
Accept the
the
Register
Register

1998 2001, Cisco Systems, Inc. All rights reserved.

43
43

Case 3 - Accepting PIM Register messages

If a router receives PIM Register message, it will apply the configured AcceptRP rules to determine if the router is permitted to be the RP or not.
Step 1 (not shown)
The Group-to-RP mapping cache is searched for the group address in the
(*, G) Join message. If an entry is found and it is a negative entry
indicating that the group has been forced to always be in Dense mode, then
the PIM Register is not accepted, a Register-Stop is sent back to the firsthop router and an error message is generated.
Step 2
The Group (contained in the multicast packet encapsulated in the Register
message) and RP addresses (the destination IP address in the Register
message) are run through the Accept-RP filters. If a permit is returned,
then the PIM Register is processed normally; otherwise a Register-Stop is
sent back to the first-hop router and an error message is generated.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

43

Filtering C-RP Announcements

Use on Mapping Agents to filter out bogus C-RPs
Some protection from RP-Spoofing denial-of-service
attacks
Multiple commands may be configured as needed

Global command
ip pim rp-announce-filter rp-list <acl> [group-list <acl>]
rp-list <acl>
Specifies from which routers C-RP Announcements are accepted.

group-list <acl>
Specifies which groups in the C-RP Announcement are accepted.
If not specified, defaults to deny all groups

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

44
44

Filtering RP Announcements
Network Administrators may wish to configure Mapping Agents so that they will
only accept C-RP Announcements from well-known routers in the network. This
will prevent C-RP Announcements from bogus routers from being accepted and
potentially being selected as the RP.

Global Command
ip pim rp-announce-filter rp-list <acl> [group-list <acl>]
The rp-list <acl> specifies the IP address(es) from which C-RP announcements
will be accepted.
The option group-list <acl> specifies the group range(s) that are acceptable for
the routers in the rp-list. If not specified, the default group-list <acl> is
deny all
Multiple instances of this command may be configured.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

44

Controlling Source Registration

New global command - IOS 12.0(6)
ip pim accept-register [list <acl>] | [route-map <map>]

Used on RP to filter incoming Register messages

Filter on Source address alone (Simple ACL)
Filter on (S, G) pair (Extended ACL)
May use route-map to specify what to filter
Filter by AS-PATH if (m)BGP is in use.

Prevents unwanted sources from sending

First hop router blocks traffic from reaching net
Note: Source can still send traffic on local wire

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

45
45

Controlling Source Registration

In some cases, it may be desirable to control which hosts in the network can
actually source traffic to a group. While there is currently no way to prevent a
bogus source from transmitting traffic on its local segment, we can prevent it
from being registered to the RP. This will, in most cases, prevent this traffic
from going past the first-hop router and reaching other hosts in the network.
A new IOS command, ip pim accept-register was introduced which when
configured on an RP, controls which (S, G) Register messages will be accepted
and which will be rejected.

Global Command (IOS 12.0(6) or later)

ip pim accept-register [list <acl>] | [route-map <map>]
If the list <acl> is specified, the <acl> can either be a simple access list to
control which hosts may send to any groups or an extended access list that
specifies both source and group address combinations that are permitted or
denied from sending.
If the route-map <map> is specified, then only matching (S, G) traffic will be
accepted. (Note: This permits other matching criteria to be considered such as
AS-PATH.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

45

Module Agenda

Static RPs
Auto RP
PIMv2 BSR
Tuning RP Operations
Debugging RP Operation
Special Cases

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Copyright ? ?1998-2001, Cisco Systems, Inc.

46
46

[Link]

46

Debugging Auto-RP Operation

Understand the Auto-RP mechanisms
This is the fundamental debugging tool for problems with
Auto--RP!!!
Auto

Verify Group-to-RP Mapping Caches

First on the Mapping Agents
Other routers will learn Group-to-RP mapping info from these
routers
If not correct, use debug commands to see whats wrong

Make sure all MAs have consistent Group-to-RP information

If not, watch for TTL Scoping problems

Then on other routers

If info doesnt match MA, there is a problem distributing the
information
Use show and debug commands to find where the break is
Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

47
47

Debugging Auto-RP
First and foremost, you must understand the fundamental mechanisms behind
Auto-RP in order to debug problems!
Verify Group-to-RP Mapping Caches on Mapping Agents
Because other routers in the network will learn the Group-to-RP mapping
information from the Mapping Agents, it is important that this information is
correct on the Mapping Agents. If the information is not correct, verify that
the C-RPs are configured correctly and that C-RP Announcements are
being received properly by the Mapping Agent.
If multiple Mapping Agents are in use, make sure that their Group-to-RP
mapping information is identical. If not, the routers in the network will
oscillate between the different RPs selected by the Mapping Agents. Again,
make sure all Mapping Agents are properly receiving Auto-RP
Announcements from all C-RPs in the network. Watch out for TTL scoping
problems!
Verify Group-to-RP Mapping Caches on all other routers
Group-to-RP mapping information should match the MAs. If not, verify that
the router is properly receiving Auto-RP Discovery messages from the
Mapping Agents. Again, watch out for TTL scoping problems!

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

47

Debugging Auto-RP Operation

Insure Auto-RP group state is correct

Should normally be in Dense mode
Watch out for mixed DM and SM conditions
Can occur when Static RPs are also defined
Always deny Auto-RP groups on Static RP configurations

Use Accept-RP filters on all routers as insurance

Watch out for DM problems in NBMA networks

(See Module 7 for details)

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

48
48

Common Problem - Incorrect Auto-RP Group mode

The two Auto-RP groups, [Link] and [Link] are normally run in Dense
mode so that this information is flooded throughout the network. Only in very
rare situations is it desirable to run these two groups in Sparse mode because
this creates a chicken-and-the-egg problem. (How do you join the RP for the
Auto-RP groups if you dont know the RP address?)
Therefore, the following situations should be verified:
Insure that the Auto-RP groups are operating in Dense mode on all routers in
the network.
Mixed DM/SM situations can arise when static RP addresses have been
configured on some routers in the network. To avoid this:
Always specify an <acl> on any ip pim rp-address commands that denies
groups [Link] and [Link].
Configure Accept-RP filters on all routers in the network that deny groups
[Link] and [Link].
(Note: The ip pim accept-rp auto-rp command has an implied set of deny
clauses for these two groups to prevent them from switching into Sparse
mode.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

48

Debugging BSR Operation

Understand the BSR mechanisms
This is the fundamental debugging tool for problems
with BSR!!!

Verify Group-to-RP Mapping Caches

First on the BSR
Other routers will learn Group-to-RP mapping info from this
router
If not correct, use debug commands to see whats wrong

Then on other routers

If info doesnt match BSR, there is a problem distributing
the information
Use show and debug commands to find where the break is

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

49
49

Debugging BSR Operation

First and foremost, you must understand the fundamental mechanisms behind
BSR in order to debug problems!
Verify Group-to-RP Mapping Caches on the elected BSR.
Because other routers in the network will learn the Group-to-RP mapping
information from the elected BSR, it is important that this information is
correct on this router. If the information is not correct, verify that the PIMv2
C-RPs are configured correctly and that C-RP Announcements are being
received properly by the BSR.
Verify Group-to-RP Mapping Caches on all other routers
Group-to-RP mapping information should match the BSR. If not, verify that
the router is properly receiving BSR messages.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

49

Module Agenda

Static RPs
Auto RP
PIMv2 BSR
Tuning RP Operations
Debugging RP Operation
Special Cases

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Copyright ? ?1998-2001, Cisco Systems, Inc.

50
50

[Link]

50

RP on a Stick
Triggering conditions on the RP:
A (*,G) entry (i.e. Shared Tree) exists with a
single outgoing interface on the RP.
And an (S,G) entry (i.e a Source) exists on the
same interface with a Null outgoing interface
list.

Results in special state at the RP

Frequently misunderstood and rarely seen
Default behavior is to join SPT which avoids this

Mishandled in versions of IOS prior to 12.0

Requires the Proxy Join Timer to resolve
Need to understand concept of atomic joins
Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

51
51

RP on a Stick
This is a special situation that occurs under the following conditions:
All branches of the Shared Tree are out a single interface on the RP (i.e.
there is only a single interface in the (*, G) OIL at the RP.)
All sources for the group are out the same interface. (This would result in
(S, G) entries with Null OILs since the incoming interface can never appear
in the OIL of an entry.)

Unusually State results in this condition

Special PIM rules had to be created that were not in the original PIMv2
specification in order to avoid situations where :
(S, G) traffic flows were incorrectly pruned.
(S, G) traffic continued to flow to the RP only to be dropped.
(S, G) state would get stuck in the RP and the First-Hop router even when
the source has long since stopped sending.
Problem was solved in IOS 12.0 by:
Special Proxy Join Timer and
Introduction of Atomic and Non-Atomic (*, G) Joins

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

51

RP on a Stick
RP
rtr-a
E0 [Link]

[Link] E1

[Link] E1

rtr-b
E0

Module6. ppt

rtr-c
E0

52
52

1998 2001, Cisco Systems, Inc. All rights reserved.

RP-on-a-Stick Example
Consider that above network topology where both rtr-b and rtr-c share a
common Ethernet segment with the RP.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

52

RP on a Stick
RP
rtr-a

Shared Tree

E0 [Link]

[Link] E1

[Link] E1

rtr-b

rtr-c

E0

E0

(*, [Link]), 00:01:21/00:02:59, RP [Link], flags: S

Incoming interface: Null, RPF nbr [Link],
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:01:21/00:02:39

Member
[Link]

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

53
53

RP-on-a-Stick Example
When a host behind rtr-c joins group [Link], a branch of the Shared Tree is
created (shown by the solid arrow) which results in the following state on the
RP:
(*, [Link]), 00:01:21/00:02:59, RP [Link], flags: S

Incoming interface: Null, RPF nbr [Link],

Outgoing interface list:

Ethernet0, Forward/Sparse, 00:01:21/00:02:39

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

53

RP on a Stick
RP
rtr-a

Shared Tree

E0 [Link]

[Link] E1

[Link] E1

rtr-b

rtr-c

E0

(*, [Link]), 00:01:21/00:02:59, RP [Link], flags: SC

Incoming interface: Ethernet1, RPF nbr [Link],
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:01:21/00:02:39

Module6. ppt

E0

Member
[Link]

1998 2001, Cisco Systems, Inc. All rights reserved.

54
54

RP-on-a-Stick Example
This also results in the following state on rtr-c:
(*, [Link]), 00:01:21/00:02:59, RP [Link], flags: SC

Incoming interface: Ethernet1, RPF nbr [Link],

Outgoing interface list:

Ethernet0, Forward/Sparse, 00:01:21/00:02:39

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

54

RP on a Stick
([Link], [Link])
Traffic Flow
Shared Tree

RP
rtr-a

SPT

E0 [Link]

[Link] E1

[Link] E1

rtr-b

Module6. ppt

rtr-c

E0

E0

Source
[Link]

Member
[Link]

1998 2001, Cisco Systems, Inc. All rights reserved.

55
55

RP-on-a-Stick Example
Now assume that source [Link] behind rtr-b begins sending to group
[Link]. After the normal Register process has completed, a branch of the
SPT (shown by the heave dashed arrow) is built from rtr-b to the RP. This
allows traffic to flow to the members as shown by the thin dashed arrows.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

55

RP on a Stick
([Link], [Link])
Traffic Flow
Shared Tree

RP
rtr-a

SPT

E0 [Link]

[Link] E1

[Link] E1

rtr-b

rtr-c

E0

E0

(*, [Link]), 00:01:21/00:02:59, RP [Link], flags: SP

Incoming interface: Ethernet1, RPF nbr [Link],
Outgoing interface list:
([Link]/32,Source
[Link]), 00:00:49/00:02:46, flags: T
Incoming interface:
192.1.1.1Ethernet0, RPF nbr [Link],
Outgoing interface list:
Ethernet1, Forward/Sparse, 00:00:49/00:02:11
Module6. ppt

Member
[Link]

1998 2001, Cisco Systems, Inc. All rights reserved.

56
56

RP-on-a-Stick Example
The creation of the SPT results in the following state on rtr-b:
(*, [Link]), 00:01:21/00:02:59, RP [Link], flags: SP
Incoming interface: Ethernet1, RPF nbr [Link],
Outgoing interface list:
([Link]/32, [Link]), 00:00:49/00:02:46, flags: T
Incoming interface: Ethernet0, RPF nbr [Link],
Outgoing interface list:
Ethernet1, Forward/Sparse, 00:00:49/00:02:11

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

56

RP on a Stick
([Link], [Link])
Traffic Flow
Shared Tree

RP
rtr-a

SPT

E0 [Link]

[Link] E1

[Link] E1

rtr-b

rtr-c

E0

E0

(*, [Link]), 00:02:43/00:02:59, RP [Link], flags: S

Incoming interface: Null, RPF nbr [Link],
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:02:43/00:02:17
([Link]/32, [Link]),
Source 00:00:49/00:02:46, flags: PT
Incoming interface: Ethernet0, RPF nbr [Link],
[Link]
Outgoing interface list:

Member
[Link]

Normally results in the suppression of (S,G) Joins

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

57
57

RP-on-a-Stick Example
The creation of the SPT also results in the following state on the RP:
(*, [Link]), 00:02:43/00:02:59, RP [Link], flags: S
Incoming interface: Null, RPF nbr [Link],
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:02:43/00:02:17
([Link]/32, [Link]), 00:00:49/00:02:46, flags: PT
Incoming interface: Ethernet0, RPF nbr [Link],
Outgoing interface list:
Notice that the OIL of the (S, G) entry is Null which, in turn, results in the P flag
being set. Normally, this would cause the RP to send an (S, G) Prune toward
the source to shut off the flow of (S, G) traffic. However in this case, that would
starve the host behind rtr-c of the desired group traffic. Obviously, something
else must be done to prevent this.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

57

RP on a Stick

Solution requires three new concepts

Atomic & Non-Atomic Joins
Proxy Join Timer/Flag
Header-only Registers

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

58
58

RP-on-a-Stick Solution
In order to deal of this special situation, several new concepts were added to the
12.0 implementation of PIM. These are:
Atomic vs. Non-Atomic (*, G) Joins
The Proxy Join Timer (and its flag) on (S, G) entries
Header-only Registers (aka Data-less Registers)
Each of the above are discussed in the following pages

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

58

RP on a Stick

Non-Atomic Joins
Contains (*, G) Join for group G only
This is the type of (*, G) Join we are familiar with

Atomic Joins
Contains (*, G) Join for group G followed by
(S, G)RP-bit Prunes for all sources in group G
Used to prune unnecessary (S, G) traffic from the Shared
Tree after switchover to the SPT.

All in the same PIM Join/Prune message

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

59
59

Non-Atomic Joins
This is a PIM Join/Prune message that contains only a (*, G) Join for group G
in the Join list without any associated (S, G)RP-bit Prunes for group G in the
Prune list.
This is the typical (*, G) Join that has been described in most of the
examples in Module 5, PIM -SM.

Atomic Joins
This is a PIM Join/Prune message that contains a (*, G) Join for group G in the
Join list AND a complete list of all (S, G)RP-bit Prunes for group G in the
Prune list.
Remember, these (S, G)RP -bit Prunes are used to Prune specific (S, G)
traffic off of the Shared Tree after a router has joined the SPT directly
toward the source.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

59

RP on a Stick
PIM Join/Prune Message
Header

Join List

([Link], [Link])

WC, RP

([Link], [Link])

WC, RP

([Link], [Link])

WC, RP

([Link], [Link])

RP

(*, G) Join
+ (S, G)RP-bit Prune

Atomic Join

.
([Link], [Link])

Prune List

([Link], [Link])

WC, RP

([Link], [Link])

RP

([Link], [Link])
.
.
.

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

60
60

Example: Atomic (*, G) Join

In this example, a (*, G) entry for group [Link] in the Join list of the PIM
Join/Prune message. (The WC (wildcard) and RP (RP -Tree) bits tell us that this
entry is a (*, G) Join to RP [Link])
In addition, there is an (S, G) entry for group [Link] ([Link], [Link])
with the RP-bit set in the Prune list. (I.e. an (S, G)RP-bit Prune exists for group
[Link]).
Because both a (*, G) Join along with one or more (S, G)RP-bit Prunes exist in
this Join/Prune message for group [Link], it is said to contain an Atomic (*,
G) Join for group [Link].

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

60

RP on a Stick
PIM Join/Prune Message
Header

Join List

([Link], [Link])

WC, RP

([Link], [Link])

WC, RP

([Link], [Link])

WC, RP

([Link], [Link])

RP

(*, G) Join
+ NO (S, G)RP-bit Prunes

Non-Atomic Join

([Link], [Link])

Prune List

([Link], [Link])

WC, RP

([Link], [Link])

RP

([Link], [Link])
.
.
.

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

61
61

Example: Non-Atomic (*, G) Join

Also in this example, is a (*, G) entry for group [Link] in the Join list of the
PIM Join/Prune message. (The WC (wildcard) and RP (RP-Tree) bits tell us
that this entry is a (*, G) Join to RP [Link])
In addition, there are no (S, G) entries for group [Link] with the RP-bit set in
the Prune list. (I.e. there are no (S, G)RP-bit Prunes for group [Link]).
Because only a (*, G) Join exists in this Join/Prune message for group [Link]
without any corresponding (S, G)RP -bit Prunes, it is said to contain an NonAtomic (*, G) Join for group [Link].

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

61

RP on a Stick
Proxy Join Timer
Used on (S, G) entries only
Started on the RP by the initial (S, G) Register
If (S, G) OIL is Null AND (*, G) OIL is Non-Null

Started/Restarted by receipt of a Non-Atomic Join

The X flag indicates when it is running
Times out in 2 minutes

Controls the sending of (S, G) Joins and Prunes down

the SPT
When Proxy Join Timer is Running (X flag set)
Send (S, G) Joins down SPT
Suppress sending any (S, G) Prunes down SPT
Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

62
62

Proxy Join Timer

The Proxy Join Timer only exists on (S, G) entries in the Mroute table. Its
purpose is to attract (S, G) traffic to the router even when the OIL of the (S, G)
entry is Null. This maintains the flow of (S, G) traffic in cases such as the RPon-a-Stick.

Proxy Join Timer Rules

The Proxy Join Timer is started when the RP receives the first (S, G) Register
message when a source goes active if:
The OIL is null in resulting (S, G) entry AND the OIL is non-Null in the (*, G)
entry. (This is the RP-on-a-Stick condition.)
The Proxy Join Timer is started whenever the router receives a Non-Atomic
(*,G) Join and an (S, G) entry already exists.
This timer runs for 2 minutes unless restarted by the receipt of another NonAtomic (*, G) Join.
When this timer is running on an (S, G) entry, the X flag will be displayed
in the flags field of the entry.
When the Proxy Join Timer is running, the router will:
Send periodic (S, G) Joins toward the source even though the OIL is Null.
Suppress the sending of (S, G) Prunes toward the source even though the
OIL is Null.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

62

RP on a Stick

Header-only Registers
Used to keep (S, G) state alive in the RP
Sent every 2 minutes by First-hop router
As long as source is still active
Continues sending until a Register-Stop is received

Register Messages contains null (S,G) data packet

Processed by the RP
Resets (S, G) entry timer at the RP
RP doesnt send Null packet down Shared Tree

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

63
63

Header-only (Data-less) Registers

Normally, the Expire timer of an (S, G) entry is reset to 3 minutes every time the
router forwards a packet associated with that entry. However, in the RP-on-aStick case, the (S, G) entry has a Null OIL and is therefore not forwarding any
packets. This would normally result in the (S, G) entry timing out at the RP. This
can not be allowed to happen as it is possible that another member somewhere
in the network could join the Shared Tree via another interface. If the (S, G)
entry was allowed to timeout, the RP would not be able to trigger the BatchJoin to rejoin the SPT when this new member joined. (Because there wouldnt
be any (S, G) entry to tell the RP of the active source.)
To prevent this from happening, the behavior of the First-Hop DR was changed
in IOS 12.0 so that (S, G) Header-only (aka Data-less) Registers would be sent
periodically (every 2 minutes) to the RP. These Header-only Registers cause
the RP to reset the Expire timer in the (S, G) entry thereby preventing it from
timing out.

Contents of Header-only Registers

Header-only Registers contain a specially formatted null or data-less (S, G)
packet.
These null (S, G) packets are not forwarded down the Shared Tree by the RP.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

63

RP on a Stick
Non-Atomic Join

RP
rtr-a

Normal Register
(S, G) Join

E0 [Link]

[Link] E1

[Link] E1

rtr-b

rtr-c

E0

E0

(*, [Link]), 00:02:43/00:02:59, RP [Link], flags: S

Incoming interface: Null, RPF nbr [Link],
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:02:43/00:02:17
00:02:43/00:02:17
([Link]/32, [Link]), 00:00:49/00:02:46, flags: PXT
PT
Incoming interface: Ethernet0
Ethernet0, RPF nbr [Link],
Source
Outgoing interface list: Null

[Link]

Member
[Link]

Trigger condition met: Proxy Join Timer started

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

64
64

RP-on-a-Stick Example
In this example, rtr-c is sending Non-Atomic (*, G) Joins to the RP to keep on
the Shared Tree. (Note that rtr-c has not joined the SPT at this point. This
could be due to the SPT-Threshold being set to Infinity.)
The RP is now running version 12.0 or later of IOS. Therefore, when the NonAtomic (*, G) Join for group [Link] is received, the RP starts the Proxy Join
Timer in all (S, G) entries for group [Link]. This results in the following state
in the RP:
(*, [Link]), 00:02:43/00:02:59, RP [Link], flags: S
Incoming interface: Null, RPF nbr [Link],
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:02:43/00:02:17
([Link]/32, [Link]), 00:00:49/00:02:46, flags: PX
XT
Incoming interface: Ethernet0, RPF nbr [Link],
Outgoing interface list:
Notice the X flag is set in the above example. This causes the RP to continue
sending (S, G) Joins toward the source (even though the OIL is Null) which, in
turn, will keep the traffic flowing to the member across the common Ethernet
segment.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

64

RP on a Stick
RP
rtr-a

Periodic (S, G) Joins

Header-only Registers

E0 [Link]

[Link] E1

[Link] E1

rtr-b

rtr-c

E0

E0

(*, [Link]), 00:02:43/00:02:59, RP [Link], flags: S

Incoming interface: Null, RPF nbr [Link],
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:02:43/00:02:17
([Link]/32, [Link]), 00:00:49/00:02:59
00:02:59, flags: PXT
Incoming interface: Ethernet0, RPF nbr [Link],
Source
Outgoing interface list:

[Link]

Member
[Link]

Expiration Timer restarted by

Header -only Registers
Module6. ppt

65
65

1998 2001, Cisco Systems, Inc. All rights reserved.

RP-on-a-Stick Example
The First-hop router (rtr-b) is also running version 12.0 or later of IOS and it will
therefore send periodic Header-only (S, G) Register messages to the RP.
When RP receives these Header-only (S, G) Registers, (roughly every 2
minutes), it resets the Expire timer in the corresponding (S, G) entry in the
Mroute table. This results in the following state in the RP:
(*, [Link]), 00:02:43/00:02:59, RP [Link], flags: S
Incoming interface: Null, RPF nbr [Link],
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:02:43/00:02:17
([Link]/32, [Link]), 00:00:49/00:02:59
00:02:59, flags: PXT
Incoming interface: Ethernet0, RPF nbr [Link],
Outgoing interface list:
(Notice the Expire timer in the (S, G) entry has been reset.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

65

Turnaround Router

Extension of the RP-on-a-Stick Problem

Occurs when the SPT and the Shared Tree share a single
common path
Want to avoid pulling traffic to the RP unnecessarily

Special state in the Turnaround Router

Uses special techniques to resolve
Proxy Join Timer
Atomic and Non-Atomic Joins
Header-only Registers

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

66
66

Turnaround Router
As it turns out, the RP-on-a-Stick problem is actually a special case of another
problem referred to the Turnaround Router problem. This situation occurs
whenever :
There is only a single branch of the Shared Tree and
the Shared Tree and a SPT share a common path to the RP.
We want to have the (S, G) traffic flow along the SPT toward the RP and
turnaround at the appropriate router in the network and flow back down the
Shared Tree without sending unnecessary traffic to the RP.

Turnaround Router Solution

Once again, the new concepts of
Proxy Join Timer
Atomic and Non-Atomic Joins
Header-only Registers
permit the routers to solve this problem.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

66

Turnaround Router
([Link], [Link])
Traffic Flow

RP

rtr-a
S0 [Link]

Shared Tree
SPT

S0 [Link]

rtr-x Turnaround Router

E0 [Link]

[Link] E1

[Link] E1

rtr-b

Module6. ppt

rtr-c

E0

E0

Source
[Link]

Member
[Link]

1998 2001, Cisco Systems, Inc. All rights reserved.

67
67

Turnaround Router Example

In this example, we once again have a single branch of the [Link] Shared
Tree at the RP.
The SPT for source ([Link], [Link]) merges with the single branch of the
[Link] Shared Tree at rtr-x. This router is referred to as the Turnaround
Router because it is here that we want the (S, G) traffic to turnaround and flow
back down the Shared Tree to the members of group [Link].
Additionally, we do not want the (S, G) traffic flow to all the way to the RP as it is
unnecessary traffic because there is only the single branch of the Shared Tree.
In cases where the number of hops between the Turnaround Router and the RP
is large or where the links along this path are congested, the flow of traffic to the
RP would simply waste precious network resources.
Instead, we want the traffic to only flow as shown by the thin dashed arrows in
the drawing above.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

67

Turnaround Router
Non-Atomic Joins

RP

rtr-a
S0 [Link]
S0 [Link]

rtr-x Turnaround Router

E0 [Link]
(*, [Link]), 00:02:43/00:02:59, RP [Link], flags: S
Incoming10.1.4.2
interface:
E1 Null, RPF nbr [Link], [Link] E1
Outgoing interface list:
Serial0, Forward/Sparse, 00:02:43/00:02:17

rtr-b

E0

Source
[Link]
Module6. ppt

rtr-c

E0
(*, [Link]), 00:02:43/00:02:59, RP [Link], flags: S
Incoming interface: Serial0, RPF nbr [Link],
Outgoing interface list:
Ethernet0, Forward/Sparse,
Member
00:02:43/00:02:17

[Link]

1998 2001, Cisco Systems, Inc. All rights reserved.

68
68

Turnaround Router Step-by-Step

Step 1
The host connected to rtr-c joins group [Link]. This causes rtr-c to
create (*, G) state and sends a Non-Atomic (*, G) Join toward the RP.
Step 2
The Turnaround Router (rtr-x) receives this Non-Atomic (*, G) Join and it too
creates (*, G) state and sends a Non-Atomic (*, G) Join to the RP.
Step 3
The RP receives the (*, G) Join and creates (*, G) state with only Serial0 in
the OIL.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

68

Turnaround Router
Non-Atomic Joins

RP

Normal Register

rtr-a
S0 [Link]
S0 [Link]

rtr-x Turnaround Router

E0 [Link]

[Link] E1

[Link] E1

rtr-b

rtr-c

(*, [Link]), 00:02:43/00:02:59,

E0
RP [Link], flags: S
Incoming interface: Null, RPF nbr [Link],
Outgoing interface list:
Serial0, Forward/Sparse, 00:02:43/00:02:17

E0

([Link]/32, [Link]), 00:00:49/00:02:59, flags: PXT

Incoming interface:
Serial0, RPF nbr [Link],
Source
Member
Outgoing interface list:

[Link]

[Link]

(S, G) Entry created & Proxy Join Timer started

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

69
69

Turnaround Router Step-by-Step

Step 4
The source, [Link], begins sending to group [Link]. This causes the
first-hop router (rtr-b) to send an (S, G) Register to the RP.
Step 5
The RP processes the Register message and creates an (S, G) entry.
Because the OIL of the newly created (S, G) entry is Null and the OIL of the
(*, G) entry is non-Null, the RP starts the Proxy Timer in the (S, G) entry and
sends an (S, G) Join toward the source.
At this point, the state in the RP is as follows:
(*, [Link]), 00:02:43/00:02:59, RP [Link], flags: S
Incoming interface: Null, RPF nbr [Link],
Outgoing interface list:
Serial0, Forward/Sparse, 00:02:43/00:02:17
([Link]/32, [Link]), 00:00:49/00:02:59, flags: PXT
Incoming interface: Serial0, RPF nbr [Link],
Outgoing interface list:
Notice that the Proxy Join Timer is running (note the X flag in the (S,G) entry.)
While the Proxy Join Timer is running, the RP will continue to send periodic
(S, G) Joins toward the source.
The Proxy Join Timer will be restarted each time the RP receives another
Non-Atomic Join from rtr-x.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

69

Turnaround Router
Non-Atomic Joins

RP

rtr-a
S0 [Link]

(S, G) Joins
S0 [Link]

rtr-x Turnaround Router

E0 [Link]

[Link] E1

[Link] E1

(*, [Link]), 00:02:43/00:02:59, RP [Link], flags: S

Incoming interface: Serial0, RPF nbr [Link],
Outgoing interface list:
E0
E0
Ethernet0, Forward/Sparse,
00:02:43/00:02:17

rtr-b

rtr-c

([Link]/32, [Link]), 00:00:49/00:02:59, flags: T

Incoming interface: Ethernet0, RPF nbr [Link],
Outgoing interface list:
Serial0, Forward/Sparse, 00:00:48/00:02:12

Source
[Link]
Module6. ppt

Member
[Link]

1998 2001, Cisco Systems, Inc. All rights reserved.

70
70

Turnaround Router Step-by-Step

Step 6
The (S, G) Join travels hop-by-hop building the SPT from the source to the
RP.
At this point, the state in the Turnaround Router (rtr-x) is as follows:
(*, [Link]), 00:02:43/00:02:59, RP [Link], flags: S
Incoming interface: Serial0, RPF nbr [Link],
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:02:43/00:02:17
([Link]/32, [Link]), 00:00:49/00:02:59, flags: T
Incoming interface: Ethernet0, RPF nbr [Link],
Outgoing interface list:
Serial0, Forward/Sparse, 00:00:48/00:02:12

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

70

Turnaround Router
Non-Atomic Joins

RP

rtr-a
S0 [Link]

(S, G) Joins
S0 [Link]

rtr-x Turnaround Router

([Link], [Link])
Traffic Flow

E0 [Link]

[Link] E1

[Link] E1

rtr-b

Module6. ppt

rtr-c

E0

E0

Source
[Link]

Member
[Link]
71
71

1998 2001, Cisco Systems, Inc. All rights reserved.

Turnaround Router Step-by-Step

Once rtr-b receives the (S, G) Join, traffic begins to flow as shown above.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

71

Turnaround Router
Non-Atomic Joins
Atomic Joins

RP

(Contains (*,G)Join + (S,G)RP-bit Prune)

rtr-a
S0 [Link]

(S, G) Joins
S0 [Link]

rtr-x Turnaround Router

([Link], [Link])
Traffic Flow

E0 [Link]

[Link] E1

[Link] E1

(*, [Link]), 00:02:43/00:02:59, RP [Link], flags: S

Incoming interface: Serial0,
Serial0, RPF nbr
nbr [Link],
Outgoing interface list:
E0
E0
Ethernet0, Forward/Sparse,
00:02:43/00:02:17

rtr-b

rtr-c

([Link]/32, [Link]), 00:00:49/00:02:59, flags: PT

Incoming interface: Ethernet0, RPF
RPF nbr
nbr [Link],
[Link],
Outgoing interface list:
Serial0, Forward/Sparse, 00:00:48/00:02:12

Source
[Link]
Module6. ppt

Member
[Link]

1998 2001, Cisco Systems, Inc. All rights reserved.

72
72

Turnaround Router Step-by-Step

Step 7
Router rtr-x detects that the paths of the SPT and the Shared Tree diverge
at this point. As a result, rtr-x begins sending periodic (S,G)RP-bit Prunes
up the Shared Tree in the same Join/Prune message with the periodic (*, G)
Joins. In other words, it begins sending Atomic Joins to the RP instead of
Non-Atomic Joins!
(Note: Router rtr-x knows that the SPT and Shared Tree paths have
diverged at this point because the RPF information (Incoming Interface
and/or RPF neighbor) of the (S, G) entry is different than the (*,G) entry.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

72

Turnaround Router
Non-Atomic Joins
Atomic Joins

RP

(Contains (*,G)Join + (S,G)RP-bit Prune)

rtr-a
S0 [Link]

(S, G) Joins
S0 [Link]

rtr-x Turnaround Router

([Link], [Link])
Traffic Flow

E0 [Link]

(*, [Link]), 00:02:43/00:02:59, RP [Link], flags: S

Incoming interface: Null, RPF nbr [Link],
E1 list:
[Link] E1
Outgoing10.1.4.2
interface
Serial0, Forward/Sparse, 00:02:43/00:02:17

rtr-b

rtr-c

([Link]/32, [Link]), 00:00:49/00:02:59, flags: PT

PXT
E0 Serial0, RPF nbr [Link],
E0
Incoming interface:
Outgoing interface list:

Source
[Link]
Proxy Join Timer eventually expires
(Non-Atomic Joins no longer being received)
Module6. ppt

Member
[Link]

1998 2001, Cisco Systems, Inc. All rights reserved.

73
73

Turnaround Router Step-by-Step

Because the RP is no longer receiving Non-Atomic Joins, the Proxy

Join Timer for the (S, G) entry is no longer being restarted and it eventually
times out. This is indicated by the X flag being clear in the (S, G) entry shown
below:
(*, [Link]), 00:02:43/00:02:59, RP [Link], flags: S

Incoming interface: Null, RPF nbr [Link],

Outgoing interface list:

Serial0, Forward/Sparse, 00:02:43/00:02:17

([Link]/32, [Link]), 00:00:49/00:02:59, flags: PT

Incoming interface: Serial0, RPF nbr [Link],

Outgoing interface list:

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

73

Turnaround Router
Non-Atomic Joins
Atomic Joins

RP

(Contains (*,G)Join + (S,G)RP-bit Prune)

rtr-a
S0 [Link]

(S, G) Joins
S0 [Link]

(S, G) Prunes

rtr-x Turnaround Router

([Link], [Link])
Traffic Flow

E0 [Link]

[Link] E1

[Link] E1

rtr-b

rtr-c

(*, [Link]), 00:02:43/00:02:59, RP [Link], flags: S

E0
Incoming interface: Serial0,
RPF nbr [Link],
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:02:43/00:02:17
([Link]/32, [Link]), 00:00:49/00:02:59, flags: PT
Incoming interface:
interface: Ethernet0, RPF nbr [Link],
Outgoing interfaceSource
list:
Serial0, Forward/Sparse,
00:00:48/00:02:12
[Link]

E0

Member
[Link]

Serial0 removed from (S, G) OIL Trigger condition met

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

74
74

Turnaround Router Step-by-Step

Step 8
Now that the Proxy Join Timer is no longer running, the RP resumes its
normal behavior and sends an (S, G) Prunes toward the source in response
to the arrival of (S, G) packets.
Step 9
When rtr-x receives the (S, G) Prune, it removes Serial0 from its outgoing
interface list. This results in the Turnaround trigger condition in rtr-x.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

74

Turnaround Router
Non-Atomic Joins
Atomic Joins

RP

(Contains (*,G)Join + (S,G)RP-bit Prune)

rtr-a
S0 [Link]

(S, G) Join
S0 [Link]

rtr-x Turnaround Router

([Link], [Link])
Traffic Flow

E0 [Link]

[Link] E1

[Link] E1

rtr-b

rtr-c

(*, [Link]), 00:02:43/00:02:59,

E0
RP [Link], flags: S
Incoming interface: Serial0, RPF nbr [Link],
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:02:43/00:02:17
([Link]/32, [Link]), 00:00:49/00:02:59, flags: PXT
PT
Incoming interface:
Ethernet0, RPF nbr [Link],
Source
Outgoing interface list:

[Link]
Proxy Join Timer started by next non-Atomic Join.
Module6. ppt

E0

Member
[Link]

1998 2001, Cisco Systems, Inc. All rights reserved.

75
75

Turnaround Router Step-by-Step

As a result of Serial0 being removed from the (S, G) OIL, the flow of traffic to the
RP is shutoff.
Step 10
Non-Atomic Joins arriving at rtr-x now start the Proxy Join Timer. (Note the
X flag in the (S, G) entry.) This causes the Turnaround Router (rtr-x) to
suppress sending (S, G) Prunes and instead, send (S, G) Joins toward the
source. This keeps the traffic flowing as shown.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

75

Turnaround Router
Non-Atomic Joins

RP

Final
Steady-State
Condition

rtr-a

Atomic Joins

S0 [Link]

(S, G) Joins
Header-only Registers
([Link], [Link])
Traffic Flow

S0 [Link]

rtr-x Turnaround Router

E0 [Link]

[Link] E1

[Link] E1

rtr-b

Module6. ppt

rtr-c

E0

E0

Source
[Link]

Member
[Link]

1998 2001, Cisco Systems, Inc. All rights reserved.

76
76

Turnaround Router
Step 11
Finally, Header-only Registers sent by the First-hop router (rtr-b) continue to
reset the Expire timer in the (S, G) entry at the RP. This prevents the (S, G)
entry from timing out and being deleted at the RP.

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

76

Turnaround Router
Non-Atomic Joins

RP

Final
Steady-State
Condition

rtr-a

Atomic Joins

S0 [Link]

(S, G) Joins
Header-only Registers
([Link], [Link])
Traffic Flow

S0 [Link]

rtr-x Turnaround Router

E0 [Link]

(*, [Link]), 00:02:43/00:02:59, RP [Link], flags: S

Incoming10.1.4.2
interface:
E1 Null, RPF nbr [Link], [Link] E1
Outgoing interface list:
Serial0, Forward/Sparse, 00:02:43/00:02:17

rtr-b

([Link]/32, [Link]),
00:00:49/00:02:59, flags: PT
E0
Incoming interface: Serial0, RPF nbr [Link],
Outgoing interface list:

Source
[Link]
Module6. ppt

rtr-c

E0

Member
[Link]

1998 2001, Cisco Systems, Inc. All rights reserved.

77
77

Turnaround Router
As a result of the Header-only Registers, the state in the RP will be as follows as
long as the source and member remain active:
(*, [Link]), 00:02:43/00:02:59, RP [Link], flags: S
Incoming interface: Null, RPF nbr [Link],
Outgoing interface list:
Serial0, Forward/Sparse, 00:02:43/00:02:17
([Link]/32, [Link]), 00:00:49/00:02:59, flags: PT
Incoming interface: Serial0, RPF nbr [Link],
Outgoing interface list:

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

77

Turnaround Router
Non-Atomic Joins

RP

rtr-a

Atomic Joins

S0 [Link]

(S, G) Joins
Header-only Registers
([Link], [Link])
Traffic Flow

S0 [Link]

Final
Steady-State
Condition

rtr-x Turnaround Router

E0 [Link]

[Link] E1

[Link] E1

(*, [Link]), 00:02:43/00:02:59, RP [Link], flags: S

Incoming interface: Serial0, RPF nbr [Link],
Outgoing interface list:
E0
E0
Ethernet0, Forward/Sparse,
00:02:43/00:02:17

rtr-b

rtr-c

([Link]/32, [Link]), 00:00:49/00:02:59, flags: PXT

Incoming interface: Ethernet0, RPF nbr [Link],
Outgoing interface list:

Source
[Link]
Module6. ppt

Member
[Link]

1998 2001, Cisco Systems, Inc. All rights reserved.

78
78

Turnaround Router
As a result of the Non-Atomic Joins, the state in the Turnaround router will be as
follows as long as the source and member remain active :
(*, [Link]), 00:02:43/00:02:59, RP [Link], flags: S
Incoming interface: Serial0, RPF nbr [Link],
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:02:43/00:02:17
([Link]/32, [Link]), 00:00:49/00:02:59, flags: PXT
Incoming interface: Ethernet0, RPF nbr [Link],
Outgoing interface list:

Copyright ? ?1998-2001, Cisco Systems, Inc.

[Link]

78

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Copyright ? ?1998-2001, Cisco Systems, Inc.

79

[Link]

79