Advice on my IP Addressing Scheme and VPN Suggestions - 70+ Stores and Counting

Hey guys!

I am working at this nationwide company with over 70+ stores and I have been task to standardise the entire network infrastructure of the company (which is currently not existent), as we have a lot of upcoming openings and the longer we are without a standard addressing scheme, the worst will be for us.

I have created a preliminary IP Addressing scheme to be followed, but I wanted to ask for advice from those who have been in the field longer than I have to see if I’m missing something or if I am in the correct track :slight_smile:

Please be kind, this is my first time doing a massive project like this, Any advice is welcomed!

Note: My IP Addressing Scheme counts for future expansion to other continents, even though, right now they are only in one.

IP ADDRESSING SCHEME:

SCHEMA: Private IP Addressing: 10.X.Y.Z
X= Continent/Country(State)
Y= Store ID
Z= Static Or Random Assigned

Asia / Oceania 10.0.0.0/12 Total Usable: 1,048,574
Australia 10.0.0.0/16 Total Usable: 65,534
Australia Queensland Total Usable: 65,534
Australia NSW 10.2.0.0/16 Total Usable: 65,534
Australia Victoria 10.3.0.0/16 Total Usable: 65,534
Australia Northern Territory 10.4.0.0/16 Total Usable: 65,534
Australia WA 10.5.0.0/16 Total Usable: 65,534
Australia Tasmania 10.6.0.0/16 Total Usable: 65,534
End Range for Countries at Asia / Oceania 10.15.255.255/12

Branch Network Schema (All Stores would have same VLAN numbers - Different Subnets)
Branch-A with STORE-ID: 123 located at Victoria

STORE SUBNET: 10.6.0.0/24 VLAN TOTAL USABLE NETWORK NAME
10.6.123.0/25 (VLAN=1231) Reference: STORE_ID+1 126 NETWORK 1
10.6.123.128/27 (VLAN=1230) Reference: STORE_ID+0 30 NETWORK 2
10.6.123.160/27 (VLAN=1233) Reference: STORE_ID+3 30 NETWORK 3
10.6.123.192/28 (VLAN=1235) Reference: STORE_ID+5 14 NETWORK 4
10.6.123.208/29 (VLAN=1237) Reference: STORE_ID+7 6 NETWORK 5
10.6.123.216/30 (VLAN=1239) Reference: STORE_ID+9 2 NETWORK 6

* Some Networks will have both reserved static IP Addressing + DHCP enabled.

My Plan is to create a standard for all new stores as well as old stores. Also I would like to connect all branch offices back to HQ using S2S VPN. There are multiple ways to connect them such as (Hub and Spoke) topology. Communication would only be one way only: (HQ -----> Branch), meaning there is no need for Metro-E or any sort of L2 Network. I would like all branches to have L3 routing back to HQ.

Should I use VLANS on my S2S VPN? Should I reserve a new NETWORK(s) for the S2S VPN connection?

I am open for feedback as well as VPN suggestions for my specific scenario :slight_smile:

When comes to HQ, I am not sure if I should have, for example, 172.16.x.y. as their IP Addressing Scheme. I have not looked into it as of now.

Thanks guys!

I think your plan looks solid. One thing I don’t like is how you map store VLANs to the store ID. I think the VLANs should be standardized and the same on all stores. VLANs shouldn’t have any relation to the subnet at all in my opinion, it adds unnecessary coupling and might paint you into a corner later on.

You also could make the IP plan simpler and give each country a /16. This works as there are currently 196 countries in the world. That allows 256 stores in each country. If some country grows beyond 256 stores (unlikely) then you could assign a second /16 to that country.

Anything WAN-related I would put in the 172.16.0.0/12 range, typically we use 172.31.0.0/16 for loopbacks, wan linknets, S2S VPNs, etc. That way they are separate from the store IP-ranges and you can easily see in a traceroute when traffic travel across the WAN.

Honestly, if I was worried enough about future expansion that I was splitting my networks into /29 and /30 subnets, I would just use IPv6 instead. Hell, I’d probably do that for any new or “remodel” mass-deployment. Then you can give every store the same “template” in IPv4 if you still require that, and all still have unique IPv6 addresses. Otherwise, it’s really going to suck when one of your /28 networks end up needing to have 15 devices across all your sites.

For smaller deployments, i.e. companies that absolutely won’t grow to 150+ sites, here’s what I said previously about the matter:

Don’t use common subnets, such as those that often come default on modems and home routers. You’ll eventually hit a problem where you have conflicts with home VPN users and a site. The most obvious subnets would be 192.168.0.x, 192.168.1.x, and 10.0.0.x. There’s also 192.168.100.x and 10.1.10.x, which a lot of home ISP modems give out by default.

Then there’s 10.10.10.x, 10.100.10.x, 10.100.100.x, 172.16.0.x, and 172.16.1.x, which I’ve seen various equipment take up by default as well, such as alarm systems, NVR’s, and printers. These are good to avoid because if that equipment gets plugged in without you knowing about it, such as when a vendor pops by and the site manager knows about it but didn’t bother to tell you, you don’t have to chase various issues afterwards. (There’s a good argument for 802.1x on wired connections in there, but depending on your size, you may not be equipped to handle all the trouble that entails right now.)

With all that in mind, what I do is simple: 10.S.V.0/24 subnets, where S is the “site number” plus 100, and V is the VLAN. Therefore, your main site (number 1) in VLAN 20 would be 10.101.20.0/24, your branch office in Anytown USA (site number 12) in VLAN 60 would be 10.112.60.0/24, and so on. Keep your VLAN’s consistent (phones are always VLAN 80, printers are always VLAN 120, whatever you want) across all sites. Always use even numbers for VLAN’s, so if you absolutely have to, you can increase a /24 to a /23 without butting into the next one. There’s an argument to be made that your VLAN’s should only increase by multiples of 4, so you can even go as far as a /22, but anything beyond a /23 is already too big of a subnet for me except for something like a large public wi-fi (with multicast disabled). I like my VLAN’s ending in a round number, so I increase by 20’s or 10’s, but that’s not strictly necessary.

This gives you 154 sites, so you have room to grow. If you chose 172.16.x.x, you would only be able to grow as far as 16 sites, and if you chose 192.168.x.x, you wouldn’t get past a single site. If your company grows past 154 sites, you’ll be doing 1:many NAT across IPSec tunnels at that point anyways, so it won’t matter if you start re-using subnets.

Also, this makes organization and troubleshooting a LOT easier. You know at a glance that 10.105.80.x is site 5, VLAN 80. You don’t have to keep some cheat sheet nearby when troubleshooting an issue across subnets, because was that subnet you were just looking at site 7 on the server VLAN, or was it site 17 on the camera VLAN? It keeps your mental load at a minimum.

Two other tips to keep in mind. One, I always put my gateways at .1, so if I increase the size of a subnet, the subnet gateway remains at the first address, not orphaned in the middle. Two, always keep a certain block free in your DHCP scopes, so you always have somewhere to drop into a network for troubleshooting if it has a broken DHCP, without causing a conflict with existing devices. I like to keep x.x.x.250 - x.x.x.254 free at all times for this reason, but you can pick a range that suits you best. NEVER put a static IP device or DHCP reservation in that range.

Source: I’ve set up and/or re-numerated about a few dozen IP schemes in my time. The first few I didn’t put enough thought into, and it bit me in the ass. I’ve developed and used this scheme ever since, and it’s never caused a problem, and significantly cut down on my troubleshooting times.

I would not dig in too deep in the scheme, like including site id or country, if not absolutely necessary. What problem are you trying to solve with that information?

  • What happens if you end up with more than 1000 stores, do you need to re-do the whole thing?

While unlikly, I still like to think like that. Keep it simple and just do pool network assignment from an IPAM instead, tied to the site id. To me, you are never going to realize that ”oh! Its network X.163.Y.Z that is san jose”, you would probably need to look it up to match anyway so whats the point in the first place :slight_smile:

There are hundered ways to IP-scheme for hundered different scenarios, this is my point of view.

And dont use different VLANs per site, same VLAN for same service.

Don’t worry about mapping regions, you can do that in DNS or in a specific field in your ipam if you need it.

My tip would be to work out the size of each network you need and double its allocation. Also don’t go smaller than a /27 - except for p2ps (use a /31) and of course loopbacks.

If you are happy with a /24 for each store, allocate two neighbouring ones (so a /23).

With your scale leave gaps to add a second /23 too, although it’s not the end of the world if a store has to have multiple different /24s. Even 100 stores routing 10 /24s each is only 1000 routes.

On your BGP I’d only allow the /24s and larger to be advertised. Add a blackhole for your /24 (or /23) and filter to only send that out. Not because of technical issues with routing table size, but just so it’s easier when you’re looking at routes.

What happens when your scheme breaks; ie you wind up with more than 256 stores in NSW, you need more than 256 addresses per store, you wind up with a store ID of 1002, etc?

“Cute” addressing schemes like yours work great, until they don’t, and then they turn into a mess (see my network). You either need to make them wildly space-inefficient, or you wind up with a headache down the line. It may make sense to reserve blocks, but a good IPAM will also serve you well, or even better than trying to make things “pretty”.

You’ve a good job with the first draft and are on the right track.

This isn’t scaleable beyond 254 stores if the third octet is store number.

I would make VLAN ID’s the same at every store. VLAN 10 POS, VLAN 20 Voice, VLAN 30 third party, VLAN 40 network management. When you open a new location, assign the appropriately sized block for each VLAN. Changing VLAN ID PER location will not be manageable long term and will be confusing for the next person that has your role.

I like the idea of using /16 or a large, easily summarized network space for the different purpose vlans. This will help standardize firewall policy templates so you don’t need to create a new policy for every VLAN at every store.

Don’t listen to advice that says don’t use anything smaller than /24 at sites. Use what you need plus growth. Someday you’ll thank me when you’re working on a large project.

For corporate, data centers and WAN links, pick something that is easily identifiable. Different enough from store LAN scheme that you can sort things like trace routes when users or app developers come with performance issues.

For host ip assignments, standardize so every site is the same. This is important as the network grows and you are giving ip assignments to other people who will be staging and shipping the store hardware.

  • First host is the router
  • Second through whatever is reserved for static
  • whatever through last host for dhcp pool.

Source: I’ve been designing, implementing and managing networks for major retail and service organizations with up to thousands of locations each for the past 25 years.

I’d be concerned about over design here. Allocating a /16 per state seem superfluous and a waste of address space. IMO start with one /16 and start allocating store supernets from that, then once its full allocate from a second /16 etc. In terms of supernet size I’d maybe go with a /20-/22 per store. Then in the future you can allocate from new /16s. A separate /16 for another region could make sense, but it needs a justifiable reason.

However another model is to simply roll out the same IP range / vlan set to every store. If you don’t need unique addressing this dramatically simplifies each site, ideal for cookie cutter stores. This lets you assign a /30 per store for a WAN, and any connections into your main site can simply be NAT’d.

Like others have said, make the VLAN IDs the same across each site. I would suggest documenting this information into something like Netbox to keep it organized.

I worked at the largest retailer in the UK (By store numbers) as it was made up of a merger between two companies the IP standard across them was different.

The first company used a /16 per service in the shop, so say VLAN 10 was tills every shop had a small subnet say a /28 assigned to VLAN10 from the /16 service address space.

The second company used a couple of /15s with each shop allocated a address block from those which in turn was subnetted to each of the shop services.

The way the second company did it was horrible to manage, it made having a secure environment impossible as you had to use the /15s in rules instead of the 2k+ shop subnets as they were not continuous.

My preference and the far easier way was the way the first company did it, you want to restrict access from only the till IPs? Easy, use the /16. Want to ensure that the CCTV server can only reach the NVRs and CCTV cameras? Easy, use the /16 for NVRs.

I would consider this as part of your design, 70 shops is not a small amount but what management overhead will you have if they scale to 200 shops? 1000 shops?

My recommendation would be assign as you are address space per region, but instead of cutting that down and assigning a /24 for each shop create a larger pool for each service in the shop. I would also look at not using unique address space for services you won’t route internally, we had a lot of third party devices which were managed and monitored via the internet that we used the same IP space across each store for to claim back address space.

What about the ACT?? :stuck_out_tongue: Poor Canberra. You are limiting yourself to 256 stores so I wouldn’t use that as your third octet. I think you are overdoing it with the /27-30’s in the store subnets too personally, you’ll quickly get confused and or over doing that per store. Keep it simple.

I agree with other suggestions to simplify the plan, and to not use unique VLANS for each store.

Another consideration should be IP allocations i other parts of the organization. Do you have data centers or cloud infrastructure that might need connections to the stores? Remote VPN that should be able to reach stores via s2s tunnels from HQ? Even if it doesn’t exist today it could be useful to reserve a range of addresses for future use.

Fair first pass. But two questions:

  • Do you need 256 countries?
  • Will you grow past 256 stores?

Don’t worry about making the numbers memorable- that’s what IPAM is for. You’re using 2^8 bits for each octet, but let’s say you’ll never grow past 64 countries- use those bits you save to your advantage and have 2^6 countries and 2^10 stores in each country. 1,000 stores per country. However you slice it, you’ve got 65,536 stores using a /24 each- less however much space you reserve for HQ and for your infrastructure.

I wouldn’t even worry about 172.16.0.0/12 except for maybe a DMZ.

Are you splitting VNETs by device role for network segmentation at your locations? If so, and your hardware is conducive to it (some have issues with too many subnets over VPN), consider using a supernet for each role and splitting those across the sites. It makes configuring firewall rules much more straightforward and maintainable, and if you ever do a cloud migration for your central services to Azure or similar, it makes life much easier.

Meaning, say you have a printer VLAN at each site, having a /16 printer supernet and allocating space from it to each site. Then at your central location, you set up firewall rules for the supernet and future locations you allocate already function on said rules.

Biggest hangup here is some equipment really doesn’t like it. Cisco ASAs had issues with too many security associations, for example.

That is essentially the addressing scheme I used at my old company. We had 700-ish stores spread across 12 states. It worked fine for a while, but became an issue when we outgrew the 256-store-per-state limit in our key states, so we had to add an additional 2nd octet for those states. It worked, it was just not quite as tidy as I would have liked.

In your case, you’re dealing with significantly fewer stores than that, so the chances that you’ll overrun the 2nd octet for any one state is less likely.

One thing I will caution is that when laying out the subnet plan for the store, think very carefully about how those address ranges will be consumed. I originally allocated the first subnet as a /25 like you did, for the “main store subnet”, thinking that most things would end up there. However, over time that subnet didn’t really get used much, and I ended up with maybe 6 devices in it. On the other hand, I allocated a /27 for the Point-Of-Sale network, which seemed fine because we only had 6 devices in it, 3 registers and 3 system controllers. But then we added pinpads, and additional kiosks, and several other devices, and before I knew it the 29 IPs I had available in that VLAN wasn’t enough.

I will echo what another person said here, make your VLAN IDs consistent. For example, VLAN 20 = POS network in every store. There is no benefit to having unique VLAN IDs in every store, and in fact it is a management and deployment headache at best. What you want is to make everything as cookie-cutter as possible.

I’ll also echo the thought that you shouldn’t worry about trying to make the store subnet reflect the store number in some way. Just start at 1 (or 0 if you really want, but I’d probably skip it to avoid confusing people) and go up. Then put them all into an IPAM that people can look up. Put all the store mailing addresses and phone numbers in there too, and make it available to everyone in the company. People will thank you for it.

Make your second Octet location/site instead of country. Unless your building out some crazy big campus with over 50 vlans I don’t see why you dont keep your third octet and vlan IDs matching. I would standardize VLAN IDs across sites with like networks. Workstations always on same vlan across sites for example. I would space my vlans by 5, 10, or 15(Nice round number that fits a /20 perfectly). This gives you room to stretch out subnets if needed without messing with VLAN IDs.

This will greatly help you memorize your networks and troubleshoot on the fly.

Example for Store ID 10

Net-MGMT 10.10.10.0/24 vlan ID 10

Workstations 10.10.20.0/23 vlan ID 20

Auditorium/Guest 10.10.240.0/20 vlan ID 240

One more thing. VLANS that will only get internet access and touch zero internal networks can be what ever you want and the same across all sites. Good if you manage places that may have thousands of guest users like a concert or convention hall.

Edit:Fixed up first sentence. Added Store ID to example.

What type of devices are you going to use for terminating the VPNs? I’d recommend a beefy bastard if you’re going to accommodate > hundreds of peers at any given time. Main thing to be aware of imo is avoiding overlaps with the local and remote networks. Makes things significantly easier to deploy and manage.

I stumbled across this post as I’m in a similar situation. I work for an ecommerce company that has a small number of retail stores, but we’re expecting significant growth and I want to make sure we revamp what currently exists so it scales up easily. Currently, stores are not connected to each other, and we don’t connect them to our corporate office or other centralized location due to PCI compliance concerns. This isn’t manageable as we scale up, so I’m going to change this, but not without careful consideration.

Do you manage your retail PCs via AD? And are you linking your retail stores to your corporate networks for monitoring, patching, management? I’m curious how larger retail establishments do this as there are security and PCI concerns to consider.

I don’t ever see a reason to use anything smaller than a /24 except for /31s for p2p links (also fug vendors that don’t support /31 and force you to use a /30 for p2p).

Agreed. VLAN ID’s same across the board.

Example. VLAN10 = Tills, VLAN20=Voice, VLAN30=Chip&Pin etc