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 +
+ + serviced by AP2 + +
+......+ +......+
10.16.109.199 10.16.109.199
In the above diagram, Central Controllers CC1 and CC2 have
been configure 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
furthure 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> 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 '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 |
| cLMobilityAnchorWlanSsid | 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 (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).
Parsed from file CISCO-LWAPP-MOBILITY-MIB.mib
Module: CISCO-LWAPP-MOBILITY-MIB
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 +
+ + serviced by AP2 + +
+......+ +......+
10.16.109.199 10.16.109.199
In the above diagram, Central Controllers CC1 and CC2 have
been configure 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
furthure 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> 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 '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 |
| cLMobilityAnchorWlanSsid | 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 (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 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 +
+ + serviced by AP2 + +
+......+ +......+
10.16.109.199 10.16.109.199
In the above diagram, Central Controllers CC1 and CC2 have
been configure 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
furthure 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> 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 '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 |
| cLMobilityAnchorWlanSsid | 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 (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).
Parsed from file CISCO-LWAPP-MOBILITY-MIB.my.txt
Company: None
Module: CISCO-LWAPP-MOBILITY-MIB
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 +
+ + serviced by AP2 + +
+......+ +......+
10.16.109.199 10.16.109.199
In the above diagram, Central Controllers CC1 and CC2 have
been configure 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
furthure 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> 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 '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 |
| cLMobilityAnchorWlanSsid | 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 (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).
cLMobilityAnchorTable OBJECT-TYPE SYNTAX SEQUENCE OF CLMobilityAnchorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "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 + + + serviced by AP2 + + +......+ +......+ 10.16.109.199 10.16.109.199 In the above diagram, Central Controllers CC1 and CC2 have been configure 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 furthure 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> 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 '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 | | cLMobilityAnchorWlanSsid | 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 (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). " ::= { ciscoLwappMobilityMIBObjects 1 }
cLMobilityAnchorTable OBJECT-TYPE SYNTAX SEQUENCE OF CLMobilityAnchorEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "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 + + + serviced by AP2 + + +......+ +......+ 10.16.109.199 10.16.109.199 In the above diagram, Central Controllers CC1 and CC2 have been configure 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 furthure 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> 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 '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 | | cLMobilityAnchorWlanSsid | 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 (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)." ::= { ciscoLwappMobilityMIBObjects 1 }
Vendor: Cisco
Module: CISCO-LWAPP-MOBILITY-MIB
[Automatically extracted from oidview.com]
cLMobilityAnchorTable OBJECT-TYPE SYNTAX SEQUENCE OF CLMobilityAnchorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "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 + + + serviced by AP2 + + +......+ +......+ 10.16.109.199 10.16.109.199 In the above diagram, Central Controllers CC1 and CC2 have been configure 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 furthure 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> 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 '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 | | cLMobilityAnchorWlanSsid | 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 (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). " ::= { ciscoLwappMobilityMIBObjects 1 }
cLMobilityAnchorTable OBJECT-TYPE SYNTAX SEQUENCE OF CLMobilityAnchorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "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 + + + serviced by AP2 + + +......+ +......+ 10.16.109.199 10.16.109.199 In the above diagram, Central Controllers CC1 and CC2 have been configure 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 furthure 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> 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 '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 | | cLMobilityAnchorWlanSsid | 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 (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)." ::= { ciscoLwappMobilityMIBObjects 1 }
| OID | Name | Sub children | Sub Nodes Total | Description |
|---|---|---|---|---|
| 1.3.6.1.4.1.9.9.576.1.1.1 | cLMobilityAnchorEntry | 5 | 5 | Each entry in this table provides information about one 802.11 LWAPP Mobility Anchor configured on a WLAN on this controller. |
| OID | Name | Sub children | Sub Nodes Total | Description |
|---|---|---|---|---|
| 1.3.6.1.4.1.9.9.576.1.2 | cLMobilityAnchorGlobalDot11Config | 4 | 8 | None |
| 1.3.6.1.4.1.9.9.576.1.3 | cLMobilityTrapVariables | 3 | 6 | None |
| 1.3.6.1.4.1.9.9.576.1.4 | cLMobilityMulticastGroupConfig | 2 | 6 | None |
| 1.3.6.1.4.1.9.9.576.1.5 | cLMobilityGroupMembersTable | 1 | 5 | This object represents the MWAR List (statically configured members of the mobility group).Entries are added to the table when co… |
| 1.3.6.1.4.1.9.9.576.1.6 | cLMobilityForeignWlcMapTable | 1 | 4 | This table is used to create mappings of the foreign controller With the interface/interface group to be used, when clients Direc… |