Home > Multicast > Basic Multicast part 4 – PIM Sparse Mode – BSR and Multicast Security

Basic Multicast part 4 – PIM Sparse Mode – BSR and Multicast Security

Continuing with Multicast topic I will talk this time about PIM BSR (Bootstrap Router) which is an alternative way to advertise dynamic RP information. We saw in the previous posts on Multicast that the RP information could be configured statically or dynamically with Auto-RP. Auto-RP is a legacy mechanism which is neither part of the PIMv2 standard nor used in IPv6 Multicast. The issue with Auto-RP is that it uses specific multicast groups to propagate the RP information which gives some challenge in NBMA partially meshed networks and some methods are needed in order to allow the Multicast Auto-RP control plane traffic to be propagate everywhere.

BSR (Bootstrap Router) which is part of PIMv2 standard and used in IPv6 Multicast is similar to Auto-RP but the RP information is not disseminate using Multicast group but instead this information is encapsulated in PIM packets.

 I will also talk about some Multicast security features that can be used in order to protect the Multicast domain.

 Before reading further I invite you to read my previous post on Multicast PIM Sparse Mode if you are not familiar with PIM SM.

 I will use the same network topology as I did in my previous posts on Multicast. Let´s consider the following topology:

Source: The multicast source will be sending to multicast group 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:

BSR: The Bootstrap router is R3 with IP

IGP: The IGP used is EIGRP

Platform/IOS: Cisco 2691/12.4(15)T11 Adv IP services

 All the routers in the PIM SM topology are configured with PIM SM. We don´t need to run sparse-dense mode or AutoRP-listener as the BSR information is advertised into PIM packets.

BSR defines two roles:

  • RP candidate: Similar to candidate RP in Auto-RP but the RP uses unicast PIM to advertise itself to the Bootstrap route Whereas Auto-RP uses a specific multicast group. That implies that the RP candidate must find out first who is the BSR router
  • BSR router: Similar to the mapping agent in Auto-RP but the BSR router Advertises RP information to other routers with PIM on a hop by hop basis and not multicast like it was the case in Auto-RP. The BSR does not elect the best RP for every group range but builds a set of candidate RPs, including all routers that advertised their willingness to service this group range.

Basic BSR configuration

 Alright, let´s go ahead and configure R4 as the PIMv2 RP candidate:

The above command is based on the following command format:

Ip pim rp-candidate <PIM-Enabled-Interface> [group-list <Standard-ACL>] [interval <seconds>] [priority <0-255>]

In our case as we omit the other arguments, R4 will advertise itself to the BSR router as the RP for all groups. The priority is used when the multicast routers select the best RP for a given group and lower is better.

As soon as we enabled R4 to announce itself as a RP the following debug appears on the RP:

That means that R4 tries to advertise itself as the RP for all the multicast groups but as it doesn´t know the IP of the BSR router it cannot send this advertisement. So let´s go ahead and configure the BSR router which is in our case R3:

The above command is based on the following command format:

 Ip pim bsr-candidate <interface-Name> [hash-mask-length] [priority]

 By default the priority is 0 and the higher is better. The IP address used to source the BSR messages is used as a tie-breaker for electing only one active BSR if priority are equals. The higher IP wins. So if there were multiple BSR, they would listen to each other BSR messages and if a BSR hears a message with a higher priority or IP it stops immediately its BSR advertisement which ensures a unique BSR in the domain while maintaining redundancy.

As soon as we enabled R3 to be a BSR we can see the following debug output:

So R3 advertise itself as a BSR to other routers via PIM multicast message (dst IP: and a TTL of 1. We can confirm this behavior with the following Wireshark output taken when R3 has just been configured as a BSR:

Now R4 knows the BSR as we can see that from the output bellow:

R4 can now send Candidate RP advertisement to the BSR R3. These advertisements are advertises as PIM unicast message as we can see from the following Wireshark output:

R3 is now receiving these Candidate RP advertisements from R4 which in turns trigger the R3 PIM process to send PIM BSR message to all its PIM connected neighbors in order to inform them about the RP information:

We can see the same result with Wireshark when R3 start sending RP to group binding information into PIM packets:

R2 is receiving the BSR message from R3 and upon receiving it, R2 does a RPF checks on the BSR address. If the RPF check succeeds, the message is flooded out all PIM-enabled interfaces.

The issue however here is that R1 is not getting the PIM BSR messages:

And that is due to the Split-horizon rule that prevents forwarding packets out the same interface they were received on. As we saw in the previous Multicast topic there are different ways to solve this issue, for example by enabling point-to-point subinterfaces, creating a tunnel or configuring PIM NBMA mode (only in SM). We will use the third method here and configure ip pim nbma on the serial WAN interface of R2 which basically disabled spilt-horizon which is similar to disable split-horizon in RIP or EIGRP. So here the issue is not related to Multicast RPF where an incoming multicast interface cannot be present in the outgoing interface list (OIL) for a particular multicast group entry, but rather related to simple split-horizon rule as PIM BSR does not use multicast group to propagate RP to group information.

Once ip pim nbma is enabled R2 is forwarding the PIM BSR messages to R1 and receive them:

So now all the routers in the multicast domain have RP information.

Multiple RP candidates

 Unlike with Auto-RP all routers in the multicast domain receive RP-set information and it is up to them to select the best matching RP. This allows the multicast routers to load-balance among multiple RPs.

 Side note: Recall that with Auto-RP, when the Mapping Agent (MA) was receiving Group to RP mapping and 2 equal Multicast group were advertised by different RPs, the MA will choose the RP with the highest IP and only announce this RP to group mapping to all regular multicast routers. In BSR, the BSR (similar to the MA in Auto-RP) will not decide which RP to group mapping to advertise but instead will advertise all the one it knows and it is up to the regular multicast routers to choose the best matching RP based on the hash value computed on the RP,Group or the RP priority (lower better).

 Here is how the selection process works for the multicast routers:

  •  Select the RP with the lowest priority in the RP-set sent by the BSR. By default all RPs have priority of 0 so they all are eligible. Priority can be adjusted to take some of the RPs out of service.
  •  For every RP IP calculate the hash function value based on the following:

Value 1=hash(Group&Mask,R1), value 2=hash(Group&Mask,R2)

This mask value is propagated by the BSR router and equal to 0 by default so the hash is made on the RP IP address only by default.

  •  Select the RP with the highest hash value, if equal, select the RP with highest IP address

 By modifying the mask it is possible to control the number of consecutive address that hash to the same C-RP address. So by using a mask of length 30 four consecutive groups will hash (map) to a single C-RP address.

 So in our example, let´s configure R5 as a C-RP for all the groups like R4. Upon configuring R5 as C-RP we can see that R5 advertises itself as a C-RP for all the multicast groups:

R5 already knows the BSR IP from the PIM BSR messages advertise by R3. R3 now receives the unicast PIM C-RP message from R5, builds the RP-group database and advertise to all PIM interfaces (except the one where it receive the C-RP packet on) PIM BSR packets with both RP IP (R4 and R5) mapped to all multicast groups:

R1 receives the PIM BSR advertisement and add R5 as the RP for all groups. But R4 is elected as the active RP for all the groups as the hash made on the R4 IP address result in a higher hash value than the hash made on R5 IP address:

The hash mask length is by default 0 so R1 is calculating the hash only on the RP IP addresses and the Multicast group IP is ignored which will result in R4 always being chosen as the RP for all Multicast group. We could change the priority of R4 and make it higher and R5 will always be chosen as the RP.

 However to achieve load balancing we can change the hash mask length advertised by R3 for all the groups:

By configuring a hash mask length of 31 every 2 Multicast groups is using the same RP as in /31 mask there is 1 bit left which give only 2 possible address every time.

Side note: In Auto-RP, load balancing could be achieved by advertising 2 RPs servicing 2 different Multicast range. If you want to add redundancy to load balancing you can configure both RPs to advertise the all range multicast group ( and it will be up to the MA to choose the RP to advertise for this range based on the highest RP IP address. If the current RP fails, the MA will start to advertise the other RP for this range.

 We could also configure redundant BSR. Unlike Auto-RP, only one BSR is active at a time while with Auto-RP multiple MA could be active. In Auto-RP there is no Master-Slave behavior and multiple MA can be active at the same time in the multicast domain which removes a complex failover protocol that could go wrong. With redundant BSR, the only thing to know is that the BSR with the highest priority is elected the active BSR, if tie in priority the one with the highest priority is elected the BSR.

 Side note: It is possible to constrain PIMv2 BSR messages from flowing into or out of the domain with the interface command: ip pim border. Please note that this command only block PIM BSR messages and not normal PIM messages like join/prune and it doesn´t block multicast traffic.

Multicast Security Features

 I would like to cover now some security features we can use with Multicast. Let´s start by the protection of the RP.

  • RP protection

 In order to prevent unwanted RPs or groups from becoming active in the PIM SM multicast domain we can use the following command:

 Ip pim accept-rp {rp-address | auto-rp} [access-list]

 This command causes the router to accept only (*, G) join/prune messages destined for the specified RP address. Additionally, the group address must be in the range specified by the access list. This command can also be used on the leaf routers for determining the group mode (sparse/dense) when a (*,G) entry is being created in the multicast routing table as a direct result of a local host joining the group. So in our example let´s configure R2 to only accept join/prune message to the RP and for multicast group only.

So let´s test this feature by configuring R1 to join the multicast group and let´s see the result on R2:

So R2 is not accepting the PIM join/prune packet as both the RP and the group are denied by the ip pim accept-rp feature which means that R2 will not create an mroute state for this group and also will not transfer the PIM join/prune towards the RP. This feature should be configured on all the routers in the multicast domain if used.

 Side note: When the rp-address argument is one of the addresses of the system, the system will be the RP only for the specified group range specified by the access list. When the group address is not in the group range, the RP will not accept join or register messages and will respond immediately to register messages with register-stop messages.

 It is also possible to configure the RP to accept only specific Multicast source IP to register with it. Previously with the command ip pim accept-rp we could deny specific Multicast group in the register message send to the RP from the DR when this feature was configured on the RP itself. Now with the following command it is also possible to select which source can register with the RP:

 Ip pim accept-register {list <Extended-ACL> | route-map <Route-map>}. The basis of the filtering is an ACL in the format:

 ip access-list REGISTER_FILTER

permit ip <source-ip> <source-wildcard><group-address><group-wildcard>

 This command is configured on the RP. So let´s test it on R4 and we will allow any source to register with R4 for any group but not the source (just for testing purpose):

Now let´s send traffic from the source to

So R4 refused to be the RP for the source and send a PIM register-stop to the DR which is in this case R5.

 Side note: in the last debug output we can see that the source of the register message is the IP of the DR interface used to reach the RP ( which can be changed with the command: ip pim register-source <interface> configured on the DR.

  • Multicast scoping

  Multicast boundary

 The multicast boundary features allows for setting administrative borders for multicast traffic. This feature applies both to control plane traffic (IGMP, PIM, AutoRP) and to data place traffic (installing multicast route states out of the configured interface). This feature has the following command format:

 Ip multicast boundary <access-list> [filter-autorp | in | out]

 A standard ACL is used with the ip multicast boundary command to define the group address range to be permitted or denied on an interface.

When a standard ACL is used, any ingress (control plane) IGMP or PIM messages are inspected to see if the group being joined or tree being built has a match in the ACL. This might be a (S,G) or (*,G) join. Additionally, on the outbound (data plane) the interface with the feature configured on it will be present in the OIL only for the group permitted in the ACL.

 An extended ACL is used with the ip multicast boundary to define (S, G) traffic to be permitted or denied on an interface. Extended ACLs can also be used to define the (*, G) state to be permitted or denied on an interface, by specifying host for the source address in the permit statements that compose the extended ACL

 Side note: PIM register messages sent from the DR to the RP are not affected by the multicast boundary feature and must be filtered using the respective feature we saw before (ip pim accept-register)

 Additionally the autorp keyword can be used to filter specific autorp control plane traffic. The user-defined boundary examines Auto-RP discovery and announcement messages and removes any Auto-RP group range announcements from the Auto-RP packets that are denied by the boundary standard ACL.

 Finally, the in or out option when used result in the following behavior:

  •  In: Filter Only control plane traffic is affected (IGMP, PIM join/prune, and Auto-RP messages)
  • Out: Filter only data plane traffic, that is to say an entry in the OIL is not created for the interface having the multicast boundary command configured on and the ACL is denying the specific group or souce/group.

 To illustrate this example let´s configure R2 so only PIM join/prune message for multicast group are accepted on the serial interface:

So if we were to make R1 to join the group let´s see what happen on R2:

As expected R2 accept the PIM join/prune from R1 (control plane) and create an entry in the OIL for the interface s0/0 (data plane) binded to the neighbor R1 / (we are using ip pim nbma mode).

 Alright, let´s make R1 join another group which is not, for example

So R2 is blocking the PIM join/prune for this group and it is not creating an mroute state for this group:

Side note: This feature is similar to the pim accept-rp feature we saw before for this particular example. But the ip pim multicast boundary feature can also filter IGMP and auto-rp. However the pim accept-rp feature can filter the RP IP address in the PIM join/prune messages and ip multicast boundary can´t.

 Side note 2: IGMP filtering could also be accomplished with the feature ip igmp access-group apllied on the interfaces facing receivers using a standard ACL for (*,G) IGMP v1,v2 joins or extended ACL for (S,G)  IGMP v3 joins.

 Thanks for reading!


  1. February 22, 2014 at 15:16

    Awesome man, exactly what I was looking for. Thanks!

  2. shahhan
    September 26, 2014 at 07:22

    Really Good very simple and descriptive. Nice way to capture all related in one place..


  3. digital retouching
    March 26, 2015 at 07:19

    I savour, lead to I found exactly what I used to be taking a look for.

    You’ve ended my 4 day long hunt! God Bless you man.
    Have a great day. Bye

  4. June 25, 2015 at 04:35

    it helps me a lot. thanks sir

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: