Subnet (vlan) size for large deployments, recommended limits?


(Jeremy Schaeffer) #1

This may be disputed topic but I cannot seem to find any real answer. What would the recommended / ideal subnet size be for a large deployment across multiple buildings be? (seperate vlan) For example if I have 800 phones, could I put them under one subnet (and vlan) or should I break the up into multiple subnets (vlans) and route the traffic? Pro’s / Con’s and what do the experts say? Thanks!


(Dickson) #2

Not an expert, but have experience. I don’t think its so much the number of devices you have on a network as much as the chatter it would be with each device and what it would generate. The broadcast really starts to ramp up, and all your devices on it would need to handle all these requests whether its for them or not. I know it seems easy to just say "What the heck, make it 255.255.252.0 (1000 devices) and let er rip. But then all these phones (assuming would have all kinds of traffic traversing all your buildings, really unnecessarily).
Your switches would also need to process all this broadcast traffic between buildings which would mostly be unnecessary, they’d spend huge amounts of processor time i think not doing anything useful towards voice traffic (along with other vlans it might have)

I think you want to consider limiting the size of the networks just to make it easier to administer and troubleshoot problems as fast as possible.

If you had 800 devices spread all over a large multi-geographical area, then if you had an issue, its going to be complicated to figure out where the device is exactly without diving into the network switches. Lets say you had a problem with a bunch of phones, but it was actually only limited to just 1 building, it would be really hard to tell because, a mega large vlan, all buildings would be in the same IP range. Is it 1 building or all of them?
Troubleshooting, you want to visualize it as fast as you can, not making guesses.

Similar situations I’ve been in we break up the VLANs like this; VLAN XYZ
X=VOICE Y=Building# Z=Floor (or maybe department like Accounting, HR, Tech operations)
So example: VLAN 253
2=Voice network
5=Building/location#
3=Floor# or Department type.

From a visual perspective just in troubleshooting you could look at a problem and narrow it down pretty fast by reducing your network segments. “Hey we had a huge outage, seems like anyone with 192.168.253.0 addresses are having a problem.” troubleshooting really fast narrowed down. And in a PBX, you want to make it as easy on you as you can.


(Jeremy Schaeffer) #3

Thank you for your reply! That is what I was thinking, but I have a situation where I am trying to explain it but I am being told that just one subnet is fine and I wanted more input on the subject. Thanks!


(Asteriskadmin) #4

i think this is a basic networking question, not really a voip thing. i would expect /24 or /23 and if you’re going to have different buildings, i would also expect to separate them as well, floor, dept etc

here’s some discussion on cisco site

you can use the book they reference as your source


(Tom Ray) #5

You’re missing some key information here.

  1. Are all these buildings in the same area? I.e. like a campus setup?
  2. Are all buildings already sharing the same subnet?
  3. How do all the buildings connect back to each other?
  4. Do VLANs already exist on this network?

My experience has shown that people will ask about multiple VLANs for their setup but after some digging it turns how that they don’t need VLANs because there networks are physically separated not logically. So that is a big piece of the puzzle.


(Jeremy Schaeffer) #6

Thanks for your reply!!

  1. Yes and no. There are two locations, one location has most of the buildings but there are a couple of other buildings a few miles away.

  2. Yes, their data is all on one subnet and the voice on another, separate vlans

  3. MPLS fiber, not managed by them

  4. Yes, actually everything is existing and they have a lot of quality issues and I am trying to explain that having the whole voice network on one subnet is making this difficult to troubleshoot and can cause instability, not to mention waisted bandwidth across the links.