Basic Multicast part 3 – PIM Sparse Mode – Auto-RP
Continuing with Multicast topic I will this time talk about PIM SM and Auto-RP. This post is the next part of the previous post called: “Basic Multicast part 2 – PIM Sparse Mode – Static RP” where I talked about how to configure PIM in Sparse Mode but I also explained and demonstrate the source registration process with the RP as well as SPT switchover.
The topology I am going to use in this post will be the same as the one I used in the previous multicast post.
Let´s consider the following topology:
Source: The multicast source 184.108.40.206 will be sending to multicast group 220.127.116.11 which is part of the administratively scoped addresses assigned by IANA which is for use in private multicast domains, much like the IP unicast range defined in RFC 1918.
RP: The RP is R4 with IP: 18.104.22.168
MA: the mapping agent is R3 with IP 22.214.171.124
IGP: The IGP used is EIGRP
Platform/IOS: Cisco 2691/12.4(15)T11 Adv IP services
We saw in the previous multicast post on PIM SM with static RP that all multicast enabled router need to know the IP address of the RP in order to build the shared tree and signal the RP of the presence of eventual multicast receivers for a specific multicast group.
I invite you to have a look at the previous post on PIM SM and static RP if you want some information on how PIM SM works and how to configure it with static RP.
Using static RP is maybe sufficient for simple PIM-SM networks that use a single RP for all multicast groups but it is not scalable when you have many routers as you have to manually make change on every router if necessary and at some point the RP address would be inconsistent across the routers in the network which will cause multicast outages.
Cisco introduce in IOS 11.1(6) Auto-RP that eliminated the need to manually configure the RP IP address on all the routers. Auto-RP use IP multicast to distribute group-to-RP information to all routers in the network. Auto-RP is a Cisco proprietary protocol and it was later replaced by the standards-based Bootsrap Router (BSR) protocol with the advent of PIMv2 (I will cover BSR) in the next post.
Auto-RP defines tow new concepts:
- Candidate RP (cRP)
- Mapping Agents (MA)
Candidates RP are the routers who are willing to become RP. A router is configured as a candidate RP using the following command: “ip pim send-rp-annonce interface scope ttl (group-list acl)”.
After this command is added the router starts to multicast RP-Announce messages to the Cisco-RP-Announce multicast group (126.96.36.199 UDP port 496) with a Time To Live (TTL) of ttl. Each message contains the IP address of the specified interface (often loopback) along with the multicast group range(s) (that were specified in the group-list option) that the router wants to be the RP for. If no group-list is not specified the router will announce itself as the RP for all the multicast groups that is to say: 188.8.131.52/4. Also note that the interface specified in the command must be enabled for PIM. cRP multicast RP-Announce messages every 60 seconds by default.
The cRP announcements are flooded across the network and reach special routers called Mapping Agents (MAs). Please note that MAs have to join the multicat group 184.108.40.206 in order to listen for the CRP announcements. MAs will gather all cRP announcements in a Group-to-RP database which in turn will be flooded to the special multicast IP address 220.127.116.11 UDP port 496. If there are multiple MAs in the network they will hear each other and only the one with the highest IP will remain active. MAs multicast RP-Discovery messages every 60 seconds by default.
MAs are configured with the following command: “ip pim sedn-rp-discovery <interface> scope <TTL> interval <seconds>”.
MAs use the following process when building a discovery message:
- If there are 2 announcements with the same group range but different RPs, the MA will select the RP with the highest RP IP address
- If there 2 announcements where one group is a subset of another, but the RP are different. Both will be sent.
All regular routers join the multicast group 18.104.22.168 and listen for the discovery messages send by the MA in order to learn Group-to-RP mapping.
One issue still remains though. If the network is configured in sparse mode and all routers are expected to learn the RP information via the RP-Discovery messages send from the MA to the multicast IP address 22.214.171.124 so how do they join the (*,126.96.36.199) shared tree if they don´t know the IP address of the RP? Furthermore how do they learn the IP of the RP if they don´t joined the shared tree? Well Dense Mode must be used for these groups as DM doesn´t need RP information because it is based on the “implicit join” model. In order to use DM for these 2 groups the following command should be configures on all the interfaces within the multicast domain: “pim sparse-dense-mode”. This command tells the router to use SM for groups with RP defined and use DM for groups without RP defined. The issue with this command is that all groups that haven´t a RP defined will work in DM which is not the safest thing to do in large-scale network. So you may want to use: “no ip dm-fallback” in global config or Auto-RP Listener which basically enable DM only for these 2 groups. I will briefly talk on Auto-RP listener later on in this post.
One advantage of the “pim sparse-dense-mode” is that the network administrator can control which groups are sparse and which are dense by modifying the configuration on a single router. For example:
ip pim send-rp-announce loopback 0 scope 16 group-list 10
Access-list 10 permit 188.8.131.52
The above configuration results in the router serving as the RP for group 184.108.40.206 and no other which means that all the groups except this one will work in DM.
The recommended method will be to use BSR which I will present in my next post. With BSR there is no need for Auto-RP as the BSR info will be advertised in PIM packets.
Let´s get started the Lab!
I will first remove the static RP configuration from the previous post: “no ip pim rp-address 220.127.116.11” on all routers and then I will start to configure the MA which is R3. Please note that the loopback 0 of R3 (IP:18.104.22.168/32) has already been advertised through EIGRP. Moreover all the interfaces in the multicast domain have been configured with: “pim sparse-dense-mode”.
The configuration of R3 as MA looks like that:
That means that R3 will send RP-Discovery message every 60 seconds (default) to the multicast IP address 22.214.171.124 which all the regular multicast routers listen to. Also note that this multicast group will operate in DM as we have configured PIM to work in sparse-dense-mode. That can be confirmed by the output bellow:
All the interface configured for PIM SM operate in DM for this group which means that as soon as R3 hears cRP announcement from R4 it will start to flood RP-to-Group mapping out all its interfaces in DM.
So let´s make R4 an RP candidate:
The above command tells R4 to announce itself as RP for all multicast group. The cRP announcement will be send to multicast IP address 126.96.36.199 which MA (R3) is listening to. As soon as we configure R4 to be a cRP candidate it starts to send RP-Announcements out all its interface (enabled for PIM) as shown by the debug output bellow:
We can also see the same output in Wireshark:
Let´s see what happen when R3 the MA receive the cRP-Announcement from R4:
From the debug output above we can see that R3 receive the cRP-Announcement from R4 and start announcing RP-Discovery message to 188.8.131.52 on all its PIM enabled interface for the following RP/Group mapping: 184.108.40.206/220.127.116.11/4. Also note that R4 forward the cRP-Announcement received from R4 to the interface listed in the OIL for the newly created (18.104.22.168, 22.214.171.124) which is in this case S0/0.1.
Moreover if you look at the multicast routing table of R3 we can see (S,G) entry for the two Auto-RP multicast groups:
From the output above we can see that R3 is the source of the packet destined to 126.96.36.199 as the RPF neighbor is NULL which means that it is himself likewise, the RPF neighbor for the (188.8.131.52, 184.108.40.206) is R4 as it is the cRP candidate sending announcement to 220.127.116.11.
Now let´s have a look at the other router and check if they have received the RP/Group mapping sent by R3. Let´s have a look at R2 first:
So R2 is receiving the RP-discovery from R3 which is find. We can also see that R2 has updated its Group/RP mapping table:
Let´s look at R1 Auto-RP counters:
So R1 hasn´t received any Auto-RP discovery message from R3.
Let´s look now at the multicast routing table of R2:
As we have learned from the previous posts, the outgoing interface list of a (S,G) is populated based on the (*,G) entry. But in this case s0/0 cannot be in the outgoing interface list of the (S,G) entry as this interface is already present in the incoming interface list. PIM general rule says that an incoming interface (RPF interface) of a multicast forwarding entry must never appear in its outgoing interface list. I have made an explanation of this in my earlier post on PIM DM and in this post we used some tunneling technique to solve the issue. The problem here is that R1 will never learn of the Group/RP mapping as R2 will not forward the (S,G) traffic from R3 to R1, the OIL is null which explained why is pruned. So how can we solve this issue and forward (18.104.22.168,22.214.171.124) over to R1 so it can get Group/RP mapping?
Auto-RP and RP/MA placement
Well the problem is similar to my previous post about PIM DM as we are trying to forward DM traffic out of the hub main interface received from a spoke (R3). In this case the multicast traffic is control plane traffic which is Auto-RP Discovery message sent from R3 to the multicast group 126.96.36.199 operating in DM. Our issue here is related to the place of the MA which is behind a spoke (R3). Due to PIM RPF split horizon rule R2 is not allowed to forward traffic received on S0/0 back to S0/0. There are 3 solutions to solve this issue:
- Use of subinterface
- Use tunneling technique (like I did in my previous post on PIM DM
- Move the MA (R3) behind the hub R2 so all spokes will be able to receive the Auto-RP discovery messages, in this case R1.
I will go ahead and configure R2 as a second MA with an IP of 188.8.131.52 (injected into EIGRP – Domain IGP in our example). When R2 is configured as the second MA Auto-RP discovery messages will now be sourced from R2 and in consequence R1 will receive the RP/Group mapping. R3 will still send Auto-RP discovery messages but they will be ignored by R2 due to the RPF split horizon rule. Note that having multiple MA multicasting identical Group-to-RP mapping information in RP-Discovery messages to all routers in the network allows MA redundancy. If one MA fails the other will take over. However in our example we have seen that in NBMA partial mesh network the MA should be place behind the HUB to avoid breaking the multicast Auto-RP control plane traffic. So it would be find to have 2 MAs but they should both be placed behind the hub R2. In our example we don´t give importance to this MA redundant design as long as R1 gets information about the RP/Group mapping. It is good to know that when having multiple MAs servicing the same Group/RP all routers in the network will create a single set of Group-to-RP mapping cache entries despite receiving redundant set of information from multiple MAs.
If you look now at the multicast forwarding table of R2 for (184.108.40.206, 220.127.116.11) we can effectively see that R2 is forwarding multicast packets for this group out its serial interface:
R2 is receiving Auto-RP announce messages from R4 and Auto-RP discovery messages from R3 but they are ignored due to RPF split horizon rule. Now R2 is sourcing its own Auto-RP discovery messages which result in R1 receiving them as we can see in the output bellow:
We now have Auto-RP control plane traffic everywhere in the network which means that all the routers in the multicast domain now know that R4 is the RP.
As in my previous post on PIM SM with Static RP let´s make R1 join the multicast group 18.104.22.168 and send some traffic to this group from the multicast source 22.214.171.124.
Please note that I will neither cover the source and RP registration process nor SPT switchover in this post becasue I did cover this 2 process in my previous post on PIM SM with static RP (so have a look if you want).
As soon as R1 join 126.96.36.199 it send a PIM join/prune (*,G) to R2. Remember that on a shared tree upstream routers receive PIM (*,G) join/prune through their outgoing interface then create an (*,G) entry with the OIL including the outgoing interface where the packet has been received on and calculate the RPF interface (incoming interface) towards RP based on the RP IP stored in the Group-to-RP mapping cache and the unicast routing table.
So in our example we can predict that R2 will receive the PIM (*,G) join/prune from R1 on its serial 0/0 interface which is its RPF interface. That means that R2 will not be able to add S0/0 to its OIL of the (*,G) entry due to RPF PIM rule which in turns means that R2 will not forward the PIM (*,G ) join/prune up to R4 as the OIL will be NULL and therefore pruned. Let´s if it is the case:
Indeed it is the case. So how can we solve this issue? There is different solutions among them tunneling, subinterface, move the RP behind the HUB, use PIM NBMA.
Well in my post about PIM DM I have talked about PIM NBMA mode which only works with PIM SM. Let´s see how this feature can help to solve the issue we have and how it works:
PIM NBMA Mode
PIM NBMA is an extension to PIM protocol operations on WAN interfaces which utilize the concept of virtual-circuits.
By default, all multicast packets are treated as broadcast on the Frame-Relay segment and queued in a special broadcast queue. Packet from this queue are replicated and sent over all active VCs that have the broadcast keyword configured. This operation is very CPU intensive as the replication of the broadcast/multicast packets are done by the CPU. Routing updates can also suffer as there are located in this broadcast queue.
Another point is that a router sees a NBMA network as a broadcast network from a L3 point of view. For example in our case we have a partial mesh Frame Relay network with R2 as a HUB and R1,R3 and R4 as the spokes. At R2 PIM sees that R1, R3, R4 as directly connected neighbor and assumes that if R3 is forwarding a multicast packet it will be received by R1 and R4 so as far as the R2’s Layer 3 PIM code is concerned, only a single copy of the multicast traffic must be sent out its serial interface. But the reality is at L2 R2 is not able to send only one copy of the packet but instead as to rely on pseudobroadcsat to provide R2´s layer 3 functions with the appearance of a broadcast medium and replicate the packet to all VCs.
Finally in Partial mesh NBMA like Frame Relay, spokes don´t hear each other´s PIM messages which will cause issue in DM when one spoke for example send a PIM prune message for a group as the Hub router from a L3 viewpoint will assume that the PIM neighbors have heard this message and it will go ahead and prune the interface as it will not receive any override (S, G) PIM join from the other spokes.
Obviously what is needed is to make the PIM code in the router aware of the actual L2 technology of the NBMA cloud. This is accomplished by PIM NBMA mode where the router treats the NBMA cloud as a collection of p2p circuits instead of a broadcast medium. When “ip pim nbma-mode” is configured the PIM code will maintain “next-hop” information for (*,G) anf (S,G) in addition to the interface.
This result in efficient multicast replication in the Cisco PIM fast-switching code and the multicast traffic is not queued to the Frame Relay output as broadcast packets anymore which means that pseudobroadcast is not used. Finally the router will only replicate multicast packet to those spoke that have joined the tree.
PIM DM does not work with PIM NBMA as this feature relies on PIM join message and PIM DM don´t use explicit join. So PIM DM with NBMA is a poor choice at the router will suffer a lot because of the replication of the multicast packet via pseudobroadcast. Moreover a full mesh NBMA is needed with PIM DM as we saw that spokes do not hear each other PIM messages which will break the multicast topology when a prune message is received from a spoke as the other spokes will not hear it and the HUB will prune multicast traffic for all spokes for that (S,G).
So let´s go back to our topology and enable PIM NBMA so when R2 receive a PIM join/prune from R1 it will create a (*,G) entry with an OIL having the IP address of R1. So R2 will be considering its link to R1 as a P2P link for the PIM control plane and data plane. Moreover R2 will not use anymore pseudobroadcast replication but will fast-switched multicast packet instead which will save on router CPU ressources.
Let´s see what happen in the debug output on R2 when R1 sends a PIM (*,G) join/prune up to R2:
So now R2 adds an entry in its OIL for S0/0 bind to R1 next-hop IP upon receiving a PIM (*,G) join/prune from R1.
So we solve the RPF control plane issue on R2 and now we can assume that R4 as an entry for (*,188.8.131.52):
Which is the case! Let´s send traffic to this group from the source now. We can confirm that R1 is receiving the multicast data plane traffic from the source and that it is transmitting it to its LAN interface:
So this topic on Auto-RP is now over as well as PIM SM. Note that Auto-RP listener if the preferred method if you want to use Auto-RP without risking any groups failing back to PIM DM. Auto-RP listener works with PIM SM (not need for PIM Sparse-Dense mode). In this mode, only 184.108.40.206 and 220.127.116.11 are running in PIM DM, no other groups are allowed to use dense mode. Auto-RP listener should be enabled on all the routers in the multicast domain in global config mode.
I will try to make a post on Multicast and the different security features later on. Note that he preferred method for disseminating RP information is BSR which I will talk about in a later post.
Thanks for reading.