You have a broadcast-based application that you want to treat as multicast so that it can cross the network.
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. This 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)#ip pim sparse-dense-mode Router1(config-if)#exit 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)#ip igmp join-group 239.3.5.35 Router2(config-if)#exit Router2(config)#ip forward-protocol udp 3535 Router2(config)#end Router2#
Before explaining this recipe in any detail, we would like to stress that the multicast helper feature should only be used 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 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 Router1 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 Router2 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 FastEthernet 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. 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. However, this command can be dangerous on public network segments. There are several well-known DoS attacks, most notably the smurf and fraggle attacks, that take advantage of directed broadcasts.
Finally, we have included a static IGMP Join on the destination interface. Recall that in Recipe 23.6 we used this command when the devices on this interface required a group but didn'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 (discussed in Recipe 23.11) 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 have 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 have 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.
 |
|
|
| Top |