Multicast Helper Maps

IP Multicast Helper Maps

Erick N Borgard CCNP

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.

Setup:

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.

In this example, R1 is sending updates as broadcast.  R2 will rewrite the destination address of the packet to the configured multicastaddress 229.0.0.1.  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 1.0.0.0

 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 229.0.0.1 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 229.0.0.1 10.1.34.255 101

 ip igmp join-group 229.0.0.1

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 4.0.0.0

 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

     1.0.0.0/32is subnetted, 1 subnets

R       1.1.1.1 [120/1]via 10.1.12.1, 00:00:15

     4.0.0.0/32is subnetted, 1 subnets

C      4.4.4.4 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.