Case Study MSDP Mesh Groups
In the preceding case study, routers Rodan and Megalon are RPs in the same AS. Large multicast domains can frequently have many RPs to share the workload or to localize multicast trees. Although MSPD has been presented so far as a tool for sharing inter-AS source information, it also proves useful when there are multiple RPs in a single domain, and sources always register to certain RPs but members throughout the domain must find any source.
Every RP in the domain commonly has an MSDP peering session to every other RP in the domain, for redundancy and robustness. Figure 7-16 shows an example. The four RPs in the illustration are in the same AS, and each is peered to the other three. The four routers may or may not be directly connected and are probably physically remote from each other.
Figure 7-16 A Full MSDP Mesh Exists Between These Four Routers
Frankenstein
Wolfman
Wolfman
Dracula
Mummy
Dracula
Example 7-16 shows the configurations of the four routers in Figure 7-16. Example 7-16 Configuring MSDP on the Four Routers in Figure 7-16
Frankenstein ip pim rp-address 10.100.1.1
ip msdp peer 10.100.1.3 connect-source LoopbackO 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 LoopbackO ip msdp description 10.100.1.4 to Dracula
Wolfman ip pim rp-address 10.100.1.2
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
Mummy ip pim rp-address 10.100.1.3
ip msdp peer 10.100.1.1 connect-source LoopbackO ip msdp description 10.100.1.1 to Frankenstein ip msdp peer 10.100.1.2 connect-source LoopbackO ip msdp description 10.100.1.2 to Wolfman ip msdp peer 10.100.1.4 connect-source LoopbackO ip msdp description 10.100.1.4 to Dracula
Dracula ip pim rp-address 10.100.1.4
ip msdp peer 10.100.1.1 connect-source LoopbackO ip msdp description 10.100.1.1 to Frankenstein ip msdp peer 10.100.1.2 connect-source LoopbackO ip msdp description 10.100.1.2 to Wolfman ip msdp peer 10.100.1.3 connect-source LoopbackO ip msdp description 10.100.1.3 to Mummy
The problem with the configuration as it stands is that an SA message generated by one router is flooded by all the other routers, causing large numbers of peer RPF flooding failures and resulting MSDP notification messages. If every RP has an MSDP connection to every other RP, however, no flooding is necessary. Every RP receives a copy of every S A directly from the originator. To remedy the flooding problem, an MSDP mesh group is built.
An MSDP mesh group is a set of fully meshed MSDP peers such as the ones shown in Figure 7-16, but no transiting of SA messages takes place. That is, when an RP receives an SA from a peer, it does not forward the message to any other peer.
Mesh groups are configured with the ip msdp mesh-group command. The group is given an arbitrary name (so that one RP can belong to more than one mesh group, if necessary), and the members of the mesh group are specified. The configurations in Example 7-17 add the RPs in Figure 7-16 to a mesh group named Boogeymen.
Example 7-17 Adding the RPs in Figure 7-16 to Mesh Group Boogeymen
Frankenstein *
ip pim rp-address 10.100.1.1
ip msdp peer 10.100.1.3 connect-source LoopbackO 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
Wolfman ip pim rp-address 10.100.1.2
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
Mummy ip pim rp-address 10.100.1.3
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
Dracula ip pim rp-address 10.100.1.4
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
Example 7-17 Adding the RPs in Figure 7-16 to Mesh Group Boogeymen (Continued)
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
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
Any cast RP 10.100.254.1
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 any cast 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 LOO interfaces; however, another loopback interface is used to configure the RP address that the routers announce. Normally, MSDP uses the RP address in its S A 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 LoopbackO 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 i router ospf 1 router-id 10.100.1.1 network 0.0.0.0 255.255.255.255 area 0
i 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 i 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 i ip pim send-rp-announce Loopback5 scope 20
ip pim send-rp-discovery LoopbackS scope 20
ip msdp peer 10.100.1.3 connect-source Loopback©
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 LoopbackS ip address 10.100.254.1 255.255.255.255 ip pim sparse-dense-mode
Example 7-18 Configuring Frankenstein, Wolfinan, Mummy, and Dracula for Any cast RP (Continued) i 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 LoopbackO neighbor 10.100.1.1 peer-group Boogeymen neighbor 10.100.1.3 peer-group Boogeymen neighbor 10.100.1.4 peer-group Boogeymen i 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 i 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 LoopbackO ip msdp description 10.100.1.1 to Frankenstein ip msdp peer 10.100.1.3 connect-source LoopbackO ip msdp description 10.100.1.3 to Mummy ip msdp peer 10.100.1.4 connect-source LoopbackO 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 LoopbackS ip address 10.100.254.1 255.255.255.255 ip pim sparse-dense-mode i router ospf 1 router-id 10.100.1.3
network 0.0.0.0 255.255.255.255 area 0
f router bgp 6500 bgp router-id 10.100.1.3 neighbor Boogeymen peer-group neighbor Boogeymen remote-as 6500 neighbor Boogeymen update-source LoopbackO
Example 7-18 Configuring Frankenstein, Wolfman, Mummy, and Dracula for Anycast RP (Continued)
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 pirn send-rp-announce LoopbackS scope 20 ip pim send-rp-discovery LoopbackS scope 20 ip msdp peer 10.100.1.1 connect-source LoopbackO 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
i interface LoopbackS ip address 10.100.254.1 255.255.255.255 ip pim sparse-dense-mode i 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 i 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
Example 7-18 Configuring Frankenstein, Wolfman, Mummy, and Dracula for Anycast RP (Continued) i ip pim send-rp-announce LoopbackS scope 20 ip pim send-rp-discovery LoopbackS scope 20 ip msdp peer 10.100.1.1 connect-source LoopbackO ip msdp description 10.100.1.1 to Frankenstein ip msdp peer 10.100.1.2 connect-source LoopbackO ip msdp description 10.100.1.2 to Wolfman % ip msdp peer 10.100.1.3 connect-source LoopbackO 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 L05 is used on each router to configure the virtual RP address, whereas LOO is the endpoint of the MSDP sessions. Notice in the configurations that the Auto-RP commands reference L05, whereas the ip msdp originator-id command references LOO. 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 L05 is higher on each router than the IP address on LOO. 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 LOO address with the router-id statement under the OSPF and BGP configura tions.
Notice also that the LOO interfaces are not running PIM. These interfaces are unnecessary to PIM functionality, and serve only to provide router-specific IP addresses for MSDP peering.
Case Study: MSDP Default Peers
If an AS is a stub or nontransit AS, and particularly if the AS is not multihomed, there is little or no reason to run BGP to its transit AS. A static default route at the stub AS, and a static route pointing to the stub prefixes at the transit AS, is generally sufficient. But what if the stub AS is also a multicast domain and its RP must peer with an RP in the neighboring domain? The overview of the MSDP operation explained that MSDP depends on the BGP next-hop database for its peer RPF checks.
You can disable this dependency on BGP with the ip msdp default-peer command. MSDP just accepts all S A messages from default peers. Figure 7-18 shows a simple example. Here, the stub AS is peered to the transit AS by a single link. RPF checks are not necessary, because there is only one path and therefore no possibility of loops.
Figure 7-18 BGP Is Typically Not Run Between a Stub AS and Its Transit AS, but This Can Cause a Problem for MSDP
- Stub AS
Freddy
RP 172.16.224.1
Transit AS
MSDP session
Example 7-19 shows the MSDP configuration of the two routers.
Example 7-19 MSDP Configurations for Routers Jason and Freddy
Jason ip msdp peer 172.16.224.1 connect-source Loopback0 ip msdp default-peer 172.16.224.1
Freddy ip msdp peer 192.168.1.1 connect-source LoopbackO ip msdp default-peer 192.168.1.1
A stub AS also might want to have MSDP peering with more than one RP for the sake of redundancy, as shown in Figure 7-19. SA messages cannot just be accepted from both default peers, because there is no RPF check mechanism. Instead, SA messages are accepted from only one peer. If that peer fails, messages are then accepted from the other peer. The underlying assumption here, of course, is that both default peers are sending the same SA messages.
Figure 7-19 Jason Is Connected to More Than One Default MSDP Peer
Figure 7-19 Jason Is Connected to More Than One Default MSDP Peer
- MSDP session Transit AS
Example 7-20 shows the configuration for Jason.
Example 7-20 Configuring Jason to Have Redundant Peering with Both Freddy and Norman ip msdp peer 172.16.224.1 connect-source LoopbackO ip msdp peer 172.16.224.2 connect-source LoopbackO ip msdp default-peer 172.16.224.1 ip msdp default-peer 172.16.224.2
Under normal circumstances, the active default peer is the first peer in the configuration— in this case, 172.16.224.1. SAs are not accepted from 172.16.224.2 unless 172.16.224.1 fails.
The RP in a transit AS is likely to have more than one default MSDP peer, as shown in Figure 7-20. Just listing the default peers, as was shown in the preceding example, does not work, because SAs would be accepted by only a single peer. To cause the RP to accept SA messages from multiple peers while still providing loop avoidance in the absence of a peer RPF check, BGP-style prefix lists are used. The RP then accepts SA messages from all of its default peers, but only for source prefixes allowed by each peer's associated prefix list. The underlying assumption here is that each AS is using distinct prefixes, so loop avoidance-is ensured.
Figure 7-20 The RP in the Transit AS Has Three Default MSDP Peers
RP 192.168.1.1
Prefix: 192.168.1.0/24
Stub AS 1
RP 192.168.2.1
Prefix: 192.168.2.0/24
Freddy
RP 172.16.224.1
Stub AS 2
Transit AS
RP 192.168.3.1
Prefix: 192.168.3.0/24
MSDP session
Stub AS 3
Example 7-21 shows the configuration for Freddy.
Example 7-21 Configuring an RP to Accept SA Messages from Multiple Peers ip msdp peer 192.168.1.1 connect-source LoopbackO ip msdp peer 192.168.2.1 connect-source LoopbackO ip msdp peer 192.168.3.1 connect-source LoopbackO ip msdp default-peer 192.168.1.1 prefix-list AS1 ip msdp default-peer 192.168.2.1 prefix-list AS2
ip msdp default-peer 192.168.3.1 prefix-list AS3 »
ip prefix-list AS1 seq 5 permit 192.168.1.0/24 le 32 ip prefix-list AS2 seq 5 permit 192.168.2.0/24 le 32 ip prefix-list AS3 seq 5 permit 192.168.3.0/24 le 32
Continue reading here: The Site Local Address
Was this article helpful?