9 Replies Latest reply: Dec 16, 2011 12:45 PM by Michael Law RSS

    Filtering BSR messages

    Michael Law

      Hi Folks,


      I have poured through CCO Multicast page: http://www.cisco.com/en/US/docs/ios-xml/ios/ipmulti/command/imc_i3.html#GUID-DD2DFDEC-D3D2-4E19-BE65-888EEFFB472F on a topic.


      If you have a multicast domain with several RPs that hosts the same groups, but you would like to filter certain rp-mapping information in the BSR messages sent, how can you do this?


      The only thing I found was the 'ip pim bsr-border' which seems to be an 'all or nothing' command. Also, the commands that perform this function I found were exclusive to Auto-RP. Surely, there  is a way to filter rp-mapping information in BSR like you can filter routes from a routing update. Any suggestions?


      Thank you



        • 1. Re: Filtering BSR messages
          Michael Law

          Apparently, if you have stub multicast domains where groups are reused, you can use the 'ip pim bsr-border' command on the uplinks and just statically configure global multicast RPs for your network for particular groups. This is the only solution I can think of until a dynamic solution presents itself.

          • 2. Re: Filtering BSR messages

            Multicast TTL scoping - ip multicast ttl-threshold (vlaue) on mcast client's router?


            This is different than what you asked to filter rp-mapping info in the BSR message though.



            • 3. Re: Filtering BSR messages
              Michael Law



              I'm searching for a control plane based scoping rather than a data plane based scoping.


              Thanks for the response.




              • 4. Re: Filtering BSR messages
                Brian McGahan - 4 x CCIE, CCDE

                Why do you want to filter out the messages?  If you have different portions of the network that don't agree on the RP you're going to have problems building the tree for that particular group.

                • 5. Re: Filtering BSR messages
                  Michael Law



                  An example would be a network where you have several branch offices connected by lower speed WAN links.


                  So if PIM was enabled on every possible layer 3 device in the enterprise, and there was at least 1 RP + BSR per site (say three sites) so no site would be without mcast routing capability, cRP and mapping information would flood to all parts of the network. Say, you were doing an intense multicast session because of an imaging application. Imaging is something frequently done at all sites. A policy is that imaging traffic can't flow over WAN links. Therefore, there must be an imaging server per site for the LAN.


                  If the cRP priority value was left to default on all three RP+BSR devices (1 per site), then wouldn't the PIM-DR hashing algorithm for all PIM devices in the enterprise choose the exact same cRP for their mapping? ...also violating the policy of no image traffic over WAN. I say this because I cannot use the priority value of a particular cRP because it would getting flooded across the WAN and the remote branch office would always choose the local branch office cRP.


                  Therefore, if you could filter cRP mapping information out the WAN links of the routers, you could essential scope the extent of that multicast group (through the control plane) and reuse it on other branch offices. PIM devices couldn't chose cRPs they don't know about it. When looking at the DocCD, AutoRP appears to be able to perform this kind of filtering. Allowing some but not all cRP mapping information to flood between PIM devices. Therefore, you could have global, and local multicast control information.


                  The only thing I can think of is to type 'ip pim bsr-border' on the WAN interfaces of the routers and then just statically define RPs on local WAN routers that I want to use for global multicast groups. The statically defined groups would be for low-intense applications like to audio. This would be analogous to several IGP domains only communicating through static routing and not an EGP.



                  • 6. Re: Filtering BSR messages
                    Brian McGahan - 4 x CCIE, CCDE

                    You could in theory do this, but as far as I know there's no way to implement it in IOS.  There's easier ways to accomplish this design-wise than filtering the actual BSR payload though.  If each site has their own RP, you would simply configure the BSR of each site to assign the local RP address for that particular group.  If you then want to prevent the particular group traffic being sent over the WAN you simply need to filter the traffic in the data plane with the ip multicast boundary command.


                    What may even be a simpler design than this is to setup the RPs as Anycast RPs, where they share the same IP address.  This way the BSR information doesn't really matter where it comes from, and you would simply control where you don't want the traffic to go in the data plane with the multicast boundary.

                    • 7. Re: Filtering BSR messages
                      Michael Law



                      I have included a screen shot of my network.screenshot.jpg



                      In this network, all devices have OSPF and PIM running. Full layer 2 and 3 convergence is achieved. R2, R3 and R4 have been setup as RPs with the following commands:

                      'ip pim rp-candidate loopback 0'

                      'ip pim bsr-candidate loopback 0'


                      Issuing the 'show ip pim rp mapping' on all devices shows 3 RPs. Loopback1 interfaces on R5, R6 and R7 have been configured with the 'ip igmp join-group' command. All three built there RPT to R4's Lo0 interface of


                      Issuing the multicast boundary command simply prohibited the join from R2/R3 to R4. Unfortunately, all PIM devices still chose R4's loopback based on hashing. Therefore, the control plane and the data plane are not properly converged. I see (*,G) in all devices except R4's loopback because it prohibited inbound (*, routes from forming. BSR still notified all devices that was the best cRP for their mapping. Therefore, my problem still continues.


                      Thanks for the advice.



                      • 8. Re: Filtering BSR messages
                        Brian McGahan - 4 x CCIE, CCDE

                        Anycast will fix this then.  Configure the same loopback interface on R2, R3, and R4 and use that as the RP, and then configure R2, R3, and R4 in an MSDP mesh group.  Your registers and joins will always go to the closet RP then, and you can filter out whatever you don't want in the data plane.

                        • 9. Re: Filtering BSR messages
                          Michael Law

                          Thanks Brian.