CISCO-LWAPP-MOBILITY-EXT-MIB Table View

This table contains the information about the
802.11 LWAPP mobility Switch Peer Group (SPG).

This table contains the information about the
802.11 LWAPP mobility Switch Peer Group (SPG) members.

This table contains the information about the
802.11 LWAPP mobility group members.

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).

This table contains the information about the
802.11 LWAPP Mobility Controllers on this MO.

This table contains the information about the
802.11 LWAPP Mobility Clients on this MC.

This table contains the information about the
802.11 LWAPP Mobility Clients on this MO.

This table contains the information about the
802.11 LWAPP mobility AP Manager.

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

This table contains the information about the
mobility groups where clients from this MC can roam.

This table contains the information about the
802.11 LWAPP SPG peer members of this MA.

This table contains the information about the
MA statistics as reported by this MC.

This table contains the information about the
APs that are reported by this MC, its peer MCs and its MAs.

This table contains the information about the total number
of APs that are reported by this MC, its peer MCs and its MAs.

This table provides information about
one 802.11 LWAPP Mobility Anchor configured with a policy name
on this controller