Case Study: Anycast RP

Designers of large, geographically diverse PIM-SM domains must often wrestle with the dilemma of where to most efficiently place the RPs. PIM-SM allows only a single group -to-RP mapping, which presents several problems in large domains:[4]

• Possible traffic bottlenecks

• Lack of scalable register decapsulation (when using shared trees)

• Slow failover when an active RP fails

• Possible suboptimal forwarding of multicast packets

• Dependence on remote RPs

You read in Chapters 5 and 6 about different schemes for alleviating some of these problems, such as the hashing algorithm used with the PIMv2 bootstrap protocol and Auto-RP filtering. None of these tools offer a completely acceptable solution. Anycast RP is a method of allowing the mapping of a single group to multiple RPs. The RPs can be distributed throughout the domain, and all use the same RP address. As a result, a "virtual RP" is created. MSDP is fundamental to the creation of a virtual RP.

NOTE

Generically, anycasting means that packets can be sent to a single address, and one of several devices can respond to the address.

Figure 7-17 shows an example where the same routers from the preceding case study are used, but all four routers are running Auto-RP and are announcing an RP address of 10.100.254.1. Source DRs within the domain know of just the one RP address and register with the closest physical RP. Normally, this causes partitioning of the PIM domain. Using an MSDP mesh group, however, the anycast RPs can exchange source information within the group.

Figure 7-17. The Four Routers Form a Virtual RP, Announcing a Single RP Address of 10.100.254.1, and Using MSDP to Exchange Information About Sources That Have Registered to Each Router

The unicast routing protocol of each anycast RP advertises the common RP address. From the perspective of source and group DRs, there is just a single RP at this address, with several routes to it. A DR chooses the shortest route, which in reality leads to the nearest anycast RP. If the anycast RP fails, the unicast protocol announces the route to the RP as unfeasible. The DR sees only the unfeasible route and chooses the next-best route, which in reality leads to the next -nearest anycast RP. As a result, RP failover is linked to and almost as fast as the unicast reconvergence time.

The MSDP peering takes place as before, between the LO0 interfaces; however, another loopback interface is used to configure the RP address that the routers announce. Normally, MSDP uses the RP address in its SA messages. Because all four routers are announcing the same RP address, MSDP must be configured to use a unique address in its SA messages. The ip msdp originator-id command accomplishes this. Example 7-18 shows the relevant configurations of the four routers, using mesh groups and ip msdp originator-id.

Example 7-18 Configuring Frankenstein, Wolfman, Mummy, and Dracula for Anycast RP

  Frankenstein   interface Loopback0   ip address 10.100.1.1 255.255.255.255   !   interface Loopback5   ip address 10.100.254.1 255.255.255.255   ip pim sparse-dense-mode   !   router ospf 1   router-id 10.100.1.1   network 0.0.0.0 255.255.255.255 area 0   !   router bgp 6500   bgp router-id 10.100.1.1   neighbor Boogeymen peer-group   neighbor Boogeymen remote-as 6500   neighbor Boogeymen update-source Loopback0   neighbor 10.100.1.2 peer-group Boogeymen   neighbor 10.100.1.3 peer-group Boogeymen   neighbor 10.100.1.4 peer-group Boogeymen   !   address-family ipv4 multicast   neighbor 10.100.1.2 activate   neighbor 10.100.1.3 activate   neighbor 10.100.1.4 activate   exit-address-family   !   ip pim send-rp-announce Loopback5 scope 20   ip pim send-rp-discovery Loopback5 scope 20   ip msdp peer 10.100.1.3 connect-source Loopback0   ip msdp description 10.100.1.3 to Mummy   ip msdp peer 10.100.1.2 connect-source Loopback0   ip msdp description 10.100.1.2 to Wolfman   ip msdp peer 10.100.1.4 connect-source Loopback0   ip msdp description 10.100.1.4 to Dracula   ip msdp mesh-group Boogeymen 10.100.1.3   ip msdp mesh-group Boogeymen 10.100.1.2   ip msdp mesh-group Boogeymen 10.100.1.4   ip msdp cache-sa-state   ip msdp originator-id Loopback0  _______________________________________________________________________  Wolfman   interface Loopback0   ip address 10.100.1.2 255.255.255.255   !   interface Loopback5   ip address 10.100.254.1 255.255.255.255   ip pim sparse-dense-mode   !   router ospf 1   router-id 10.100.1.2   network 0.0.0.0 255.255.255.255 area 0   !   router bgp 6500   bgp router-id 10.100.1.2   neighbor Boogeymen peer-group   neighbor Boogeymen remote-as 6500   neighbor Boogeymen update-source Loopback0   neighbor 10.100.1.1 peer-group Boogeymen   neighbor 10.100.1.3 peer-group Boogeymen   neighbor 10.100.1.4 peer-group Boogeymen   !   address-family ipv4 multicast   neighbor 10.100.1.1 activate   neighbor 10.100.1.3 activate   neighbor 10.100.1.4 activate   exit-address-family   !   ip pim send-rp-announce Loopback5 scope 20   ip pim send-rp-discovery Loopback5 scope 20   ip msdp peer 10.100.1.1 connect-source Loopback0   ip msdp description 10.100.1.1 to Frankenstein   ip msdp peer 10.100.1.3 connect-source Loopback0   ip msdp description 10.100.1.3 to Mummy   ip msdp peer 10.100.1.4 connect-source Loopback0   ip msdp description 10.100.1.4 to Dracula   ip msdp mesh-group Boogeymen 10.100.1.1   ip msdp mesh-group Boogeymen 10.100.1.3   ip msdp mesh-group Boogeymen 10.100.1.4   ip msdp cache-sa-state   ip msdp originator-id Loopback0  _______________________________________________________________________  Mummy   interface Loopback0   ip address 10.100.1.3 255.255.255.255   !   interface Loopback5   ip address 10.100.254.1 255.255.255.255   ip pim sparse-dense-mode   !   router ospf 1   router-id 10.100.1.3   network 0.0.0.0 255.255.255.255 area 0   !   router bgp 6500   bgp router-id 10.100.1.3   neighbor Boogeymen peer-group   neighbor Boogeymen remote-as 6500   neighbor Boogeymen update-source Loopback0   neighbor 10.100.1.1 peer-group Boogeymen   neighbor 10.100.1.2 peer-group Boogeymen   neighbor 10.100.1.4 peer-group Boogeymen   !   address-family ipv4 multicast   neighbor 10.100.1.1 activate   neighbor 10.100.1.2 activate   neighbor 10.100.1.4 activate   exit-address-family   ip pim send-rp-announce Loopback5 scope 20   ip pim send-rp-discovery Loopback5 scope 20   ip msdp peer 10.100.1.1 connect-source Loopback0   ip msdp description 10.100.1.1 to Frankenstein   ip msdp peer 10.100.1.2 connect-source Loopback0   ip msdp description 10.100.1.2 to Wolfman   ip msdp peer 10.100.1.4 connect-source Loopback0   ip msdp description 10.100.1.4 to Dracula   ip msdp mesh-group Boogeymen 10.100.1.1   ip msdp mesh-group Boogeymen 10.100.1.2   ip msdp mesh-group Boogeymen 10.100.1.4   ip msdp cache-sa-state   ip msdp originator-id Loopback0  _______________________________________________________________________  Dracula   interface Loopback0   ip address 10.100.1.4 255.255.255.255   !   interface Loopback5   ip address 10.100.254.1 255.255.255.255   ip pim sparse-dense-mode   !   router ospf 1   router-id 10.100.1.4   network 0.0.0.0 255.255.255.255 area 0   !   router bgp 6500   bgp router-id 10.100.1.4   neighbor Boogeymen peer-group   neighbor Boogeymen remote-as 6500   neighbor Boogeymen update-source Loopback0   neighbor 10.100.1.1 peer-group Boogeymen   neighbor 10.100.1.2 peer-group Boogeymen   neighbor 10.100.1.3 peer-group Boogeymen   !   address-family ipv4 multicast   neighbor 10.100.1.1 activate   neighbor 10.100.1.2 activate   neighbor 10.100.1.3 activate   exit-address-family   !   ip pim send-rp-announce Loopback5 scope 20   ip pim send-rp-discovery Loopback5 scope 20   ip msdp peer 10.100.1.1 connect-source Loopback0   ip msdp description 10.100.1.1 to Frankenstein   ip msdp peer 10.100.1.2 connect-source Loopback0   ip msdp description 10.100.1.2 to Wolfman   ip msdp peer 10.100.1.3 connect-source Loopback0   ip msdp description 10.100.1.3 to Mummy   ip msdp mesh-group Boogeymen 10.100.1.1   ip msdp mesh-group Boogeymen 10.100.1.2   ip msdp mesh-group Boogeymen 10.100.1.3   ip msdp cache-sa-state   ip msdp originator-id Loopback0  

In Example 7-18, each of the four routers is configured as both an Auto-RP candidate RP and a mapping agent. You also can use static mapping or PIMv2 bootstrap with anycast RP. All four routers in this example are configured to cache SA messages.

Interface LO5 is used on each router to configure the virtual RP address, whereas LO0 is the endpoint of the MSDP sessions. Notice in the configurations that the Auto-RP commands reference LO5, whereas the ip msdp originator-id command references LO0. This is vital , because MSDP must have unique IP addresses at the endpoints of its peering sessions.

The OSPF and BGP stanzas are shown for an important reason. Recall that OSPF and BGP use the highest IP address configured on any loopback interface as its router ID. Unfortunately, the IP address on LO5 is higher on each router than the IP address on LO0. As a result, the OSPF and BGP processes on each router would by default use a router ID of 10.100.254.1. One of many undesirable results would be the thrashing of the OSPF databases as each router's LSAs try to override the other routers' LSAs. One solution is to always use a virtual RP address that is numerically lower than any other loopback address, but there are obvious impracticalities in this and some large vulnerabilities to inadvertent configuration mistakes. A better solution, used in this example, is to force each router to use its unique LO0 address with the router-id statement under the OSPF and BGP configurations.

Notice also that the LO0 interfaces are not running PIM. These interfaces are unnecessary to PIM functionality, and serve only to provide router-specific IP addresses for MSDP peering.