IPv4 Address Space Planning Best Practices
A recent question from Craig Constantine pertained to IPv6, but many people are not on the leading edge with IPv6 yet and are still responsible for new or improved IPv4 deployments.
I would like to validate my own enterprise IPv4 address space planning against any public documents or guidance given directly here. Addressing has some unique needs between the DC and Campus that would ideally be considered.
I'm specifically looking to see what best practices exist for planning out private (RFC1918) IP space assignments for regions, cities, campus, buildings, floors, uplinks, WAN links, loopbacks, etc. Wired vs wireless. Internal networks vs. guest networks. *I know this on its own can be a bit of an open-ended question, so I'm looking for specific references or examples to proven and well-thought out plans in a similar way as to the IPv6 answers. Suggested CIDR blocks would be helpful as the space gets allocated.
Aggregation for routing, of course, is desired, and so is the ability to have simplified ACLs. There's a trade-off in ACLs on with the desire to aggregate all employee subnets, for example, whether wired or wireless vs aggregating all wireless users regardless if they are employees, contractors, or guests.
Being in a semi-small company, we broke down our private network somewhat liberally as so:
/24 per Vlan /16 per location
Vlans are spread out, skipping 10 /24s per. Vlan number matches the third octet. Locations are sequential, starting 10 /16s in.
10.10.1.0/24 - Location A, Management Vlan 1
10.10.11.0/24 - Location A, Wireless Vlan 11
10.11.11.0/24 - Location B, Wireless Vlan 11
10.11.81.0/24 - Location B, SAN Vlan 81
10.11.101.0/24 - Location B, Wired Office Vlan 101
1 - management
2 - management for wireless
11 - wireless access
21 - guests
31 - mobile devices
41 - factory equipment
51 - SAN
61 - VoIP
71 - Wired access
And so on.
The benefits we saw with this are:
Easy to refer to an entire location via /16. We use this quite often for VPN ACLs.
Easy to group device types together for web filtering.
Any Vlan within the next 10 /24s belongs to the same type as the previous root.
So for example, factory equipment... Vlan 31, for certain vendors who have 24/7 remote access, we gave them their own Vlan, 32 or 33 or 34, up to 40. Their VPN access limits them to the equipment that they support without getting granular on IPs/ACEs. If the manufacturing team needs to drop more equipment in, we don't have to update the VPN ACLs. This also includes access ACLs/ACEs between Vlans.
Another example: SAN Vlans, we use two of them at minimum for redundancy. So they are always 81 and 82.
Last example: Wireless management is broken out to its own Vlan, 2. We do this because we have enough APs to need a WLAN controller but no budget for controllers. This Vlan uses tftp and dhcp options to auto configure and boot the APs from a central config repo and we don't want other equipment that can auto boot to pull the wireless configs.
This setup gives us an easy way to look at an IP and know the location and type of equipment it belongs to. This means less ACLs/ACEs in configuration files for us, especially on limited VPN users. We also have breathing room for expansion in the event we run out of IPs in a Vlan or because we need to further segregate traffic. And since we're a small company, we haven't broken into three digit location numbering yet. Plenty of growth room.