PIM Rendezvous Points

johnny_jiang

                                               
There are two RP mechanisms supported by Cisco router:

• Cisco's Auto-RP
• PIMv2 Bootstrap router

Auto-RP (Cisco Proprietory)
=======
1. Messages in Auto-RP mechanism
Cisco-RP-Discovery (224.0.1.40)
All routers join this group to get the RP-group mapping information, mapping agent send RP-Discovery message to 224.0.1.40
Cisco-RP-Announce (224.0.1.39)
Mapping agent joins this group to get candidate RP announcement sent to 224.0.1.39
Both these two messages are sent every 1 minute, holdtime is 3 times longer (3min).
2. How to select the Group-RP mapping.
Since mapping agent receive quite a bit RP announcement, it will select RP for specific group range from these announcement. For the same group range, highest RP ip address will be used.
If a router fails to receive RP-Discovery messages and the Group-to-RP mapping information expires, the router switches to a statically configured RP that was defined with the ip pim rp-address command. If no statically configured RP exists, the router switches the group(s) to dense mode.
3. Set up Auto-RP
Set up a candidate RP
ip pim send-rp-announce interface scope ttl [group-list acl]
if group-list parameter is not specified, all multicast traffic will be served by this rp.
**********************
Set up a mapping agent
ip pim send-rp-discovery scope ttl

• This command will let router join RP-Announce multicast group. (224.0.1.39)
• Caching RP-Announce from candidate RP
• Select RP based on highest ip address
• Periodically send out RP-Discovery message to inform other routers Group-to-RP mapping

multiple mapping agents can stay in a network, because all of them are running same algorithm to calculate the mapping relationship.
Chicken-and-Egg problem
==========
Up to now, we learn how to use multicast to select RP, however, in SM network, if there's no RP info, how can we join 224.0.1.39/40 group and get RP info for other groups.
Solution 1: Define static RP
This is not the original intention for Auto-RP.
Solutino 2: ip pim sparse-dense-mode
224.0.1.39/40 will be treated as dense mode.
Multicast Boundary
===========
Care should be taken that the ttl argument should be set large enough for multicast packet (224.0.1.39/40 to reach mapping agent or joined routers).
Meanwhile, we can use the following command to confine multicast traffice
ip multicast boundary [acl num]
This command is configured in interface mode, so the interface will be the boundary for configured multicast group address.
RP spoofing
===========
ip pim rp-announce-filter rp-list acl [group-list acl]
This command should be configured on mapping agent who receives RP-Announce, this will filter RP-Announce message.
What RP will be accepted, based on these RP, what group range will be accepted.
((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
Bootstrap (Open standard)
=========
C-RP,C-BSR,BSR are three roles in bootstrap protocol.
C-BSR is for redundancy of BSR. ---> BSR is selected based on priority of C-BSRs. --> Highest priority will be prefered. If same, see highest ip --> all C-BSRs fail, go to static rp --> dense mode
1. C-RP sends their C-RP advertisement directly to elected BSR via unicast every 60 seconds, the holdtime will be 2.5 times.
2. BSR flood BSR message out all interface with PIMv2 neighbor every 60 seconds, and this message contains BSR router ip address and all Group-to-RP advertisements received from C-RPs, called candidate RP-set.
3. BSR messages sent by C-BSR (without RP-set) and elected BSR are flooded hop-by-hop all over the network. (224.0.0.13) Just like OSPF. When a router receives a BSR message, it will make a copy of it with ttl 1 to other neighbor routers.
4. BSR selection is preempted. New C-RP with higher priority will break the peace.
Set up bootstrap
==========
C-RP:
ip pim rp-candidate interface [group-list acl][interval secs]
C-BSR:
ip pim bsr-candidate interface hash-mask-length [priority]
               
                1. A unicast RP address that corresponds to the IP address of the interface specified in the bsrcandidate command.
2. The RP hash mask length specified in the hash-mask-length field of the bsr-candidate command.
3. The BSR priority specified in the optional priority field of the bsr-candidate command. (If this field is omitted, the BSR messages will contain a BSR priority of 0 by default.)
4. The complete candidate RP-set learned from all C-RPs via C-RP advertisement messages.
The router runs the hashing algorithm on all C-RP addresses in the RP-set whoseadvertised group range matches the target group. From this set of C-RPs, the one with the lowest hash value is selected as the active RP for target group G. If for some reason two C-RPs result in the same hash value, the tie is broken in favor of the C-RP with the highest IP address.
RP load balancing
==========
Other than Auto-RP, only one RP is available for group range at any moment. In BSR, several RP can loadbalance a group range.
For example:
239.0.0.1-239.0.0.4 will be taken care by two C-RPs, 192.168.1.1 and 192.168.1.2
basically 192.168.1.1 will be charge of 239.0.0.1 and 239.0.0.2
192.168.1.2 will be charge of 239.0.0.3 and 239.0.0.4
This is actually a distributed RP group.
How to allocate group addresses to multiple RPs is based on hash mask length.
For example:
hash mask length = 30 => mask will be 255.255.255.252 (0xFFFFFFFC) => 4 consecutive group address assigned to each router in turn
RP failover
===========
Since bootstrap router contains all C-RP advertisement entries and their holdtime, it is easy to do RP failover than Auto-RP (calculated by mapping agent).
bootstrap boundary
===========
Just like Auto-RP, we can use the following command to control bootstrap message boundary:
ip pim border
remeber: This is only affecting bootstrap message.
(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
Mroute Table Memory Requirements
(*, G) entry 260 bytes + outgoing interface list overhead
(S, G) entry 212 bytes + outgoing interface list overhead
Outgoing interface list overhead 80 bytes per outgoing interface list entry
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Force in dense mode
==============
ip pim accept-rp {rp-address | Auto-rp} [group-list acl]
The command above can do the following things:
1. Determining group mode (sparse/dense) when a (*, G) entry is being created in the multicast routing table as a direct result of a local host joining the group.
2. Accepting or rejecting an incoming (*, G) Join that has been sent by a downstream router. (The RP address to be validated is contained in the (*, G) Join message.)
3. Accepting or rejecting an incoming PIM Register message from a Designated Router.
For detail example, please check out my note and p346-p356. ^_^
This command can be used multiple times at a time.
The ip pim accept-rp command has the following three basic forms:
ip pim accept-rp rp-address [group-list acl]
ip pim accept-rp Auto-rp [group-list acl] (RPs from Group-to-RP map, 'sh ip pim rp mapping')ip pim accept-rp 0.0.0.0 [group-list acl]
The last two commands can only occur once on a router. Note: group-list cannot define 224.0.1.39/40, since they're treated as dense mode.
Note: Static defined rp address can cause  224.0.1.39/40 in sparse mode, so we should use this command to prevent this.
The rule is:
1. first match is not Auto-rp, do what rule says
2. first match is Auto-rp and invalid, check if there's 0.0.0.0 rule, do what it says
3. at last, no match means invalid


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/42903/showart_410326.html