Clarifying Multicast Automatic RP configurations
At first, Multicast was daunting to me because I had no understanding of which mode to use (sparse, dense, or sparse-dense), or which method to use to configure the RP. I hope that some of my comments below help others past the cloud. Please let me know if you see anything incorrect here.
*** MODES ***
Sparse: Sparse mode means that initially, multicast streams are sent to a Rendezvous Point. The Rendezvous point then sends the traffic out all interfaces where a device is subscribed to that group. Once the rate of traffic reaches a predefines threshold, the source and recievers of that multicast group will create more optimal paths between them, no longer depending on the RP.
Dense: When a speaker on a group sends multicast traffic, a router running in dense mode will forward that traffic out all PIM enabled interfaces. It is up to the recieving routers to send a prune message back to the sending router if that stream is not needed out that interface. There is no RP in dense mode.
Sparese-dense: There are really only two modes: Sparse and Dense. These are industry standard. Cisco created the Sparse-dense mode as a combination of having both sparse and dense modes running at the same time. If a multicast group has an RP defined, then that multicast traffic is treated as sparse, otherwise it's treated as dense.
*** RP CONFIGURATION ***
There are 3 different ways to let routers know who the RP for a specific group is: 1) Statically configure each router with the RP's address 2) Automatic Discovery of RP using AutoRP 3) Automatic discovery of RP using BootStrap Router. The trick is to know when to use each of these.
Static Configuration: You can literally go to each router and use the "ip pim rp-address" command to define the RP-address for various groups. The configuration of the RP itself is identical. When the RP sees its own address defined as the RP, it automagically knows to assume that role. Static configuration can be used with both sparse and SD modes.
AutoRP: AutoRP was developed by Cisco to work in conjunction with sparse-dense mode. It defines two roles. The RP will announce its role as a potential RP for certain multicast groups. The mapping agent recieves these RP announcements (group 224.0.1.39) and in return sends out discovery announcements (group 224.0.1.40) containing RP information to PIM enabled routers. So, the mapping agent is listening for the RP announcements, and the PIM routers are listening for the mapping announcements. The mapping-agent role is required as PIM routers aren't listening to the RP announcements directly.
AutoRP uses dense mode multicast groups to propagate both the RP announcements and the mapping announcements. Therefore, AutoRP only works with sparse-dense mode, natively. I say natively because the global config command "ip pim autorp listener" will cause a router to flood 224.0.1.39 and 224.0.1.40 out even sparse-mode interfaces. This command will essentially allow autorp to propagate across a sparse-mode network.
Bootstrap Router: In the beginning, you were required to configure RP information manually (with PIMv1). After Cisco created Sparse-dense mode with AutoRP, the industry created PIMv2 which, among other things, included Bootstrap router. Bootstrap router is a method of propagating RP information in sparse mode. It operates similarly to AutoRP, with the key difference being that information is propagated using unicast, not multicast, addresses. Therefore, Bootstrap Router will work with either sparse mode or sparse-dense mode.
Bootstrap also defines two roles. The RP-Candidate still announces its candidacy as an RP. The BSR-candidate listens for RP-candidate announcements and in return sends RP information out to PIM-enabled routers. Just as with AutoRP, the BSR role is necessary as PIM routers aren't directly listening to the RP-candidate announcements.
*** WHAT TO USE??? ***
PIM mode: Sometimes requirements will be specifically stated. ("use dense mode", for example). I usually read forward to see if they're going to have me define an RP, and how they ask me to define it. Having an RP would limit you to Sparse or SD.
A requirement to use AutoRP would usually require you to select sparse-dense mode. The 'autorp listener' command, however, will allow an interface configured with sparse mode to listen to and propagate information in dense mode for the addresses that autorp uses.
Requiring BSR would allow for either sparse or SD modes.
RP Configuration: If they ask you to define an RP, then look for keywords like 'automatic', 'AutoRP', 'bootstrap', etc. Asking you to auto-propagate information using an industry standard would require bsr. If automatic is required and you're in sparse mode, then you have to use bootstrap or autorp with "autorp listener". If automatic is required and you're in SD mode, then you can use either AutoRP or BSR.
*** TYPICAL GOTCHAS ***
There are two things I automatically look for when first configuring multicast:
1) The first thing I look for is for PIM being enabled on more than one 'spoke' of a hub-and-spoke frame-relay network. A multipoint interface won't, by default, send multicast received from one spoke out to another spoke. This doesn't apply to a 'hub-and-spoke' where the hub is using separate physical or virtual interfaces, just multipoint interfaces. When you see this, you likely will have a problem. For sparse traffic this can be fixed by applying 'ip pim nbma-mode' to the multipoint interface. For both sparse or dense traffic, you can use a PIM-enabled tunnel (typically a tunnel between the spokes) to remedy this. (Remember, if you use a tunnel, you will also have to use an mroute, pointing to the tunnel, to cause the RPF check to not fail.)
2) The second thing I look at is which interfaces PIM is enabled on. If multicast traffic will be required to take a path which unicast wouldn't, then the receiving router will likely drop the traffic because it fails the RPF check. This is typically fixed by applying an mroute.
Whatever issues you spot, don't jump to fix them. Read the entire multicast section first. Then fix only the things they ask you to fix. As they ask you to fix it, they'll tend to make stipulations of what you can and cannot do. You may have to get creative (like enabling PIM on another network segment as opposed to using a static mroute).
- strobelight's blog
- Login or register to post comments
