Multicast – Inter AS Multicast (Auto-RP and BSR), Anycast RP MSDP, MSDP SA Filter and MBGP

If you want to learn how multicast works and different multicast protocols, you need to read this post. It will guide you through the details progressively to fully understand the key concepts.

Contents

• AS65001 Physical Topology
• AS65001 Multicast Topology – Auto RP
  • User 1 Joins 224.1.1.1
  • Server1 sends Multicast Traffic to 224.1.1.1
  • Building the Shortest-Path Tree (SPT)
• Designated Router (DR) Election
• PIM Assert Mechanism – Forwarder Election
• AS65002 Physical Topology
• AS65002 Multicast Topology – Bootstrap router (BSR)
  • User 2 Joins 234.2.2.2
  • Server2 sends Multicast Traffic to 234.2.2.2
  • Building the Shortest-Path Tree (SPT)
• Merge AS65001 and AS65002 – Physical Topology
• Merge AS65001 and AS65002 – Multicast Topology
  • Anycast and Multicast Source Discovery Protocol (MSDP)
  • Configuration Requirements
  • Server1 sends Multicast Traffic to 224.1.1.1
  • Enable Multicast BGP (MBGP)
  • Server2 sends Multicast Traffic to 234.2.2.2
  • Server 1 and Server2 send Multicast Traffic to 227.3.3.3 – MSDP SA Filtering
• Appendix
  • Filter RP-Group in the Mapping Agent
  • Filter RP Announcements and Mappings to leave the AS
  • ip pim accept-register (S,G)
  • ip pim accept-rp (*,G)
  • Multicast Stub Routing

AS65001 Physical Topology

Figure 1

AS65001 Multicast Topology – Auto RP

AS 65001 is running Protocol Independent Multicast (PIM) Sparse Mode (SM) on all links. PIM SM uses explicit Join/Prune Messages and Rendezvous Points (RPs) instead of Dense Mode (DM) broadcast and prune technique.

Cisco proprietary protocol Auto-RP is enabled to dynamically distribute RP information to other routers in the PIM SM domain. As it is shown in Figure 2, R3 an R4 are the candidate RPs and R2 is the Mapping Agent.

Figure 2

Auto-RP uses two Multicast Groups: 224.0.1.39 and 224.0.1.40. Candidate RPs send RP Announce messages on the 224.0.1.39 Group. These messages contain a list of Multicast Groups the device would like to be the RP for. Mapping Agents listen to 224.0.1.39 in order to collect the RP information from all candidate RPs and send RP Discovery Messages on the 224.0.1.40 Group. The RP Discovery Messages destined to 224.0.1.40 contain the best elected RP-to-Group mapping information from Mapping Agents. All the PIM routers join the Multicast Group 224.0.1.40 when the first PIM-enabled interface comes up.

By default, the RP Discovery Message could not be sent out of PIM SM enabled interfaces. One of the possible solutions to send this information to other PIM Enabled Routers is to enter the ip pim autorp listener command. This causes the IP Multicast traffic for the two Auto-RP Groups, 224.0.1.39 and 224.0.1.40, to be PIM DM flooded across the interfaces configured for PIM SM. This way the routers which listen for Group 224.0.1.40 learn the Auto-RP information and hence learn the RP address.

We enable ip pim autorp listener feature and ip multicast-routing in configuration mode on all routers and ip pim sparse-mode at interface level on all routers’ interfaces.

R1 – R5:

R3 is the RP for 224.0.0.0/5 (224.0.0.0 – 231.0.0.0) and the whole Multicast range 224.0.0.0/4.

R4 is the RP for 232.0.0.0/5 (232.0.0.0 – 239.0.0.0) and the whole Multicast range 224.0.0.0/4.

R2 is the Mapping Agent (MA) and receives the Multicast Groups-RP mappings from R3 and R4. Then, R2 selects and advertises only one RP for Multicast Group (in case it receives multiple advertisements from different RPs for the same Multicast Group) to all routers in the Multicast domain.

Figure 3 shows the Auto-RP discovery process. R2 receives two possible mappings for 224.0.0.0/4: 224.0.0.0/4 – 1.1.1.1 from R3 and 224.0.0.0/4 – 2.2.2.2 from R4. R2 chooses the announcement from R4 because of the highest RP IP address: 2.2.2.2. Having multiple candidates for the role of RP greatly enhances the redundancy of the PIM SM network. R3’s mapping will be advertised by R2 if R4 stops advertising itself as RP for 224.0.0.0/4.

Figure 3

This is the result Multicast Groups-RP mappings on R2.

If we select any other router in the Multicast domain, for example R3, and we show the RP-to-Group mappings we only see the selection made by R2 (MA). We do not see R3’s mapping for 224.0.0.0/4.

Finally, the Multicast Routing Table shows that the RPs (R3 and R4) have successfully joined 224.0.1.39 and the MA (R2) is successfully listening on 224.0.1.39 and forwarding on 224.0.1.40.

In this scenario, R5 does not have any other downstream PIM neighbors; this is why the Outgoing interface list (OIL) shows as Null.

User 1 Joins 224.1.1.1

User1 becomes a Receiver for the Multicast Group 224.1.1.1 by signalling with an IGMP Report message on the LAN segment. The Designated Router (DR) is going to translate the IGMP Report into a PIM Join for 224.1.1.1. The DR then checks its RP-to-Group mapping database and forwards the PIM Join to the RP allocated to that specific Multicast Group, R3.

The DR election is based on highest priority or, in case of a tie, highest IP address.

Figure 4

User 1 notifies it wants to receive Multicast traffic for 224.1.1.1 Group.

R2 receives the IGMP Report from User1 and sends a PIM Join on its fa2/0 towards R3 (1.1.1.1).

R3 receives the PIM Join from R2 and adds fa2/0 into the OIL list.

At this point we can see that only the DR (R2) and the RP (R3) know about the (*,G) = (*,224.1.1.1).

Figure 5 describes the Registration proccess of a Multicast Source for the Group 224.1.1.1.

Figure 5

Server1 generates some traffic and we can verify that User1 is receiving it because is replying to the pings.

When R5 receives Server1’s pings to a Multicast Group, it generates a PIM Register message (S,G) = (10.1.5.100,224.1.1.1) towards the RP assigned to that particular Multicast Group, R3 in our example.

The RP, R3, replies with a Register Stop and updates its Multicast Routing Table.

Now we check who knows about (S,G) = (10.1.5.100,224.1.1.1) querying the Multicast Routing Table. We can see that only the routers in the path between Server1 and RP (R3) know about the (S,G) pair.

The RP, R3 for 224.1.1.1, is going to merge the two trees together sending its own PIM Join (10.1.5.100, 224.1.1.1) towards Server1 in order to notify the devices in the path that it wants to receive the Multicast traffic. Now the SPT is built from the Server1 to R3 (RP). Then the Shared Tree (RPT) is built from R3 to User1, the Receiver. R3 is then receiving the Multicast traffic inbound from the SPT and sending it outbound on the RPT down to the Receiver. The last hop router, R2, can switchover to the SPT sending a PIM Join (10.1.5.100, 224.1.1.1)  towards the Source, Server1, and a PIM Prune (*,224.1.1.1) towards R3, the RP. User1 is now joined the SPT (10.1.5.100, 224.1.1.1).

Note that in order to clearly appreciate the switchover of R2 from the RPT to the SPT we have made the link between R2 and R4 more preferred than the link between R2 and R3. This way we can appreciate that the RP, R3, is not longer in the data plane.

Figure 6

The debup ip pim shows how R2 sends a PIM Join in order to join the SPT (10.1.5.100, 224.1.1.1).

If we run a mtrace on R2 towards the Multicast Source, we see that R3 (RP) is not longer in the data plane.

As I mentioned before, the DR translates IGMP Reports from Receivers into PIM Joins towards the RP. The DR checks its RP-to-Group mapping database to find out the RP associated to the Multicast Group and sends the PIM Join (*,G).

The DR election is based on highest priority or, in case of a tie, highest IP address.

The DR for the segment 10.1.121.0/24 (R1, R2, User1) is R2.

To make R1 the DR we can change the priority to a higher value.

Figure 7

PIM uses Assert messages to elect the single router that forwards the data traffic to the LAN. When both R3 and R4 forward the data traffic for channel (S,G) or (*,G), R3 receives R4’s data traffic and R4 receives R3’s data traffic on their downstream interfaces. This condition triggers the Assert on the downstream interfaces. To start with, R3 and R4 will assume that they are Assert-winners and send out the PIM Assert message.

All the routers on the LAN will carry out the election based on the PIM Assert messages. PIM Assert messages contain Group address, Source address, RPT bit and route metric for the Source in case of (S,G) or RP in case of (*,G).

The election is based on the following order:

• If a router has (S,G) state and others have (*,G) state, router having (S,G) state wins. RPT bit in the message identifies this.
• Router with lower Administrative Distance (AD) wins.
• Router with lower unicast route metric wins.
• Router with the highest IP address wins.

The election algorithm is such that there will always be only one winner.

In our topology shown in Figure 7, R3 wins the Assert election for (1.1.1.1, 224.0.1.39). Its AD to the RP Address 1.1.1.1 (R3’s Loopback1) is lower than R4’s AD: 0 (connected) < 110 (OSPF).

So from now onwards, router R4 stops forwarding data traffic.

R4 stores the Assert-winner and its Assert-metric for future use.

So R5 sends their periodic PIM Join messages for (1.1.1.1, 224.0.1.39) to R3, the Assert-winner.

Figure 8

AS 65002 is running PIM SM on all links. Bootstrap router (BSR) protocol is enabled to dynamically distribute RP information to other routers in the PIM SM domain. It is a standard-based protocol available with PIMv2.

As it is shown in Figure 9, R10 an R11 are the candidate RPs and R9 is the Bootstrap Router (similar to MA role in Auto-RP).

Unlike Auto-RP, BSR does not use any dense-mode Groups to flood candidate RP and RP mapping information. Instead, the information is flooded using PIM messages, on hop-by-hop basis. R9 (BSR) listens to candidate RP announcements from R10 and R11. Unlike Auto-RP MA, the BSR does not elect the best RP for every Group range it learns about. Instead of this, for every Group range known, the BSR builds a set of candidate RPs, including all routers that advertised their willingness to service this range. The resulting array of Group range to RP set mappings is distributed by the BSR using PIM messages to all routers in AS 65002. Then every Multicast router in the domain uses this information to populate their RP caches.

Figure 9

We enable ip multicast-routing in configuration mode on all routers and ip pim sparse-mode at interface level on all routers’ interfaces.

R8 – R12:

R10 is the candidate RP for 224.0.0.0/5 (224.0.0.0 – 231.0.0.0) and the whole Multicast range 224.0.0.0/4.

R11 is the candidate RP for 232.0.0.0/5 (232.0.0.0 – 239.0.0.0) and the whole Multicast range 224.0.0.0/4.

R9 is configured to be the BSR and receives the RP-to-Group mappings from R10 and R11. Then, R9 advertises the RP-to-Group mappings received to all routers in the Multicast domain.

Figure 10 shows the BSR discovery process.

Figure 10

These are the RP-to-Group mappings on R9.

If we select any other router in the Multicast domain, for example R8, and show the RP-to-Group mappings we see the same output.

User 2 Joins 234.2.2.2

User2 becomes a Receiver for the Multicast Group 234.2.2.2 by signalling with an IGMP Report message on the LAN segment . The DR, R9, is going to translate the IGMP Report into a PIM Join for 234.2.2.2. R9 then checks its RP-to-Group mapping database and forwards the PIM Join to R11, which is the RP allocated to that specific Multicast Group.

R11 now has the (*, 234.2.2.2) entry in its Multicast Routing Table.

Server 2 sends Multicast Traffic to 234.2.2.2

Server2 generates some traffic and we can verify that User2 is receiving it because is replying to the pings.

When R12 receives Server2’s pings to a Multicast Group, it generates a PIM Register message (S,G) = (10.2.12.100, 234.2.2.2) towards the RP assigned to that particular Multicast Group, R11 in our example. R11 replies with a Register Stop and updates its Multicast Routing Table.

Building the Shortest-Path Tree (SPT)

The RP, R11 for 234.2.2.2, is going to merge the two trees together: SPT and RPT (See Figure 11). For more detailed information check “Building the Shortest-Path Tree (SPT)” section for AS6001.

Figure 11

R11 is not longer in the Data Plane.

Merge AS65001 and AS65002 – Physical Topology

Figure 12

R2 configuration.

R3 configuration.

R4 configuration.

R8 configuration.

R10 configuration.

R11 configuration.

Merge AS65001 and AS65002 – Multicast Topology

Anycast and Multicast Source Discovery Protocol (MSDP)

In the PIM SM model, Multicast Sources and Receivers must register with their local RP. RPs in other domains have no way of knowing about Sources located in other domains. MSDP solves this problem.

MSDP is a mechanism that allows RPs to share information about active Sources. RPs know about the Receivers in their local domain. When RPs in remote domains hear about the active Sources, they can pass on that information to their local Receivers and Multicast data can then be forwarded between the domains. PIM SM is still used to forward the traffic between the Multicast domains and needs to be enabled on the links between ASs.

The RP in each domain establishes a MSDP peering session using a TCP connection with the RPs in other domains or with border routers leading to the other domains. When the RP learns about a new Multicast Source within its own domain (through the normal PIM Register mechanism), the RP encapsulates the first data packet in a Source-Active (SA) message and sends the SA to all MSDP peers. The SA is forwarded by each Receiving peer using a modified RPF check, until the SA reaches every MSDP router in the interconnected networks. If the receiving MSDP peer is an RP, and the RP has a (*, G) entry for the group in the SA (there is an interested Receiver), the RP creates (S, G) state for the Source and joins to the SPT for the Source. The encapsulated data is decapsulated and forwarded down the shared tree (RPT) of that RP. When the packet is received by the last hop router of the Receiver, the last hop router also may join the SPT to the Source. The MSDP speaker periodically sends SAs that include all Sources within the own domain of the RP.

Figure 13

Figure 13 above shows that candidate RPs in AS65001 (R3 and R4) share the same IP addresses that candidate RPs in AS 65002 (R10 and R11):

• R3 and R10: 1.1.1.1/32
• R4 and R11: 2.2.2.2/32

This is known as Anycast RPs.  Anycast RP is an implementation strategy that provides load sharing and redundancy in PIM SM networks. Anycast RP allows two or more RPs to share the load for Source Registration and the ability to act as hot backup routers for each other. MSDP is the key protocol that makes Anycast RP possible.

The Anycast RP loopback address should be configured with a 32-bit mask, making it a host address. All the downstream routers should be configured to “know” that the Anycast RP loopback address is the IP address of their local RP. In our topology Auto-RP is used to advertise the candidate RPs R3 (1.1.1.1/32) and R4 (2.2.2.2/32) in AS65001 and BSR is used to advertise the candidate RPs R10 (1.1.1.1/32) and R11 (2.2.2.2/32) in AS65002. IP routing automatically will select the topologically closest RP address (1.1.1.1/32 or 2.2.2.2/32) for each Source and Receiver.

Because a Source may register with one RP and Receivers may join to a different RP (e.g. User2 in AS65002 joins 224.1.1.1 and Server1 in AS65001 sends traffic to 224.1.1.1), a method is needed for the RPs (R3 and R10) to exchange information about active Sources. This information exchange is done with MSDP.

When a Source registers with one RP, an SA message will be sent to the other MSDP peers informing them that there is an active Source for a particular Multicast Group. The result is that each RP will know about the Active sources in the area of the other RPs. If any of the RPs were to fail, IP routing would converge and one of the RPs would become the active RP in more than one area. New Sources would register with the backup RP. Receivers would join toward the new RP and connectivity would be maintained.

Note that the RP is normally needed only to start new sessions with Sources and Receivers. The RP facilitates the SPT so that Sources and Receivers can directly establish a multicast data flow. If a multicast data flow is already directly established between a Source and the Receiver, then an RP failure will not affect that session. Anycast RP ensures that new sessions with Sources and Receivers can begin at any time.

Now we proceed with the configuration. Note that the IP addresses selected for the peering cannot be the Anycast IP Addresses (1.1.1.1/32 or 2.2.2.2/32). For example, R3 peers with R10’s Loopback0 (172.16.10.10/32) from its Loopback0 (172.16.1.1/32). R3 and R10’s Loopback1 (1.1.1.1/32, the Anycast address) cannot be used.

The output below shows the MSDP peering sessions have been successfully established.

Configuration Requirements

Our goal in this section is to achieve the following requirements:

• User1 receives Multicast traffic for 224.1.1.1 and 227.3.3.3 from Server1 and 234.2.2.2 from Server2.
• User2 receives Multicast traffic for 224.1.1.1 from Server1 and 234.2.2.2 and 227.3.3.3 from Server2.
• SERVER 1 sends Multicast traffic to 224.1.1.1, 227.3.3.3.
• SERVER 2 sends Multicast traffic to 234.2.2.2, 227.3.3.3.
• The ASs must never see any RP announcement from the other AS.

Server 1 send Multicast Traffic to 224.1.1.1

Figure 14

Server1 only receives replies to the pings from User1 (10.1.121.100) located in its local AS. This indicates there is a problem in the multicast design that is not allowing User2 to receive the Multicast flow.

We query R3 Multicast Routing Table for 224.1.1.1 and we see both (*,G) and (S,G) pairs as expected.

We query R10 Multicast Routing Table for 224.1.1.1 and we see the (S,G)  = (10.1.5.100, 224.1.1.1) pair is received via MSDP peer. However, the incoming interface is fa1/0 towards R8 instead of fa2/1 towards R4. Fa2/1 is the PIM SM enabled link to send and receive Multicast traffic to/from AS65001 and therefore must be selected as the incoming interface. This points to some kind of configuration issue in the topology.

The output below shows a Multicast Reverse Path Forwarding (RPF) failure: R9 does not have a Multicast route to the Source 10.1.5.100.

The problem is R8 is the preferred exit point for AS65002; it has been configured with Local Preference 200. This means all unicast/multicast traffic will exit the AS through R8-R2 and this link has not been configured for PIM SM.

In order to overcome the design limitation of not enabling PIM SM on fa2/1 between R2 and R8, we need to look for another way to influence the routing decision for Multicast traffic. This method has to select R10 as the exit point for 65002 instead of R8. We can use a static Multicast route or Multicast BGP (MBGP). The latest is the one chosen in our design.

Figure 15

R3 is configured as Multicast Route Reflector (RR) for AS65001 and R11 is configured as Multicast Route Reflector (RR) for AS65002. R1, R2 and R4 are Multicast iBGP RR clients of R3 and R8, R9 and R10 are Multicast iBGP RR clients of R11. In addition, R4 and R10 are Multicast EBGP neighbors.

R1 configuration.

R2 configuration.

R4 configuration.

R3 configuration.

R8 configuration.

R9 configuration.

R10 configuration.

R11 configuration.

The output below shows that R3 is the Unicast and Multicast RR in AS65001.

On the other hand, R1 only runs the BGP Multicast address family.

R2 has R3 as Multicast iBGP neighbor, R3 as Unicast iBGP neighbor and R8 as Unicast EBGP neighbor.

Finally, R4 has R3 as Unicast and Multicast iBGP neighbor and R10 as Unicast and Multicast EBGP neighbor.

However, if we recheck multicast reachibility to the source 10.1.5.100 from R9 we can see that there is not route available yet.

To resolve the RPF check failure, we need to advertise the Multicast Source address (or network 10.1.5.0/24) into MBGP as shown in Figure 16. Remember the order of preference:

• Static IP Multicast route (ip mroute command).
• MBGP Multicast route.
• Unicast Route.

Figure 16

R4 advertises 10.1.5.0/24 network into MBGP.

R9 now knows about a Multicast route to Server1 (Source) that is preferred over any unicast route.

Finally, if we now ping from Server1 to the Multicast Group 224.1.1.1 we can see that User1 and User2 are both responding.

Figure 17

As we saw in the previous section, we need to advertise the Source IP address (Server2) or network (10.1.12.0/24) for User1 to be able to receive the Multicast traffic.

If we run a ping to 234.2.2.2 from Server2, both User1 and User2 are responding.

R2 shows the interface Fa0/1 towards R4 as the incoming interface for (10.2.12.100, 234.2.2.2).

The mtrace command verifies the reverse path from R2 to the Multicast Source Server2.

We can see the Unicast traffic goes through R8 though.

The next Multicast requirement says:

• SERVER 1 sends Multicast traffic to 227.3.3.3 and it is only received by User1.
• SERVER 2 sends Multicast traffic to 227.3.3.3 and it is only received by User2.

Figure 18

MSDP-SA messages contain (S,G) information for RPs (called MSDP peers) in PIM SM domains. This mechanism allows RPs to learn about Multicast Sources in remote PIM SM domains so that they can join those Sources if there are local Receivers in their own domain. With a default configuration, MSDP exchanges SA messages without filtering them for specific Source or Group addresses.

Typically, there are a number of (S,G) states in a PIM SM domain that should stay within the PIM SM domain, but, due to default filtering, they get passed in SA messages to MSDP peers. In the native IP Multicast Internet, this default leads to excessive (S,G) information being shared. To improve the scalability of MSDP in the native IP Multicast Internet, and to avoid global visibility of domain local (S,G) information, it is recommended to use SA filtering.

Coming back to our scenario (Figure 18), we need to filter Group 227.3.3.3 from being advertised to MSDP peers. Therefore, only local Receivers will receive the Multicast traffic for the local Source.

User1 and User 2 join the Multicast Group 227.3.3.3.

Before configuring any MSDP Filtering we can see User2 in AS65002 is responding to the pings from Server1 in AS65001. This is not the desired output, we want only User1 to receive the Multicast traffic from Server1.

R3 configuration.

R4 configuration.

R10 configuration.

R11 configuration.

If we check the MSDP Peer information, we can see the filter has been applied inbound and outbound.

We run the same ping on Server1 and this time only User1 answers.

We ping 227.3.3.3 from Server2 and only User2 answers.

R3 and R4 are configured to advertise themselves as candidate RPs for 227.3.3.3.

R3 configuration.

R4 configuration.

R2, the MA, receives the RP announcements and updates the RP-to-Group mappings.

Now imagine we do not want R3 to be a candidate RP for 227.3.3.3. We can do the configuration on R3 accordingly or we can filter on the MA, R2. The first option is recommended but if R3 is not managed by us or it is a Rogue RP, we can use the second option as a Control Plane Security feature. Mainly this avoids non authorized RPs to announce themselves as legitimate RPs. It is not recommended to be used as a filter of what RPs serve what Groups.

Figure 19

Match RPs.

Match Multicast Groups.

Apply the filters on R2, the MA.

This filter only works if R3 advertises and R2 matches exactly the same Multicast Group.

R2 configuration.

R3 configuration.

If we now check the RP-to-Group mappings we can see R3 (1.1.1.1) is not longer available for 227.3.3.3.

Figure 20 shows a capture run between R4 and R10. It shows RP announcements on 224.0.1.39 and RP mappings on 224.0.1.40 being advertised on fa2/1.

Figure 20

We can filter them with the following configuration on R4 and R10.

Now the same capture does not show any packets.

Figure 21

On R10 the same result can be achieved by issuing the ip pim bsr-border interface command:

ip pim accept-register (S,G)

To configure a RP to filter PIM Register messages. Use this command to prevent unauthorized Sources from registering with the RP.

Figure 22

The following example shows how to deny Register packets from Server2 to the Multicast Group 229.9.9.9. All other PIM register messages not matching the extended access list are permitted.

R10 configuration.

We can disable the filter with the no command.

To configure a router to accept join or prune messages destined for a specified RP and for a specific list of Groups, use the ip pim accept-rp command in global configuration mode.

This command causes the router to accept only (*, G) join messages destined for the specified RP address. Additionally, the Group address must be in the range specified by the access list.

Figure 23

The following example shows how to configure R11  to deny join or prune messages destined for the RP at address 2.2.2.2 for the Multicast Group 233.3.3.3:

User2 now joins 233.3.3.3.

We can disable the filter with the no command.

Multicast Stub Routing

Multicast Stub routing can be used for remote sites that are connected to the main site using low bandwidth links. The remote router has to accept RP discovery messages, build the RP cache and maintain states in the multicast routing table for all its local Receivers.

When we configure a router as Multicast Stub then it will not process any PIM or IGMP messages. Instead it will forward all these messages to the router on the main site.

Figure 24

R13 simulates the remote site in our configuration example.

R9 is the router that connects R13 to the main site.

The result of this configuration is that R9 appears as it would have the Receivers directly connected to its fa0/0. It takes the role of R13.

We can verify that reachibility is maintened to the Receiver (User2) from the Source (Server2).

References

https://www.cisco.com/c/en/us/support/docs/ip/multicast/118405-config-rp-00.html

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti/command/imc-cr-book/imc_i3.html#wp1379259139

http://www.routerfreak.com/pim-assert-mechanism/

https://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/Phase_1/mcstmsdp/mcst_p1.html

https://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/anycast.html

https://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/13717-49.html#topic1