VXLAN to the Access Point

If you did not know, Arista Networks has wireless offerings, while this won't be an exhaustive look at the product line, they do provide what you expect from a modern provider, cloud controlled, assisted troubleshooting, client monitoring, and VXLAN encapsulation from the AP. That last feature, this is something new, and a recent approach. In this short article I want to explore that and understand how it works and when you would use it.

Controllerless Trade Off

Traditionally within large wireless deployments a centralized controller would be a one stop shop. This is where the administrator would configure networks, policy and where the access points themselves would tunnel user traffic. This is and continues to be a double edged sword. On one hand you can determine your wireless traffic flow and enforce centralized policy, on the other hand your capacity is directly determined by your controllers ability.

In recent years a shift to cloud managed deployments has increased. With the emergence of this model, the centralized controller has been pushed aside, but the need for centralized policy has not diminished. The cloud control model presents some tradeoffs in this area, while initial deployment has been simplified, this comes at the cost of granular control. In most cases the cracks start to appear in larger scale deployments. In a controller based deployment, user wireless traffic was isolated via encapsulation to the controller. Within the wired network or distributed system the traffic load fluctuated with user density and overall activity, but the flow remained predictable.

Upon removing the controller all the user data originating from the wireless network spills into the distribution and core layer with unique flows. The individual flows present dynamic and unpredictable paths where previously the initial next hop was always known. A controllerless architecture is not a deal breaker, but the loss of a predictable aggregation point shifts the planning burden onto the underlay.

Arista's Approach

So, you have a large deployment base, want deterministic traffic flows, and policy enforcement but don't want a specialized controller. Also, you need a well established transport, maybe even standards based. VXLAN has reached wide spread deployment in various networking domains, making it well understood and accepted. This is likely why Arista leverages it as an access point tunneling option.

Via VXLAN tunnels, the access network can achieve meaningful separation from the underlay network, provide predictable traffic paths and enable the steering of traffic into an administrator's choice of policy engine (Firewall, SASE, DPI node). The option brings back many of the pros of a controller based network, without additional equipment or siloed expertise. So how does it work, and what does a real world flow look like?

Focusing on the example above picture an organization that operates on the premise that all traffic must be brought to a centralized point and inspected. The AP can now act as the ingress point for the overlay negating the need to worry about VLAN tags and appropriate trunking policies to the access point. The user authenticates to an SSID, that SSID tunnels all traffic to a specified endpoint via VXLAN encapsulation, the packet is then de-encapsulated and routed accordingly. The underlay is none the wiser as it is only able to view the Layer 3 information within the outermost header for forwarding.

To establish this communication path the first order of business is to ensure layer 3 connectivity between the access point IP address and the desired termination device. This is achieved via BGP in this example. The core and border leaf peer via eBGP to share the appropriate subnets. So in this particular example the wireless clients live in 10.30.55.0/24, and the VTEP loopback for the EOS device is 10.109.0.1/32

Upon this basis, the tunnel is ready to be formed. Within the Arista wireless settings, specifically within the network section of the SSID a user can select a tunneling capability and configuration template. The configuration options are shown below.

On the terminating switch we need to call out the VLAN to VNI mapping and a flood list. The vxlan flood vtep learned data-plane command will take care of needing to map APs statically.

The simple configuration above will establish the VXLAN tunnel. The AP is now sending VXLAN encapsulated traffic, arriving on the CEOS interface and destined toward the VTEP IP 10.109.0.1

The cell phone mac address is also registering to the AP's VTEP in the address table.

The wireless client's gateway lives on the VXLAN terminating switch and then follows the default route to the Palo Alto unit to be inspected and forwarded accordingly. The final flow is depicted in the diagram below.

So we have come full circle and again ask what does this solve? With VXLAN at the AP an administrator can now tunnel across an arbitrary underlay to anywhere as long as a layer 3 path exists and MTU allocations permit. The wireless network can maintain operation as an overlay architecture, without reliance on proprietary tunneling methods. Also, with an Arista switch as the concentration point, you inherit all the capability of that unit, some of which may not have been available in dedicated wireless controllers, such as advanced routing and scale.