Chapter 10. Configuring and Verifying Multicast Routing on Cisco Systems Routers
10.1 Configuring PIM and IGMP
10.1.4 Configuring the PIM-SM Bootstrap Mechanism
To configure the bootstrap mechanism in a PIM-SM domain, select which routers are candidate RPs and which routers are candidate BSRs. A single router can be both a candidate RP and a candidate BSR. You need at least one candidate RP and one candidate BSR for the bootstrap mechanism to work. All of the interfaces within the PIM-SM domain must run PIM version 2. The interfaces that connect to other PIM-SM domains should run PIM version 1 or be configured as PIM borders so that Candidate RP and Bootstrap messages are not leaked to the other domain.
To configure a router to announce itself as a candidate RP for groups in the 239.0.0.0/8 range using the IP address of its loopback 0 interface, use the following commands in global configuration mode:
ip pim rp-candidate loopback 0 group-list 4 access-list 4 permit 239.0.0.0 0.255.255.255
To configure a router as a candidate BSR using the IP address of its loopback 0 interface and setting a bootstrap priority of 50, use the following command in global configuration mode:
ip pim bsr-candidate loopback 0 50
The value of the bootstrap priority can be 0 to 255. The default is 0, and the router with the largest preference is elected BSR.
To keep Bootstrap messages from traversing an interface connected to a neighboring PIM-SM domain, use the following command in interface configuration mode:
ip pim border
Use the following command to turn on debugging for PIM BSR messages:
debugging ip pim bsr
10.1.5 Configuring Auto-RP
A domain running auto-RP needs at least one router providing the announce functionality and one router providing the mapping functionality. The same router can provide both announce and mapping functions. In IOS software, 224.0.1.39 and 224.0.1.40 are automatically set to be dense groups when any interfaces on the router are enabled for sparse-dense mode. The steps to configure auto-RP are as follows:
1.
On all routers, configure sparse-dense mode on all PIM-enabled interfaces. Use the following command in interface configuration mode:
ip pim sparse-dense-mode
On an interface configured for sparse-dense mode, any ASM group that does not have an RP is
automatically considered a dense group. If a Cisco Systems router somehow loses its group-to-RP mapping, it considers all groups to be dense. Likewise, if the RP(s) in a domain becomes unreachable, all Cisco Systems routers in that domain flood all groups according to dense mode. This behavior is fundamentally different from the way sparse-dense mode operates in Juniper Networks routers. In JUNOS software, only groups that are explicitly configured in dense mode are forwarded densely.
2.
In a PIM domain running auto-RP, each router falls into one of four categories. The following lists each category along with its configuration:
o
Discovery: The IOS software automatically listens for auto-RP Mapping messages. No configuration is necessary.
o
Announce-only: Transmit auto-RP Announce messages and listen for auto-RP Mapping messages. Use the following commands in global configuration mode:
ip pim send-rp-announce loopback 0 scope 255 group-list 5 access-list 5 permit 224.0.0.0 15.255.255.255
The scope parameter sets the IP TTL value in the auto-RP Announce messages transmitted by this router.
Prior to the advent of administrative scoping of IP multicast, TTL was used as a mechanism to scope auto-RP control packets. Setting the scope parameter to 255 ensures that auto-RP messages can reach the farthest edges of a domain. To prevent leaking, the interfaces that connect to other PIM-SM domains should be set to administratively scope the two auto-RP group addresses.
o
Mapping-only: Listen for auto-RP Announce messages, perform RP-to-group mapping function, and transmit auto-RP Mapping messages. Use the following command in global configuration mode:
ip pim send-rp-discovery scope 255
o
Announce and mapping: Perform combined tasks of both Announce-only and Mapping-only categories.
Use the following commands in global configuration mode:
ip pim send-rp-announce loopback 0 scope 255 group-list 5 access-list 5 permit 224.0.0.0 15.255.255.255
ip pim send-rp-discovery scope 255
Use the following command to show the RPs learned through auto-RP:
Router# show ip pim rp mapping
The first two groups are the auto-RP groups, which are treated as dense groups. Info source: 10.0.0.1 indicates that 10.0.0.1 is the mapping agent.
Use the following command to turn on debugging for PIM auto-RP messages:
debug ip pim auto-rp
At the edges of a domain running auto-RP, the auto-RP control messages should be administratively scoped, which keeps them from leaking into other domains. For example, if the Ethernet 0 interface connects to another PIM-SM domain, use the following commands in global configuration mode to scope the two groups used for auto-RP control messages:
Anycast RP can use any RP-set mechanism to distribute the RP-to-group mapping (that is, static, bootstrap, or auto-RP). Anycast RP with static group-to-RP mapping is the most common strategy used by ISPs because it provides load balancing and redundancy in the simplest and most intuitive manner. Anycast RP requires additional configuration only on the routers that are serving as the RPs. All other routers are configured with the standard static RP configuration pointing to the shared anycast address.
To configure anycast RP, perform the following steps on each RP:
1.
Configure two addresses on a loopback interface. One is unique to the router, and the other is the shared anycast address. The unique address should be the primary address on the loopback interface. For example, if 192.168.1.1 is an address unique to the local router and 10.10.10.10 is the shared anycast address, use the following commands in global configuration mode:
interface loopback 0
ip address 192.168.1.1 255.255.255.255
ip address 10.10.10.10 255.255.255.255 secondary ip pim sparse-mode
Alternatively, two loopback interfaces can be used. In this example, loopback 0 contains the unique address of the router, while interface loopback 1 contains the shared anycast address:
interface loopback 0
Use the unique address as the local address for the MSDP sessions to the other RPs in the domain. Also, the originator ID command sets the RP address in all originating SA messages to the unique address, which prevents originating SA messages from being rejected by other anycast RPs because of RPF failures.
The following commands in global configuration mode create an MSDP peering with another anycast RP whose unique address is 192.168.1.2:
ip msdp peer 192.168.1.2 connect-source loopback 0 ip msdp originator-id loopback 0
10.1.7 Monitoring PIM Join State and Multicast Forwarding
Once PIM is enabled on all the routers and one of the RP mapping mechanisms is configured, the network is ready to carry multicast traffic. The command used to show PIM Join state is show ip mroute.
The following example shows the output of this command for all (*,G) and (S,G) state for the group 232.1.1.1. This router is treating 232.1.1.1 as an SSM group, so there is no RP for the group, and the (*,G) entry has no upstream or downstream interfaces listed.
Outgoing interface flags: H - Hardware switched Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode (*, 232.1.1.1), 4d21h/00:02:59, RP 0.0.0.0, flags:sSJP Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.69.214.1, 232.1.1.1), 4d21h/00:02:45, flags:CTI Incoming interface: Ethernet3/2, RPF nbr 10.108.1.1 Outgoing interface list:
Ethernet3/1, Forward/Sparse-Dense, 4d21h/00:02:45
The following output is an example of an ASM group for which the local router is serving as the RP, which is evidenced by the null incoming interface for the (*,G) entry. The output also shows us that the RPF neighbor for the 10.102.222.70 source is 10.1.196.13 and that the route used to decide it came from the MBGP routing table.
Router# show ip mroute 234.12.251.11 I - Received Source Specific Host Report
Outgoing interface flags: H - Hardware switched Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 234.12.251.11), 00:15:24/00:03:02, RP 10.190.196.253, flags: S Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
ATM3/0.3, Forward/Sparse-Dense, 00:15:24/00:03:02
(10.102.222.70, 234.12.251.11), 00:01:00/00:01:59, flags: M Incoming interface: ATM3/0.10, RPF nbr 10.1.196.13, Mbgp Outgoing interface list:
ATM3/0.3, Forward/Sparse-Dense, 00:01:00/00:02:32 This document is created with the unregistered version of CHM2PDF Pilot
10.2 Configuring MSDP
To configure an MSDP peer, use the following command in global configuration mode:
ip msdp peer 192.168.1.2 connect-source loopback 0
By default, the IOS software does not cache Source-Active state. To enable Source-Active caching, use the following command in global configuration mode:
ip msdp cache-sa-state
Use the following command to display the MSDP Source-Active cache:
Router# show ip msdp sa-cache
MSDP Source-Active Cache - 5 entries
(10.39.41.33, 238.105.148.0), RP 10.39.3.111, MBGP/AS 65000, 2d10h/00:05:33 (10.240.112.8, 224.2.0.1), RP 10.9.200.65, MBGP/AS 65001, 00:03:21/00:02:38 (10.69.10.13, 227.37.32.1), RP 10.39.3.92, MBGP/AS 65002, 05:22:20/00:03:32 (10.67.66.18, 234.0.0.1), RP 10.39.3.111, MBGP/AS 65002, 2d10h/00:05:35 (10.67.66.148, 234.0.0.1), RP 10.39.3.111, MBGP/AS 65002, 2d10h/00:05:35
The AS listed is the AS in which the originating RP resides according to the MBGP table.
To configure peers in an MSDP mesh group, use the following commands in global configuration mode:
ip msdp mesh-group mesh-group-01 192.168.1.2 ip msdp mesh-group mesh-group-01 192.168.1.3
The mesh-group-01 parameter is a user-assigned mesh group name. This string is not carried in MSDP messages, so it is significant only to the local router. A router can participate in multiple mesh groups, and the name is used to distinguish among them.
To configure a default peer, use the following command in global configuration mode:
ip msdp default-peer 192.168.1.2
To filter SA messages for the 229.9.9.9 group received from a particular peer (192.168.1.2) by defining an MSDP import policy, use the following commands in global configuration mode:
ip msdp sa-filter in 192.168.1.2 route-map msdp-import route-map msdp-import permit 10
match ip address 1
access-list 1 deny 229.9.9.9 0.0.0.0 access-list 1 permit any
Care should be taken when using SA filters in transit domains. Preventing SAs from being flooded to other domains can lead to multicast "blackholes."
This document is created with the unregistered version of CHM2PDF Pilot
10.3 Configuring a Dedicated RPF Table
In IOS, the following four routing tables are used for RPF:
Unicast routing table (which includes tables for each unicast routing protocol)
When performing an RPF check, the software searches each table to find the longest-match prefix. If it finds a matching prefix in more than one of the tables, it uses the protocol preference (known as administrative distance in IOS software) to determine the route that is used for RPF.
It is important to note that the RPF route-selection process is different from that of unicast routing. With unicast routing, the longest-match prefix is chosen even if a matching prefix with a shorter mask exists from a more preferred protocol. In the case of RPF, the same selection criteria are used on each of the four routing tables, and then the route from the most preferred protocol is selected regardless of mask length. For example, the route 10.0.0.0/14, learned via MBGP, will be selected over the route 10.0.0.0/16, learned via BGP, when performing an RPF check. Unlike the unicast routing table, the longest-match prefix rule does not take effect because administrative distance is considered prior to prefix length.
Table 10-1 lists the default protocol preferences (lower preference values are more preferred).
Table 10-1. Routing Preferences
You can override the default preference for each protocol. For example, to change the preference value for Internal MBGP to 20, use the following commands in global configuration mode:
router bgp 65005
distance bgp 20 20 200
The parameters in the distance bgp command are in the order external-internal-local. To change the preference of all DVMRP-learned routes to 100, use the following commands in global configuration mode:
access-list 1 permit 0.0.0.0 255.255.255.255 interface ethernet 0
ip dvmrp accept-filter 1 100
You can check the route that is used as the RPF route for any address by using the following command:
Router # show ip rpf 10.69.10.13
The RPF Type field shows the routing table from which this route was selected. The possible values for RPF Type are unicast, DVMRP, MBGP, or static mroute.
Static mroutes are static routes that are used for multicast RPF but are not used for unicast forwarding. To configure a static mroute to 10.0.0.0/8 with a next hop of 172.16.1.1 and a preference (administrative distance) of 180, use the following command in global configuration mode:
ip mroute 10.0.0.0 255.0.0.0 172.16.1.1 180
Note
It can be confusing that the show ip mroute command shows the PIM Join state instead of the contents of the ip mroute table. There is no way to show the contents of the mroute table, but it can be inferred from the configuration file and the output of show ip rpf.
Static mroutes have a default preference of 0. A static mroute to 0.0.0.0/0 prevents the unicast routing table and the MBGP table from ever being used for RPF, assuming that administrative distances are not modified.
10.3.1 Configuring MBGP
By default, the router establishes BGP sessions as unicast-only (that is, AFI = 1, SAFI = 1). To configure a specific neighbor as an MBGP peer (AFI = 1, SAFI = 2), use the following configuration:
router bgp 65005
neighbor 10.108.1.1 remote-as 65006 nlri multicast
Use the following command to show that the neighbor is configured to exchange both unicast and multicast RPF routes:
Router# show ip bgp neighbors 172.16.232.178
BGP neighbor is 172.16.232.178, remote AS 65007, external link BGP version 4, remote router ID 192.168.3.3
BGP state = Established, up for 1w1d
Last read 00:00:53, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities:
Route refresh: advertised and received
Address family IPv4 Unicast: advertised and received Address family IPv4 Multicast: advertised and received Received 12519 messages, 0 notifications, 0 in queue Sent 12523 messages, 0 notifications, 0 in queue Route refresh request: received 0, sent 0
Minimum time between advertisement runs is 30 seconds For address family: IPv4 Unicast
BGP table version 5, neighbor version 5 Index 1, Offset 0, Mask 0x2
Community attribute sent to this neighbor Inbound path policy configured
Outbound path policy configured
Route map for incoming advertisements is uni-in Route map for outgoing advertisements is uni-out 3 accepted prefixes consume 108 bytes
Prefix advertised 6, suppressed 0, withdrawn 0 For address family: IPv4 Multicast
BGP table version 5, neighbor version 5 Index 1, Offset 0, Mask 0x2
Inbound path policy configured Outbound path policy configured
Route map for incoming advertisements is mul-in Route map for outgoing advertisements is mul-out 3 accepted prefixes consume 108 bytes
Prefix advertised 6, suppressed 0, withdrawn 0
BGP-learned routes tagged as IPv4 multicast RPF routes (that is, AFI = 1, SAFI = 2,3) are placed into the MBGP routing table. The active route for each prefix in the MBGP routing table is advertised to MBGP peers, based on the standard BGP route advertisement rules.
To specify separate policy for unicast and multicast RPF routes, BGP export and import policies can be configured to reference the unicast BGP table and the MBGP table. For example, this policy sets the local preference to 100 for unicast routes but to 200 for multicast RPF routes for routes learned from the 10.108.1.1 neighbor:
route-map bgp-mbgp permit 10
neighbor 10.108.1.1 remote-as 65005 nlri unicast multicast neighbor 10.108.1.1 route-map bgp-mbgp in
To display the contents of the MBGP table, use the following command:
Router# show ip mbgp
MBGP table version is 6, local router ID is 192.168.200.66
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete
10.3.2 Configuring DVMRP to Provide RPF Information to PIM
In IOS software, you can configure DVMRP to provide RPF information for PIM. This mode of operation is known as unicast-only mode because DVMRP is not used to set up forwarding state for multicast traffic. When used in this fashion, DVMRP is essentially equivalent to RIP, except DVMRP places its routes into a dedicated multicast RPF table. To enable DVMRP in unicast-only mode on an interface, use the following command in interface configuration mode:
ip dvmrp unicast-routing
To display the contents of the DVMRP routing table, use the following command:
Router# show ip dvmrp route DVMRP Routing Table - 1 entry
10.68.0.0/16 [100/11] uptime 07:55:50, expires 00:02:52 via 10.39.3.93, Tunnel3
The [100/11] signifies that this route has an administrative distance of 100 and a metric of 11. Like RIP, DVMRP uses hop count as its metric.
Having provided guidelines for IMR configuration with Juniper Networks and Cisco Systems routers in the previous two chapters, we provide in Chapter 11 a representative case study for native deployment of IMR by an ISP. In the case study, a feasible combination of Juniper Networks and Cisco Systems router configurations is presented.
This document is created with the unregistered version of CHM2PDF Pilot