Where to place the RP in an Enterprise John Zwiebel 12/9/98 Where to place an RP for an enterprise may not be obvious. Here are some random thoughts on making this choice. Right now, cisco has only one RP for all groups and its on the border with our ISP. That has been working all right for us for 4 years and if you have customers that use multicast at the same level that cisco does, its a good idea. Some of the other points though: -- customer does not want to connect to the MBONE or any external multicast Put the RP in the middle of his enterprise on a backbone. If the multicast traffic is very high, you _might_ want to consider having a router dedicated to being the RP. I would prefer a highly reliable router that keeps itself up with a backup power supply to a back up router configured to be a secondary (backup) RP. -- customer wants to connect to the MBONE and external multicast If the level of traffic is high, encourage him to use two RP's one for the local groups 239.0.0.0-239.255.255.255 which is in the middle of the network and a second "global" RP which is on the border to the ISP. -- customer wants to limit scope of some groups to a certain physical scope of routers. This one is harder to accomplish. This is when a customer wants to have some multicast that is suppose to go to just the manufactoring sectors and some multicast goes to engineering and some to marketing. You'd need to select the group ranges that you want to limit to those physical area and set up administrative boundaries for those ranges. Then you'll have to configure "ip pim accept rp " within each of those area for those specific groups. Then select an RP within each are that is the RP only for those groups. Finally, you'll also need to have the "enterprise" RP for groups that are local to the company and a "global" RP for groups that are to be available on the internet. At this time, I am not aware of any customer that has tried to set up something as complicated as the above. I'm not recommending it, just stating that it is a possible way of configuring the multicast network. The level of multicast traffic just is not high enough yet to get into this scenerio. BTW, the selection of multicast groups that would be specific to a certain business sector would mean a group range that would be something like 239.255.255.0 - 239.255.255.255. And this group range could be re-used in each of the business sectors since the multicast boundary will prevent forwarding of traffic for this range. -- customer is willing to use 12.0S This includes MBGP and MSDP. These two capabilities make the location of the RP much more independent. Each RP within a PIM sparse-mode cloud is a MSDP peer with the RP in each of the PIM clouds on which it borders. This lets the RP know of any sources sending to a given multicast group. If the RP receives a (*,G) join for a source that is outside of its sparse-mode cloud, it now has the information it needs to send a (s,g) join toward that source. Once that path is set up, and data for the external source is sent down the shared tree of the local cloud, then local routers may also decide to join to the shortest path. IMHO, MSDP makes it possible to put the RP almost anywhere. So if your enterprise wants to have a single RP located on its backbone, and have that still be the RP for global multicast groups that have sources external to the enterprise, things will still work. One last thing to worry about and that is whether your customer is getting native multicast from its ISP via PIM or if its coming over a DVMRP network. In this case, the location of the RP may be influenced by other factors, but usually, putting it on the border with the ISP is the correct choice. So, it gets complicated if you want to let it get complicated. You should press your customer to walk before running. A single RP for the enterprise on the border with the ISP service (like cisco does it now) is the right way to go while the customer tries to figure out the best way to use the multicast capability.