Multicast Helper Maps

Visibility: Open to anyone

    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 Helper Map1.jpg

    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.

     

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

     

    Happy studying.....