Connecting PIM-SM Domains Using MSDP and MBGP

Problem

You want to configure the routers so that customers in your AS can receive multicast streams from sources that are managed and maintained by another ISP.

Solution

Use MSDP, along with Multiprotocol BGP (MBGP), to connect the two PIM-SM domains. The MSDP connection runs parallel to the MBGP connection. Start by setting up the BGP border routers. This recipe has redundant EBGP connections between the ASs, one that runs MSDP and carries the multicast traffic and one that carries only unicast traffic.

Lets start with the multicast-enabled border router. Create RIB groups for MSDP, PIM, and the routers interfaces to use:

	[edit routing-options]
	aviva@RouterG# set rib-group mcast-rib export-rib inet.2
	aviva@RouterG# set rib-group mcast-rib import-rib inet.2
	aviva@RouterG# set rib-group if-rib import-rib [inet.0 inet.2]
	aviva@RouterG# set interface-routes rib-group inet if-rib

Configure MSDP, specifying the address of its peer and telling it to use the multicast RIB groups:

	[edit protocols msdp]
	aviva@RouterG# set local-address 192.168.19.1
	aviva@RouterG# set peer 192.168.19.1
	aviva@RouterG# set rib-group inet mcast-rib

Configure an EBGP session, enabling MBGP on it:

	[edit routing-options]
	aviva@RouterG# set router-id 192.168.19.1 
	aviva@RouterG# set autonomous-system 65500 

	[edit protocols bgp group external ]
	aviva@RouterG# set type external 
	aviva@RouterG# set peer-as 65520 
	aviva@RouterG# set neighbor 10.0.1.1 
	aviva@RouterG# set family inet any 

The border router also needs to be the PIM-SM RP, and PIM needs to use the multicast RIB groups:

	[edit protocols pim]
	aviva@RouterG# set interface all
	aviva@RouterG# set interface fe-0/0/0 disable
	aviva@RouterG# set rp local address 192.168.19.1
	aviva@RouterG# set rib-group inet mcast-rib

The configuration on the EBGP/MSDP peer router in the other AS should be the same, substituting the correct AS number and interface names and addresses.

Next, configure the border router that will handle the unicast traffic. Configure an EBGP session with the remote peer, configuring it to carry only unicast routes:

	[edit routing-options]
	aviva@RouterB# set router-id 192.168.12.1 
	aviva@RouterB# set autonomous-system 65500 

	[edit protocols bgp group external ]
	aviva@RouterB# set type external 
	aviva@RouterB# set peer-as 65520 
	aviva@RouterB# set neighbor 10.0.22.2 
	aviva@RouterB# set family inet unicast 

Configure PIM-SM only on the interfaces facing the local AS:

	[edit protocols pim]
	aviva@RouterB# set interface se-0/0/2
	aviva@RouterB# set rp static address 192.168.19.1

For all the other routers that are not on the AS border, just configure PIM-SM normally:

	[edit protocols pim]
	aviva@RouterE# set interface all
	aviva@RouterE# set interface fe-0/0/0 disable
	aviva@RouterE# set rp static address 192.168.19.1

All the routers must also be running an IGP. The routers in this example are running OSPF.

Discussion

With PIM-SM, the RP in each domain learns about active sources within its domain and the DRs learn the source information from the data that is received down the shared tree when they send a (*.G) toward the RP. MSDP enables RPs in different domains to share information about active sources. This allows customers in your AS to access multicast sources that are maintained somewhere else on the Internet. MSDP uses TCP to establish reliable sessions between PIM-SM domains and passes source active messages over the session so that the RPs can learn about external sources. Also, MSDP enables different RPs within a domain to exchange source information between the subdomainswith anycast, for example.

One way to set up MSDP to handle interdomain source information is to create redundant EBGP connections to the remote AS. One EBGP session carries the multicast traffic, and the other carries unicast traffic. On the multicast-enabled EBGP router, you enable MBGP and create a separate routing table that contains only the unicast routes whose next hop points to a multicast-enabled router. (It is still the case that most routers in the Internet don support multicast.)PIM consults this table during RPF calculations instead of using the default inet.0 table to forward multicast traffic. Another way to set up the MSDP peering session is to do so between two RP routers that are in the core of the network instead of at the edge.

Figure 16-2 shows the topology used in this recipe. The following points summarize the overall configuration:

• There are two EBGP connections between the two ASs, one between RouterG and RouterH, the second between RouterB and RouterC.
• The EBGP connection between RouterG and RouterH is multicast-enabled. MSDP runs on both these routers, and each is the RP for its PIM-SM domain. PIM runs on interfaces, both the inward-facing ones and the one facing the remote AS.
• The EBGP connection between RouterB and RouterC carries the unicast traffic between the two ASs. These two routers run PIM only on internally facing interfaces, and the PIM configuration points to their local RP.
• All routers within each AS have PIM enabled on all interfaces, and the PIM configuration points to their local RP.
• All routers within a domain are running OSPF as the IGP.

The bulk of the configuration is on the multicast-enabled border routers. First, create two JUNOS RIB groups (routing-table groups) that populate the multicast RPF table, inet.2, with the routes that PIM and MSDP will use.

PIM and MSDP normally consult inet.0 (the default unicast routing table) to make their RPF decisions. They never add multicast routes to inet.0. However, when multicast and unicast topologies are not congruent, you can configure PIM and MSDP to consult inet.2 as an alternative unicast routing table to use to base their RPF decisions on. (This network is not congruent because the RouterGRouterH link carries only multicast traffic and the RouterBRouterC link carries all unicast traffic.)The RIB groups populate inet.2 with unicast routes that are a subset of the unicast routes in inet.0. The routes placed in inet.2 are only those unicast routes that resolve to multicast-enabled routers. For PIM and MSDP to work, the inet.2 table needs to include all the sources prefixes, all the RPs prefixes, and all direct routes.

Figure 16-2. MSDP network topology

The first RIB group you create, called mcast-rib, imports routes into and exports routes from inet.2:

	[edit routing-options]
	aviva@RouterG# set rib-group mcast-rib export-rib inet.2
	aviva@RouterG# set rib-group mcast-rib import-rib inet.2

When you associate this RIB group with MSDP and PIM, they consult it for their RPF decisions.

The second RIB group, called if-rib, is for interface (direct) routes:

	[edit routing-options]
	aviva@RouterG# set rib-group if-rib import-rib [inet.0 inet.2]

This RIB group populates inet.2 with the routers direct routes. Then associate the if-rib RIB group with the routers interfaces:

	[edit routing-options]
	aviva@RouterG# set interface-routes rib-group inet if-rib

The full RIB group configuration looks like this:

	aviva@RouterG> show configuration routing-options
	interface-routes {
	 rib-group inet if-rib;
	}
	rib-groups {
	 if-rib {
	 import-rib [ inet.0 inet.2 ];
	 }
	 mcast-rib {
	 export-rib inet.2;
	 import-rib inet.2;
	 }
	}

Next, configure MSDP, PIM, and your IGP on the multicast-enabled border routers. For MSDP, specify the IP addresses of the local router and its remote peer, using the routers loopback addresses. You also need to associate the mcast-rib RIB group, which populates the inet.2 routing table, with MSDP. Heres what the MSDP configuration looks like for RouterG:

	aviva@RouterG> show configuration protocols
	msdp {
	rib-group inet mcast-rib; # <-- RIB group to populate inet.2
	local-address 192.168.19.1; # <-- loopback address of RouterG
	peer 192.168.18.1; # <-- loopback address of RouterH
	}

The multicast-enabled routers must be the PIM-SM RPs for their domains and must be running PIM both on the internally facing interfaces and on the interface facing the remote border router.

Although this recipe configures the EBGP and MSDP peering sessions between the same two routers (RouterG and RouterH), this is not necessary. The MSDP peering session can be configured between any two RPs.

You also need to associate the mcast-rib RIB group with PIM. Heres the PIM configuration on RouterG:

	aviva@RouterG> show configuration protocols
	pim {
	 rib-group inet mcast-rib;
	 rp {
	 local {
	 address 192.168.19.1;
	 }
	 }
	 interface all;
	 interface fe-0/0/0.0 {
	 disable;
	 }
	}

For the EBGP connection, in addition to the standard configuration (see Recipe 13.1), enable MBGP on the connection so that the BGP connection can carry the NLRI for both unicast and multicast routes. Here is the EBGP configuration:

	aviva@RouterG> show configuration protocols
	bgp {
	 group external {
	 type external;
	 family inet { # <-- turn on MBGP
	 any; # <-- have BGP carry both unicast and multicast NLRIs
	 }
	 peer-as 65520;
	 neighbor 10.0.1.1;
	 }
	}

This completes the configuration for the multicast-enabled border routers. For the border routers that will be carrying only unicast traffic, you must set up EBGP and can optionally set up PIM. For the EBGP session, turn on MBGP, specifying that it carry only the NLRIs for unicast routes. To do this, use the unicast option in the family inet statement:

	aviva@RouterB> show configuration protocols bgp
	group external {
	 type external;
	 family inet { # <-- turn on MBGP
	 unicast; # <-- carry unicast NLRIs only
	 }
	 peer-as 65520;
	 neighbor 10.0.22.2;
	}

This border router does not need to be part of the PIM-SM domain. However, if it is, configure PIM only on the internally facing interface (on RouterB, this is se-0/0/2) and set the RPs address to be the address of the multicast-enabled border router, which in this recipe is RouterG (192.168.19.1). Here is RouterBs PIM configuration:

	aviva@RouterB> show configuration protocols pim
	rp {
	 static {
	 address 192.168.19.1; # <-- RP and EBGP/MSDP border router
	 }
	}
	interface se-0/0/2.0;

For all the other PIM-SM routers within the AS, use a standard PIM-SM configuration, setting the RP to be the multicast-enabled border router. Heres an example, for RouterE:

	aviva@RouterE> show configuration protocols
	pim {
	 rp {
	 static {

	 address 192.168.19.1; # <-- RP and EBGP/MSDP border router
	 }
	 }
	 interface all;
	 interface fe-0/0/0.0 {
	 disable;
	 }
	}

You also need an IGP running within each AS. The router setup for this recipe uses OSFP.

When the configuration of the routers in both ASs is complete, the routers can handle a request from a multicast receiver in one of the ASs to a multicast source in the other. Lets follow a request from a receiver host connected to RouterF in AS 65200 to a source that is connected to RouterE in AS 65500. For this lab setup, the receiver is simulated by a ping command to multicast group 224.1.1.1. RouterE is configured with SAP to this group. Here is the ping command issued on RouterF:

	aviva@RouterF> ping 224.1.1.1 interface t1-0/0/3 ttl 8 count 5 bypass-routing
	PING 224.1.1.1 (224.1.1.1): 56 data bytes
	64 bytes from 10.0.15.1: icmp_seq=0 ttl=251 time=27.881 ms
	64 bytes from 10.0.15.1: icmp_seq=1 ttl=251 time=30.562 ms
	64 bytes from 10.0.15.1: icmp_seq=2 ttl=251 time=30.341 ms
	64 bytes from 10.0.15.1: icmp_seq=3 ttl=251 time=40.328 ms
	64 bytes from 10.0.15.1: icmp_seq=4 ttl=251 time=30.336 ms
	--- 224.1.1.1 ping statistics ---
	5 packets transmitted, 5 packets received, 0% packet loss
	round-trip min/avg/max/stddev = 27.881/31.890/40.328/4.332 ms

Lets follow the join request downstream to the multicast source. Look on the neighbor, RouterD, to see whether it has received the PIM Join/ Prune messages for 224.1.1.1:

	aviva@RouterD> show pim join extensive 224.1.1.1
	Instance: PIM.master Family: INET
	Group: 224.1.1.1
	 Source: 10.0.31.2
	 Flags: sparse
	 Upstream interface: t1-0/0/3.0
	 Upstream neighbor: 10.0.31.2
	 Upstream State: Local Source
	 Keepalive timeout: 170
	 Downstream Neighbors:
	 Interface: t1-0/0/2.0
	 10.0.24.1 State: Join Flags: S Timeout: 167

This output shows that the source of the PIM Join message is 10.0.31.2, which is the interface to RouterF. This is confirmed by the Upstream interface and Upstream neighbor fields, which show you the RPF interface and neighbor for the source address: t1-0/0/3 is the interface on RouterF that connects to RouterD. The Upstream State is Local Source, indicating that the source of the join request (here, RouterF) is directly connected to this router (RouterD). The Downstream Neighbors field shows where RouterD is forwarding the Join message. You see that the message has been forwarded out RouterDs interface t1-0/0/2 to 10.0.24.1, which is the t1-5/0/0 interface on the border router, RouterH.

Moving to the next downstream router, which is the border router, check for PIM joins for group 224.1.1.1:

	aviva@RouterH> show pim join extensive 224.1.1.1
	Instance: PIM.master Family: INET
	Group: 224.1.1.1
	 Source: 10.0.31.2
	 Flags: sparse,spt-pending
	 Upstream interface: t1-5/0/0.0
	 Upstream neighbor: 10.0.24.2
	 Upstream State: Local RP, Join to Source
	 Keepalive timeout: 108
	 Downstream Neighbors:
	 Interface: fe-1/0/1.0
	 10.0.1.2 State: Join Flags: S Timeout: 170

Again, you see that the source is RouterF (10.0.31.2)and that the upstream information points to RouterHs neighbor, RouterD. The Upstream State shows that this router is the RP and that it has sent a PIM Join/Prune message to the multicast source.

RouterH is the RP and is running MSDP. An MSDP-enabled RPs builds a cache of SA messages, which it then uses to notify the RPs in other domains about active sources. The RP creates the entries in this cache when it receives a PIM Register message from a DR advertising a new source. You already saw that RouterD sent a PIM register message, so look on RouterH to see the entries in the SA cache:

	aviva@RouterH> show msdp source-active
	Group address Source address Peer address Originator Flags
	224.1.1.1 10.0.31.2 local 192.168.18.1 Accept

The output shows that the router has learned that 224.1.1.1 is an active source. RouterH should be advertising this source to its EBGP peer RouterG, so look at the MSDP SA cache there:

	aviva@RouterG> show msdp source-active
	Group address Source address Peer address Originator Flags
	224.1.1.1 10.0.31.2 192.168.18.1 192.168.18.1 Accept

The group 224.1.1.1 is present, with the source 10.0.31.2 (RouterF in the remote AS), which confirms that the join request has crossed from AS 65200 into AS 65200.

	aviva@RouterG> show pim join extensive 224.1.1.1
	Instance: PIM.master Family: INET
	Group: 224.1.1.1
	 Source: *
	 RP: 192.168.19.1
	 Flags: sparse,rptree,wildcard

	 Upstream interface: local
	 Upstream neighbor: Local
	 Upstream State: Local RP
	 Downstream Neighbors:
	 Interface: se-5/0/1.0
	 10.0.16.1 State: Join Flags: SRW Timeout: 186
	Group: 224.1.1.1
	 Source: 10.0.31.2
	 Flags: sparse,spt-pending
	 Upstream interface: fe-1/0/1.0
	 Upstream neighbor: 10.0.1.1
	 Upstream State: Local RP, Join to Source
	 Keepalive timeout: 194
	 Downstream Neighbors:
	 Interface: se-5/0/1.0
	 10.0.16.1 State: Join Flags: S Timeout: 186

RouterG, the RP in the receivers domain has two join entries for 224.1.1.1. The first is a (*,G) entry and the second is an (S,G) entry. The (*,G) join is from the receiver and propagates up to its domain RP and stops there. The Upstream interface and Upstream neighbor for this entry are both local, and the Upstream State field confirms that the upstream interface is the domains RP router. The second entry, the (S,G) entry, is the one sending the Join message downstream to the multicast source. The MSDP-speaking RP sends the (S,G) entries to remote domains, so you see only (S,G) entries on the remote side.

To verify that RouterG learned this information from MBGP, use the show multicast rpf command:

	aviva@RouterG> show multicast rpf 10.0.31.2
	Multicast RPF table: inet.2 , 20 entries
	10.0.31.0/24
	 Protocol: BGP
	 Interface: fe-1/0/1.0
	 Neighbor: 10.0.1.1

The output shows that the inet.2 multicast RPF table has an entry for 10.0.31.2 (RouterF, the multicast receiver) and that this route was learned from BGP. The listed interface is the one that connects RouterH to RouterG, and the neighbor address is that of RouterHs interface to RouterG. You can also look at this route in the inet.2 table directly:

	aviva@RouterG> show route table inet.2 10.0.31.2
	inet.2: 20 destinations, 24 routes (20 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	10.0.31.0/24 *[BGP/170] 16:46:35, MED 130, localpref 100
	 AS path: 65520 I
	 > to 10.0.1.1 via fe-1/0/1.0

Again, you see that this route was learned from EBGP and from AS 65520.

Continuing toward the multicast source, check the PIM joins on RouterA:

	aviva@RouterA> show pim join extensive 224.1.1.1
	Instance: PIM.master Family: INET
	Group: 224.1.1.1
	 Source: *
	 RP: 192.168.19.1
	 Flags: sparse,rptree,wildcard
	 Upstream interface: se-0/0/3.0
	 Upstream neighbor: 10.0.16.2
	 Upstream State: Join to RP
	 Downstream Neighbors:
	 Interface: fe-0/0/1.0
	 10.0.15.1 State: Join Flags: SRW Timeout: 187

The downstream neighbor is 10.0.15.1 (RouterE), which is the DR for the multicast receiver:

	aviva@RouterE> show pim join extensive 224.1.1.1
	Instance: PIM.master Family: INET
	Group: 224.1.1.1
	 Source: *
	 RP: 192.168.19.1
	 Flags: sparse,rptree,wildcard
	 Upstream interface: fe-0/0/1.0
	 Upstream neighbor: 10.0.15.2
	 Upstream State: Join to RP
	 Downstream Neighbors:
	 Interface: local
	Group: 224.1.1.1
	 Source: 10.0.31.2
	 Flags: sparse,spt
	 Upstream interface: fe-0/0/1.0
	 Upstream neighbor: 10.0.15.2
	 Upstream State: Join to Source
	 Keepalive timeout: 202
	 Downstream Neighbors:
	 Interface: local

The Downstream Neighbors field shows that the next interface is on the local router because this router is a SAP listener and so is acting as a receiver (sink) for the group. If the receiver was a host system, you would see the name of the interface toward the host here.

When both ASs have multicast sources and receivers, the MSDP-enabled routers have entries for all the groups in the SA cache. When a multicast receiver in AS 65500 joins group 225.2.2.2 in AS 65520, the SA cache on RouterG has two entries:

	aviva@RouterG> show msdp source-active
	Group address Source address Peer address Originator Flags
	224.1.1.1 10.0.31.2 192.168.18.1 192.168.18.1 Accept
	225.2.2.2 10.0.15.1 local 192.168.19.1 Accept

The first entry is for the source in the remote domain, and the second entry is for the source in the local domain. The Source address shows the IP address of the multicast source. For the first SA entry, the source is RouterF (10.0.31.2)in AS 65520, and for the second SA entry, the source is 10.0.15.1 (RouterE) in RouterGs AS. The Peer address field tells how MSDP learned the SA message. The first was learned from RouterGs MSDP peer, RouterH (192.168.18.1), and the second was learned in the local AS. This is confirmed by the Originator field, which is the address of the peer that originated the SA message.

Looking at the SA cache on the MSDP shows the same information, with the peer addresses being reversed:

	aviva@RouterH> show msdp source-active
	Group address Source address Peer address Originator Flags
	224.1.1.1 10.0.31.2 local 192.168.18.1 Accept
	225.2.2.2 10.0.15.1 192.168.19.1 192.168.19.1 Accept

Again, you can verify that RouterH has learned the route to RouterE from the multicast RPF table, inet.2:

	aviva@RouterH> show multicast rpf 10.0.15.1
	Multicast RPF table: inet.2, 20 entries
	10.0.15.0/24
	 Protocol: BGP
	 Interface: fe-1/0/1.0
	 Neighbor: 10.0.1.2

	aviva@RouterH> show route table inet.2 10.0.15.1
	inet.2: 20 destinations, 24 routes (20 active, 0 holddown, 0 hidden)
	+ = Active Route, - = Last Active, * = Both
	10.0.15.0/24 *[BGP/170] 17:19:46, MED 13, localpref 100
	 AS path: 65500 I
	 > to 10.0.1.2 via fe-1/0/1.0

The other two EBGP routers, RouterB and RouterC, which you configured to carry only unicast NLRIs, have only the standard inet.0 routing table for unicast routes. Issuing a show route table inet.2 command on these routers confirms that the multicast RPF table is empty.

See Also

Recipe 13.1