Separating Broadcast Domains

D

darrenster

Weaksauce
Joined
Nov 28, 2009
Messages
99
I don't think this is really possible, but thought I would ask... I am in the broadcast field with a whole bunch of devices that are all on the same network, same subnet and broadcast domain. Because of advancement in broadcast technology, a lot of new devices we receive all all network interfaces and we need to get them onto the network, and we only have one subnet we can put them into. With all these new devices communicating to each other, we are starting to see broadcast storms form on the network and we worry that a failure may happen while on air. (There goes Sunday Night Football...)

Currently all these devices are on the 192.168.253 subnet. Is there a way to group these various devices into their own broadcast domain yet still allowing communication to these groups via an engineering computer? The catch is without changing the IP addresses. Changing these addresses can be done, but it is a PITA.

I'm looking at trying to form about 6 different groups.

I know in a perfect world, each set of devices would be in their own subnet. A router would then be used to allow certain devices access to the different subnets. But this theory is not really practical here.

Thanks!
 
You can break up that /24 network into 6 ( well, 8 ) subnets ( or a /27 cidr ). You would then only need to worry about changing the IPs of any devices that fall on the network boundaries and getting a router to pass traffic between them all ( well, and getting a good switch that understands vlans ).

Not too terribly difficult.
 
Last edited:
XOR != OR said:
You can break up that /24 network into 6 ( well, 8 ) subnets ( or a /27 cidr ). You would then only need to worry about changing the IPs of any devices that feel on the network boundaries and getting a router to pass traffic between them all ( well, and getting a good switch that understands vlans ).

Not too terribly difficult.
Click to expand...

2nded to re-illiterate this. Segment things into different vlans and use something to route traffic for what you need to talk to everything
 
Langly said:
2nded to re-illiterate this. Segment things into different vlans and use something to route traffic for what you need to talk to everything
Click to expand...
It's worth noting you don't need a fancy router to pull this off. If you have a vlan capable switch, you just deliver those to a linux box with vlans setup on it's interface with routing turned on. All of about 2 minutes worth of work.
 
XOR != OR said:
It's worth noting you don't need a fancy router to pull this off. If you have a vlan capable switch, you just deliver those to a linux box with vlans setup on it's interface with routing turned on. All of about 2 minutes worth of work.
Click to expand...

Or better yet, get a Layer 3 switch and do the routing on there. Saves you from needing two pieces of gear.
 
agree....

KISS
Buy a HP 1810-????

Start with using Vlans...and move on from there.
 
/usr/home said:
Or better yet, get a Layer 3 switch and do the routing on there. Saves you from needing two pieces of gear.
Click to expand...
Good point. I'm used to an external device, but many layer 3 devices can handle vlans and routing internally.
 
darrenster said:
it wouldn't matter that all the devices are still on the same subnet?
Click to expand...
They wouldn't be. If you break up 192.168.253.0/24 into 8 subdomains:

192.168.253.0/27
192.168.253.32/27
192.168.253.64/27
192.168.253.96/27
192.168.253.128/27
192.168.253.160/27
192.168.253.192/27
192.168.253.224/27

They would be within their own subnets/broadcast domains.
 
Back up a second here.

Changing subnet masks and default gateways on all the machines isn't going to be an easy task, and you'll use up a bunch of the IPs in the subnetting; which means some devices will have to be renumbered. So that isn't a perfect fix.

In any case, if your devices really do communicate via broadcast, separating them into separate broadcast domains will completely break the communication between those devices.

But before you do that, investigate your broadcast storms. Are you really getting your equipment communicating primarily via broadcast? That doesn't sound right. You need to throw a packet sniffer on the network when the problem occurs and find out what is going on.

Also make sure you understand the difference between multicast and broadcast and that your switches are set to handle multicast properly.
 
XOR != OR said:
They wouldn't be. If you break up 192.168.253.0/24 into 8 subdomains:

192.168.253.0/27
192.168.253.32/27
192.168.253.64/27
192.168.253.96/27
192.168.253.128/27
192.168.253.160/27
192.168.253.192/27
192.168.253.224/27

They would be within their own subnets/broadcast domains.
Click to expand...

I forgot about the detail of changing the subnet mask address. If I'm going to change the mask, I might as well change the IP addresses to new subnets.

Running wireshark yields a lot of ARP requests and UDP broadcasts between various servers and control panels.

I think the best solution would be to do it right and reprogram new IP addresses on new subnets. This really only means having to serial console into about 75 devices...
 
I'm curious, how many devices are on this single broadcast domain? What applications are they running? What kind of switch are you currently running?
 
Hey Darrenster -

I work for a company that probably makes some of those devices you're talking about in your studio. Our largest subnet (Engineering) has some ~600 devices, most of them send ungodly broadcasts. Most of the time the network performs great. I've never seen one (or hundreds) of our devices kill the network. When we see a storm it's someone plugging in a cable wrong or device dying (usually a shitty switch or shitty network device made in china - network aware power plugs have caused me bane many times).

I would suggest two things:
First, set yourself up to be able to find storms quickly. Learn how to use your core switch to track it down (get a managed switch if you don't have one!). Put in a network sniffing device if you need to. Do whatever it takes to find and stop it immediately. You're only going to see more and more networked devices and a lot of *ahem* our competitors make cheap (crappy?) products. If and when you find a product causing problems, call their support and complain. Get them to figure out what happened. If they can't, I suggest trying a different product because they're obviously not ready for prime-time.

Second, put all the management on it's own network (or at least subnet and VLAN). You're playing with fire if your equipment is all communicating on the same network that your video is fed over. I suspect you're probably sending video over a video-centric network (3G BNC or something), but that's not always the case any more. For the love of god, keep the management of your products on its own island where it can't stop your broadcast!

I don't know about the devices you're using, but ours can be manually controlled if the network goes down. Clearly that sucks, but at least it's something.

I'm not suggesting you shouldn't segment out devices. Maybe you should, but I'd suggest you figure out the real problem before taking action.

FYI others who asked about broadcast traffic - our products, and probably most of the others darrenster is talking about are using Avahi, Zeroconf, or similar to find all the other products (of ours) in use in the studio so they can make it very easy to move back and forth between their GUIs and/or help them work together better.
 
Last edited:
lol, obrith, i was wondering how you knew so much about the OP's scenario with what little was given.
and then i realized the op was using "broadcast" in two completely different contexts!
 
If the devices doesnt need to speak to each other directly (but towards some aggregating device like adminserver or such) you can enable protected vlan in the switch.

With protected vlan an interface which is protected cannot speak to another protected interface in the same vlan (only to unprotected interfaces in that vlan).

Another setup is to use private vlan.

With private vlan you can setup one vlan per interface which will be called secondary vlan. These secondary vlans can be either isolated (interfaces within this vlan cannot speak to each other) or community (interfaces within this vlan can speak to each other).

The secondary vlans are then aggregated to a primary vlan which then will be able to route traffic between the secondary vlans (which also explains why private vlan only exists on L3-switches while L2-switches only has the protected vlan available). The defgw which the clients connected to each secondary vlan will use as defgw is an ip attached to the primary vlan.

Also you will need to enable proxy-arp on the primary vlan in order for each client on each secondary vlan to be able to speak to the other secondary vlans through the primary vlan (otherwise the clients wont know which mac address to send the packets for 192.168.0.0/24).

So to show some examples:

1) Protected vlan (given that the whole switch is a single vlan (we ignore mgmt for now)):

int1-48
switchport protected

int 49-50
no switchport protected

This gives that int1-48 cannot speak or see each other but 1-48 can speak to uplinkports at 49-50.

2) Private vlan (asuming current setup is all devices on a single vlan with 192.168.0.254/24 as defgw):

private vlan primary 100
ip: 192.168.0.254/24
int 49-50

secondary vlan isolated 101
int1
...
secondary vlan isolated 148
int48

The good thing with private vlans is that they can span multiple switches while protected vlan is only within a single switch. A common mistake regarding protected vlans is that clients on SW1 cannot reach each other but they can reach clients on other switches. With private vlan you can still use one vlan per switch (which will be secondary vlan isolated in case you dont want the clients to be able to speak to each other) and then in the primary vlan define acl over which client should be able to speak to which client.

Since vlaning is being used you can also trunk this with 802.1Q.

Like setup one primary vlan (which will be defgw) along with a bunch of secondary vlans in a L3-switch and then use L2-switches close to the clients (which will receive the vlan/vlans with 802.1Q on uplink ports and then just put each vlan to each physical interface).
 
You must log in or register to reply here.
Back
Top