So Long, Thanks For All The Help

[ATLga]

I believe the UI help is pretty clear.

In Networks:

View attachment 62413

In WiFi:

View attachment 62414

Yes those are both clear which is why I don’t understand why in networks, their help page omitted that step of toggling that on (link in post 118). I must be missing something

 

[Tech9]

Perhaps the documentation is assuming when you need a Guest Network you select it as a Guest Network. Also keep in mind the online documents are for UniFi OS or Network Application and not specifically for your Cloud Gateway Max. Ubiquiti has many different devices. Some of the settings you see there may not be present on your device or you may have settings appearing after software update not mentioned there.

Sometimes you may see even things like this in the UI:

 

[ATLga]

Perhaps the documentation is assuming when you need a Guest Network you select it as a Guest Network. Also keep in mind the online documents are for UniFi OS or Network Application and not specifically for your Cloud Gateway Max. Ubiquiti has many different devices. Some of the settings you see there may not be present on your device or you may have settings appearing after software update not mentioned there.

Sometimes you may see even things like this in the UI:

View attachment 62416

Nice placeholder
You’re most likely correct. So it’s safe to assume my settings for that are correct. Goal is totally isolated guest network

 

[Tech9]

Your Guest Network is fine. It's different VLAN, has own DHCP server, perhaps you have selected DHCP scope already, firewall rules were created automatically for you, Captive Portal authentication options are, etc. Enjoy playing with the settings and testing the results because in short time you'll have nothing more to tweak and play with. The Gateway doesn't reboot on network changes and you'll go through the available options pretty fast.

 

[ATLga]

Your Guest Network is fine. It's different VLAN, has own DHCP server, perhaps you have selected DHCP scope already, firewall rules were created automatically for you, Captive Portal authentication options are, etc. Enjoy playing with the settings and testing the results because in short time you'll have nothing more to tweak and play with. The Gateway doesn't reboot on network changes and you'll go through the available options pretty fast.

Yeah I’ll dismantle the ASUS in the morning and get this in place and tweak it a bit more. I do like the cloud management, two factor turned on is a must.
Do you also use the phone app and if so, is it pretty similar to the cloud management console. Some apps skimp on the features

 

[Tech9]

Not really an App person, but I have both UniFi App and WiFiman on my phone. UniFi App receives the notifications and it's almost full featured management tool. WiFiman with the life data is useful for adjusting the APs settings, performance evaluation, etc. So far I'm happy with the software.

 

[tgl]

So I'm wondering about something. As I've said I live here in Atlanta. Worlds Busiest Airport. I've always had the DFS turned off on the asus routers to prevent them channel hopping. With that was the AX features disabled on 2.4 and 5.0. 2.0 I had limited to 20mhz and the 5.0 was set to 80mhz; both with fixed channels. Thoughts on this. Should I just leave most at default and go with it or set it the same as I've always done with my other routers; set channels, set bandwidth, guest network, etc. Thinking out loud...

Received wisdom on the community.ui.com boards is to not trust UniFi's "Auto" settings for channel or Tx power (or indeed anything else). Their auto channel selection is notoriously stupid, and as far as anyone can tell "Auto" power is just a synonym for "High", which is seldom what you want. Use a wifi scanner or the "Radios/Environment" tab in the UniFi GUI to identify which channels are cleanest where you are, and then select those as fixed channels. Don't put adjacent APs on the same channel.

As for DFS channels ... you might try it. I remember having been scared off that back when I was using Asus XT8s, because (not knowing much about it at the time) I'd tried a DFS channel and the system almost immediately saw a radar pulse and fell over. I acquired my UniFi gear shortly after moving across town into a high-rise apartment block. I figured DFS would be even more of a loss here, because (a) I'm about half as far as before from the local airport and NOAA weather radar station, and (b) I'm on top of a high hill where I've practically got line-of-sight to those institutions, where before the same hill had been blocking them. Nonetheless, the congestion in the 5GHz band in this building is bad enough that I thought I'd try anything, so I started using channels 52 and 132 (both at 80MHz) ... and darn if it hasn't worked great. I don't think I've seen a single radar outage in the roughly-a-year since I set this up, and my neighbors are mostly not using these channels. I do not recall exactly which DFS channel I tried previously, but I wonder if it could've been in the 120-128 range. One of many things I know now that I didn't then is that weather radars run in that frequency range. The rest of the DFS range is reserved for other sorts of legacy radio services that might or might not be operating anywhere near you. TL;DR: give it a try, and try a few different channels in the DFS range before deciding you can't use it.

 

[Tech9]

Don't put adjacent APs on the same channel.

I have all 4x APs currently on the same channels. They share the total available bandwidth, but the roaming happens faster. I rarely have clients taking the entire bandwidth, but I have clients moving from one AP to another. For 2x APs it won't be a problem. Let @ATLga experiment and find own best settings.

 

[tgl]

I have all 4x APs currently on the same channels. They share the total available bandwidth, but the roaming happens faster.

Hmm, have you re-checked that with UniFi? I have all my APs on different channels, and roaming between them works just fine AFAICT. I do have "BSS Transition" (a/k/a 802.11v) enabled, which might help on this.

Let @ATLga experiment and find own best settings.

Yeah, "YMMV" is always applicable with wifi.

 

[ATLga]

I have all 4x APs currently on the same channels. They share the total available bandwidth, but the roaming happens faster. I rarely have clients taking the entire bandwidth, but I have clients moving from one AP to another. For 2x APs it won't be a problem. Let @ATLga experiment and find own best settings.

This was actually one of my questions I had forgotten to ask, thanks @tgl for the initial comment. I do have both ap's set to use the same channels because I had always read previously on the old asus mesh threads when setting those up that they should use same channels for best roaming and that they wouldn't have to reassociate (or something like that as best I remember). I never did have a mesh setup so didn't test that theory.

This may make a difference though and I'll look into it a bit futher: BSS Transition" (a/k/a 802.11v) enabled
From my quick reading:
802.11k is on regardless.
802.11r = Fast Roaming in the settings.
802.11v = BSS Transition in the settings.

Disclaimer: I'm leary of toggling a bunch of things on/off that aren't the defaults unless I absolutely know what they do and have used them. Kinda like the people who get a new asus and immediately go to the professional tab and starting messing with stuff. Then can't figure out why their stuff doesn't work.

---
Edit to add some of my reading this morning -

"Fast BSS Transition only makes the roam faster. It keeps the client from having to do a full authentication each time it roams. It does not affect when the client decides to roam
802.11r/Fast BSS Transition is all about reducing the amount of frames to authenticate the client and set up encryption. I can walk you through the exact differences in frame exchanges if you want, but Meraki has a nice summary:

- 802.11r uses Fast Basic Service Set Transition (FT) to allow encryption keys to be stored on all of the APs in a network. This way, a client doesn't need to perform the complete authentication process to a backend server every time it roams to a new AP within the network. Thus avoiding a significant amount of latency that would have previously delayed network connectivity.

They also have a nice summary about 802.11k:

- 802.11k reduces the time required to roam by allowing the client to more quickly determine which AP it should roam to next and how. The Cisco Meraki AP the client is currently connected to will provide it with information regarding neighboring APs and their channels. This way when the client is ready to roam, it has a better idea of where it will be roaming to.

Source: https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/802.11k_and_802.11r_Overview"
----
"802.11k gives the client neighbor reports. It can help the client make a good decision about where and when to roam, but it does not force the client to roam and thus does not fix sticky client issues. The client still has to decide to roam.

802.11r speeds up the roam by simplifying the authentication process during the roam. It makes the roaming event happen in a shorter amount of time from start to finish, but does not influence when the client decides to roam, and does not fix sticky client issues. The client still has to decide to roam.

These are extremely well-documented, widely known, and basic facts about 802.11 networks.

Yes, 802.11k and 802.11r absolutely do improve roaming, they do not fix sticky clients. The client alone chooses when to roam, and 802.11r and 802.11v just improve how long it takes for the roam to happen. They improve the speed of the roam, but the client must still decide to roam."

 

[Jbennett360]

Max and the U6+ are both out of stock in the UK

 

[Tech9]

Hmm, have you re-checked that with UniFi?

For my home - I checked what works best for my ~20 clients and we don't have 4x 80MHz wide channels on 5GHz band. My previous setup was set on 2x Ch.42 + 2x Ch.155, but this one works better on 4x Ch.42. It comes down to what the user wants - maximum throughput or a bit faster transition. I get a bit faster transition and the throughput is enough. For my business - the system is set on different 40MHz wide channels for ~200 clients.

I do have both ap's set to use the same channels

Just test and see what works best for you. With 2x APs you can do same or different 80MHz non-DFS channels. You may find tuning the system easier on the same channels because wall penetration on 5.2GHz (Ch.42) and 5.8GHz (Ch.155) is a bit different.

 

[ATLga]

This was actually one of my questions I had forgotten to ask, thanks @tgl for the initial comment. I do have both ap's set to use the same channels because I had always read previously on the old asus mesh threads when setting those up that they should use same channels for best roaming and that they wouldn't have to reassociate (or something like that as best I remember). I never did have a mesh setup so didn't test that theory.

This may make a difference though and I'll look into it a bit futher: BSS Transition" (a/k/a 802.11v) enabled
From my quick reading:
802.11k is on regardless.
802.11r = Fast Roaming in the settings.
802.11v = BSS Transition in the settings.

Disclaimer: I'm leary of toggling a bunch of things on/off that aren't the defaults unless I absolutely know what they do and have used them. Kinda like the people who get a new asus and immediately go to the professional tab and starting messing with stuff. Then can't figure out why their stuff doesn't work.

---
Edit to add some of my reading this morning -

"Fast BSS Transition only makes the roam faster. It keeps the client from having to do a full authentication each time it roams. It does not affect when the client decides to roam
802.11r/Fast BSS Transition is all about reducing the amount of frames to authenticate the client and set up encryption. I can walk you through the exact differences in frame exchanges if you want, but Meraki has a nice summary:

- 802.11r uses Fast Basic Service Set Transition (FT) to allow encryption keys to be stored on all of the APs in a network. This way, a client doesn't need to perform the complete authentication process to a backend server every time it roams to a new AP within the network. Thus avoiding a significant amount of latency that would have previously delayed network connectivity.

They also have a nice summary about 802.11k:

- 802.11k reduces the time required to roam by allowing the client to more quickly determine which AP it should roam to next and how. The Cisco Meraki AP the client is currently connected to will provide it with information regarding neighboring APs and their channels. This way when the client is ready to roam, it has a better idea of where it will be roaming to.

Source: https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/802.11k_and_802.11r_Overview"
----
"802.11k gives the client neighbor reports. It can help the client make a good decision about where and when to roam, but it does not force the client to roam and thus does not fix sticky client issues. The client still has to decide to roam.

802.11r speeds up the roam by simplifying the authentication process during the roam. It makes the roaming event happen in a shorter amount of time from start to finish, but does not influence when the client decides to roam, and does not fix sticky client issues. The client still has to decide to roam.

These are extremely well-documented, widely known, and basic facts about 802.11 networks.

Yes, 802.11k and 802.11r absolutely do improve roaming, they do not fix sticky clients. The client alone chooses when to roam, and 802.11r and 802.11v just improve how long it takes for the roam to happen. They improve the speed of the roam, but the client must still decide to roam."

Note that by default in my Cloud GUI, the network settings have Band Steering and BSS Transition toggled on

 

[tgl]

This was actually one of my questions I had forgotten to ask, thanks @tgl for the initial comment. I do have both ap's set to use the same channels because I had always read previously on the old asus mesh threads when setting those up that they should use same channels for best roaming and that they wouldn't have to reassociate (or something like that as best I remember). I never did have a mesh setup so didn't test that theory.

Yes, if you're using wireless meshing then the parent and remote APs must use the same 5GHz channel, because that's where their backhaul traffic happens. (Unlike some Asus models, UniFi APs don't have a spare radio for backhaul.) But if you have wired APs, I think putting them on nonoverlapping channels is a better choice. With 802.11k there's no reason why a client would have to search to find a signal on another channel.

The text you quoted about 802.11k/v/r matches my understanding of things. The thing it won't tell you is whether (or how well) the clients you have work with those features. The clients I have for which I care about roaming are almost all fairly-recent Apple gear, and they all seem to roam fine with all of those features turned on. The one non-Apple roaming device is a robot vacuum, which seems to have extremely bottom-of-the-line wifi hardware (2.4G only, 1x1 WiFi 4 per UNA). I rather doubt that it knows anything about k/v/r. But it doesn't seem to have a problem either as it trundles around the apartment. So for sure YMMV, but I encourage you to experiment.