One of my client sites called to ask me to change the subnet masks of the Linux servers I manage there while they re-IP/change the netmask of their network based on a 10.0.0.x scheme.

"Can you change the Linux server netmasks from to"

You mean,


Are you sure you need that many IP addresses?

"Yeah, we never want to run out of IP addresses."

A quick check against the Subnet Cheat Sheet shows:

  • a netmask, a /24 provides 256 hosts. It's clear to see that an organization can exhaust that number of IP addresses.
  • a netmask, a /12 provides 1,048,576 hosts. This is a small < 200-user site. I doubt that they'd allocate more than 400 IP addresses, ever... Maybe 500, but at that point, more subnets/VLANs should be established.

I suggested something that provides fewer hosts, like a /22 or /21 (1024 and 2048 hosts, respectively), but was unable to give a specific reason against using the /12 subnet.

Is there anything this customer should be concerned about? Are there any specific reasons they shouldn't use such an incredibly large mask in their environment?

  • The argument should focus more on whether or not they should, or can, have all future addresses within the same subnet, or if they might need to split subnets. Then bring up the ARP scaling issue.
    – Skaperen
    Commented Dec 9, 2012 at 0:31
  • 3
    You definitely don't want to do this. There are applications that will ARP for every valid IP in the subnet. You really want that to be bounded. Plus, by consuming more IP addresses with this one subnet, you actually increase the chance that you'll run out of IP addresses. (Though it's still near zero in both cases.) This may be a good time to consider whether they've outgrown a single subnet already. Commented Dec 9, 2012 at 6:52
  • 2
    They should migrate to IPv6. ;-). Commented Dec 12, 2012 at 20:54
  • Stealing gateway's IP address could disconnect that network from other networks (and Internet). I had such problems in my networks and that's one of the reasons why I'm putting users, guest, server, etc. in separate VLAN-s. Other reasons (security, ARP, etc.) are mentioned in other comments.
    – 0xFF
    Commented Dec 28, 2012 at 7:53

4 Answers 4

  • As stated in other answers, having too many hosts in the broadcast domain can really start to make broadcasts a mess.

    They'll need a lot of expansion in the subnet before it becomes a potential problem.

  • Future growth planning becomes a mess.

    Adding extra sites with their own IP space gets difficult when you've already laid a needlessly huge footprint down in the available space.

  • Internal network security boundaries become impossible.

    Assigning different subnets to different groups of users and splitting up low security servers/high security servers/restricted management interfaces of servers/storage/network devices goes out the window.

    Any ol' user's laptop that picked up a virus at home can ARP poison the network and take the servers down or man-in-the-middle them. You have no way to keep a compromised device away from sensitive network locations, like out-of-band management interfaces of servers. A typo in an innocent reconfig of network settings can potentially IP conflict with any other device on the network.

If they're not planning on growing in any way that would ever require more subnets, and not planning on ever adding any complexity or security to their network, then it's fine, since it's effectively identical to their current network configuration -- but if they're asking for this, they're obviously planning on expanding.

Needless at best, and seriously bad idea at worst.

  • Excellent explanation!
    – ewwhite
    Commented Dec 9, 2012 at 23:59

No, there is nothing wrong with using a larger mask, if the number of hosts inside stays the same.

The only problem is that doing this causes network admins to get lazy, and not-do proper subnetting, resulting in a large number of hosts being in the same broadcast domain. For example, each ARP request is a broadcast, and all the machines (in the same broadcast domain) have to process it (even though usually one one responds). Same goes for other protocols using broadcast.

Other issue could be address space, since 10/8 has space for only 16 /12 networks, and if they continue with their /12 requests, they can only fit 15 more.

Some security software, which does port/pingscans, to discover live hosts will take up alot more time then it does now (if they have it).

Otherwise, it doesn't matter. If you have only two hosts, the performance will be the same with a /30 or a /8 - the size of the network does not cause any performance issues.

  • I suggested the same and was downvoted for it. You CAN control the broadcast problem using VLAN functionality.
    – mdpc
    Commented Dec 8, 2012 at 23:13
  • This is a single location, so I don't think additional /12's were planned. Security and IP camera software IS in the mix.
    – ewwhite
    Commented Dec 8, 2012 at 23:13
  • 3
    @mdpc You can't control broadcasts with VLANs if all the hosts are in one subnet...in one VLAN...
    – HostBits
    Commented Dec 8, 2012 at 23:26
  • Different VLANs on the same subnet is simply bad architecture, and actually does create problems when hosts try to talk to each other. Commented Jul 25, 2013 at 22:03

The arguments against it I can see are you then have a larger broadcast domain, and they would not have as many additional subnets available from 10.X.X.X.

To counter the broadcasts argument, if they are only planning for future growth, the impact to the current network should be negligible. You could also limit your DHCP servers to only distribute a small portion of the full subnet to control things until more IPs were truly needed.

I would personally still argue against doing so, as it unnecessary. Identify the number of needed host addresses, and project for future growth rather than just throw a huge subnet out there.


A previous employer had a large department decide to redesign their departmental network around a /16. Even though this particular department had multiple sites across relatively high-latency links (municipal-area broadbandish). It worked for them, and this was coming on a decade ago when Gig links were only common in the datacenter and in distribution links.

So far as I was aware, they never had any issue with broadcast problems. As I said, this was a about a decade ago with much stupider devices handling broadcast traffic; modern devices shouldn't even think twice about it. This particular network had about twice the nodes you had.

Which is to say, there is nothing wrong with such a large subnet, so long as your network can handle it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .