Press J to jump to the feed. Press question mark to learn the rest of the keyboard shortcuts
7

Broadcast traffic advice please.

Hi, I look after school network but I'm certainly not a network specialist, I do everything. 50 Ruckus AP's hooked to Allied Telesis switches in around 10 different buildings, all coming back to a core switch. We have around 1200 devices on the wireless on 3 SSIDs, staff, students, other stuff. 802.1x auth to NPS. Most of those devices are MacOS or iOS. The network is flat. We don't have VLANs. Are you cringing yet?

The broadcast packets are starting to kill us slowly with around ~100 broadcast/s and 200-300 multicast/s, the Ruckus APs are certainly struggling to keep up. A Wireshark shows that most of it is mDNS, Bonjour traffic, and a smaller amount of IPv6 broadcasts. They drop to around 10% of those levels overnight (we have 1/4 users resident).

The Bonjour is being used primarily for printer finding, and Apple TV's, so doesn't need to be broadcast between outlying buildings.

I'm looking for advice on strategies to deal with this. VLAN per building? Some sort of ACL on the core switch to keep those broadcasts in the building for the AppleTV's and to the print server attached to the core?

many thanks.

14 comments
82% Upvoted
What are your thoughts? Log in or Sign uplog insign up
level 1

I’d suggest vlans/subnets for every building as a start. So you’ll need some routing added. The more subnets, the less broadcast traffic. Ubiquiti EdgeRouters are cost effective and work if you can’t afford something better. Their new UNMS system gives you some centralized management and visibility.

Maybe check out PaperCut for providing your print services. We use PaperCut to provide access to printers that are on disparate subnets. Plus it allows us to track all printing, etc to a fine degree.

level 2

Jumping in on this... OP ( /u/doofusdog ) will probably want to dive straight into the PaperCut Mobility product:

https://www.papercut.com/products/ng/mobility-print/manual/

and if ZeroConf/mDNS/Bonjour is a problem, maybe look at the DNS options: https://www.papercut.com/products/ng/mobility-print/manual/how-to-setup/step-2-configuration/discover-your-printers-using-dns/

level 3
Original Poster1 point · 3 months ago

Yes we've run Papercut for a long time! It's great.

level 2
Original Poster1 point · 3 months ago

Yes we've run Papercut for a long time! It's great.

level 1
9 points · 3 months ago

You need to hire a consultant at this scale. There are wwwaaayyy to many factors for simple advice.

level 2
Original Poster1 point · 3 months ago

Yes, agreed, just getting my head around it some before talking to him.

level 1
CCNA3 points · 3 months ago

VLANs per building to start with. If there's more than 20% broadcast traffic on each segment then split it further or look for other options.

level 1

Well if you don’t need broadcast traffic on certain ssid block it at the ap. I am not sure about rockus but suppress broadcast is something ubnt can do.

You need subnets and layer 3 switches for the inter vlan routing and routing. I would segment my traffic by type and then further by building then down to the floor or hall level. Just be sure that say a Mac on floor 1 zone 1 are are part of the same network as the ssid if you really have to have the bonjour with out setting multicast forwarding in the switch / router.

These are just some musing. I did a school campus network like this in my past. Broadcast storms are very real. We forget about them cause most of us now use vlan and layer 3 for segmenting for security. I know the pain your seeing. I bet if you loose power and a whole lab of macs fire off your network all but crashes.

I defiantly say if your not keen on digging in and pulling a whole over haul by the bootstraps bring in some help. I do think you can make changes on your own to tame this beast.

level 2
Original Poster1 point · 3 months ago

Won't just straight out blocking broadcasts on an SSID kill DHCP?

level 3
2 points · 3 months ago

If you were to block all broadcast sure but dhcp is well known. So most controls allow dhcp broadcasts but eliminate all the rest.

level 1
L3 All the things!1 point · 3 months ago · edited 3 months ago

Definitely need a whole look at your setup, but a good place to start is to surpress broadcast/multicast traffic at the AP. This will significantly help with your problem, and is something you're going to have to deal with no matter what solution you come up.

level 2
Original Poster1 point · 3 months ago

We've already limited broadcast/multicast at the switch ports for traffic heading up to the AP's, this helped a lot, but not enough.

level 3
L3 All the things!5 points · 3 months ago

I would look into doing it at the AP level. If you are still getting the packet rates you're talking about, then the switch port protections aren't doing what they need to be doing. All of the major Enterprise AP manufacturers have some kind of broadcast/multicast suppression mechanism.

I've got /18s covering 30-40 buildings each in the same broadcast domain with no issues.

level 1
Original Poster1 point · 2 months ago

So been working on limits, but not getting too far. Got command entered on the switch CLI, but it's not doing much at all. PRTG is showing still showing 300+ packets/s but the switch deals in kB/s. Assuming my math is sound (around 576 bytes in a packet) 100kB/s is about 174packets/s. Now one of the suppliers of the gear is saying the AP's shouldn't care until 20,000 packets/s. At least I have their attention now... we'll see.

thanks guys.. CJK

Community Details

127k

Subscribers

648

Online

###Enterprise Networking Routers, switches and firewalls. Network blogs, news and network management articles. Cisco, Juniper, Brocade and more all welcome.

Create Post
r/networking Rules
1.
Rule #1: No Home Networking.
2.
Rule #2: No Certification Brain Dumps / Cheating.
3.
Rule #3: No BlogSpam / Traffic re-direction.
4.
Rule #4: No Low Quality Posts.
5.
Rule #5: No Early Career Advice.
6.
Rule #6: Educational Questions must show effort.
Cookies help us deliver our Services. By using our Services or clicking I agree, you agree to our use of cookies. Learn More.