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).
Status in source: current.
Names: cLMobilityExtAnchorTable
Technical details
{
"smi_kind": "OBJECT-TYPE",
"definition": [
"cLMobilityExtAnchorTable",
"OBJECT-TYPE",
"SYNTAX",
"SEQUENCE",
"OF",
"CLMobilityExtAnchorEntry",
"MAX-ACCESS",
"not-accessible",
"STATUS",
"current",
"DESCRIPTION",
"\"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).\"",
"::=",
"{",
"ciscoLwappMobilityExtTableObjects",
"4",
"}"
],
"syntax_tree": [
[
"conceptualTable",
[
"row",
"CLMobilityExtAnchorEntry"
]
],
null,
[
"MaxAccessPart",
"not-accessible"
],
[
"Status",
"current"
],
[
"DESCRIPTION",
"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)."
],
null,
null,
null,
null
]
}- Cisco
· Publisher's source file
· Archived source file
Source location: CISCO-LWAPP-MOBILITY-EXT-MIB::cLMobilityExtAnchorTable.Source version and references
Downloaded: 2026-10-19T00:18:11.696854+00:00. SHA-256:
d12132b9278e9ba2f7c374139d73a75648a61e04c2a7e9d63085df9b1a78f6cb{'kind': 'OBJECT-TYPE', 'details': {'module': 'CISCO-LWAPP-MOBILITY-EXT-MIB', 'imports': {'CISCO-SMI': ['ciscoMgmt'], 'SNMPv2-TC': ['TEXTUAL-CONVENTION', 'MacAddress', 'DateAndTime', 'TruthValue', 'RowStatus', 'StorageType'], 'SNMPv2-SMI': ['MODULE-IDENTITY', 'OBJECT-TYPE', 'NOTIFICATION-TYPE', 'Unsigned32', 'Counter32', 'Counter64'], 'SNMPv2-CONF': ['MODULE-COMPLIANCE', 'OBJECT-GROUP', 'NOTIFICATION-GROUP'], 'Q-BRIDGE-MIB': ['VlanIndex'], 'INET-ADDRESS-MIB': ['InetAddressType', 'InetAddress'], 'CISCO-QOS-PIB-MIB': ['Dscp'], 'SNMP-FRAMEWORK-MIB': ['SnmpAdminString'], 'CISCO-LWAPP-WLAN-MIB': ['cLWlanIndex', 'cLWlanProfileName'], 'CISCO-LWAPP-WLAN-POLICY-MIB': ['cLWlanWlanPolicyName']}, 'smi_kind': 'OBJECT-TYPE', 'definition': 'cLMobilityExtAnchorTable OBJECT-TYPE\n SYNTAX SEQUENCE OF CLMobilityExtAnchorEntry \n MAX-ACCESS not-accessible\n STATUS current\n DESCRIPTION\n "This table contains the information about the\n 802.11 LWAPP Mobility Anchors on individual WLANs.\n\n +...............+\n + +\n + ROUTER +\n + 10.16.1.1 +\n +...............+\n ..\n . .\n . .\n . .\n . .\n . .\n 10.16.109.112 10.16.105.39\n +......+ <<-------->> +......+\n + + [3]CC2 tunnels + +\n + CC1 + MN1\'s traffic + CC2 +\n + + to Anchor CC1 + +\n +......+ using EoIP +......+\n . .\n . Anchor Foreign .\n . .\n +......+ +......+\n + + + +\n + AP1 + + AP2 +\n + + + +\n +......+ +......+\n WLAN \'1\' . ^ WLAN \'1\'\n . |\n . [2] associates |\n . with AP2/CC2 |\n . |\n +......+ [1] +......+\n + + moves to region + +\n + MN1 + ---------->>> + MN1 +\n + + serviced by AP2 + +\n +......+ +......+\n 10.16.109.199 10.16.109.199\n\n In the above diagram, Central Controllers CC1 and CC2 have\n been configured in a Mobility Group.\n\n Currently the Mobile Node \'MN1\' obtains its IP from the\n Central Controller \'CC1\' with which it first associates\n via WLAN \'1\' through Access Point \'AP1\'. \'CC1\'\n obtains DHCP address, say 10.16.109.199 for client \'MN1\'.\n Now the client \'MN1\' is identified by 10.16.109.199 for\n further communication with the network and the\n communication happens via \'CC1\'.\n\n Since, \'CC1\' and \'CC2\' are in same mobility group, \'CC1\'\n sends the authentication block of \'MN1\' to \'CC2\'.\n\n\n Central Controller \'CC2\' has an associated Access Point\n \'AP2\' which beams WLAN \'1\' and uses 10.16.105.0 /\n 255.255.255.0 subnet instead.\n\n Next, the Mobile Node \'MN1\' moves out of range of \'AP1\'\n and gets in to proximity with \'AP2\' and continues to use\n WLAN \'1\'. \'CC2\' locally authenticates \'MN1\' against\n authentication block shared from \'CC1\'. \'CC2\' forwards all\n traffic from \'MN1\' to router. This is called WLAN mobility.\n\n But hold on, \'CC2\' uses 10.16.105.0 / 255.255.255.0 subnet\n for WLAN \'1\'. So we have two problems here :\n\n a> Traffic of 10.16.109.0 / 255.255.255.0 subnet has to be\n accessible from 10.16.105.0 / 255.255.255.0 subnet.\n\n b> Unneccessary overloading of 10.16.105.0 / 255.255.255.0\n subnet by traffic from 10.16.109.0 / 255.255.255.0 subnet.\n\n How do we address these issues ??\n\n If an EoIP tunnel can be established between \'CC1\' and \'CC2\'\n and \'CC1\' sends all traffic bound to \'MN1\', 10.16.109.199,\n on this tunnel to \'CC2\', which in turn forwards it to \'MN1\',\n then, above two subnet-problems are resolved. This is called\n Mobility Anchoring. \'CC1\' is the Mobility Anchor and \'CC2\' is\n the \'Foreign\' for WLAN \'1\'.\n\n As per the configuration, user creates a Mobility Anchor entry\n in \'CC2\' for WLAN \'1\' with IP address as \'CC1\', i.e.\n 10.16.109.112. So, when \'MN1\' connects to WLAN \'1\' via\n \'AP2\', then \'CC2\' establishes EoIP tunnel with 10.16.109.112\n and forwards the packets to \'MN1\'.\n\n Given the above example, the cLMobilityAnchorEntry on \'CC2\'\n looks like :\n\n ------------------------------------------------------------------\n | MIB - ATTRIBUTES | ROW#1 | ROW#2 |\n ------------------------------------------------------------------\n | cLWlanIndex | 1 | |\n ------------------------------------------------------------------\n | cLMobilityExtAnchorAssociatedMCAddressType | ipv4 | |\n ------------------------------------------------------------------\n | cLMobilityExtAnchorAssociatedMCAddress | 10.16.109.112 | |\n ------------------------------------------------------------------\n | cLMobilityExtAnchorStatus | up(4) | |\n ------------------------------------------------------------------\n | cLMobilityExtAnchorRowStatus | active(1) | |\n ------------------------------------------------------------------\n\n This feature has advantages for both security and load\n balancing. It can be used to restrict a WLAN to a single\n subnet, regardless of the MN\'s entry point into the network.\n A \'public\' or guest WLAN can thus be accessed throughout an\n enterprise, but still is restricted to a specific subnet.\n It can also be used to provide some geographic load balancing,\n since the WLANs can represent a particular section of a\n building (ie., engineering, marketing). Those groups can be\n \'anchored\' on a particular subnet/switch rather than on the\n CC of first occurrence (ie., the switch controlling the APs\n by the front door)."\n ::= { ciscoLwappMobilityExtTableObjects 4 }', 'syntax_tree': [['conceptualTable', ['row', 'CLMobilityExtAnchorEntry']], None, ['MaxAccessPart', 'not-accessible'], ['Status', 'current'], ['DESCRIPTION', "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)."], None, None, None, None], 'source_encoding': 'utf-8-sig'}, 'parser_version': 'mib-4'}