CISCO-LWAPP-MOBILITY-MIB Table View

This table represents 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 +
+      +                  +      +
+......+                  +......+
'typhoon'   .                      ^'typhoon'
.                          |
.           [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 'typhoon' 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 'typhoon' 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 'typhoon'. '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 'typhoon'. 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> Unnecessary 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 'typhoon'.
          
As per the configuration, user creates a MobilityAnchor entry
in 'CC2' for WLAN 'typhoon' with IP address as 'CC1', i.e.
10.16.109.112. So, when 'MN1' connects to WLAN 'typhoon' 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  |
---------------------------------------------------------------
| cLMobilityAnchorWlanProfileName |     typhoon     |         |
---------------------------------------------------------------
| cLMobilityAnchorSwitchIPAddress |   10.16.109.112 |         |
---------------------------------------------------------------
| cLMobilityAnchorStatus          |       up(4)     |         |
---------------------------------------------------------------
| cLMobilityAnchorRowStatus       |    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 (i.e., engineering, marketing).  Those groups can be
'anchored' on a particular subnet/switch rather than on the
CC of first occurrence (i.e., the switch controlling the APs
by the front door).

This table is used to configure multicast group
IP address per mobility group. Entries are added to the
table when configuring multicast group IP address per
mobility group.

This table represents the MWAR List (statically configured
members of the mobility group). Entries are added to the
table when configuring mobility group members.

This table is used to create mappings of the foreign
controller with the interface/interface group to be used,
when clients are directly connected to the foreign
controller send the DHCP request to the anchor
controller.

This object represents the MWAR List (statically configured
members of the mobility group).Entries are created to the table
when configuring mobility group members.