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 Configurationinterface 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
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 TestingR6(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 TestingR5(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 TestingR5#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 Configurationip 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 Configurationip 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. |