IP Multicast Helper Maps
Erick N Borgard CCNP/CCNP Security
Can you remember back when you were studying for your CCNA? One of the concepts you read or heard from an instructor was that routers do not forward broadcast messages. While that is true, what you probably didn't read was engineers can use multicast helper maps to translate that broadcast traffic to a multicast address and route those packets via multicast to another broadcast only network. This lab will demonstrate the use of ip multicast helper maps to carry RIP broadcast routing information over and ip multicast-enabled IP network. Please see the diagram for more details.
Multicast routing is enabled on R2 & R3
OSPF is enabled between R2 & R3
RIPv2 is enabled on R1 & R4 with the loopback and fa0/0 interfaces participating in the protocol
RIPv2 is configured to send version 2 updates as broadcasts on R1 & R4
Note: It should not be implied that RIP is or needs to operate and provide connectivity. This lab is only to show how broadcast packets destined for UDP port 520 can be translated, routed via multicast, and translated again on another broadcast only network. RIP is the tool being used in this example because it's easy to see it work with RIP, but the engineer can use whatever port he/she wants to use or use the one outlined in your task and use the response time reporter to test.
Steps to configure multicast helper maps are:
- Configure an ACL to identify the traffic the multicast helper map will use on first and last hop routers
- Configure the routers to forward broadcast traffic destined for specified port number
- Configure the first-hop router to translate broadcast packets to a multicast address
- Configure the last hop router to translate received multicast traffic to the IP directed broadcast address of the link on which traffic needs to be forwarded
- Configure the router to forward directed broadcast on the interface on which the broadcast needs to be forwarded
One thing that tends to confuse people is on which interface the ip multicast helper-map command should be applied. The ip multicast helper-map command should be applied to upstream facing interfaces. Or more specific, the commandis applied to interfaces facing towards the source of the broadcast traffic that needs to be translated. In this example, R1 is sending the traffic to be translated to multicast. So on the first hop router (R2), the command is applied to the LAN interface(fa0/0). On the last hop router, the command is applied to the S0/0 interface. The best way to remember this is to think about it from the perspective of the router and the direction in which traffic is flowing. Just keep in mind while looking at this lab that the commands are applied to interfaces pointing towards R1.
I have attached the configurations to this document so the reader can load them into a home lab or GNS3.
In this example, R1 is sending updates as broadcast. R2 will rewrite the destination address of the packet to the configured multicastaddress 126.96.36.199. R2 will route that traffic via PIM to R3. When R3 receives that packet, it will rewrite the destination address ofthe IP packet to the directed broadcast address configured in the multicast helper-map command. It will then use the ip directed-broadcast command to forward that traffic onto the destination link.
Here are the relevant configurations.
R1 router rip version 2 network 188.8.131.52 network 10.0.0.0 no auto-summary interface FastEthernet0/0 ip address 10.1.12.1 255.255.255.0 ip rip v2-broadcast R2 ip forward-protocol udp rip access-list 101 permit udp any any eq rip interface FastEthernet0/0 ip address 10.1.12.2 255.255.255.0 ip pim dense-mode ip multicast helper-map broadcast 184.108.40.206 101 ttl 5 R3 ip forward-protocol udp rip access-list 101 permit udp any any eq rip interface Serial0/0 ip address 10.1.23.2 255.255.255.252 ip pim dense-mode ip multicast helper-map 220.127.116.11 10.1.34.255 101 ip igmp join-group 18.104.22.168 interface FastEthernet0/0 ip address 10.1.34.3 255.255.255.0 ip directed-broadcast R4 router rip version 2 no validate-update-source network 22.214.171.124 network 10.0.0.0 no auto-summary
There is one other thing that needs to be addressed. By default, RIP will perform a sanity check on the source address of the RIP update to ensure that it is part of it's directly connected interfaces. The packet originated on the 10.1.12.x subnet. When R4 performs the sanity check, it will not accept/install the route into the routing table. Note that the above configuration disables these sanity checks with the no validate-update-source command under the RIP routing process. Once this command is entered, R4 will accept and install the route learned from R1 into the IP routing table.
R4#sh ip route | beg Gate Gatewayof last resort is not set 126.96.36.199/32is subnetted, 1 subnets R 188.8.131.52 [120/1]via 10.1.12.1, 00:00:15 184.108.40.206/32is subnetted, 1 subnets C 220.127.116.11 is directly connected, Loopback4 10.0.0.0/24is subnetted, 1 subnets C 10.1.34.0 is directly connected, FastEthernet0/0
Here we see that R4 did receive the RIP route from R1 as expected. Obviously we will not have IP connectivity because the nexthop(10.1.12.1) is not reachable from R4. RIP was only used to show how broadcast traffic is handled with the ip multicasthelper-map command.