CopyrlghL 2012, Merakl, lnc.

!"#$%& ()*+,&)- .+&/"0

!"#$% ' ()"*+,-







Vers|on 1.0, Iu|y 2012 This document describes the requirements for layer 3 roaming within a
typical campus architecture, and explains how Merakis auto-tunneling
technology can facilitate seamless layer 3 roaming for turnkey mobility.















1 of 8

Copyright
2012 Meraki, Inc. All rights reserved.
Trademarks
Meraki is a registered trademark of Meraki, Inc.










www.meraki.com

660 Alabama St.
San Francisco, California 94110

Phone: +1 415 632 5800
Fax: +1 415 632 5899
Merakl SoluLlon Culde: Layer 3 8oamlng

2 of 8

1ab|e of Contents
1 What |s Layer 3 koam|ng? .............................................................................................................. 3
2 1yp|ca| Campus Arch|tecture .......................................................................................................... 4
3 Merak|'s Auto-1unne||ng 1echno|ogy .............................................................................................. S
4 Conf|gur|ng Merak| |n a L3 koam|ng Campus Arch|tecture .............................................................. 7
S 8enef|ts of Merak|'s Auto-1unne||ng 1echno|ogy ............................................................................ 8


Merakl SoluLlon Culde: Layer 3 8oamlng WhaL ls Layer 3 8oamlng?

3 of 8

1 WhaL ls Layer 3 8oamlng?
Large WLAN networks (for example, those found on large campuses)
may require IP session roaming at layer 3 to enable application and
session persistence while a mobile client roams across multiple VLANs.
For example, when a user on a VoIP call roams between APs on
different VLANs without layer 3 roaming, the users session will be
interrupted as the external server must re-establish communication with
the clients new IP address. During this time, a VoIP call will noticeably
drop for several seconds, providing a degraded user experience.

In smaller networks, it may be possible to configure a flat network by
placing all APs on the same VLAN. However, on large networks filled
with thousands of devices, configuring a flat architecture with a single
native VLAN may be an undesirable network topology from a best
practices perspective; it may also be challenging to configure legacy
setups to conform to this architecture. A turnkey solution designed to
enable seamless roaming across VLANs is therefore highly desirable
when configuring a complex campus topology. Using Merakis secure
auto-tunneling technology, layer 3 roaming can be enabled using a
Mobility Concentrator, allowing for bridging across multiple VLANs in a
seamless and scalable fashion.
Merakl SoluLlon Culde: Layer 3 8oamlng 1yplcal Campus ArchlLecLure

4 of 8

2 1yplcal Campus ArchlLecLure
Large campuses are often designed with a multi-VLAN architecture to
segment broadcast traffic. Typically, network best practices dictate a one
to one mapping of an IP subnet to a VLAN, e.g., client devices joining
VLAN 10 will be assigned an IP address out of the subnet range
10.0.10.0/24. In this design, clients in different VLANs will receive IP
addresses in different subnets via a DHCP server. Multi-VLAN
architectures can vary to include multiple subnets within a building (e.g.,
one for each floor/area), or multiple subnets across a large site (e.g., one
for each building/region in a large campus or enterprise environment).

As seen in the diagram below, the typical campus architecture has the
core L3 switch connected to multiple L3 distribution switches (one per
site), with each distribution switch then branching off to L2 access
switches configured on different VLANs. In this fashion, each site is
assigned a different VLAN to segregate traffic from different sites.
Without an L3 roaming service, a client connected to an L2 access
switch at Site A will not be able to seamlessly roam to a L2 access
switch connected to Site B. Upon associating with an AP on Site B, the
client would obtain a new IP address from DHCP service running on the
Site B scope. In addition, a particular route configuration or router NAT
may also prevent clients from roaming, even if they do retain their
original IP address.


Figure 1 Typical Campus Architecture
Merakl SoluLlon Culde: Layer 3 8oamlng Merakl's AuLo-1unnellng 1echnology

3 of 8

3 Merakl's AuLo-1unnellng 1echnology
With layer 3 roaming, a client device must have a consistent IP address
and subnet scope as it roams across multiple APs on different
VLANs/subnets. Merakis auto-tunnelling technology achieves this by
creating a persistent tunnel between the L3 enabled APs and the Mobility
Concentrator. Any client that is connected to a layer 3 roaming enabled
SSID is automatically bridged to the Meraki Mobility Concentrator. The
Mobility Concentrator acts as a focal point to which all client traffic will be
tunneled and anchored when the client moves between VLANs. In this
fashion, any communication data directed towards a client by third party
clients or servers will appear to originate at this central anchor.

Meraki supports two types of Mobility Concentrators: Meraki MX security
appliances and Meraki VMware concentrators. The network architecture
for both is similar and described below.
















Merakis Auto-Tunneling Process:

i. Meraki AP 1 and Meraki AP 2 are configured to create a seamless
mobility tunnel to the on-site Mobility Concentrator.

Figure 2 Merakis Auto-Tunneling Architecture
w/ Mobility Concentrator
Merakl SoluLlon Culde: Layer 3 8oamlng Merakl's AuLo-1unnellng 1echnology

6 of 8

ii. The client device associates to Meraki AP 1 (on VLAN 1) and begins a
wireless session. The client is now effectively part of VLAN 5.

iii. The wireless client receives an IP address from a DHCP server
configured to hand out IP addresses for VLAN 5.

iv. Ingress traffic destined for the client on the mobility VLAN is
encapsulated by the Mobility Concentrator and tunneled through the new
AP to the client.

v. The client device roams and associates to Meraki AP 2 (VLAN 2). At
this point, the new AP notifies the concentrator that the client has
physically changed APs configured in different VLANs.

vi. The Mobility Concentrator, acting as an anchor, tunnels all traffic
destined for the end client through VLAN 2 to allow the end client to
maintain the same mobility VLAN (VLAN 5).

vii. The device has now roamed between APs configured in different
VLANs successfully, with session persistence of the IP application.

The next step in understanding how to configure Merakis auto-tunneling
technology is to look at how it would be applicable in an actual campus
architecture environment.

Merakl SoluLlon Culde: Layer 3 8oamlng Conflgurlng Merakl for a Layer 3 8oamlng Campus

7 of 8

4 Conflgurlng Merakl for a Layer 3 8oamlng Campus




















Applying Merakis auto-tunneling technology to a campus architecture
allows administrators to enable layer 3 roaming with minimal
configuration. As described in the previous chapter, the steps involved
include (a) connecting a Meraki Mobility Concentrator to your core Layer
3 switch in bridge or NAT mode, (b) defining your mobility VLANs, and
ensuring that the necessary routes are in place between the Mobility
Concentrator and your APs. More detailed configuration instructions for
your APs and Mobility Concentrator are available at
http://docs.meraki.com.


Figure 3 Merakis Auto-Tunneling in a
Campus Architecture

Merakl SoluLlon Culde: Layer 3 8oamlng Merakl's AuLo-1unnellng 1echnology: 8eneflLs

8 of 8

3 Merakl's AuLo-1unnellng 1echnology: 8eneflLs
Merakis auto-tunneling architecture was chosen as the approach to
implement layer 3 roaming after a careful analysis of the various possible
options, including inter-AP tunneling. This architecture is the ideal
balance between an intuitive ease of deployment and a high degree of
scalability enabled by an optimized hardware appliance with the
necessary processing specifications. The benefits are outlined as
follows:

No throughput limitations. No capacity, processing or throughput
limitations - inter-AP tunneling will not scale to hundreds of users due to
throughput and CPU processing bottlenecks on a thin AP architecture.
The Mobility Concentrator offers the scalability and the performance
afforded by a hardware appliance, without the hassle of configuration
due to Merakis one-touch mobility tunneling technology.

Ease of configuration. In a mobility concentrator architecture, the only
configuration required is ensuring that the APs and concentrator can
route to each other pairwise. Merakis auto-tunneling technology will
handle the rest.

Horizontal scalability. If more than one MX is needed for scalability
reasons, have a single DHCP server serve all the MXs and make sure it
hands out the same IP address to the same client, even if it DHCPs from
a different MX.

Additional applications. MX security appliances are multi-purpose; they
can be used as a Mobility Concentrator for layer 3 roaming, VPN
concentrators for teleworker VPNs from thousands of sites, and site-to-
site VPN concentrators for sites with VPN requirements. In addition,
there are a number of additional features that can be enabled such as
content filtering, intrusion detection, and more.

High Availability. For high availability, you can have an MX in hot
standby. If the primary MX fails, you can redirect your APs to the hot-
standby MX. Meraki intends to provide automatic failover in a future
release.