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.
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#
| 
