cLMobilityExtAnchorTable

This table contains the information about the
802.11 LWAPP Mobility Anchors on individual WLANs.
          
       +...............+
       +               +
       +    ROUTER     +
       +   10.16.1.1   +
       +...............+
              ..
            .    .
          .        .
        .            .
      .                .
    .                    .
10.16.109.112        10.16.105.39
+......+   <<-------->>   +......+
+      +  [3]CC2 tunnels  +      +
+  CC1 +   MN1's traffic  +  CC2 +
+      +   to Anchor CC1  +      +
+......+   using EoIP     +......+
   .                        .
   . Anchor        Foreign  .
   .                        .
+......+                  +......+
+      +                  +      +
+  AP1 +                  +  AP2 +
+      +                  +      +
+......+                  +......+
WLAN '1'   .                        ^   WLAN '1'
.                          |
.           [2] associates  |
.              with AP2/CC2  |
.                             |
+......+   [1]              +......+
+      +  moves to region   +      +
+  MN1 +  ---------->>>     +  MN1 +
+      +  serviced by AP2   +      +
+......+                    +......+
10.16.109.199               10.16.109.199
          
In the above diagram, Central Controllers CC1 and CC2 have
been configured in a Mobility Group.
          
Currently the Mobile Node 'MN1' obtains its IP from the
Central Controller 'CC1' with which it first associates
via WLAN '1' through Access Point 'AP1'. 'CC1'
obtains DHCP address, say 10.16.109.199 for client 'MN1'.
Now the client 'MN1' is identified by 10.16.109.199 for
further communication with the network and the
communication happens via 'CC1'.
          
Since, 'CC1' and 'CC2' are in same mobility group, 'CC1'
sends the authentication block of 'MN1' to 'CC2'.
          
          
Central Controller 'CC2' has an associated Access Point
'AP2' which beams WLAN '1' and uses 10.16.105.0 /
255.255.255.0 subnet instead.
          
Next, the Mobile Node 'MN1' moves out of range of 'AP1'
and gets in to proximity with 'AP2' and continues to use
WLAN '1'. 'CC2' locally authenticates 'MN1' against
authentication block shared from 'CC1'. 'CC2' forwards all
traffic from 'MN1' to router. This is called WLAN mobility.
          
But hold on, 'CC2' uses 10.16.105.0 / 255.255.255.0 subnet
for WLAN '1'. So we have two problems here :
          
a> Traffic of 10.16.109.0 / 255.255.255.0 subnet has to be
accessible from 10.16.105.0 / 255.255.255.0 subnet.
          
b> Unneccessary overloading of 10.16.105.0 / 255.255.255.0
subnet by traffic from 10.16.109.0 / 255.255.255.0 subnet.
          
How do we address these issues ??
          
If an EoIP tunnel can be established between 'CC1' and 'CC2'
and 'CC1' sends all traffic bound to 'MN1', 10.16.109.199,
on this tunnel to 'CC2', which in turn forwards it to 'MN1',
then, above two subnet-problems are resolved. This is called
Mobility Anchoring. 'CC1' is the Mobility Anchor and 'CC2' is
the 'Foreign' for WLAN '1'.
          
As per the configuration, user creates a Mobility Anchor entry
in 'CC2' for WLAN '1' with IP address as 'CC1', i.e.
10.16.109.112. So, when 'MN1' connects to WLAN '1' via
'AP2', then 'CC2' establishes EoIP tunnel with 10.16.109.112
and forwards the packets to 'MN1'.
          
Given the above example, the cLMobilityAnchorEntry on 'CC2'
looks like :
          
------------------------------------------------------------------
|      MIB - ATTRIBUTES           |       ROW#1        |  ROW#2  |
------------------------------------------------------------------
| cLWlanIndex                     |     1              |         |
------------------------------------------------------------------
| cLMobilityExtAnchorAssociatedMCAddressType |   ipv4    |       |
------------------------------------------------------------------
| cLMobilityExtAnchorAssociatedMCAddress | 10.16.109.112 |       |
------------------------------------------------------------------
| cLMobilityExtAnchorStatus          |        up(4)    |         |
------------------------------------------------------------------
| cLMobilityExtAnchorRowStatus       |    active(1)    |         |
------------------------------------------------------------------
          
This feature has advantages for both security and load
balancing.  It can be used to restrict a WLAN to a single
subnet, regardless of the MN's entry point into the network.
A 'public' or guest WLAN can thus be accessed throughout an
enterprise, but still is restricted to a specific subnet.
It can also be used to provide some geographic load balancing,
since the WLANs can represent a particular section of a
building (ie., engineering, marketing).  Those groups can be
'anchored' on a particular subnet/switch rather than on the
CC of first occurrence (ie., the switch controlling the APs
by the front door).

MIB

CISCO-LWAPP-MOBILITY-EXT-MIB

OID

.1.3.6.1.4.1.9.9.846.1.2.4

Type

table

Status

current

Parent

ciscoLwappMobilityExtTableObjects

Siblings

14

Children

1