Wireless Access

how good or bad is roaming between remote APS?

Let say i got 3 APS on a remote Site, and roaming between them its needed.

Those  APS will be on RAP mode and  will have one  ssid on bridge mode and he other one on split tunnel.

Anyone have an idea?

Cheers

Carlos

I believe roaming between RAPs is fine, but you should note the following with respect to band steering taken from the cli guide,

Note, however, that if a campus or remote APs has virtual AP profiles configured in bridge or split-tunnel forwarding mode but no virtual AP in tunnel mode, those APs will gather information about 5G-capable clients independently and will not exchange this information with other APs that also have bridge or split-tunnel virtual APs only.

It's not clear whether this impacts roaming as well.

If im using client match how is this affected on raps with rap bridge and rap split tunneling vaps?

Cheers

Carlos

---

@NightShade1 wrote:

how good or bad is roaming between remote APS?

Let say i got 3 APS on a remote Site, and roaming between them its needed.

Those  APS will be on RAP mode and  will have one  ssid on bridge mode and he other one on split tunnel.

 

Anyone have an idea?

 

Cheers

Carlos

 

 

---

Roaming works on bridged SSIDs.  Roaming does not work on split-tunneled SSIDs.  You should use an instant cluster for a split-tunneled setup.  Do not deploy more than one split tunneled AP at a site; use instant instead.

Clientmatch will work on a bridged SSID.

Okay

So it will work on bride mode even if the ap is on RAP mode right??

If this true i bealive that if i put always on on the SSID and when he is not reporting to the WC for some reason in that particualr momment the roaming will not work until it see it again right???

The other question

The client match on bridge mode on rap mode is as good as the one that is on tunnel mode? or they are not?

Also t, The split tunneling here  will be for  guest access so the roaming i dont think it will be THAT important... guest just access the wifi on conference room and stay there.

The requirement he has is that the internet traffic must go out to the internet locally in each site... thats why i need split tunnel on captive portal.

For now they do not want to invest in more equipment so the instant option or anything that involve bying is out of the table... they had one controller and one ap per site, now they are changing this for the controller they got alrady and 3 aPS per site or something like that.

Roaming works in Bridged mode, period.  Clientmatch works in bridged mode period.  If the AP is not reporting to the WC, the client will make its own decisions about roaming without Clientmatch.

So there is no roaming on split tunneling neither the normal client roaming without the help of the controller???

Cheers

Carlos

When you do a split tunnel, the client's firewall state is contained within the access point.  When that client roams, there is no expectation that the firewall state is transferred to the next access point, because there is no expectation of roaming on  a split tunneled SSID.  If the client roams, the firewall state is forgotten making for a poor experience.  It has always been this way, because the expectation is that a split-tunneled SSID is one at a remote site with a single access point.  That is just about the client firewall state.

wifi clients have always roamed and will continue to roam like they always have.  When the access point is not connected to the controller, clientmatch cannot assist the clients in roaming, so clients will have their default roaming behavior.