PIM-SM with Auto-RP
Load multicast.init.cfg
Configure R2 and R4 to join (*, 239.1.1.1)
Configure R9 and XR4 as RPs for 239.1.1.0/24 using AutoRP.
Both CSR9 and XR4 should be mapping agents as well.
Use R1 and R3 as the sources to verify that multicast traffic is working.
Answer
Explanation
Auto-RP was the first mechanism created to automatically propagate RP information within a domain. This was created by Cisco and is Cisco-propreitary. Auto-RP is not supported for IPv6, so in this lab we will only test IPv4.
In Auto-RP, we configure candidate RPs to announce their group mappings to 224.0.1.39. A candidate RP is configured as follows:
Mapping Agents listen to 224.0.1.39 to learn about candidate RPs. Mapping Agents then select the best RP for a given mapping (the highest IP address), and disseminate this information to 224.0.1.40, which all PIM-SM routers listen for.
For this to work, 224.0.1.39 and 224.0.1.40 must be treated as dense mode. By default, IOS-XR treats this as dense mode, and you can disable this using auto-rp listen disable under router pim. IOS-XE requires you to use the global command:
A common deployment model is to use the same routers as mapping agents and candidate RPs, however this does not have to be the case. You can separate these functions onto different routers. Also note that when you have multiple mapping agents, all will actively propagate RP mappings. This is not a problem though, as all mapping agents will use the same selection method and end up all relaying redundant information.
The default interval for candidate RP messages is 60 seconds. Likewise the default interval for candidate RP mappings from the mapping agent is 60 seconds. This can be changed by setting the interval on the command enabling the feature. The scope keyword sets the TTL on the packets. The group-list keyword can refrence an ACL to set which groups the RP announces its interest in serving. This can be used to facilitate better failover which we will see later. Also remember to enable PIM-SM on the loopback that is used for AutoRP messages.
An RP announcement to 224.0.1.39 looks as follows. The default 224/4 announcement is “positive” because a “negative” announcement can be used to indicate that a given range should be treated as dense mode. Dense mode is not even supported on IOS-XR, so we won’t explore this.
The mapping agents will learn of all candidate RPs through these RP annoucements. We can see that R9 knows of both candidate RPs and has only selected R14 as the Auto-RP RP based on the higher IP address:
IOS-XR appears to only display the winning candidate RP:
The RP mapping looks as follows. It is sent to 224.0.1.40 which all Cisco routers by default listen for.
We should see on any other router in the domain that it only knows of XR4 as the RP:
We can now test multicast traffic by joining a group on the listeners:
We see on the LHRs that XR4 is the RP for the group:
The distribution tree is now setup between the RP and receivers.
The PIM register process works exactly the same as we have seen, so this is not demonstrated.
Failover Considerations
Currently, we can say that we have an active/standby setup. R9 is also advertising itself as candidate RP, but it cannot be propagated because XR4 has a higher IP address, and both RPs are advertising the same group mapping.
Unfortunately, failover in this situation is very slow. Let’s see what happens if we shut down Lo0 on XR4:
At this point, no new RP distribution trees can be built, and no new sources can be registered. The candidate RP announcement on the mapping agents will time out in three minutes. After three minutes, the mapping agents will select the next best RP, which is 1.0.0.9 in this case. So total failure time is three minutes, which is quite unacceptable in today’s networks.
The expiration time for a candidate RP advertisement is present as the “holdtime” in the RP announcement. This is three times the interval. So to speed up convergence, we can alter the interval for the candidate RP announcement.
The holdtime that XR4 advertises is now 6 seconds:
The RP mapping on R9 reflects that XR4’s candidate RP status will always expire within 6 seconds. XR4 must continually send RP announcements every 2 seconds. These are dense mode flooded, so this is not the most graceful solution.
However, this does work to fix the slow convergence. If we shut down XR4’s loopback, all other routers will learn of R9 as the RP from the RP mapping after 6 seconds. The mapping agent will immediately send the new RP mapping when XR4’s entry expires, even if its own interval is slower (i.e. 60 seconds).
Note that there is no priority configuration on candidate RPs in order to select one RP over the other for an identical mapping range. The mapping agents simply use the highest IP address, which is a bit crude. There is also no way to do load sharing for multiple RPs mapped to the same range, as only one is selected and propagated to all other PIM routers. BSR solves both of these issues, which we will see in the next lab.
Last updated
