Anchor Mode Layer3 Roaming

[AnuW]

Hi, 

I'm looking to deploy Anchor AP Layer3 roaming mode in our network as I have got access layer switches running L3 to spine and I would like to avoid extending a one big L2 across about 50 switches. 

Has anyone come across any issues with L3 roaming specially with voice traffic when anchoring to the first AP? 

Thanks..

Anu

[cmr]

@AnuW we did have it set up and it did work for voice, however you need to bear in mind that the first AP that the device sees becomes the anchor.  Therefore you would want the best AP model with the best connectivity in the areas where devices arrive, like reception and have them connected to the core with the most bandwidth and lowest latency.

[AnuW]

Thanks for the quick response cmr. Have you tried using the concentrator mode for the same purpose ? by reading the deployment documentation it seems the concentrator mode is to make the AP portable. (moving the AP to different location and connect to the same SSID). However I'm thinking what if all APs are connected with the concentrator mode and let users roam between APs. 

[cmr]

All of our SSIDs are L2 now, our largest site has about 15 switches and 30 APs so we can cope with the L2 spread across all devices at each site.  We do have the same SSIDs across all sites, but each site has it's own network so this works just fine.  We move APs between sites reasonably often and this is simply a case of moving the AP to the new network in the dashboard.

[Ryan_Miles]

Tunneling to a MX using VPN or L3 roaming does nearly the same thing. Both modes use a VPN tunnel between the AP and MX. The only difference is VPN mode allows for split tunneling config.

Because both MX tunnel modes use VPN the crypto process will limit the max throughput. This number varies by AP platform. Old APs will suffer more than newer APs. But even on new APs like the MR56 max throughput could be cut by as much as 50% when VPN tunneling to a MX.

Distributed L3 Roaming (DL3R) doesn't use VPN and therefore doesn't suffer from the crypto overhead. Additionally, DL3R doesn't require the additional cost of MX hardware, licensing, resiliency considerations like single MX or MX HA, placement of the MXs, etc.

DL3R roaming also allows for more segmentation. Tunneling to a MX requires you to set the egress VLAN or interface. So, it still is placing all clients on a given SSID into a single subnet. DL3R uses AP tag to VLAN ID association which is far more flexible. We have an example of this config in our DL3R doc.

The real use case for MR to MX is for teleworker deployments or where the AP is traversing an untrusted network like the Internet to reach the MX..

[AnuW]

Thanks Ryan_Miles, having throughput cutdown is something I would like to avoid. Therefore I think Distributed L3 Roaming is the right option for me. 

Given the large number of access switches in the network, and as they all connects to the spine layer over L3 running eBGP. Therefore I will have a WiFi VLAN per access switch. 

It looks like if I don't have multiple APs in the same VLAN, clients will always get the anchored to the first AP they get connected. Given that DHCP lease is longer, they will always be hooked to that AP. 

With the concentrator tunnels, it seems I will get bandwidth capped for 50%. 

Looks like there isn't much options other than having a connection to the MX from multiple access switches and putting multiple APs in the same VLAN.

[Ryan_Miles]

Review the L3 roaming doc. The anchor AP selection is based on a load balancing process as to avoid creating all roamed sessions tunnels to a single anchor/originating AP.