L3
Mobility Implementation
With WS5100 version 3.0
·
Implementation Overview
·
Key Concept
·
Mobility Exchange Protocol : Peer
Configuration
·
Mobility Exchange Protocol : MU Database
·
L3 Mobility Exchange Messages
·
L3 /L2 Roam operation and data
forwarding
·
Test Network Diagram
·
Configuring L3 Mobility
·
Verify L3 Mobility
Implementation
Overview
-
Driving
Requirement:
In
large campuses / enterprises with a highly segmented network, provide the
ability for mobile units (MUs) to roam across Subnets (L3 boundaries) when
associated with Symbol Wireless Switches and retain their IP Address.
Deliver
QoS and Security as the devices move across Subnets
-
Layer 3 mobility is a mechanism which
enables a Mobile Unit (MU) to maintain the same Layer 3 address while roaming
throughout a multi-VLAN network.
This
enables transparent routing of IP datagrams to MUs during their movement, so
that data sessions can be initiated to them while they roam (in particular for
Voice applications).
Layer
3 mobility also enables TCP/UDP sessions to be maintained in spite of roaming
among different IP subnets.
-
Seamless roaming of MUs between wireless
switches on different Layer 3 subnets, while retaining the same IP address.
-
Static configuration of “Mobility Peer”
switches
-
Plans to automate the peer discovery
process in a future release.
This
solution does not require any changes to the MU. In comparison, other solutions
to this problem such as Mobile IP [RFC 3344] require special functionality
& software on the mobile unit.
This
creates numerous inter-working problems with working with MUs from different
vendors/ legacy devices which do not support this
Support
for a maximum of 15 mobility peers, with each switch handling up to a maximum
of 500 MUs.
A
full mesh of GRE tunnels would be established between the mobility peers.
Each
tunnel is between a pair of switches and would be capable of handling data
traffic for all MUs (for all VLANs) associated directly or indirectly (if the
switch is the HS and not the CS) with the MU.
Data
traffic for roamed MUs is tunneled between and the home and current switches by
encapsulating the entire L2 packet inside GRE with a proprietary code-point.
L2oGRE
was chosen instead of IPoGRE so that VLAN headers can be carried across the
tunnels to identify the VLAN of broadcast/multicast packets.
When
MUs roam within the same VLAN, the current behavior is retained by re-homing
the MU to the new switch so that extra hops are avoided while forwarding data
traffic
Mobile
units can be assigned IP addresses statically or dynamically.
The
forward and reverse data paths for traffic originating from and destined to MUs
that have roamed from one L3 subnet to another will be symmetric.
Key
Concepts (Terminology)
•
Mobility Domain:
–
A Mobility Domain comprises of a network
of Wireless Switches to which an MU can roam seamlessly without changing its IP
address.
–
The initial implementation will support
only a single mobility domain.
•
Home Switch (HS):
–
As soon as a MU enters a mobility domain
by associating with a switch, it is first assigned a “Home Switch”
–
The HS for a MU does not change for the
remainder of the MU’s stay in the mobility domain.
–
All data packets transmitted/received by
the MU including DHCP and ARP is tunneled through the HS.
–
The IP address for the MU is assigned
from the RON subnet of the HS.
•
Current Switch (CS):
–
The CS for the MU is the switch in the
mobility domain to which it is currently associated to and keeps changing as
the MU continues to roam between the different switches.
–
The CS is also responsible for
delivering data packets from the MU to its HS and vice-versa.
-
Mobility
Exchange protocol : Peer Configuration
•
Peer Configuration and Establishment
–
All Wireless Switches that support the
L3 mobility functionality peer with every other switch in the mobility domain
to exchange mobility related control plane information.
•
This includes the IP address, MAC
address, HS IP address, CS IP address and HS-VLAN-id of all the MUs in the
mobility-domain.
•
A consistent peer configuration
resulting in a full-mesh of peering sessions is required for L3 mobility to
work correctly.
–
Peering sessions use TCP as the
transport layer protocol to carry mobility update messages. Using TCP provides
the following advantages:
•
TCP retransmits lost messages thereby
providing reliable connectivity
•
TCP ensures in-order delivery of
messages using sequence numbers.
•
TCP has a built-in keep-alive mechanism
which helps detect loss of connectivity to the peer or peer failure.
–
In WS5100 v3.0, this feature will have
support only for static configuration of mobility peers with plans to automate
to automate the peer-discovery and establishment process in a future release.
•
Mobility Exchange Protocol : MU Database
•
MU-Database
–
The MU
database is a complete set of all MUs currently associated with switches in the
mobility domain.
–
Every switch
needs to be aware of all the MUs and their mobility-related parameters to
distinguish between new MUs entering the network and existing MUs roaming
within the mobility domain.
–
The mobility
related parameters include:
•
MU MAC address
•
MU IP-address
•
Home Switch IP
address
•
Current Switch
IP address
•
Home Switch
VLAN identifier
–
As soon as a
peering session is established between two switches, the initial data flow
involves the exchange of the full MU database.
•
The protocol
does not require periodic refresh of the entire MU database and only
incremental updates are sent as the database changes.
–
The MU
database within a switch consists of two distinct parts:
•
Home MU
Database (HMDB):
•
The set of MUs
for which this switch is the HS.
•
Foreign MU
Database (FMDB):
•
The set of MUs
for which we are not the HS.
•
These MUs are
learnt from other peers in the mobility domain via Mobility Exchange messages.
L3 Roam Operation and
Data Forwarding
•
The MU first associates with a wireless
switch in the mobility domain.
•
This switch becomes the “home switch”
(HS) for the MU.
•
The HS sends a JOIN message with MU’s
MAC-address, IP-address and HS-VLAN information to all its peers.
•
When the MU roams to a WS on a different
L3 subnet, this switch becomes the CS for the MU and sends out a L3-ROAM
message to the HS, which is then relayed out to all the peers.
•
The CS tunnels all data packets
(including DHCP and ARP) transmitted by the MU out to the HS, which then
decapsulates and forwards the packet as if the MU were local to the HS.
•
The MU thus continues to retain its IP
address in the HS-VLAN.
•
All packets destined to the MU are
tunneled back by the HS to the CS
The MU to MU disallow feature allows the RF Switch to block communications exchanged between clients associated to a WLAN.With the Motorola ...
Pre-Requisites: Requirements: The following requirements must be met prior to attempting this configuration: One (or more) RF Switc...
RADIUS Authentication Attributes: The RADIUS protocol follows client-server architecture and uses the User Datagram Protocol (UDP) as de...
LDAP Server can be used as the database with WS5100 radius server. This document provides the details of configuration need to done for WS5...
WS5100 login: cli User Access Verification Username: restore Password: restoreDefaultPassword WARNING:This will wipe out the con...
IPSec VPN offers the security and encryption features necessary to protect enterprise data, voice, and video traffic as it traverses public...
Components Used: The information in this document is based on the following hardware and software versions: · 1 x RFS4000 Swit...
The following section outlines the configuration steps required to configure 802.11i with 802.1X and pre-shared keys on a RF Switch: 1) ...
Snipe-IT is a free and open source, cross-platform, feature-rich IT asset management system built using a PHP framework called Laravel ...
RADIUS Authentication Attributes: The RADIUS protocol follows client-server architecture and uses the User Datagram Protocol (UDP) as de...
Use of ARP Cache in a network device Most of the network devices will have anARP cache; the content of the same will be a collection of IP...
Components Used: The information in this document is based on the following Motorola hardware and software versions: 1 x RFS6000 or ...
WS5100 login: cli User Access Verification Username: restore Password: restoreDefaultPassword WARNING:This will wipe out the con...
L3 Mobility Implementation With WS5100 version 3.0 · Implementation Overview · Key Concept · Mobility Excha...
Requirements: The following requirements must be met prior to attempting this configuration: One RFS4000 or RFS6000 WLAN Switch Contr...
Overview WiNG version 4.0 includes a rich suite of features which are included with each RF Switch at no additional charge as well as...
Components Used: The information in this document is based on the following hardware and software versions: · 1 x RFS4000 Swit...
Wireless filters can be applied to specific WLANs to grant or deny access to MUs based on individual or ranges of MAC addresses. Wireless f...