cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
487
Views
5
Helpful
7
Replies

Odd broadcast behavior

epeeler
Level 1
Level 1

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.

7 Replies 7

gpulos
Level 8
Level 8

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

subnet X: 192.168.1.0/24 - broadcast 192.168.1.255

subnet Y: 192.168.2.0/24 - broadcast 192.168.2.255

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 http://www.ethereal.com)

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.

NE1 is on subnet x Ip address 192.168.123.14

NE2 is on subnet y Ip address 192.168.120.12

Ethereal trace on NE2's port shows the following:

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

This is immediately followed by outbound packet from NE2 with src IP 192.168.123.14 (NE1's address) dest IP of 192.168.123.255 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.

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

Standard 24 bit mask. 255.255.255.0 on both.

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.

netops
Level 1
Level 1

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.

scottmac
Level 10
Level 10

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. http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ipmulti.htm

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

Scott

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco