Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Odd broadcast behavior

Hey all.

Here's the situation. I have a lab network with a bunch of network elements. The network consists of a single vlan with multiple IP subnets running on it. The router interface is configured with a main and secondary ip address. Nothing too complicated.

The issue is this. Subnet x is full of network elements which use UDP broadcasts to discover each other. Subnet y is full of network elements that have nothing to do with the elements on x. However, since they share the same layer 2 vlan, subnet y elements are seeing the broadcasts from subnet x and, I assume since they realize that the broadcast came from a different IP subnet than their own, they are taking the broadcast packet and forwarding it to their default gateway. So, if there are 50 elements on x broadcasting and 50 elements on y receiving these broadcasts and each forwarding a copy of each broadcast to the gateway, you can see that the gateway router is getting clobbered.

I've spoken with the engineers in charge of the elements on y and they have no clue what I'm talking about. There is no feature in the configuration to turn off to make this behavior stop. As near as I can determine. The elements are using an old version of the freeBSD tcp/ip stack.

Does anyone know of any bugs or features in this stack that might be responsible for this unwanted broadcasting behavior?

I've asked the folks in charge of the broadcasting NE's to change their TTL field to 1 instead of 255 in the hopes of having the subnet y elements just drop the packet instead of forwarding it on but I'd sure like to figure out what it is that's making them do this in the first place.

Any direction would be very much appreciated.


Re: Odd broadcast behavior

if you have 2 subnets with 50 hosts each and they are connected to the same vlan the following is true:

subnet X: - broadcast

subnet Y: - broadcast

subnet X hosts can send brodcasts but only other hosts on that subnet will process them. a subnet Y host cannot/will not process a subnet X broadcast. subnet X and Y use different broadcast addresses so they cannot process each others subnet broadcast.

you can verify this behavior with a packetAnalyzer (sniffer such as ethereal; get this free from

if a subnet X host is processing a subnet Y broadcast, then the IP addressing is configured incorrectly.

either way, the best practice is to move away from secondary addresses and create a new vlan for the second subnet. then create a trunk from the router LAN interface to the switch. configure the router to do routing between the two vlans.

New Member

Re: Odd broadcast behavior

NE1 is on subnet x Ip address

NE2 is on subnet y Ip address

Ethereal trace on NE2's port shows the following:

Inbound broadcast packet from NE1 with src IP, dest IP and dest mac of ff:ff:ff:ff:ff:ff.

This is immediately followed by outbound packet from NE2 with src IP (NE1's address) dest IP of and dest mac of NE2's default gateway (not the broadcast mac). The source mac on this packet is NE2's.

NE1 and NE2 have been checked and IP configuration is correct on both.

We need global layer two connectivity for all NE's for various reasons. Regardless of best practice, I'm stuck with what I have.


Re: Odd broadcast behavior

please provide the subnet mask for both NE1 and NE1 ip addresses.

New Member

Re: Odd broadcast behavior

Standard 24 bit mask. on both.

New Member

Re: Odd broadcast behavior

It looks to me like the NE's on network y are actually routing the broadcasts to their next hop/default gateway. The engineers tell me that the NE's shouldn't be doing that and so I was wondering if it was a feature/bug of the network stack that they're using (old bsd stack I think) and thus is happening at lower layer than the Engineers are actually working with.

New Member

Re: Odd broadcast behavior

You could try asking your FBSD admins to check and see if they have the net.inet.ip.forwarding sysctl setting set to 1. This is a tunable kernel parameter that is usually enabled for when you wish to use a FBSD system as a firewall or router. It will cause on incoming packets on an interface that is processed by the kernel to be 'routed' out. Since the only route option for packets that are not on the configured subnet for your host is the default gateway, they get passed on per your configuration.


Re: Odd broadcast behavior

Well, the IP address of both subnets map to the same source MAC so it looks like any station on either subnet is the valid source, no matter who's talking.

Check out this link; scroll down to multicast MAC mapping.

Since the destination is ff.ff.ff.ff.ff.ff, all stations are going to at least receive the frame, and send it up the stack ... so no matter what, you are wasting cycles getting the frame, stripping the frame, then throwing away the packet.

The 100 stations aren't forwarding anything (stations don't forward ... they accept or ignore); your gateway is just seeing all of the broadcasts as valid traffic and acting on it.

This is just a drawback of using secondary addressing. For anything except transitioning an IP addressing scheme or extremem emergencies, it's bad design.

You might be able to improve thing a little by separating the IP address blocks of the two subnets so that the MACs of each network map to different source address ... but it's probably not worth the effort, it'll still suck.

Good Luck