Section 9: Multicast (5 Points)

• Configure a new loopback interface on R1 of 10.9.9.1/24; advertise this out of FastEthernet0/0 (VLAN2) interface using RIP V1.

This is required for the multicast question to follow; you should ensure that FastEthernet0/0 is the only interface that is enabled for RIP. If you have configured this correctly as shown in Example 3-86, you have scored 1 point.

Example 3-86. R1 RIP V1 Configuration

 interface Loopback2  ip address 10.9.9.9 255.255.255.0 ! router rip  passive-interface default  no passive-interface FastEthernet0/0  network 10.0.0.0  version 1 

• Configure R5 to receive the RIP advertisement from R1. Use a multicast solution to achieve this and do not create any tunnel interfaces. You are not required to be able to ping 10.9.9.9 from R5.

This is where it begins to get interesting. You now have to transport the RIP advertisements across your network to R5. A number of ways are normally available to accomplish this including enabling RIP all the way along the path at each interface, creating a tunnel interface between routers and enable RIP through this tunnel, or by bridging within the switch; however, you must use a multicast method. An IOS feature exists called IP Multicast Helper, which is similar to an IP Helper Address; however, this takes a defined broadcast and converts this into a multicast. You should remember that RIP V1 broadcasts its routing updates. R6 will receive the RIP broadcast on its VLAN2 interface and can be considered the first hop router for the multicast scenario. R6 converts the broadcast stream arriving at incoming interface FastEthernet0/0 destined for UDP port 520 (RIP) to a multicast stream. Access-list 130 allows only RIP to be forwarded into the multicast cloud. The traffic is sent to multicast address 224.9.9.9 using PIM Dense Mode. The command ip forward-protocol udp rip is required to ensure the proper process level is used to perform the conversion. The second configuration on the last hop router R5 converts the multicast stream at incoming interface virtual-template1 (not ATM3/0) back to a broadcast. Only traffic destined for UDP port 520 should be converted back to broadcast. After configuration, Example 3-87 shows the RIP traffic arriving at R6.

Example 3-87. R6 Multicast Helper Testing

 R6(config)#access-list 130 permit udp any any eq rip R6#debug ip packet 130 det IP packet debugging is on (detailed) for access list 130 R6# 00:03:46: IP: s=10.80.80.1 (FastEthernet0/0), d=255.255.255.255, len 52, rcvd 2 00:03:46:     UDP src=520, dst=520 00:03:56: IP: s=10.80.80.1 (FastEthernet0/0), d=255.255.255.255, len 52, rcvd 2 00:03:56:     UDP src=520, dst=520 00:03:56: IP: s=10.80.80.1 (FastEthernet0/0), d=255.255.255.255, len 52, rcvd 2 00:03:56:     UDP src=520, dst=520 

Example 3-88 shows the multicast traffic being converted into RIP on R5. Notice how RIP ignored the update as it assumes a bad source. This is rectified by configuring RIP with the command no validate-update-source on R5. Example 3-89 shows the valid RIP update after the source is ignored. You should also notice that the route has come through as a /29 and not a /24. The route has taken the attributes of the interface on which it was effectively received on which is also a /29. If you have configured this correctly as shown in Example 3-90 and Example 3-91, you have scored 4 points.

Example 3-88. R5 Multicast Helper Testing

 R5(config)#access-list 130 permit udp any any eq rip R5#debug ip pack 130 det IP packet debugging is on (detailed) for access list 130 R5# 00:03:54: IP: s=10.80.80.1 (Virtual-Access1), d=224.9.9.9, len 52, rcvd 0 00:03:54:     UDP src=520, dst=520 00:04:03: IP: s=10.80.80.1 (Virtual-Access1), d=224.9.9.9, len 52, rcvd 0 00:04:03:     UDP src=520, dst=520 00:04:03: IP: s=10.80.80.1 (Virtual-Access1), d=224.9.9.9, len 52, rcvd 0 00:04:03:     UDP src=520, dst=520 00:04:05: IP: s=10.80.80.1 (Virtual-Access1), d=224.9.9.9, len 52, rcvd 0 00:04:05:     UDP src=520, dst=520 00:04:22: IP: s=10.80.80.1 (Virtual-Access1), d=224.9.9.9, len 52, rcvd 0 00:04:22:     UDP src=520, dst=520 00:04:48: IP: s=10.80.80.1 (Virtual-Access1), d=224.9.9.9, len 52, rcvd 0 00:04:48:     UDP src=520, dst=520 00:05:17: IP: s=10.80.80.1 (Virtual-Access1), d=224.9.9.9, len 52, rcvd 0 00:05:17:     UDP src=520, dst=520 R5#debug ip rip RIP protocol debugging is on R5# 00:05:48: RIP: ignored v1 update from bad source 10.80.80.1 on Virtual-Access1 

Example 3-89. R5 Multicast Helper Testing

 R5#debug ip rip 01:41:46: RIP: received v1 update from 10.80.80.1 on Virtual-Access1 01:41:46:      10.9.9.0 in 1 hops R5#sh ip route rip      10.0.0.0/8 is variably subnetted, 16 subnets, 4 masks R       10.9.9.0/29 [120/1] via 10.80.80.1, 00:00:05 

Example 3-90. R6 Multicast Helper Configuration

 ip multicast-routing ! interface FastEthernet0/0  ip address 10.80.80.2 255.255.255.0  ip directed-broadcast  ip pim dense-mode  ip multicast helper-map broadcast 224.9.9.9 130 ! interface Virtual-Template1  ip pim dense-mode ! ip forward-protocol udp rip ! access-list 130 permit udp any any eq rip 

Example 3-91. R5 Multicast Helper Configuration

 ip multicast-routing ! interface FastEthernet0/0  ip address 10.50.50.1 255.255.255.248 ! interface Virtual-Template1  ip pim dense-mode  ip directed-broadcast  ip multicast helper-map 224.9.9.9 10.50.50.7 130 ! router rip  no validate-update-source  passive-interface default  network 10.0.0.0 ! ip forward-protocol udp rip ! access-list 130 permit udp any any eq rip 

NOTE

This configuration will actually also allow the broadcast to be propagated out onto VLAN4 network 10.50.50.0/29. As well as answering the question, this would be the normal practice for this feature for transporting broadcast traffic end-to-end over a multicast-enabled network.