Hello, I was hoping to get some more information on using NAT on an SSID.
First, a bit of background, we offer a service where we setup devices for customers. We can currently do around 2,000 devices at a time, but are looking to scale that up to around 3K-4K over the next couple years. The setup process can take anywhere between 15-30 minutes per batch. These devices do not need to connect to anything locally, and only need to connect to the enrollment servers over the internet. We are running off a MX450, and have
4x MR56 AP's for production.
So, my questions are,
1) If we use NAT on the SSID we use for production, do we get the whole 16.7 million addresses that having a /8 subnet gets you? I would imagine that is split between all networks using NAT, which is fine.
2) What is the DHCP lease time for NAT? Is there anyway to change it?
3) Is there a general rule of thumb that would dictate if using NAT or a /19 subnet (largest Meraki will support) is "best practice"?
I'll add my two cents worth in here and let other people add their own too. My personal opinion is that if you want any control whatsoever over the IP addressing (e.g. static assignments, DHCP options like TFTP options, ...the list goes on) then don't use NAT mode. Go with a bridge mode SSID and stand-up your own DHCP server.
I was told this a while back, so not sure if it still applies, the DHCP in NAT mode is a pseudo-DHCP. The DHCP discovery and response messages are as you'd expect (so the client is doing normal DHCP), but essentially the AP just does a hash of the client MAC to create an IP address in the 10.0.0.0/8 range - and before you ask I've no idea what happens if two devices end up on the same hash, or if it ends up on the gateway address (10.128.128.128), I just assume there are checks built in. So there is very little smarts in the AP.
Specifically in response to your questions...
1) Yes, you do, on every SSID and every AP that uses NAT - but you probably won't have enough access points to handle that many simultaneous clients, and you've no way of specifically assigning an IP to a particular device (or knowing which IP is going to be assigned to a device, that is until its assigned).
2) I've never looked to see what lease time is given to a device, it just works. You could look on the client, or sniff the DHCP packet to be sure. There is no way to change this value that I'm aware of, and why would you? Chances are every client is going to hash to a different IP address anyway.
3) No general rule of thumb. For basic connectivity NAT mode is fine, but its dumb. If you want to do even the slightest 'smart' thing (e.g. change the lease time) then you'll need your own DHCP server, so bridge mode starts looking attractive.
I'm always careful about using large subnets, as you don't want to create a broadcast issue, even if it is just clients ARPing. You obviously can use them, but you need to understand your traffic flows, and how to mitigate any broadcast issues.
Hope this helps.
When you say "NAT on SSID" I'm going to assume you have this configured on the MR, rather than the MX.
When using NAT mode on an MR the DHCP address is calculated by hashing the client's MAC address. This is done to avoid DHCP starvation attacks on guest WiFi. Consequently, you will always get the same private IP address, no matter which Meraki AP you connect to - in the whole world - configured in this mode.
I do not know the NAT timeout. I have not experienced any issues with NAT timeouts.
The DHCP lease time, on an MX or MR (when not in NAT mode), is whatever you configure it to be.
I've done corporate Wifi using /22 (1024 devices) and that has worked fine using lower-spec Cisco Meraki kit, and I've done nothing special. I suspect a /21 (2048) wouldn't not be that much worse.
I think only using 4 x MR56's might not be enough though. That is like 500 devices per AP. That sounds like way too many. I'm not sure you can even connect more than 128 clients at a time.
If you allowed for 50 clients per AP (which is still a lot) you would need closer to 40 APs.
So in conclusion - I think you will need a lot more APs if you want 2,000 connected clients.
@JDavie on your last point, yes that’s correct. Since the IP address is NATed on a per AP and per SSID basis it’s only relevant within a specific AP and SSID combination. But because the IP address is a hash of the MAC a client is likely always going to get the same IP address for a specific SSID no matter which AP they connect to.
The point @PhilipDAth made around number of APs and number of clients is very valid. It’s going to take a lot of APs to connect that many clients. The theoretical maximums are here, but I’d be surprised if you can actually achieve this (hence why they’re theoretical):
> I was unaware of the 512 clients per radio with Wifi 6.
That is the technical maximum limit. You will undoubtedly run into issues if you run it exactly on that limit. I would try and get down to at least 100 connected clients per AP. At that limit, it should work as long as you have very low data transfer rates and assuming no one else in your vicinity is using up the WiFi spectrum and that you are only using 5Ghz spectrum.
I have not run into any "hash" collisions using the NAT functionality. And with only 2,000 clients at a time and with 16.7 million addresses available - I would suggest this is never going to be an issue for you. I would suggest you are more likely to be struck by lightning, twice, than for this to occur (to help you see the perspective).
I would also not attempt to try and project today's technology into a use case 15 years from now. I don't know what it will be like in 15 years - but I know it will be completely different to it is now. Any current networking kit will have been long since thrown away.
2.4Ghz can't be used for dense deployments. You should disable 2.4Ghz on the SSID.
Typically I design for 20 clients per AP, which gives excellent results. I don't deliberately go over 50 as the performance tends to drop off a lot. So I doubled the worst number I wanted to see - 100.
To manage 300 clients I would think you would have to have a pristine RF spectrum. Perhaps if you build your own Faraday cage and do everything inside of that to get rid of the effects from the outside world. Even then, I think you would crash and burn.
I found this article which gives some understanding of the maths and why this is not going to work.
The IP addresses are not reserved. They are the result of a simple hash. The whole point is so the system does not have to track them so that it can survive a starvation attack.
To make it even clearer - it is a stateless DHCP server. Nothing about the DHCP addresses being given out is stored anywhere.
Thank you for explain and clarifying everything. I feel like I understand it all now. I was really overthinking the NAT DHCP.
Thank you so much for all the help, it went a long way.