UDP Broadcast Forwarding - Cisco Routers

I think your problem is in how you are trying to use ip helper-address. It's function is to specify the node that will respond to the broadcast. While you can have multiple helper-address definitions on an interface, if you want an entire subnet to see the broadcasts you'd need to use broadcast flooding.

Thanks jlevie,  Since I wrote this, i've realized that the ip helper-address was incorrect.  I have since made it a specific address of a host.  I still get nother on the other side, at that host.  I'm watching with a sniffer and can see all of the traffic.
  The UDP port I want to forward is 11001.  I have done: "ip forward-protocol udp 11001" and "ip helper-address 192.168.50.50".  I can see the all one's UDP broadcast on the e0/1 interface, but never a forwarded broadcast on the e0/0 side.
  I'm thinking of setting "ip directed-broadfcast", since it is "no" at this time.  Do you have any other suggestions?  By the way, the ip address range for the broadcast are "secondary" addresses on the e0/1 interface.

TNX, Roger

Did  you put the helper-address on both eth0 and eth1? I believe that you have to have it on each interface that's a party to the traffic. I also think that it's necessary to reboot the router when using broadcast forwaring the first time. Once it's been started you can change it and add other protocols w/o a reboot.

So far as I know it doesn't matter if the IP lies within a subnet that's a secondary. I can't seem to get to Cisco right now to check the directed-broadcast directive, but if putting the helper-address on both e0/0 & e0/1 & rebooting still doesn't work, then try it. I'll try to remember to check the directeced-broadcast later when I can get to Cisco's docs.

BTW, what IOS version are you running?

Thanks for your help jlevie.  I’ve only placed the helper on E0/1 to this point.  This is the subnet where the broadcasts originate.  I did save and reboot the router this last time.  I also enabled “ip directed-broadcast” on both sides.  So far, no broadcasts have been forwarded.  I’ve included the router config.  Maybe there is another parm that is conflicting with my interests.  The IOS is 12.0, the router is a 2600.  Thanks again,

Roger
---------------------------------
version 12.0
service timestamps debug uptime
service timestamps log uptime
service password-encryption

hostname <removed>
<password stuff removed>

clock timezone Central 6
ip subnet-zero
ip host internet 207.63.187.145
ip host ryder 192.168.60.62
ip host pcsdtr 192.168.60.14
ip host pcsdit 192.168.60.18
ip host pcsdwe 192.168.60.6
ip host pcsdwg 192.168.60.26
ip host pcsdrv 192.168.60.46
ip host pcsdlf 192.168.60.38
ip host pcsdgp 192.168.60.34
ip host pcsdcl 192.168.60.30
ip host pcsdce 192.168.60.22
ip host pcsdhs 192.168.60.10
ip host pcsddo 192.168.60.9
ip host do8 192.168.62.8
ip host do7 192.168.62.7
ip host do6 192.168.62.6
ip host do5 192.168.62.5
ip host do4 192.168.62.4
ip host do3 192.168.62.3
ip host do2 192.168.62.2
ip host do1 192.168.62.1
ip host pcsdhg 192.168.60.54
ip domain-name <removed>
ip name-server 192.168.61.6
ip name-server 206.166.50.100
ip name-server 207.63.187.52

appletalk routing
ipx routing 00d0.5865.e820

 interface FastEthernet0/0
 ip address 192.168.62.2 255.255.255.0
 ip directed-broadcast
 ipx network 168062 encapsulation SAP
 ipx network 168063 encapsulation NOVELL-ETHER secondary
 bridge-group 1

interface Serial0/0
 ip address 192.168.60.45 255.255.255.252
 no ip directed-broadcast
 no ip mroute-cache
 ipx network 60046
 service-module t1 data-coding inverted
 service-module t1 linecode ami
 bridge-group 1

interface FastEthernet0/1
 ip address 192.168.50.193 255.255.255.248 secondary
 ip address 192.168.51.193 255.255.255.248 secondary
 ip address 192.168.3.1 255.255.255.0 secondary
 ip address 192.168.25.1 255.255.255.0 secondary
 ip address 192.168.26.1 255.255.255.0 secondary
 ip address 192.168.24.1 255.255.255.0 secondary
 ip address 207.63.186.65 255.255.255.240 secondary
 ip address 207.63.186.81 255.255.255.240 secondary
 ip address 207.63.187.49 255.255.255.240 secondary
 ip address 10.160.1.1 255.255.0.0
 ip helper-address 207.63.187.52
 ip helper-address 192.168.50.50
 ip directed-broadcast
 appletalk cable-range 7208-7208 7208.112
 appletalk zone high-school
 ipx network 187208 encapsulation SAP
 ipx network 187209 encapsulation NOVELL-ETHER secondary
 bridge-group 1

router eigrp 100
 redistribute static
 network 10.0.0.0
 network 192.168.3.0
 network 192.168.24.0
 network 192.168.25.0
 network 192.168.26.0
 network 192.168.50.0
 network 192.168.51.0
 network 192.168.60.0
 network 192.168.62.0
 network 207.63.186.0
 network 207.63.187.0
 no auto-summary

ip classless
ip forward-protocol udp 11001
ip http server

bridge 1 protocol dec
bridge 1 lat-service-filtering

<login info removed>

no scheduler allocate
end

Thanks for your help jlevie.  I’ve only placed the helper on E0/1 to this point.  This is the subnet where the broadcasts originate.  I did save and reboot the router this last time.  I also enabled “ip directed-broadcast” on both sides.  So far, no broadcasts have been forwarded.  I’ve included the router config.  Maybe there is another parm that is conflicting with my interests.  The IOS is 12.0, the router is a 2600.  Thanks again,

Roger
---------------------------------
version 12.0
service timestamps debug uptime
service timestamps log uptime
service password-encryption

hostname <removed>
<password stuff removed>

clock timezone Central 6
ip subnet-zero
ip host internet 207.63.187.145
ip host ryder 192.168.60.62
ip host pcsdtr 192.168.60.14
ip host pcsdit 192.168.60.18
ip host pcsdwe 192.168.60.6
ip host pcsdwg 192.168.60.26
ip host pcsdrv 192.168.60.46
ip host pcsdlf 192.168.60.38
ip host pcsdgp 192.168.60.34
ip host pcsdcl 192.168.60.30
ip host pcsdce 192.168.60.22
ip host pcsdhs 192.168.60.10
ip host pcsddo 192.168.60.9
ip host do8 192.168.62.8
ip host do7 192.168.62.7
ip host do6 192.168.62.6
ip host do5 192.168.62.5
ip host do4 192.168.62.4
ip host do3 192.168.62.3
ip host do2 192.168.62.2
ip host do1 192.168.62.1
ip host pcsdhg 192.168.60.54
ip domain-name <removed>
ip name-server 192.168.61.6
ip name-server 206.166.50.100
ip name-server 207.63.187.52

appletalk routing
ipx routing 00d0.5865.e820

 interface FastEthernet0/0
 ip address 192.168.62.2 255.255.255.0
 ip directed-broadcast
 ipx network 168062 encapsulation SAP
 ipx network 168063 encapsulation NOVELL-ETHER secondary
 bridge-group 1

interface Serial0/0
 ip address 192.168.60.45 255.255.255.252
 no ip directed-broadcast
 no ip mroute-cache
 ipx network 60046
 service-module t1 data-coding inverted
 service-module t1 linecode ami
 bridge-group 1

interface FastEthernet0/1
 ip address 192.168.50.193 255.255.255.248 secondary
 ip address 192.168.51.193 255.255.255.248 secondary
 ip address 192.168.3.1 255.255.255.0 secondary
 ip address 192.168.25.1 255.255.255.0 secondary
 ip address 192.168.26.1 255.255.255.0 secondary
 ip address 192.168.24.1 255.255.255.0 secondary
 ip address 207.63.186.65 255.255.255.240 secondary
 ip address 207.63.186.81 255.255.255.240 secondary
 ip address 207.63.187.49 255.255.255.240 secondary
 ip address 10.160.1.1 255.255.0.0
 ip helper-address 207.63.187.52
 ip helper-address 192.168.50.50
 ip directed-broadcast
 appletalk cable-range 7208-7208 7208.112
 appletalk zone high-school
 ipx network 187208 encapsulation SAP
 ipx network 187209 encapsulation NOVELL-ETHER secondary
 bridge-group 1

router eigrp 100
 redistribute static
 network 10.0.0.0
 network 192.168.3.0
 network 192.168.24.0
 network 192.168.25.0
 network 192.168.26.0
 network 192.168.50.0
 network 192.168.51.0
 network 192.168.60.0
 network 192.168.62.0
 network 207.63.186.0
 network 207.63.187.0
 no auto-summary

ip classless
ip forward-protocol udp 11001
ip http server

bridge 1 protocol dec
bridge 1 lat-service-filtering

<login info removed>

no scheduler allocate
end

That's an odd network configuration... Okay one problem that I see right away is that the helper-address points to 192.168.50.50, but that network isn't assigned to either eth0/0 or eth0/1. There is a secondary on eth0/1 of 192.168.50.193, but it has a netmask of 255.255.255.248 which is a subnet of 8 IPs (192.168.50.192-192.168.50.199). The other helper-address is valid for a node on eth0/1, but you don't have a matching helper-address on eth0/0 or ser0/0, so the router isn't going to forward anything (you haven't told it what other interface(s) the broadcasts should be forwarded between).

Jleveie,

  Yes, it's odd.  There has been many network admins here.  This has not been looked at, by "out sider's", until now.
  You bring about some interesting questions.  First, the “ip helper-address 207.63.187.52” was there before I got involved.  It’s the address of a web server that’s several routers away, off of E0/0.  I don’t know why it’s there.  The only one I installed was for 192.168.50.50.  It’s my sniffer PC on E0/0.  I didn’t need an IP for the sniffer since it collects everything without an assigned IP.  But I did assign one so a program I have running there, will display UDP broadcasts for port 11001.   I know it’s not on the correct network.  I just wanted to use that IP since it’s the helper IP I set up for test program.  I thought that I would at least see the broadcast packet on the sniffer if not both.
Are you saying that I need a helper on the E0/0 side to match the E0/1 side, or does the helper need to be a host address within the range of an assigned network address on the E0/0 side?  The E0/0 side goes to a switch with many other routers.  The remainder of the 192.168.50.0 devices are on the other side of those other routers.  I want to forward the UDP broadcasts from the E0/1 side (subnet 192.168.50.192) devices, to every other 192.168.50.0 device, every where else.  Does forwarding not work if the helper address is not part of known address range of the opposite interface?

-Roger

Lets go back to what forward-protocol and helper-address is designed to do and how it works. The two work in conjunction to allow clients that are broadcasting requests for services to find a server on another network. It's purpose is to allow things like bootp, dhcp, netbios, etc to work. In each of those cases the client will broadcast a request for a service on its local net. The router sees that it's to forward the data and that there is a helper-address configured for the local interface. It will then pass the broadcast packet to the interface that contains the target of the helper-address, re-writing the packet addresses so the target of the broadcast will know where the broadcast came from and where the reply is to be sent.

It's not really meant to work the other way around, which is what you're trying to do. You want a single node which is broadcasting traffic to flood that broadcast to everyone on another network. For that type of forwarding you need bridging and the use of "ip forward-protocol spanning-tree" & friends.

Jlevie,

      You make a good point.  However, the Cisco doc does say that the helper address can be a network address as well as a host address.  It does seem that this feature is meant for forwarding to a specific host, for a cetin service, as you mention,.  Yes, I’m looking for a broadcast to everyone in the 192.168.50.0 network.  But, the forwarding is not working at all.  My tests so far have produced nothing on the E0/0 side.
      After reviewing this config with a friend who’s got more Cisco experience than me, as you do, he’s pointed out something I had missed.  The test address I enabled as the helper… 192.168.50.50, is an unused host IP in the range I’m dealing with.  In fact, I don’t think any router is configured for this subnet.  If this is true, then the IP 192.168.50.50 would not be in the route table, causing any packets to that device to be dropped.  As you can see, there is another helper, the one I didn’t install (it was already there), to a 207.x device.  I don’t think there is any subnet with that address either.  This would explain why no broadcasts were forwarded to either of these IP.  The two helpers should cause the udp port 11001 (my) broadcasts to forward to both of these, even if the 207.x IP is unintended.
      So, my next plan is to install a helper that is a real host address, since my sniffer does not need an IP.  In other words, use one that’s in the route table.  I plan to use “show ip route”, to show the route table, to be sure.  I also have some trace commands, to monitor what is really getting forwarded.
      Thanks for you continued support jlevie.

-Roger

Right, as I pointed out in my first comment you have to use a helper address that the router knows where is. So if your sniffer is on a network attached to E0/1, it has to have an IP within that network. Furthermore, you have to specify the helper-address on the E0/0 interface (and on each interface of any down stream routers atttached to E0/0).

And yes the helper-address docs do say that it can be a broadcast address. However, the forward-protocol docs do specifically state that:

"To enable BOOTP broadcast forwarding for a set of clients, configure a helper address on the router interface closest to the client. The helper address should specify the address of the DHCP server. If you have multiple servers, you can configure one helper address for each server."

Those doc's then go on and reference forward-protocol spanning-tree, which "Permits IP broadcasts to be flooded throughout the internetwork in a controlled fashion.". It would seem that the docs wouldn't state that you can configure multiple helper addresses unless that's in fact necessary. I'll admit that I've never checked to see if a second DHCP server on the same net as the one specified in the helper-address will in fact see client requests (I use helper-address all the time to forward DHCP requests throughout a WAN). My reading of the docs indicates that you need more than just  helper-address and forward-protocol to forward a broadcast from one box to multiple clients, but try it and see what happens.

jlevie,

I've been on vacation.  Back to work now.  I will update the "ip helper-address" with a real IP soon.  Also plan to "show ip route", so I can see what's in the table, since I haven't seen any other router configs here.  I will let you know.  Thanks for your continued support.

-Roger

Okay, waiting for words...

if you add this to your e0/1
ip helper-address 192.168.62.255

you should start seeing some broadcast packets with your sniffer on E0/0 side

also, you say your broadcast packets on udp 11001  are all 1's, i.e. 255.255.255.255?

"directed" broadcasts are in the form of 192.168.50.255, where the broadcasting workstation uses the local address/mask/broadcast address. In the case of a BOOTP or DHCP broadcast, or even NETBIOS (upd 137/138/139), those broadcasts are directed "subnet" broadcasts. Directed broadcasts can be routed and controlled as you want them to be.
Conversely, a full 255.255.2552.255 broadcast will be dropped by the router.

One option is to bridge these two interfaces, or allow broadcast flooding (not recommended)
Another option is to check the client software that is sendig these udp packets on port 11001 and see if it can be configured to use true subnet broadcasts.

lrmoore,

Thanks for your suggestions.  As to the type of broadcasts, the sending stations can be configured for either all one’s or subnet directed broadcast.  I have four sending stations on the E0/1 interface, three configured for subnet directed and one is all one’s.  I did this for test purposes.

I don’t want to allow broadcast flooding, as you mention, and bridging is already enabled, but for DEC protocols.  I don’t have the config info in front on me, so I can’t tell you the details of the bridging setup.

I tried the 192.168.62.255 address, and nothing happened.  However, we may have not had the UDP port 11001 enabled at the time.

My biggest issue right now is the customer.  I’m having trouble getting them to act.  Change one thing today, the next a week later…  I hope to get them going again soon.  I’ll report what happens.

-Roger

You can use your router to watch these broadcast packets:
router#debug ip udp

If you are telnetted into it, be sure to turn on monitoring to terminal:
router#term mon

This way you can see exactly what the router is doing with the packets a lot easier than combing through the Sniffer.

Good luck!

Adjusted points from 200 to 300

lrmoore, jlevie,

      It looks like the problem is solved.  However, there was an issue with the sniffer monitoring.  There is a 3Com Super stack II 3300, Ethernet switch on either side of the router.  The sniffer was plugged into these ports to monitor traffic.  Sometimes the sniffer laptop had an IP assigned, and sometimes it did not.  IP assignment was used to support a broadcast collect program on the laptop.  The sniffer software will work either way, since it uses the NIC card in a promiscuous mode.
      The switch however, will not let the sniffer see any traffic, except for broadcast, that are not destine for the MAC address that your device represents.  So, since the 192.168.50.197, etc., broadcasts were converted to unicasts by the ip-helper command in the router, and the sniffer was not the target, it didn’t see anything but Novell broadcast from other parts of the net.  Debug on the router displayed UDP broadcasts forwarding on port 11001 as desired.  With a hub on the switch port that the router and sniffer are connected to, I can see all the traffic I was looking for.
      So, the monitoring was flawed and some incorrect router commands were originally used, but all is well now.  Thank you both for your time and effort.  It is very much appreciated.

-Roger

Comment accepted as answer

Well jlevie, I didn't close this correctly.  Thanks for the note and all your help.  I'm on the road to fixing this MetaSys problem!

-Roger