Case Study: Configuring MSDP
Figure 7-15 again shows the routers from the preceding case study. Here, the four routers are also RPs for their respective autonomous systems, and the illustration shows their RP addresses.
MSDP is enabled quite simply with the command ip msdp peer, specifying the peer's IP address. Example 7-12 shows the MSDP configurations for the four routers in Figure 7-15.
Example 7-12 Configuring MSDP Sessions Between the Four RPs in Figure 7-15
Gorgo
ip msdp peer 192.168.1.2
_______________________________________________________________________
Kong
ip msdp peer 192.168.1.10
_______________________________________________________________________
Rodan
ip msdp peer 192.168.1.1
ip msdp peer 192.168.254.2 connect-source Loopback0
_______________________________________________________________________
Megalon
ip msdp peer 192.168.254.1 connect-source Loopback0
ip msdp peer 192.168.1.9
The peering between Gorgo and Rodan, and between Kong and Megalon, is quite straightforward. Each has only a single link over which to peer, so the session is configured between the two physical interface addresses. Between Rodan and Megalon, however, the peering is between loopback addresses. As with IBGP peering, MSDP sessions between loopback interfaces provide more resiliency. If the link shown between Rodan and Megalon in Figure 7-15 should fail, and if there is another path between the routers (not shown in the illustration), the TCP session can be rerouted. By default, the source address of the TCP packets carrying the MSDP session is the address of the originating physical interface. For peering to an address that is not part of a directly connected subnet, the connect-source option is used to change the default source address.
Example 7-13 displays the status of Megalon's two MSDP sessions using the show ip msdp peer command. Such expected information as the state of the connection, uptime, and messages sent/received appears.
Example 7-13 The show ip msdp peer Command Displays the Status of MSDP Peering Sessions
Megalon#show ip msdp peer
MSDP Peer 192.168.254.1 (?), AS 100
Description:
Connection status:
State: Up, Resets: 0, Connection source: Loopback0 (192.168.254.2)
Uptime(Downtime): 3d22h, Messages sent/received: 5683/5677
Output messages discarded: 0
Connection and counters cleared 3d22h ago
SA Filtering:
Input filter: none, route-map: none
Output filter: none, route-map: none
SA-Requests:
Input filter: none
Sending SA-Requests to peer: disabled
Peer ttl threshold: 0
Input queue size: 0, Output queue size: 0
MSDP Peer 192.168.1.9 (?), AS 300
Description:
Connection status:
State: Up, Resets: 0, Connection source: none configured
Uptime(Downtime): 3d22h, Messages sent/received: 5674/5694
Output messages discarded: 0
Connection and counters cleared 3d22h ago
SA Filtering:
Input filter: none, route-map: none
Output filter: none, route-map: none
SA-Requests:
Input filter: none
Sending SA-Requests to peer: disabled
Peer ttl threshold: 0
Input queue size: 0, Output queue size: 0
Megalon#
Example 7-13 also shows fields for displaying filters that might have been configured for SA and SA Request messages. You have several options for filtering at an MSDP router to control and scope MSDP activity. You can do the following:
Control the local sources that are allowed to register with the RP. Control the SA messages the RP sends to and receives from its MSDP peers. Control the SA Request messages the RP sends to and receives from its peers.
Other options for larger-scale MSDP environments are the addition of descriptions for each peer and configurable TTL values for the MSDP messages. Example 7-14 shows a more elaborate configuration for router Megalon in Figure 7-15.
NOTE
The configuration shown here is for demonstration purposes only. No argument is made as to the practicality of the configuration.
Example 7-14 A More-Complex MSDP Configuration
ip pim rp-address 192.168.254.2
ip msdp peer 192.168.254.1 connect-source Loopback0
ip msdp description 192.168.254.1 Rodan in AS 100
ip msdp sa-filter out 192.168.254.1 list 101
ip msdp filter-sa-request 192.168.254.1 list 1
ip msdp sa-request 192.168.254.1
ip msdp ttl-threshold 192.168.254.1 5
ip msdp peer 192.168.1.9
ip msdp description 192.168.1.9 Kong in AS 300
ip msdp sa-filter in 192.168.1.9 list 101
ip msdp sa-filter out 192.168.1.9 list 103
ip msdp sa-request 192.168.1.9
ip msdp ttl-threshold 192.168.1.9 2
ip msdp cache-sa-state list 101
ip msdp redistribute list 102
!
access-list 1 permit 229.50.0.0 0.0.255.255
access-list 101 permit ip 10.254.0.0 0.0.255.255 224.0.0.0 31.255.255.255
access-list 102 permit ip 192.168.224.0 0.0.0.255 224.0.0.0 31.255.255.255
access-list 103 permit ip 172.16.0.0 0.0.255.255 230.0.0.0 0.255.255.255
access-list 103 permit ip 192.168.224.0 0.0.0.255 224.0.0.0 31.255.255.255
The two statements enabling MSDP to Rodan and Kong, as shown in Example 7-12, remain. But added to the configuration is a text description for each peer, using the ip msdp description command. The description always appears directly after the ip msdp peer command for a specific peer, and it is obviously useful when there are large numbers of MSDP peers.
SA caching is enabled with ip msdp cache-sa-state, and in this configuration, an optional access list is referenced. Access list 101 specifies that Megalon will cache only SA messages for (S, G) pairs whose source address begins with 10.254.0.0/16. The group can be any multicast address (224.0.0.0/3).
An ip msdp sa-request statement is entered for each of the two peers to further reduce join latency. If the router receives a join message for a particular group, it sends an SA Request message to the two neighbors. The assumption here, as previously discussed, is that the two neighbors are configured to cache SA messages.
SA Requests to Rodan (192.168.254.1) are further restricted with the ip msdp filter-sa-request command. This filter references access list 1, which allows only 229.50.0.0/16. The result is that Megalon will request only source information from Rodan for groups whose addresses fall under prefix 229.50.0.0/16.
Next, Megalon is configured to send only SA messages for a subset of the possible sources that might send PIM-SM Register messages to it. The ip msdp redistribute statement references access list 102, which in turn permits source prefixes of 192.168.224.0/24 and group address prefixes of 224.0.0.0/3 (all multicast groups). Any source can still register with the RP, within the limits of the RP's PIM-SM configuration, but only those sources whose first 24 address bits are 192.168.224 are advertised in SA messages.
The forwarding of SA messages to MSDP peers is regulated with the ip msdp sa-filter out command. This filter applies to all SA messages, whether locally originated or received from another MSDP peer, whereas the ip msdp redistribute command applies only to locally originated SA messages. Megalon has two of these statements. For neighbor Rodan (192.168.254.1), only messages from source prefix 10.254.0.0/16 are forwarded, as specified by access list 101. Megalon sends to Kong (192.168.1.9) only SA messages that are permitted by access list 103. This access list permits messages whose source prefix is 172.16.0.0/16 and whose group addresses belong to 230.0.0.0/8, or sources whose prefix is 192.168.224.0/24 originating packets for any multicast group.
You can also filter incoming SA messages with the ip msdp sa-filter in command. Using this command, Megalon accepts SA messages from Kong only if the (S, G) pair is permitted by access list 101. Notice that this is the same constraint that is placed on outgoing SA messages to Rodan.
Finally, the TTL values of the MSDP messages are regulated with the ip msdp ttl-threshold command. The TTL of messages sent to Rodan is set to 5, whereas the TTL of messages sent to Kong is set to 2.
Example 7-15 shows the results of this configuration. Compare this display with the display in Example 7-13, and you can see the descriptions, filters, and TTL thresholds that have changed.
Example 7-15 This Display Reflects the Changes Made to Megalon's MSDP Configuration
Megalon#show ip msdp peer
MSDP Peer 192.168.254.1 (?), AS 100
Description: Rodan in AS 100
Connection status:
State: Up, Resets: 0, Connection source: Loopback0 (192.168.254.2)
Uptime(Downtime): 4d14h, Messages sent/received: 6624/6617
Output messages discarded: 0
Connection and counters cleared 4d14h ago
SA Filtering:
Input filter: none, route-map: none
Output filter: 101, route-map: none
SA-Requests:
Input filter: 1
Sending SA-Requests to peer: enabled
Peer ttl threshold: 5
Input queue size: 0, Output queue size: 0
MSDP Peer 192.168.1.9 (?), AS 300
Description: Kong in AS 300
Connection status:
State: Up, Resets: 0, Connection source: none configured
Uptime(Downtime): 4d14h, Messages sent/received: 6614/6634
Output messages discarded: 0
Connection and counters cleared 4d14h ago
SA Filtering:
Input filter: 101, route-map: none
Output filter: 102, route-map: none
SA-Requests:
Input filter: none
Sending SA-Requests to peer: enabled
Peer ttl threshold: 2
Input queue size: 0, Output queue size: 0
Megalon#
In addition to access lists, you can link incoming and outgoing SA filters to route maps for even better granularity of control and application of policy. You also can use route maps in conjunction with MSDP redistribution, as well as AS path access lists.
| 
