Case Study: Multicasting Across Non-Multicast Domains

One challenge you will face is connecting diverse multicast domains across domains in which multicast is not supported. This may certainly be the case when multicasting is required in only certain areas of a large routing domain. You would not want to enable multicast on every router in the unicast domain just to provide connectivity to a relatively small number of multicast routers. A second and very common example is connecting multicast domains across the decidedly unicast Internet.

In Figure 7-1, two PIM domains are separated by a unicast-only IP domain. The unicast domain might be the backbone of an enterprise network, or it might be the Internet itself. The important point is that the two multicast domains must have connectivity across it. The solution is a simple one: Create a tunnel between the two routers that can carry the PIM traffic.

Figure 7-1. PIM Domains Separated by a Unicast-Only IP Domain

Example 7-2 shows the tunnel configurations of the two routers depicted in Figure 7-1.

Example 7-2 Configuring Godzilla and Mothra to Provide Connectivity Between the Multicast Domains Through the Unicast-Only Domain

  Godzilla   interface Tunnel0   ip unnumbered Ethernet0   ip pim sparse-dense-mode   tunnel source Ethernet0   tunnel destination 10.224.6.2   !   interface Ethernet0   ip address 10.224.1.2 255.255.255.0   !   interface Serial0.407 point-to-point   description PVC to R7   ip address 192.168.50.1 255.255.255.0   ip pim sparse-dense-mode   frame-relay interface-dlci 407   !   router ospf 1   passive-interface Tunnel0   network 10.0.0.0 0.255.255.255 area 0   network 192.168.0.0 0.0.255.255 area 0   !   ip mroute 172.16.0.0 255.255.0.0 Tunnel0  _______________________________________________________________________  Mothra   interface Tunnel0   ip unnumbered Ethernet0   ip pim sparse-dense-mode   tunnel source Ethernet0   tunnel destination 10.224.1.2   !   interface Ethernet0   ip address 10.224.6.2 255.255.255.0   !   interface Serial1.506 point-to-point   description PVC to R6   ip address 172.16.35.1 255.255.255.0   ip pim sparse-dense-mode   frame-relay interface-dlci 506   !   router ospf 1   passive-interface Tunnel0   network 0.0.0.0 255.255.255.255 area 0   !   ip mroute 192.168.0.0 255.255.0.0 Tunnel0  

You already have seen a tunnel used in Chapter 6 to provide for load sharing across equal-cost paths. The configuration here is similar. The tunnel source is the Ethernet interface on each router, but PIM is not configured on that physical interface ”only on the tunnel. GRE encapsulation, the default tunnel mode, is used. OSPF is configured to run passively on TU0 to ensure that no unicast traffic traverses the tunnel. Finally, static multicast routes are configured, referencing all possible source addresses from the opposite domain and showing their upstream interface as TU0. Recall from Chapter 6 that this route is necessary to prevent RPF failures. Without it, RPF checks would use the OSPF routes and determine the upstream interface to be the routers' E0 interfaces. As a result, all packets arriving on TU0 would fail the RPF check.

NOTE

If the DVMRP routers do not support GRE encapsulation, you can use IP-in-IP.

Example 7-3 shows the results of the configuration.

Example 7-3 A PIM Adjacency Is Formed Across the GRE Tunnel

 Godzilla#  show ip pim neighbor  PIM Neighbor Table Neighbor Address  Interface          Uptime    Expires   Ver  Mode 192.168.50.2      Serial0.407        01:08:51  00:01:27  v2 172.16.35.1       Tunnel0            01:03:31  00:01:16  v2 Godzilla# _______________________________________________________________________ Mothra#  show ip pim neighbor  PIM Neighbor Table Neighbor Address  Interface          Uptime    Expires   Ver  Mode 172.16.35.2       Serial1.506        01:10:06  00:01:42  v2 192.168.50.1      Tunnel0            01:04:33  00:01:15  v2 Mothra#