Converting Broadcasts to Multicasts

Problem

You have a broadcast-based application that you want to treat as multicast so that it can cross the network.

Solution

Cisco has a special feature called an IP Multicast Helper, which you can use to convert broadcast packets to multicast packets. Then you can use PIM to send these packets throughout the network. At the last-hop routers you can then convert the multicast packets back to broadcast. This is useful for older broadcast-based applications that do not support multicast transmission.

Router1 is the first-hop router, or the one closest to the broadcast source, which is on the interface FastEthernet0/0. It converts broadcast packets with UDP port 3535 received on this interface into multicast packets in group 239.3.5.35:

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ip multicast-routing
Router1(config)#access-list 115 permit any any udp 3535
Router1(config)#access-list 115 deny any any udp
Router1(config)#interface FastEthernet0/0
Router1(config-if)#ip directed broadcast
Router1(config-if)#ip multicast helper-map broadcast 239.3.5.35 115
Router1(config-if)#exit
Router1(config)#ip pim sparse-dense-mode
Router1(config)#ip forward-protocol udp 3535
Router1(config)#end
Router1#

The last-hop router's configuration is similar, except that it must be configured to turn multicast packets for this group back into broadcasts:

Router2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#ip multicast-routing
Router2(config)#access-list 115 permit any any udp 3535
Router2(config)#access-list 115 deny any any udp
Router2(config)#interface Ethernet0
Router2(config-if)#ip address 192.168.9.1 255.255.255.0
Router2(config-if)#ip directed broadcast
Router2(config-if)#ip multicast helper-map 239.3.5.35 192.168.9.255 115
Router2(config-if)#ip pim sparse-dense-mode
Router2(config-if)#exit
Router2(config)#ip igmp join-group 239.3.5.35
Router2(config)#ip forward-protocol udp 3535
Router2(config)#end
Router2#

 

Discussion

Before explaining this recipe in any detail, we would like to stress that the multicast helper feature should be used only as a temporary measure until a proper multicast application can be found. It tends to consume a lot of the router's CPU resources. And it can be difficult to troubleshoot application problems if the router is rewriting all of the packets. It is always preferable to use a native multicast application if possible.

The most important lines in this example are the ip multicast helper-map commands that are applied on the two routers. The command on Router A converts broadcast to multicasts with a group address of 239.3.5.35:

Router1(config-if)#ip multicast helper-map broadcast 239.3.5.35 115

Then Router B converts this group to the network broadcast address 192.168.9.255 of the destination network:

Router2(config-if)#ip multicast helper-map 239.3.5.35 192.168.9.255 115

End devices on the destination network can now receive the broadcast as if a device on this same segment had sent it.

This example doesn't convert all broadcasts received on the Fast Ethernet port of Router1 to multicasts. It first applies the access-list number 115 to broadcasts that it receives. This picks out a single UDP port, number 3535, for conversion. If you wanted to convert other broadcasts received on this port as well, it is simply a matter of opening up this access-list.

There are three additional commands in these configuration examples that are critical to the broadcast multicast conversion working properly. First is the ip forward-protocol command. The multicast conversion process is done in the router's CPU, so it cannot be fast switched. By default, the router will ignore all broadcasts except for a few important UDP ports such as NetBIOS. So this command forces the routers to see the broadcast packets so that it can decide whether to process them.

Second, and related to this, is the ip directed-broadcast command. A directed broadcast is one that is sent to a particular network or group of networks. So, for example, Router2 in the recipe turns the multicast packet into the directed broadcast with an address of 192.168.9.255. By default, a Cisco router will drop all incoming directed broadcasts. So this needs to be enabled on both routers. We note in passing, however, that this command can be dangerous on public network segments. There are several well-known denial of service attacks, most notably the smurf and fraggle attacks, that take advantage of directed broadcasts.

And, finally, we have included a static IGMP Join on the destination interface. Recall that in Recipe 23.9 we used this command when the devices on this interface require a group but don't implement IGMP properly. In this case, the devices on the segment don't even know that there is a multicast group to join. So we can use this command to ensure that this router receives the group. Otherwise, the multicast packets will never reach Router2.

You should be careful when using multicast helper commands in a network that uses TTL scoping. Cisco doesn't provide a way to adjust the initial TTL setting on these multicast packets. So you may need to set up address-based boundaries as in Recipe 23.15 to prevent these artificial multicasts from leaking out of the network.

One last point on the subject of broadcast to multicast conversion might be useful in some rare cases. If you have an application that is capable of sending multicasts but end devices that can only receive broadcasts, you might be able to use only the last-hop (Router2) configuration to get the packets to the receiving devices. Similarly, if you had a server that can only broadcast but end devices that understand multicasts, you could conceivably use just the first-hop (Router1) configuration. However, it is unlikely that you will encounter such strange applications in any production network.

See also

Recipe 23.9