Author's note: While researching and writing Cisco Cookbook, we discovered several tasty IOS features that we had never heard of before. One of these is called IP Multicast Helper, which allows the router to convert broadcast application packets into multicasts so that they can be routed through the network. The router closest to the broadcast source converts the packets to multicasts, and the routers closest to the destination devices convert these multicast packets back into broadcasts. This can be extremely useful if you have to support a legacy broadcast-based application across your network.
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
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 188.8.131.52 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 184.108.40.206 192.168.9.255 115 Router2(config-if)#ip pim sparse-dense-mode Router2(config)#ip igmp join-group 220.127.116.11 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
Router1(config-if)#ip multicast helper-map broadcast 18.104.22.168 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 22.214.171.124 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
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.
Recipe 23.6; Recipe 23.11
Author's note: To manage your network effectively, you need to be able to keep track of all of the important events that happen. In a small network, it is often sufficient to simply monitor the router syslog messages. But, in many networks there are too many of these messages to monitor in real time. This recipe provides one simple way of ensuring that the routers never send the unimportant messages.
You want to prevent the router from sending link up/down syslog messages for unimportant router interfaces.
Use the no logging event configuration commands to disable the logging of common interface-level messages:
Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#interface Serial0/0 Router(config-if)#no logging event link-status Router(config-if)#no logging event dlci-status-change Router(config-if)#no logging event subif-link-status Router(config-if)#end Router#
By default, log messages are sent whenever a router interface status changes states. Generally, you want to see log messages that indicate that an interface status has changed, but there are times when it can be useful to disable these types of messages. For instance, dial interfaces may cycle up and down many times throughout the course of a normal day without being cause for concern. Suppressing these messages helps keep logs uncluttered and can prevent network management staff from wasting time responding to unnecessary trouble reports:
%LINK-3-UPDOWN: Interface Serial0, changed state to down %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to down %LINK-3-UPDOWN: Interface Serial0, changed state to up %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to up
This example shows the log messages that are sent when a router interface changes states from up to down and back to up. The no logging event link-status command will prevent the router from creating these messages.
On Frame Relay interfaces, DLCI state changes trigger the router to create log messages. In large Frame Relay-based networks, many DLCI changes can occur daily, which can clutter logs and open duplicate trouble reports. The no logging event dlci-status-change configuration command will prevent these log messages from being created:
%FR-5-DLCICHANGE: Interface Serial0 - DLCI 50 state changed to INACTIVE %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0.1, changed state to down %FR-5-DLCICHANGE: Interface Serial0 - DLCI 50 state changed to ACTIVE %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0.1, changed state to up
You can also suppress subinterface link up or down messages by using the no logging event subif-link-status configuration command. The following example shows a typical Frame Relay interface failure. Note that the router sends a "line protocol down" log message for the main interface and each of the subinterfaces. Although this example only shows one subinterface, it is not uncommon to see dozens of subinterfaces on a single physical interface. In these cases, it can be useful to suppress subinterface messages:
%LINK-3-UPDOWN: Interface Serial0, changed state to down %FR-5-DLCICHANGE: Interface Serial0 - DLCI 50 state changed to DELETED %FR-5-DLCICHANGE: Interface Serial0 - DLCI 102 state changed to DELETED %FR-5-DLCICHANGE: Interface Serial0 - DLCI 103 state changed to DELETED %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0.1, changed state to down %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to down
Kevin Dooley is an independent networking consultant who has been designing and implementing networks for more than ten years.
Return to the O'Reilly Network.
Copyright © 2009 O'Reilly Media, Inc.