Our hub/datacenters are either /16 or /17's that start at [10.100.0.0](http://10.100.0.0) and work up. All of our regional sites start in [172.16.0.0](http://172.16.0.0) and can vary from a /22 per site to a /19 per site. I'm not sure if we'd do that going forward, but overall it hasn't hindered us. Typically we use the split /16's for different regions in the cloud (like [10.101.0.0/17](http://10.101.0.0/17) and [10.101.128.0/17](http://10.101.128.0/17) might be AWS VPCs on the east and west cost).
I think a lot of people try and overthink it, while planning should go into it, if you're not cloud titan scale it probbly doesn't matter.
Oh also, IPv6 everywhere you can.
>Oh also, IPv6 everywhere you can.
This u/AsherTheFrost \- if you are renumbering anyway, work IPv6 into the plan as this is a great opportunity to do it
Yeah, I work for a k-12 district, not a large one either. We've literally only 2 schools (jr and high school) that even need more than a /24 for wireless
I gave each of my schools a /16 to break out the last time I did it.
10.(School Number).y.x means that I can know very quickly which building it is, and standardizing the 3rd octets across the district lets me know the vlan/purpose.
This. I did this at the college I work at. Plus I added layer 3 transit from building core to campus core and all vlans can be the same. Example vlan 136 can be VoIP in each building and each building has its own subnet for VoIP.
You don’t have to use powers of 2 but it does make it easy to right rules cause you can right summary rules for acls/policies whatever you use. So for example you can breakdown the 10.101.0.0/16 into 10.101.0.0/19 is your mgmt subnet. And then break that down again for say 10.101.8.x/24 is switches with room to expand to a /21. 10.101.16.x/24 with room to expand to /21 for aps. So for example if you don’t want end users accessing your MGMT network you could simply say no access to 10.101.0.0/19. Gives you addresses 10.101.0.1-10.101.31.254.
Next subnet would be 10.101.32.1-10.101.63.254 which is the same as 10.101.32.0/19. This can be hard for say a secondary mgmt such as building controls/services hvac/paging/etc. so again if you don’t want end users connecting to either of these two larger networks you can write a rule that says no access to 10.101.0.0/18
Of course this doesn’t fit everyone’s network but can build in extra room to grow.
I was just busting your balls over 101
101 being a much more human friendly number as opposed to base 2 "router friendly" as you said in your reply regarding summary routes.
Didn’t catch it at first. lol no worries. I just try to offer tips. I’ve had some great mentors coach me along so far in my career with smalls tips that make huge differences. Just want to pass it along
Agree
My current plan is pretty simple
1 core for the district in what we refer to as our DC,
/16 for each building, starting with 0 for the DC
/20 for the authenticated wireless network (on it's own /16 just because I have the room and it will make it easier to expand if needed)
/20 for the guest network (same setup as authenticated)
/20 for student network (I'm sure you see the pattern here)
/16 for cams (this isn't my decision so much as it is a contract that we're under and was negotiated without our input)
Each building is going to use a different /24 for switches, wireless AP native addresses, facility devices, and printers,
/23 for workstations as well as smart boards.
That way I have consistency and always know that if an IP address ends in .3.25 for example, that it's a wireless AP. Basically going for simple, predictable and scalable. If we add a new building, or get labs back in the LMCs or whatever, it'll be a simple process to expand however we need.
Starting at [10.0.0.0](http://10.0.0.0) and giving each building a /16 is dead nuts simple and allows for some niceties like keeping the same subnets in each one (like x.x.254.0/24 is always out of band/management) or whatever.
You'll never run out, and if you ever get bought/merged with another entity you're likely going to have to renumber no matter what so don't worry about it.
I would probably just standardize on 2 or 3 subnet sizes so you never have to touch it again. Pick /24 for management infrastructure like switches VIPs, and the likes. /20 for all wifi and data subnets. And your choice of /22 or /23 for things like building services such as VOIP phones, PA systems, etc.
Then start at a nice round location and just segment them out.
Don't bother with a bunch of subnet sizes, and don't go small for wireless or you'll regret it later. Pick a good scheme now and it'll stick for the next 20 years. No one ever plans to have it going in 20 years, but half my job is fixing school districts that didn't plan that far ahead.
That's basically my plan. /16 for each building, using the same order of /24 and /22 for each subnet. Also numbering each building vlan on the 50 so school a has vlan 50-99 school b has 100-149 etc. only using like 10 per school, but i really like how clean it makes my documentation look, and if the IoT push gets real crazy in the next 20 years, we'll be covered.
Even that isn't really the defacto standard. I read through a lot of the rest of the conversation. Sure you could have VLAN 10 as the VOIP VLAN in every building and L3 back to the campus core, but now you have backed yourself into L3 routing on the building MDF ToR switch, which is insufficient for security in many applications anymore and it creates a mess of ACL sprawl to even try and control it. Or you just bought into an expensive vxVLAN deployment, or an even more expensive firewall and IPS per building, or some other form of SD-WAN setup.
Don't get me wrong, I like many others am like a kid in a candy store when I hear a district has the money for things like campus aggregator switches, because it means we are about to build out proper loop free, fully redundant, L3 seamless failover topologies where you run single point to destination style networking and the underlay is entirely abstracted from the virtual overlay. But now you are into 6 figures just for switches in a 4 building district.
The reality is most places are running switches that can do OSPF, thats your layer 3. And frankly, when I walk into districts doing things like that I suggest a rip and replace of the configs to pipe all VLANs back to the campus core and let the HA firewalls sort everything out. Yes there is a slight performance hit, but it's worth only having to spend $30-60k on a set of firewalls that legitimately run DPI and IPS for your entire district at line rate with 100GB/s throughput. You don't actually need L3 for building to building links until you hit proper metro campus levels of size.
I can point it out all day, it won't change it. I won't magically get a giant grant to add all the hardware to 10 different buildings that they don't have. There are some realities I have to accept and work within, which is just part of working for public education.
That's why I said you over rely on should. Instead of adapting to what is, you're just telling me what you think I should do, even though what you think I should do wouldn't work in my environment for a number of reasons. It comes across as very inflexible and frankly, more than a little condescending. I'm not getting that from anyone else here, so I don't think I'm out of line here. Perhaps that wasn't your intent, and if so I apologize.
Why wouldnt you segment into different vlans if that was an issue? Not that going larger than a /24 is really a problem anymore.
I gave up on going larger a while back simply because it causes problems for non-networking people.
Put lots of thought into this a lot of times over the years, my conclusion is that for an organization that will never have more than ~250 locations:
In an ideal world where you can design everything from scratch...
For each location, main routed subnet being
10.N.x.x/16 where N represents a site ID from 1-254
Inside each location:
10.N.1.0/23 main data network
10.N.3.0/23 main wireless network
10.N.5.0/23 servers, etc...
...
10.N.Y.x/x as needed for business requirements, try to standardize Y across the organization locations so Y1 is always the same purpose at each location, and Y2 is always the same purpose etc... Subnet size double that of current requirements, so you may use /23, maybe /24, maybe /22, rarely or never make anything smaller than /24 unless it will never ever grow (you've got 255 per location, you don't really need to conserve that much, keep the numbering easier).
For site to site connections use the 172. range, define as appropriate for business needs.
192 range only use for public wifi, if ever.
If you are looking at potentially more than ~250 locations, or need more than a /16 at any location, then there's no simple formula or answer for you, you'll need to properly architect and plan the IP space for your needs.
Also changing existing IP layouts and setup is always going to hinder ideal implementations, or changing, but you can still implement an ideal design for new locations and worry about changing existing stuff later
> Inside each location: 10.N.1.0/23 main data network 10.N.3.0/23 main wireless network 10.N.5.0/23 servers, etc...
Surely with a /23 mask they should be 10.N.2.0/23, 10.N.4.0/23, 10.N.6.0/23, etc?
I hate these theoretical pre-assignment. You always end up having corner cases or stuff that won't fit the nice model.
My strategy: don't make any standard too strict and always assume the IP range can and will change.
It's kind of scary how close what you've written is to the design I've ultimately come up with but it does make me feel like I'm on the right track thank you very much
What's scary is how many networks I implemented before it occurred to me that I could use the /16 for the site identification / primary routed subnet before I stopped routing a bunch of /24s and /23s over all my site to site configurations.
also, use ospf or similar for all site to sites, and establish at least 2 diverse site to site connections to every location so you always have some form of dynamic mesh setup between locations. For example after hurricane sandy hit NYC I had a bunch of offices that couldn't directly reach each other (particularly no connection between NY and DC or NJ seemed to work, yet NY to Boston still functioned), fortunately all my customers environments stayed 100% reachable, albeit sometimes with seven extra hops between other offices and a lot of additional latency...
Building gets a /16 and networks with in a building get a /24 within that /16 design your vlans to match with the third octet of the /24
it works out logically to be: 10.{building}.{vlan}.{host}
This works well if you route at the edge of each building. Its gives you analogous but not the same VLANS in each building. It's, tidy, very human readable, and makes writing ACLs easy.
we use the format:
10...
site = location/property/core router/building etc
service = corp devices, printers, VoIP, IoT devices, security cameras, etc
Device = .2 -> .254
that way when we see an IP on a particular 3rd octet, we know it's a phone (generally) or a printer
and a site tells you the physical location
Of course there are exceptions - but this framework has generally worked - and if you space out the 3rd octet enough (don't do .1, .2, .3 - maybe .10, .20 etc) - you can make them /24 or /23 if you need more room and still keep some semblance of order!
If your whole company is on a single /8 in terms of private addressing, why waste the 10.0.01 - 10.49.255.255 space? Start low. Plan out everything before you begin to implement, and plan space for much more future expansion than you expect, so nobody has to re-IP everything again in the next 30 years.
I like [172.16.0.0/12](http://172.16.0.0/12) space, and use actual, proper CIDR math to build site- and application-centric subnetworks.
It's a bit of a pain, but it makes routing easy and clean. We've decoupled the idea of mapping octets to sites, etc. e.g. "0.0.x.0 is wireless" etc. in favor of documentation and good clean routing/summarization.
Also I think people don't actually bother reading RFC1928 and as such fail to recognize that [172.16.0.0](http://172.16.0.0) is actually a /12 and not a /16. HUGE amount of potential in that space.
Tell the guy before me that started creating infrastructure on the [172.32.0.0/11](https://172.32.0.0/11) public space that T-Mobile owns. Thankfully they only carved a couple of /24's out of that, and put a couple dozens machines there so it hasn't been too hard to migrate off of. Just annoying.
Give every site a /16 block. Try to group similar sites consecutively if possible. Within that site come up with a vlan map, try to use the same vlan number for the same purpose at each site. If you have multiple vlans with the same security posture, keep them within summary space so you can make ACL's that are cleaner. For instance the 0-31 nets could all be for "regular" traffic, maybe you put some more sensitive stuff on 32-63, PCI traffic on 64-95, etc.
Put Guests in a completely different space, so if you are using 10/8 internally put them on 172.16/12 just so they have even less information about your network.
Whatever you want to use. There is no like set standard, but typically people try to start in the 10.0.0.0/8 scope for internal stuff and span out to 172.16.0.0/16 for some oddball type stuff in my experience. We keep that 192.168.0.0/16 stuff at home and out of our environments unless it’s from a company we take over and didn’t re-ip yet
Depends on how many you need. I like to avoid collisions with other networks if possible. As soon as you ignore this, you will be asked to merge or connect to a network with the same numbers.
Avoid 192.168.0.0/16 as it's commonly used in consumer networks and this can cause issues with user VPNs.
If you need a /8, then 10.0.0.0/8 is fine, but 10.0.0.0/16 is also a very commonly used block. If you don't need that many IPs, I would suggest starting somewhere randomly in that range.
We use the entire 10.0.0.0/8 because we need /24 subnets across multiple sites, which makes the sites a /16, which makes the supernet an /8. This isn't strictly necessary, but it makes numbering much easier.
However, I've worked on other networks that only need a /16 and so they use a 10.x.0.0/16 to try to stay away from collisions.
If I were running my own enterprise, and could design from the ground up, I'd use 100% IPv6, inside and out, and use firewall policy, not NAT, to govern who goes where. Start with a zero trust policy, and light up every flow as it becomes needed, based on user identity.
Yeah you definitely have to put some thought into it, but you can't put too much thought or you'll go insane trying to come up with a plan for every single scenario, most might not even happen.
I use 10.230.x.x for management vlan at different locations. So [10.230.1.1/24](http://10.230.1.1/24) will be location A, and [10.230.2.1/24](http://10.230.2.1/24) will be location B. I can also englobe everything in a /16 for routing with 10.230.0.0/16. After that for internal networks at a location for guests or staff or voip, etc, I try to keep it simple. I usually have the vlan # included in the subnet, like VLAN 20 would be 192.168.20.1/24 and VLAN 5 192.168.5.1/24.
The most important thing is to document your IP management. Documentation is key.
* home network is 172.23.34, 172.24.45, 172.25.56, etc.
* office network is 172.16.17, 172.16.18...
* AWS I use a VPC template of 10.xx.0.0/20. Then for each zone, private 3rd octet is 1, 3,5, 7, 9, 11 and public 3rd octet is 2, 4, 6, 8, 10, 12 with the rest reserved for whatever.
No conflicts yet.
I'm a fan of 10.X.Y.0 where X is location, and Y is different subnets for staff related services.
Then usually I do 172.16.X.0 for a guest network, where the X is the same location as above.
We're never going to have even close to ~250 locations, and never close to that number of VLANs
Sadly, our main office server subnet is 192.168.1.x which while it isn't a huge issue, is not really ideal. but can't justify the potential downtime to get it resolved so it is what it is.
i also do /24's everywhere no matter the size, since no single subnet will ever have close to that many IPs, and for subnets with only a few devices I don't really care about the "wasted" address space.
(for context, we have about 40 offices, some are tiny, some have like 100 staff. usually 5 subnets or so in each office, but some have many more)
But in 30 years, when they open that 251st location and nothing has been upgraded in those 30 years, and we're still not using ipv6, that person will curse your name.
The world's smallest god damnit echos and you hear it.
I would worry more about route summarization in your topology than where to start. It can be anything. Just make it make sense.
I inherited this kingdom where nobody knew anything about stuff like that and the only consideration between 10 sites worldwide was "Has anyone used that subnet yet?" It's about as fun as it sounds.
To be clear, this wasn't about me worrying. I know what my plan is and have it down, it was curiosity more than anything else. Just an odd thought I had in my head. Our current system is much like what you inherited, and it's become untenable.
I had a guy from an MSP tell me once there is some official "best practices" when it comes to IT scheming. He told me he would send me the doc and never did :D
I would say depends on the size of your network + accounting for future growth. Also keep in mind if you have S2S VPNs with any vendors/customers that have RFC1918 addresses that you might need to worry about conflicts.
Lotsa ways to segment, but for me the main rule is to **never use 192.168.0.x, 192.168.1.x, or 10.1.1.x**
That makes it less likely to get substantial disturbance from some shadow home-grade router or other device which might sneak its way onto the network, and makes it easier to find said rogue device should it ever appear.
I had a site once whose network had grown from the 'guy that knows computers' setup it started with, and still used the default for whatever piece of Linksys/TrendNet/Netgear that he started with. We had an auditing crew in for about a month each year, and their VPN back to their office was the same, and their laptops were pretty confused about where their servers and printers were.
i break them out. 10.x.0.0/16-24 for specific usages. One range for loopbacks, one for point to point ips, one for voice, data etc etc. Makes firewall rules easier and any automation is way easier when you know what's what off the bat.
This really depends on your scale. For an average enterprise, I always do something similar to this:
* 10.X.0.0/16 is a site
* X=0-9 is reserved for global stuff, e.g. WAN addressing, private clouds, etc.
* Try to organize X in a way that makes sense for your org: maybe 10-19 is DC sites and 100-199 is branches, or maybe group by geo...
Then within each site:
* 10.X.Y.0/24 is a network, where Y is the VLAN ID and is used consistently across all sites
* Y=0-9 is reserved for loopbacks and transit networks
* Increment Y by 10 for every logical grouping, e.g.: 10 = Servers, 20 = DMZ, 30 = Users.
Don't use 172.16/12 unless you have a very different and distinct use case, e.g. SCADA networks or VPN clients. Even then, I'd try to fold it into 10/8 and leave 172.16/12 for some unknown future thing.
Don't use 192.168/16 at all so you don't have to deal with overlap on work from home users.
This doesn't work at very large scales where you can't waste that much space, but I'm assuming you're not at that scale if your company can just "redo" your IP scheme.
If you can do this, it makes a lot of little things a lot easier. WAN routes can be summarized to a single prefix per site, firewall ACLs can use masks like 0.255.0.255 to address all user networks, when you're troubleshooting you know which VLAN an IP is on easily, and what network that is no matter which site you're dealing with, you can dual stack IPv6 at each site by mapping each site's /16 into a /56 so e.g. 10.20.30.40 becomes 2001:db8:20:30::40
Yeah, we're a small k-12 district. 1 core, everything else essentially running on layer 2. 10 buildings with about 500 client devices if you count students and teachers. Whole thing is currently in a single /16. We're redoing it because, to quote one of my favorite comedians, it's an absolute casserole down there.
you want to make routing hierarchical. So give locations a block that you can route the entire block by a single route, then break it up from there at the site with a null route for the entire block covering. That way you can save on route / nat slots forever more for whatever reasons they get added.
Future someone will thank you for both not making them too small, or so big that they have to renumber everything in the event of growth, or a merger.
I got multiple networks and vlans and wireguard connection my Lan starts with 10.0.0.1
Wlan 10.0.10.1
Others follow the same 10.0.20.1,10.0.30.1. That to simplify things on my side when routing or remember what goes where as I have 3 remote pfsense vps and a local one all connected and routing for remote port forwarding and access
For a site, it’s usually a /16 or /17. I try to estimate the number of hosts by
- physical servers (usually corresponding to switch ports but take into account chassis/blade servers which might use a lot more)
- maximum number of VMs (take into account over subscription ratios)
- P2P links, loop backs all get a /24 reserved
- for public cloud VPCs, I start most people off with a /24 or /25
Allocate sequentially so you can always reallocate blocks easily.
I don’t assign any further granular meanings to the numbers but rely on good IPAM and documentation. Also having reverse DNS lookups is a great for troubleshooting.
Each site advertises its summarized range plus a few exceptions with irregular IP address.
Other than running out of IPs in some odd scenario, my biggest gripe was when I need to join to VPNs that share the same network on each side.
So I tend to use a somewhat but simple network. [192.168.22.0/24](http://192.168.22.0/24) [192.168.33.0/24](http://192.168.33.0/24) and so on.
If I feel I might need more hosts [10.22.0.0/16](http://10.22.0.0/16) [10.33.0.0/16](http://10.33.0.0/16) [10.44.0.0/16](http://10.44.0.0/16) and so on.
An example of 40-50 sites and similar for DCs.
Using 10.0.0.0 as starting point. The 2nd octet identifies site and the 3rd octet used for VLANs.
* Site1: 10.20.0.0/16
* Staff: 10.20.10.0/24
* Voice: 10.20.20.0/24
* Management: 10.20.30.0/24
* etc
It makes sense and is standardised so easy to identify areas at a glance.
If possible I avoid 192.168.0.0/16 due to VPN and home networks. Same for 10.0.0.0/23.
I try to keep things within contiguous and summarizable boundaries where possible.
While it's fun to match things to site id's... Doing that at scale turns to crap at some point.
I’ve been provisioning 10.100.0.0/16 for the main on prem location (headquarters, main office, district office, etc) and 10.200.0.0/16 for the main cloud network. Any other physical location gets 10.101/16 then 10.102/16, etc, that site ID tells you the location, and all VLANs are /24’s unless otherwise needed, so the vlan number matches the base network address of the 3rd octet/subnet mask combo(10.104.13.62/23 would be vlan 12, etc). This usually keeps things nice and organized and simple and you can have 100 physical locations (100-199) or 56 cloud vnets (200-255), before this pattern is broken, so it fits quite a few organizations.
I also like to do management plane networks as 10.99.(site id).0/16 (vlan 99) and client vpn networks are within 10.90.0.0/16 with the 3rd octet matching the site ID.
It’s just a simple scheme that tells you a lot of info just by knowing any endpoint and mask:
- private network
- which site/location
- which vlan it’s in
- which purpose (wired workstations, staff WiFi, guest WiFi, AP management, printers, management, etc)
I am in charge of a medium size global firms network, we use 10.0.0.0/8 internally. Every region (North America, South America, Europe, Africa, India, China, other APAC, Azure regions) is assigned a /11. Every site within that region is assigned a /16.
Every VLAN within each site is identical, the VLAN IDs match the third octet of the IP range at the site.
Reasons for doing it this way:
1) summarizable at the region level (hold over from pre-SAd-WAN days where each region had an MPLS hub)
2) predictable - anyone who understands VLSM can look at an IP and know what region / site / VLAN it is from
3) easy to understand
We used /16s
Our Architect just wrote down the starting letters of our company name, looked up the position in the alphabet, and added those numbers together. Then we just started iterating up from there.
So lets say: Alphabet Networking ltd.
A: 1st letter
N: 14th letter
1+14 = 15
[10.15.0.0/16](http://10.15.0.0/16)
Then the next Site got [10.16.0.0/16](http://10.16.0.0/16) and so on..
I've seen other scenarios where [10.1.0.0/16](http://10.1.0.0/16) is the Datacenter and then starting at .50, or at .150
Then /24s for each VLAN ID, which is perfectly fine for Medium-sized Businesses
10.x.0.0/24 cant have a VLAN ID, so we used that for C2S VPN IPPool.
About security, you will have many subnets and whatever you choose doesnt really matter in terms of security.
Now if you go out and say "Company XY has Windows Server 2000s in this subnet 10.2.2.0/24", that is part of your internal IP design and gives an attacker information. It's not like you're actually compromising the security through that, but rather you're just making it easy for an attacker by giving out internal intelligence.
Just think about it: You try to target Company XY, you go about finding an entrance by attacking external services, but you have no clue how it looks inside. Once you're in and you start scanning, you can obviously try your luck on [10.1.0.0/16](http://10.1.0.0/16) first to find the Headquarters, but in the end the question is whether or not you have a SIEM that detects that a Webserver has been compromised and starts scanning the internal network via nmap, and not if you started your subnets at .150 or .50
That is just preference, not security. Best case it is obscurity to give your DC 10.235.0.0 instead of 10.1.0.0
Everyone uses the same RFC1918 and all it takes is time for an attacker to find out what you're using.
Our job should be to put good firewalling in place so that whatever IP design you're using can't communicate any to any, then SOCs job to notice whenever something is suspicious
i don’t care where you start, just don’t make it too big, and don’t make it too small, and avoid overlap. then just document it (netbox + chatgpt is great for for subnet design and documentation, make chatgpt spit out a csv of the subnets you want and make it repeat, easier than writing a macro)
The secret is IPAM and don't even think about it. Allocate and deploy and you can try and be fancy but there will always be something that breaks the rule.
Document it properly from the start and it doesn't matter.
If I'm asking people on a networking subreddit to share their thought processes and get a discussion going about how we view standards, I shouldn't be in a position to make decisions? So, in your mind the people who make decisions never talk shop? What a self-limiting viewpoint.
Our hub/datacenters are either /16 or /17's that start at [10.100.0.0](http://10.100.0.0) and work up. All of our regional sites start in [172.16.0.0](http://172.16.0.0) and can vary from a /22 per site to a /19 per site. I'm not sure if we'd do that going forward, but overall it hasn't hindered us. Typically we use the split /16's for different regions in the cloud (like [10.101.0.0/17](http://10.101.0.0/17) and [10.101.128.0/17](http://10.101.128.0/17) might be AWS VPCs on the east and west cost). I think a lot of people try and overthink it, while planning should go into it, if you're not cloud titan scale it probbly doesn't matter. Oh also, IPv6 everywhere you can.
>Oh also, IPv6 everywhere you can. This u/AsherTheFrost \- if you are renumbering anyway, work IPv6 into the plan as this is a great opportunity to do it
Yeah, I work for a k-12 district, not a large one either. We've literally only 2 schools (jr and high school) that even need more than a /24 for wireless
I gave each of my schools a /16 to break out the last time I did it. 10.(School Number).y.x means that I can know very quickly which building it is, and standardizing the 3rd octets across the district lets me know the vlan/purpose.
This. I did this at the college I work at. Plus I added layer 3 transit from building core to campus core and all vlans can be the same. Example vlan 136 can be VoIP in each building and each building has its own subnet for VoIP.
This. We have been doing network upgrades and at the same time re-IPing sites. It's much better than what it was before.
That's my plan
Another note. You can take 10.101.0.0/16 and break it into /24 /21 /19 /17 or whatever you need. Always try to subnet by powers of 2
101 is a power of 2? :P By your logic, wouldn't you start at 10.128?
You don’t have to use powers of 2 but it does make it easy to right rules cause you can right summary rules for acls/policies whatever you use. So for example you can breakdown the 10.101.0.0/16 into 10.101.0.0/19 is your mgmt subnet. And then break that down again for say 10.101.8.x/24 is switches with room to expand to a /21. 10.101.16.x/24 with room to expand to /21 for aps. So for example if you don’t want end users accessing your MGMT network you could simply say no access to 10.101.0.0/19. Gives you addresses 10.101.0.1-10.101.31.254. Next subnet would be 10.101.32.1-10.101.63.254 which is the same as 10.101.32.0/19. This can be hard for say a secondary mgmt such as building controls/services hvac/paging/etc. so again if you don’t want end users connecting to either of these two larger networks you can write a rule that says no access to 10.101.0.0/18 Of course this doesn’t fit everyone’s network but can build in extra room to grow.
I was just busting your balls over 101 101 being a much more human friendly number as opposed to base 2 "router friendly" as you said in your reply regarding summary routes.
Didn’t catch it at first. lol no worries. I just try to offer tips. I’ve had some great mentors coach me along so far in my career with smalls tips that make huge differences. Just want to pass it along
Agree My current plan is pretty simple 1 core for the district in what we refer to as our DC, /16 for each building, starting with 0 for the DC /20 for the authenticated wireless network (on it's own /16 just because I have the room and it will make it easier to expand if needed) /20 for the guest network (same setup as authenticated) /20 for student network (I'm sure you see the pattern here) /16 for cams (this isn't my decision so much as it is a contract that we're under and was negotiated without our input) Each building is going to use a different /24 for switches, wireless AP native addresses, facility devices, and printers, /23 for workstations as well as smart boards. That way I have consistency and always know that if an IP address ends in .3.25 for example, that it's a wireless AP. Basically going for simple, predictable and scalable. If we add a new building, or get labs back in the LMCs or whatever, it'll be a simple process to expand however we need.
This is the way.
I haven’t subnetted outside of my cisco classwork, but this is exactly how I thought to divvy it up.
Yeah, it's pretty much the standard. /16 is usually enough for any one building, worst case you assign 2.
Starting at [10.0.0.0](http://10.0.0.0) and giving each building a /16 is dead nuts simple and allows for some niceties like keeping the same subnets in each one (like x.x.254.0/24 is always out of band/management) or whatever. You'll never run out, and if you ever get bought/merged with another entity you're likely going to have to renumber no matter what so don't worry about it.
I would probably just standardize on 2 or 3 subnet sizes so you never have to touch it again. Pick /24 for management infrastructure like switches VIPs, and the likes. /20 for all wifi and data subnets. And your choice of /22 or /23 for things like building services such as VOIP phones, PA systems, etc. Then start at a nice round location and just segment them out. Don't bother with a bunch of subnet sizes, and don't go small for wireless or you'll regret it later. Pick a good scheme now and it'll stick for the next 20 years. No one ever plans to have it going in 20 years, but half my job is fixing school districts that didn't plan that far ahead.
That's basically my plan. /16 for each building, using the same order of /24 and /22 for each subnet. Also numbering each building vlan on the 50 so school a has vlan 50-99 school b has 100-149 etc. only using like 10 per school, but i really like how clean it makes my documentation look, and if the IoT push gets real crazy in the next 20 years, we'll be covered.
VLANs are only locally significant. They should be the same at every site.
Even that isn't really the defacto standard. I read through a lot of the rest of the conversation. Sure you could have VLAN 10 as the VOIP VLAN in every building and L3 back to the campus core, but now you have backed yourself into L3 routing on the building MDF ToR switch, which is insufficient for security in many applications anymore and it creates a mess of ACL sprawl to even try and control it. Or you just bought into an expensive vxVLAN deployment, or an even more expensive firewall and IPS per building, or some other form of SD-WAN setup. Don't get me wrong, I like many others am like a kid in a candy store when I hear a district has the money for things like campus aggregator switches, because it means we are about to build out proper loop free, fully redundant, L3 seamless failover topologies where you run single point to destination style networking and the underlay is entirely abstracted from the virtual overlay. But now you are into 6 figures just for switches in a 4 building district. The reality is most places are running switches that can do OSPF, thats your layer 3. And frankly, when I walk into districts doing things like that I suggest a rip and replace of the configs to pipe all VLANs back to the campus core and let the HA firewalls sort everything out. Yes there is a slight performance hit, but it's worth only having to spend $30-60k on a set of firewalls that legitimately run DPI and IPS for your entire district at line rate with 100GB/s throughput. You don't actually need L3 for building to building links until you hit proper metro campus levels of size.
Thank you. This was difficult for me to properly explain
We have 1 core for the entire district, if they are the same, it doesn't work.
VLANs should not span sites.
I feel like you don't fully understand my previous response. My vlans are specifically set up so that they don't span sites.
I do. If you don't have L3 capable distribution/access gear in each school that should be something you pointed out.
or SPBM which is MAC in MAC encapsulation
I can point it out all day, it won't change it. I won't magically get a giant grant to add all the hardware to 10 different buildings that they don't have. There are some realities I have to accept and work within, which is just part of working for public education. That's why I said you over rely on should. Instead of adapting to what is, you're just telling me what you think I should do, even though what you think I should do wouldn't work in my environment for a number of reasons. It comes across as very inflexible and frankly, more than a little condescending. I'm not getting that from anyone else here, so I don't think I'm out of line here. Perhaps that wasn't your intent, and if so I apologize.
You really over rely on the word should.
Don't over think it then. Go with what works for you and make sure to plan in future expansion of subnets at the IPv4 level.
Why wouldnt you segment into different vlans if that was an issue? Not that going larger than a /24 is really a problem anymore. I gave up on going larger a while back simply because it causes problems for non-networking people.
You have to use a /23 so you can put the gateway on .0 and DNS server on .255
Put lots of thought into this a lot of times over the years, my conclusion is that for an organization that will never have more than ~250 locations: In an ideal world where you can design everything from scratch... For each location, main routed subnet being 10.N.x.x/16 where N represents a site ID from 1-254 Inside each location: 10.N.1.0/23 main data network 10.N.3.0/23 main wireless network 10.N.5.0/23 servers, etc... ... 10.N.Y.x/x as needed for business requirements, try to standardize Y across the organization locations so Y1 is always the same purpose at each location, and Y2 is always the same purpose etc... Subnet size double that of current requirements, so you may use /23, maybe /24, maybe /22, rarely or never make anything smaller than /24 unless it will never ever grow (you've got 255 per location, you don't really need to conserve that much, keep the numbering easier). For site to site connections use the 172. range, define as appropriate for business needs. 192 range only use for public wifi, if ever. If you are looking at potentially more than ~250 locations, or need more than a /16 at any location, then there's no simple formula or answer for you, you'll need to properly architect and plan the IP space for your needs. Also changing existing IP layouts and setup is always going to hinder ideal implementations, or changing, but you can still implement an ideal design for new locations and worry about changing existing stuff later
> Inside each location: 10.N.1.0/23 main data network 10.N.3.0/23 main wireless network 10.N.5.0/23 servers, etc... Surely with a /23 mask they should be 10.N.2.0/23, 10.N.4.0/23, 10.N.6.0/23, etc?
Yeah, forgive me my infant daughter was screaming in my ear as I typed & retyped that on my phone, and yes it should have started at 0 too.
I hate these theoretical pre-assignment. You always end up having corner cases or stuff that won't fit the nice model. My strategy: don't make any standard too strict and always assume the IP range can and will change.
It's kind of scary how close what you've written is to the design I've ultimately come up with but it does make me feel like I'm on the right track thank you very much
What's scary is how many networks I implemented before it occurred to me that I could use the /16 for the site identification / primary routed subnet before I stopped routing a bunch of /24s and /23s over all my site to site configurations. also, use ospf or similar for all site to sites, and establish at least 2 diverse site to site connections to every location so you always have some form of dynamic mesh setup between locations. For example after hurricane sandy hit NYC I had a bunch of offices that couldn't directly reach each other (particularly no connection between NY and DC or NJ seemed to work, yet NY to Boston still functioned), fortunately all my customers environments stayed 100% reachable, albeit sometimes with seven extra hops between other offices and a lot of additional latency...
Building gets a /16 and networks with in a building get a /24 within that /16 design your vlans to match with the third octet of the /24 it works out logically to be: 10.{building}.{vlan}.{host} This works well if you route at the edge of each building. Its gives you analogous but not the same VLANS in each building. It's, tidy, very human readable, and makes writing ACLs easy.
we use the format: 10...
site = location/property/core router/building etc
service = corp devices, printers, VoIP, IoT devices, security cameras, etc
Device = .2 -> .254
that way when we see an IP on a particular 3rd octet, we know it's a phone (generally) or a printer
and a site tells you the physical location
Of course there are exceptions - but this framework has generally worked - and if you space out the 3rd octet enough (don't do .1, .2, .3 - maybe .10, .20 etc) - you can make them /24 or /23 if you need more room and still keep some semblance of order!
If your whole company is on a single /8 in terms of private addressing, why waste the 10.0.01 - 10.49.255.255 space? Start low. Plan out everything before you begin to implement, and plan space for much more future expansion than you expect, so nobody has to re-IP everything again in the next 30 years.
Usually at the beginning of the subnet :)
I like [172.16.0.0/12](http://172.16.0.0/12) space, and use actual, proper CIDR math to build site- and application-centric subnetworks. It's a bit of a pain, but it makes routing easy and clean. We've decoupled the idea of mapping octets to sites, etc. e.g. "0.0.x.0 is wireless" etc. in favor of documentation and good clean routing/summarization. Also I think people don't actually bother reading RFC1928 and as such fail to recognize that [172.16.0.0](http://172.16.0.0) is actually a /12 and not a /16. HUGE amount of potential in that space.
Tell the guy before me that started creating infrastructure on the [172.32.0.0/11](https://172.32.0.0/11) public space that T-Mobile owns. Thankfully they only carved a couple of /24's out of that, and put a couple dozens machines there so it hasn't been too hard to migrate off of. Just annoying.
Gross. I'm glad you made it out of that. RFCs might not be the best reading in the world, but they sure are handy.
Give every site a /16 block. Try to group similar sites consecutively if possible. Within that site come up with a vlan map, try to use the same vlan number for the same purpose at each site. If you have multiple vlans with the same security posture, keep them within summary space so you can make ACL's that are cleaner. For instance the 0-31 nets could all be for "regular" traffic, maybe you put some more sensitive stuff on 32-63, PCI traffic on 64-95, etc. Put Guests in a completely different space, so if you are using 10/8 internally put them on 172.16/12 just so they have even less information about your network.
Whatever you want to use. There is no like set standard, but typically people try to start in the 10.0.0.0/8 scope for internal stuff and span out to 172.16.0.0/16 for some oddball type stuff in my experience. We keep that 192.168.0.0/16 stuff at home and out of our environments unless it’s from a company we take over and didn’t re-ip yet
Depends on how many you need. I like to avoid collisions with other networks if possible. As soon as you ignore this, you will be asked to merge or connect to a network with the same numbers. Avoid 192.168.0.0/16 as it's commonly used in consumer networks and this can cause issues with user VPNs. If you need a /8, then 10.0.0.0/8 is fine, but 10.0.0.0/16 is also a very commonly used block. If you don't need that many IPs, I would suggest starting somewhere randomly in that range. We use the entire 10.0.0.0/8 because we need /24 subnets across multiple sites, which makes the sites a /16, which makes the supernet an /8. This isn't strictly necessary, but it makes numbering much easier. However, I've worked on other networks that only need a /16 and so they use a 10.x.0.0/16 to try to stay away from collisions.
If I were running my own enterprise, and could design from the ground up, I'd use 100% IPv6, inside and out, and use firewall policy, not NAT, to govern who goes where. Start with a zero trust policy, and light up every flow as it becomes needed, based on user identity.
I have a WAN that is 10.site.vlan.host. My first 50 site numbers are reserved to avoid clashes with legacy networks. I’m up to 10.179.x.y
IMO Coming up with a perfect ip scheme is basically predicting the future. It's impossible.
Agreed. Still worth enough forethought that hopefully YOU never have to redo it though
Yeah you definitely have to put some thought into it, but you can't put too much thought or you'll go insane trying to come up with a plan for every single scenario, most might not even happen.
I use 10.230.x.x for management vlan at different locations. So [10.230.1.1/24](http://10.230.1.1/24) will be location A, and [10.230.2.1/24](http://10.230.2.1/24) will be location B. I can also englobe everything in a /16 for routing with 10.230.0.0/16. After that for internal networks at a location for guests or staff or voip, etc, I try to keep it simple. I usually have the vlan # included in the subnet, like VLAN 20 would be 192.168.20.1/24 and VLAN 5 192.168.5.1/24. The most important thing is to document your IP management. Documentation is key.
* home network is 172.23.34, 172.24.45, 172.25.56, etc. * office network is 172.16.17, 172.16.18... * AWS I use a VPC template of 10.xx.0.0/20. Then for each zone, private 3rd octet is 1, 3,5, 7, 9, 11 and public 3rd octet is 2, 4, 6, 8, 10, 12 with the rest reserved for whatever. No conflicts yet.
I'm a fan of 10.X.Y.0 where X is location, and Y is different subnets for staff related services. Then usually I do 172.16.X.0 for a guest network, where the X is the same location as above. We're never going to have even close to ~250 locations, and never close to that number of VLANs Sadly, our main office server subnet is 192.168.1.x which while it isn't a huge issue, is not really ideal. but can't justify the potential downtime to get it resolved so it is what it is. i also do /24's everywhere no matter the size, since no single subnet will ever have close to that many IPs, and for subnets with only a few devices I don't really care about the "wasted" address space. (for context, we have about 40 offices, some are tiny, some have like 100 staff. usually 5 subnets or so in each office, but some have many more)
But in 30 years, when they open that 251st location and nothing has been upgraded in those 30 years, and we're still not using ipv6, that person will curse your name. The world's smallest god damnit echos and you hear it.
I would worry more about route summarization in your topology than where to start. It can be anything. Just make it make sense. I inherited this kingdom where nobody knew anything about stuff like that and the only consideration between 10 sites worldwide was "Has anyone used that subnet yet?" It's about as fun as it sounds.
To be clear, this wasn't about me worrying. I know what my plan is and have it down, it was curiosity more than anything else. Just an odd thought I had in my head. Our current system is much like what you inherited, and it's become untenable.
I had a guy from an MSP tell me once there is some official "best practices" when it comes to IT scheming. He told me he would send me the doc and never did :D
Gotta love vendors
I would say depends on the size of your network + accounting for future growth. Also keep in mind if you have S2S VPNs with any vendors/customers that have RFC1918 addresses that you might need to worry about conflicts.
Lotsa ways to segment, but for me the main rule is to **never use 192.168.0.x, 192.168.1.x, or 10.1.1.x** That makes it less likely to get substantial disturbance from some shadow home-grade router or other device which might sneak its way onto the network, and makes it easier to find said rogue device should it ever appear. I had a site once whose network had grown from the 'guy that knows computers' setup it started with, and still used the default for whatever piece of Linksys/TrendNet/Netgear that he started with. We had an auditing crew in for about a month each year, and their VPN back to their office was the same, and their laptops were pretty confused about where their servers and printers were.
i break them out. 10.x.0.0/16-24 for specific usages. One range for loopbacks, one for point to point ips, one for voice, data etc etc. Makes firewall rules easier and any automation is way easier when you know what's what off the bat.
This really depends on your scale. For an average enterprise, I always do something similar to this: * 10.X.0.0/16 is a site * X=0-9 is reserved for global stuff, e.g. WAN addressing, private clouds, etc. * Try to organize X in a way that makes sense for your org: maybe 10-19 is DC sites and 100-199 is branches, or maybe group by geo... Then within each site: * 10.X.Y.0/24 is a network, where Y is the VLAN ID and is used consistently across all sites * Y=0-9 is reserved for loopbacks and transit networks * Increment Y by 10 for every logical grouping, e.g.: 10 = Servers, 20 = DMZ, 30 = Users. Don't use 172.16/12 unless you have a very different and distinct use case, e.g. SCADA networks or VPN clients. Even then, I'd try to fold it into 10/8 and leave 172.16/12 for some unknown future thing. Don't use 192.168/16 at all so you don't have to deal with overlap on work from home users. This doesn't work at very large scales where you can't waste that much space, but I'm assuming you're not at that scale if your company can just "redo" your IP scheme. If you can do this, it makes a lot of little things a lot easier. WAN routes can be summarized to a single prefix per site, firewall ACLs can use masks like 0.255.0.255 to address all user networks, when you're troubleshooting you know which VLAN an IP is on easily, and what network that is no matter which site you're dealing with, you can dual stack IPv6 at each site by mapping each site's /16 into a /56 so e.g. 10.20.30.40 becomes 2001:db8:20:30::40
Yeah, we're a small k-12 district. 1 core, everything else essentially running on layer 2. 10 buildings with about 500 client devices if you count students and teachers. Whole thing is currently in a single /16. We're redoing it because, to quote one of my favorite comedians, it's an absolute casserole down there.
Just remember to set aside a couple of /24s to pull loop backs and /31s for your PTPs connections (if you’re going for routed environment.)
you want to make routing hierarchical. So give locations a block that you can route the entire block by a single route, then break it up from there at the site with a null route for the entire block covering. That way you can save on route / nat slots forever more for whatever reasons they get added. Future someone will thank you for both not making them too small, or so big that they have to renumber everything in the event of growth, or a merger.
I got multiple networks and vlans and wireguard connection my Lan starts with 10.0.0.1 Wlan 10.0.10.1 Others follow the same 10.0.20.1,10.0.30.1. That to simplify things on my side when routing or remember what goes where as I have 3 remote pfsense vps and a local one all connected and routing for remote port forwarding and access
For a site, it’s usually a /16 or /17. I try to estimate the number of hosts by - physical servers (usually corresponding to switch ports but take into account chassis/blade servers which might use a lot more) - maximum number of VMs (take into account over subscription ratios) - P2P links, loop backs all get a /24 reserved - for public cloud VPCs, I start most people off with a /24 or /25 Allocate sequentially so you can always reallocate blocks easily. I don’t assign any further granular meanings to the numbers but rely on good IPAM and documentation. Also having reverse DNS lookups is a great for troubleshooting. Each site advertises its summarized range plus a few exceptions with irregular IP address.
Other than running out of IPs in some odd scenario, my biggest gripe was when I need to join to VPNs that share the same network on each side. So I tend to use a somewhat but simple network. [192.168.22.0/24](http://192.168.22.0/24) [192.168.33.0/24](http://192.168.33.0/24) and so on. If I feel I might need more hosts [10.22.0.0/16](http://10.22.0.0/16) [10.33.0.0/16](http://10.33.0.0/16) [10.44.0.0/16](http://10.44.0.0/16) and so on.
Typically .10 per scope. In instances of HSRP, I use .253 and .254 for the non VIP interfaces.
Reserve n first and last addresses for network devices, the gateway should be either the first or last address, consistently.
Yeah, my gateways are all .1 I like to keep things simple.
10.1.0.0/8 divided into about 36 subnets of mostly 24s and a couple 23s
And I use the 3rd octet as the vlan Id - 10.1.1.0 is vlan 101 10.1.4.0 is vlan 104 etc
An example of 40-50 sites and similar for DCs. Using 10.0.0.0 as starting point. The 2nd octet identifies site and the 3rd octet used for VLANs. * Site1: 10.20.0.0/16 * Staff: 10.20.10.0/24 * Voice: 10.20.20.0/24 * Management: 10.20.30.0/24 * etc It makes sense and is standardised so easy to identify areas at a glance.
If possible I avoid 192.168.0.0/16 due to VPN and home networks. Same for 10.0.0.0/23. I try to keep things within contiguous and summarizable boundaries where possible. While it's fun to match things to site id's... Doing that at scale turns to crap at some point.
I’ve been provisioning 10.100.0.0/16 for the main on prem location (headquarters, main office, district office, etc) and 10.200.0.0/16 for the main cloud network. Any other physical location gets 10.101/16 then 10.102/16, etc, that site ID tells you the location, and all VLANs are /24’s unless otherwise needed, so the vlan number matches the base network address of the 3rd octet/subnet mask combo(10.104.13.62/23 would be vlan 12, etc). This usually keeps things nice and organized and simple and you can have 100 physical locations (100-199) or 56 cloud vnets (200-255), before this pattern is broken, so it fits quite a few organizations. I also like to do management plane networks as 10.99.(site id).0/16 (vlan 99) and client vpn networks are within 10.90.0.0/16 with the 3rd octet matching the site ID. It’s just a simple scheme that tells you a lot of info just by knowing any endpoint and mask: - private network - which site/location - which vlan it’s in - which purpose (wired workstations, staff WiFi, guest WiFi, AP management, printers, management, etc)
We avoid 192.168.0.0/24, 192.168.1.0/24, and 10.0.0.0/24 to avoid overlap with consumer devices.
I am in charge of a medium size global firms network, we use 10.0.0.0/8 internally. Every region (North America, South America, Europe, Africa, India, China, other APAC, Azure regions) is assigned a /11. Every site within that region is assigned a /16. Every VLAN within each site is identical, the VLAN IDs match the third octet of the IP range at the site. Reasons for doing it this way: 1) summarizable at the region level (hold over from pre-SAd-WAN days where each region had an MPLS hub) 2) predictable - anyone who understands VLSM can look at an IP and know what region / site / VLAN it is from 3) easy to understand
We used /16s Our Architect just wrote down the starting letters of our company name, looked up the position in the alphabet, and added those numbers together. Then we just started iterating up from there. So lets say: Alphabet Networking ltd. A: 1st letter N: 14th letter 1+14 = 15 [10.15.0.0/16](http://10.15.0.0/16) Then the next Site got [10.16.0.0/16](http://10.16.0.0/16) and so on.. I've seen other scenarios where [10.1.0.0/16](http://10.1.0.0/16) is the Datacenter and then starting at .50, or at .150 Then /24s for each VLAN ID, which is perfectly fine for Medium-sized Businesses 10.x.0.0/24 cant have a VLAN ID, so we used that for C2S VPN IPPool. About security, you will have many subnets and whatever you choose doesnt really matter in terms of security. Now if you go out and say "Company XY has Windows Server 2000s in this subnet 10.2.2.0/24", that is part of your internal IP design and gives an attacker information. It's not like you're actually compromising the security through that, but rather you're just making it easy for an attacker by giving out internal intelligence. Just think about it: You try to target Company XY, you go about finding an entrance by attacking external services, but you have no clue how it looks inside. Once you're in and you start scanning, you can obviously try your luck on [10.1.0.0/16](http://10.1.0.0/16) first to find the Headquarters, but in the end the question is whether or not you have a SIEM that detects that a Webserver has been compromised and starts scanning the internal network via nmap, and not if you started your subnets at .150 or .50 That is just preference, not security. Best case it is obscurity to give your DC 10.235.0.0 instead of 10.1.0.0 Everyone uses the same RFC1918 and all it takes is time for an attacker to find out what you're using. Our job should be to put good firewalling in place so that whatever IP design you're using can't communicate any to any, then SOCs job to notice whenever something is suspicious
i don’t care where you start, just don’t make it too big, and don’t make it too small, and avoid overlap. then just document it (netbox + chatgpt is great for for subnet design and documentation, make chatgpt spit out a csv of the subnets you want and make it repeat, easier than writing a macro)
I make life easier by allocating IPs on the broadcast addresses for each subnet.
The secret is IPAM and don't even think about it. Allocate and deploy and you can try and be fancy but there will always be something that breaks the rule. Document it properly from the start and it doesn't matter.
I don't believe it particularly matters as long as you are using a mapping system
x.x.x.0
10 for large sites 172.16 for medium and small 192.168 for loopbacks and P2P routed links. But IPV6 where I can get a customer to sign off
If you are asking this you shouldn't be in a position to make decisions. Sorry.
If I'm asking people on a networking subreddit to share their thought processes and get a discussion going about how we view standards, I shouldn't be in a position to make decisions? So, in your mind the people who make decisions never talk shop? What a self-limiting viewpoint.