CISCO-LWAPP-MOBILITY-MIB
AI MIB Summary
The CISCO-LWAPP-MOBILITY-MIB monitors and manages 802.11 WLAN mobility states, mobility group configurations, and mobility anchor assignments on Cisco Central Controllers terminating Light Weight Access Point Protocol (LWAPP) tunnels. It provides visibility into the encapsulation of 802.11 frames from Access Points to the controller and tracks Mobile Node roaming authentication across multiple controllers within a defined mobility group.
This MIB is intended to be implemented on all those devices operating as Central Controllers (CC) that
terminate the Light Weight Access Point Protocol
tunnel from Light-weight LWAPP Access Points.
This MIB provides configuration and status information
about the 802.11 WLAN mobility.
The relationship between CC and the LWAPP APs
can be depicted as follows:
+......+ +......+ +......+ +......+
+ + + + + + + +
+ CC + + CC + + CC + + CC +
+ + + + + + + +
+......+ +......+ +......+ +......+
.. . . .
.. . . .
. . . . .
. . . . .
. . . . .
. . . . .
+......+ +......+ +......+ +......+
+......+
+ + + + + + + + +
+
+ AP + + AP + + AP + + AP + + AP
+
+ + + + + + + + +
+
+......+ +......+ +......+ +......+
+......+
. . . .
. . . . .
. . . . .
. . . . .
. . . . .
+......+ +......+ +......+ +......+
+......+
+ + + + + + + + +
+
+ MN + + MN + + MN + + MN + + MN
+
+ + + + + + + + +
+
+......+ +......+ +......+ +......+
+......+
The LWAPP tunnel exists between the controller and
the APs. The MNs communicate with the APs through
the protocol defined by the 802.11 standard.
LWAPP APs, upon bootup, discover and join one of the
controllers and the controller pushes the configuration,
that includes the WLAN parameters, to the LWAPP APs.
The APs then encapsulate all the 802.11 frames from
wireless clients inside LWAPP frames and forward
the LWAPP frames to the controller.
GLOSSARY
Access Point ( AP )
An entity that contains an 802.11 medium access
control ( MAC ) and physical layer ( PHY ) interface
and provides access to the distribution services via
the wireless medium for associated clients.
LWAPP APs encapsulate all the 802.11 frames in
LWAPP frames and sends it to the controller to which
it is logically connected.
Basic Service Set Identifier (BSSID)
The identifier for the service set comprising of
all the 802.11 stations under the control of
one coordinating Access Point. This identifier
happens to be the MAC address of the dot11 radio
interface of the Access Point. The wireless
clients that associate with the Access Point
get the wired uplink through this particular
dot11 interface.
Central Controller ( CC )
The central entity that terminates the LWAPP protocol
tunnel from the LWAPP APs. Throughout this MIB,
this entity also referred to as 'controller'.
Light Weight Access Point Protocol ( LWAPP )
This is a generic protocol that defines the
communication between the Access Points and the
Central Controller.
Mobile Node ( MN )
A roaming 802.11 wireless device in a wireless
network associated with an access point.
Mobility
Concept by which a Mobile Node can roam from one
Access Point to another Access Point, across multiple
Central Controllers, without need for repeated
authentication.
Mobility Group
A set of Central Controllers which exchange Mobile
Node's authentication information, so that the Mobile
Node upon roaming need not re-authenticate.
Mobility Anchor
When a Central Controller in the Mobility Group is
designated as Mobility Anchor, then all the Mobile
Node's traffic is tunnelled to it by other
Controllers in the Mobility Group.
Guest Tunneling (GT)
The concept of designating a Central Controller in
the Mobility Group as Mobility Anchor, so that all
the Mobile Node's traffic is tunnelled to it by other
Controllers in the Mobility Group.
Station Management (SMT)
This term refers to the internal management of the
802.11 protocol operations by the AP to work
cooperatively with the other APs and 802.11
devices in the network.
Ethernet over Internet Protocol (EoIP)
Ethernet over IP (EoIP) is a protocol that creates
an Ethernet tunnel between two routers on top of an
IP connection. The EoIP interface appears as an
Ethernet interface.
Reverse path filtering (RPF)
Reverse path filtering (RPF) is a feature provided
by most modern Internet Protocol routers, which may
be used to reduce the risk of customers attacking
other internet hosts. One of the problems network
service providers face today is hackers generating
packets with fake source IP addresses, a technique
known as spoofing. This is often done in order to
initiate a denial-of-service attack against another
internet host or network.
Since the source IP addresses of the incoming packets
change, often randomly, and for every packet, the
target of such an attack can't easily filter out the
attacking packets. However, the source of the attack,
i.e. the network service provider of the attacking
host, has a simple way to stop such packets from ever
leaving its network. A router always knows which
networks are reachable via any of its interfaces.
By checking the source IP address of all packets
coming in via an interface against the networks known
to be behind that interface, the router can simply
drop packets that aren't supposed to come from there.
Hence, reverse path filtering filters packets
according to the 'reverse path' to their source
address. If the path back to the source address
does not match the path the packet is coming from,
it is dropped.
REFERENCE
[1] Part 11 Wireless LAN Medium Access Control ( MAC )
and Physical Layer ( PHY ) Specifications.
[2] Draft-obara-capwap-lwapp-00.txt, IETF Light
Weight Access Point Protocol.
Main OID:
ciscoLwappMobilityMIB.1.3.6.1.4.1.9.9.576
46
Objects
Active
Status
6
Dependencies
Imported Objects
Objects
46 total| Object Name |
|---|
ciscoLwappMobilityMIBThis MIB is intended to be implemented on all those
devices operating as Central Controllers (CC) that
terminate the Light Weight Access Point Protocol
tunnel from Light-weight LWAPP Access Points.
This MIB provides configuration and status information
about the 802.11 WLAN mobility.
The relationship between CC and the LWAPP APs
can be depicted as follows:
+......+ +......+ +......+ +......+
+ + + + + + + +
+ CC + + CC + + CC + + CC +
+ + + + + + + +
+......+ +......+ +......+ +......+
.. . . .
.. . . .
. . . . .
. . . . .
. . . . .
. . . . .
+......+ +......+ +......+ +......+
+......+
+ + + + + + + + +
+
+ AP + + AP + + AP + + AP + + AP
+
+ + + + + + + + +
+
+......+ +......+ +......+ +......+
+......+
. . . .
. . . . .
. . . . .
. . . . .
. . . . .
+......+ +......+ +......+ +......+
+......+
+ + + + + + + + +
+
+ MN + + MN + + MN + + MN + + MN
+
+ + + + + + + + +
+
+......+ +......+ +......+ +......+
+......+
The LWAPP tunnel exists between the controller and
the APs. The MNs communicate with the APs through
the protocol defined by the 802.11 standard.
LWAPP APs, upon bootup, discover and join one of the
controllers and the controller pushes the configuration,
that includes the WLAN parameters, to the LWAPP APs.
The APs then encapsulate all the 802.11 frames from
wireless clients inside LWAPP frames and forward
the LWAPP frames to the controller.
GLOSSARY
Access Point ( AP )
An entity that contains an 802.11 medium access
control ( MAC ) and physical layer ( PHY ) interface
and provides access to the distribution services via
the wireless medium for associated clients.
LWAPP APs encapsulate all the 802.11 frames in
LWAPP frames and sends it to the controller to which
it is logically connected.
Basic Service Set Identifier (BSSID)
The identifier for the service set comprising of
all the 802.11 stations under the control of
one coordinating Access Point. This identifier
happens to be the MAC address of the dot11 radio
interface of the Access Point. The wireless
clients that associate with the Access Point
get the wired uplink through this particular
dot11 interface.
Central Controller ( CC )
The central entity that terminates the LWAPP protocol
tunnel from the LWAPP APs. Throughout this MIB,
this entity also referred to as 'controller'.
Light Weight Access Point Protocol ( LWAPP )
This is a generic protocol that defines the
communication between the Access Points and the
Central Controller.
Mobile Node ( MN )
A roaming 802.11 wireless device in a wireless
network associated with an access point.
Mobility
Concept by which a Mobile Node can roam from one
Access Point to another Access Point, across multiple
Central Controllers, without need for repeated
authentication.
Mobility Group
A set of Central Controllers which exchange Mobile
Node's authentication information, so that the Mobile
Node upon roaming need not re-authenticate.
Mobility Anchor
When a Central Controller in the Mobility Group is
designated as Mobility Anchor, then all the Mobile
Node's traffic is tunnelled to it by other
Controllers in the Mobility Group.
Guest Tunneling (GT)
The concept of designating a Central Controller in
the Mobility Group as Mobility Anchor, so that all
the Mobile Node's traffic is tunnelled to it by other
Controllers in the Mobility Group.
Station Management (SMT)
This term refers to the internal management of the
802.11 protocol operations by the AP to work
cooperatively with the other APs and 802.11
devices in the network.
Ethernet over Internet Protocol (EoIP)
Ethernet over IP (EoIP) is a protocol that creates
an Ethernet tunnel between two routers on top of an
IP connection. The EoIP interface appears as an
Ethernet interface.
Reverse path filtering (RPF)
Reverse path filtering (RPF) is a feature provided
by most modern Internet Protocol routers, which may
be used to reduce the risk of customers attacking
other internet hosts. One of the problems network
service providers face today is hackers generating
packets with fake source IP addresses, a technique
known as spoofing. This is often done in order to
initiate a denial-of-service attack against another
internet host or network.
Since the source IP addresses of the incoming packets
change, often randomly, and for every packet, the
target of such an attack can't easily filter out the
attacking packets. However, the source of the attack,
i.e. the network service provider of the attacking
host, has a simple way to stop such packets from ever
leaving its network. A router always knows which
networks are reachable via any of its interfaces.
By checking the source IP address of all packets
coming in via an interface against the networks known
to be behind that interface, the router can simply
drop packets that aren't supposed to come from there.
Hence, reverse path filtering filters packets
according to the 'reverse path' to their source
address. If the path back to the source address
does not match the path the packet is coming from,
it is dropped.
REFERENCE
[1] Part 11 Wireless LAN Medium Access Control ( MAC )
and Physical Layer ( PHY ) Specifications.
[2] Draft-obara-capwap-lwapp-00.txt, IETF Light
Weight Access Point Protocol. MODULE-IDENTITY .1.3.6.1.4.1.9.9.576 |
ciscoLwappMobilityMIBNotifs OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.576.0 |
ciscoLwappMobilityAnchorControlPathDownThis trap will be declared by the Controller when,
successive ICMP ping attempts to the anchor fails
and the anchor is conclusively down.
Variable cLMobilityAnchorIPAddress denotes the
IP Address of the anchor. NOTIFICATION-TYPE .1.3.6.1.4.1.9.9.576.0.1 |
ciscoLwappMobilityAnchorControlPathUpThis trap will be declared by the Controller when,
ICMP ping to the anchor is restored and anchor is
conclusively up.
Variable cLMobilityAnchorIPAddress denotes the
IP Address of the anchor. NOTIFICATION-TYPE .1.3.6.1.4.1.9.9.576.0.2 |
ciscoLwappMobilityAnchorDataPathDownThis trap will be declared by the Controller when,
successive EoIP ping attempts to the anchor fails
and the anchor is conclusively down.
Variable cLMobilityAnchorIPAddress denotes the
IP Address of the anchor. NOTIFICATION-TYPE .1.3.6.1.4.1.9.9.576.0.3 |
ciscoLwappMobilityAnchorDataPathUpThis trap will be declared by the Controller when,
EoIP ping to the anchor is restored and anchor is
conclusively up.
Variable cLMobilityAnchorIPAddress denotes the
IP Address of the anchor. NOTIFICATION-TYPE .1.3.6.1.4.1.9.9.576.0.4 |
ciscoLwappMobilityAllAnchorsOnWlanDownThis trap will be declared by the Controller when,
successive EoIP ping attempts to all the anchors on
WLAN, denoted by cLMobilityAnchorWlanId, fails and
all the anchors are conclusively down. NOTIFICATION-TYPE .1.3.6.1.4.1.9.9.576.0.5 |
ciscoLwappMobilityOneAnchorOnWlanUpThis trap will be declared by the Controller when,
successive EoIP and UDP ping to atleast one anchor
on the WLAN, denoted by cLMobilityAnchorWlanId, is
restored and anchor is conclusively up. NOTIFICATION-TYPE .1.3.6.1.4.1.9.9.576.0.6 |
ciscoLwappMobilityMIBObjects OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.576.1 |
cLMobilityAnchorTableThis 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). SEQUENCE OF CLMobilityAnchorEntry .1.3.6.1.4.1.9.9.576.1.1 |
cLMobilityAnchorEntryEach entry in this table provides information about
one 802.11 LWAPP Mobility Anchor configured on a WLAN
on this controller. CLMobilityAnchorEntry .1.3.6.1.4.1.9.9.576.1.1.1 |
cLMobilityAnchorWlanSsidLocal wlan-ssid to connect to Guest/Anchor switch DisplayString .1.3.6.1.4.1.9.9.576.1.1.1.1 |
cLMobilityAnchorSwitchAddressTypeGuest/Anchor switch Address type. InetAddressType (INET-ADDRESS-MIB) .1.3.6.1.4.1.9.9.576.1.1.1.2 |
cLMobilityAnchorSwitchAddressGuest/Anchor switch Address.
The IP Address is limited to IPv4 and IPv6. InetAddress (INET-ADDRESS-MIB) .1.3.6.1.4.1.9.9.576.1.1.1.3 |
cLMobilityAnchorStatusOperational and Connectivity status of the
Mobility Anchor.
controlpath:
When bit is '0', this means successive
ICMP pings to the anchor have failed.
When is '1', this means anchor is
reachable and responding to ICMP pings.
datapath:
When bit is '0', this means successive
EoIP pings to the anchor have failed.
When bit is '1', this means anchor is
reachable and responding to EoIP pings.ro Bits .1.3.6.1.4.1.9.9.576.1.1.1.4 |
cLMobilityAnchorRowStatusRow Statusrw RowStatus (SNMPv2-TC) .1.3.6.1.4.1.9.9.576.1.1.1.5 |
cLMobilityAnchorGlobalDot11Config OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.576.1.2 |
cLMobilityAnchorGroupKeepAliveNumberThis parameter determines how many successive
ping attempts to the anchor should fail before
the anchor is declared DOWN.rw Integer32 .1.3.6.1.4.1.9.9.576.1.2.1 |
cLMobilityAnchorGroupKeepAliveIntervalThis parameter determines the time interval
(in seconds) between two consecutive ping attempts
to an anchor.rw Integer32 .1.3.6.1.4.1.9.9.576.1.2.2 |
cLMobilityAnchorSmtStatusThis object allows user to enable or disable
Symmetric mobility tunneling for the controller.
The controller provides inter-subnet mobility
for clients roaming from one AP to another within
a Wireless LAN. This mobility is asymmetric in
nature where the client traffic to the wired
network is routed out directly via the 'foreign'
controller. See the diagram above. This mechanism
breaks when an upstream router has RPF enabled.
In this case the client traffic will be dropped
at the router because the RPF check ensures that
the path back to the source address matches the
path the packet is coming from.
This attribute is aimed at addressing this issue.
It will allow enabling 'Symmetric Mobility
Tunneling' or 'Bi-directional Tunneling'
for mobile clients such that all the client
traffic is sent to the 'anchor' controller and
go successfully through RPF check.
When set to 'true', Symmetric Mobility Tunneling
will be enabled on the Controller on next reset.
When set to 'false', Symmetric Mobility Tunneling
will be disabled on the Controller on next reset.
After setting this attribute to the desired value,
user should reset the Controller for the change to
take effect.rw TruthValue (SNMPv2-TC) .1.3.6.1.4.1.9.9.576.1.2.3 |
cLMobilityAnchorCurrentSmtThis object represents the current state of
Symmetric mobility tunneling for the controller.
When value is 'true', this means Symmetric Mobility
Tunneling is currently enabled on the Controller.
When value is 'false', this means Symmetric Mobility
Tunneling is currently disabled on the Controller.ro TruthValue (SNMPv2-TC) .1.3.6.1.4.1.9.9.576.1.2.4 |
cLMobilityTrapVariables OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.576.1.3 |
cLMobilityAnchorWlanIdThis object uniquely identifies one instance of
a WLAN on the controller.ro Unsigned32 .1.3.6.1.4.1.9.9.576.1.3.1 |
cLMobilityAnchorAddressTypeGuest/Anchor switch Address type.ro InetAddressType (INET-ADDRESS-MIB) .1.3.6.1.4.1.9.9.576.1.3.2 |
cLMobilityAnchorAddressGuest/Anchor switch Address.
The IP Address is limited to IPv4 and IPv6ro InetAddress (INET-ADDRESS-MIB) .1.3.6.1.4.1.9.9.576.1.3.3 |
cLMobilityMulticastGroupConfig OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.576.1.4 |
cLMobilityMulticastMessagingEnableThis object specifies whether the mobility multicast
messaging feature is enabled or disabled on the controller.
A value of 'true' enables the multicast messaging among the
mobility group memebers and 'false' disables the multicast
messaging and uses unicast messaging.rw TruthValue (SNMPv2-TC) .1.3.6.1.4.1.9.9.576.1.4.1 |
cLMobilityMulticastGroupTableThis 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. SEQUENCE OF CLMobilityMulticastGroupEntry .1.3.6.1.4.1.9.9.576.1.4.2 |
cLMobilityMulticastGroupEntryEach entry in this table provides information about
multicast group IP address per mobility group. CLMobilityMulticastGroupEntry .1.3.6.1.4.1.9.9.576.1.4.2.1 |
cLMobilityGroupMacAddressThis object represents the mobility group name present on the controller. MacAddress (SNMPv2-TC) .1.3.6.1.4.1.9.9.576.1.4.2.1.1 |
cLMobilityMulticastGroupIPAddressThis object represnts the multicast
group IP address.The Ip address is limited to ipv4 and ipv6.rw InetAddress (INET-ADDRESS-MIB) .1.3.6.1.4.1.9.9.576.1.4.2.1.2 |
cLMobilityMulticastGroupIPAddressTypeThis used represents the multicast
group IP address type.The Ip address is limited to ipv4 and
ipv6.rw InetAddressType (INET-ADDRESS-MIB) .1.3.6.1.4.1.9.9.576.1.4.2.1.3 |
cLMobilityGroupMembersTableThis object represents the MWAR List (statically configured
members of the mobility group).Entries are added to the table
when configuring mobility group members. SEQUENCE OF CLMobilityGroupMembersEntry .1.3.6.1.4.1.9.9.576.1.5 |
cLMobilityGroupMembersEntryThis object represents an Entry (conceptual row) in the
cLMobilityGroupMembers table. CLMobilityGroupMembersEntry .1.3.6.1.4.1.9.9.576.1.5.1 |
cLMobilityGroupMemberIPAddressTypeThis object represents the IP Address type of the mobility
member
IP Address represented by cLMobilityGroupMemberIPAddress. The Ip
address is limited to ipv4 and ipv6.ro InetAddressType (INET-ADDRESS-MIB) .1.3.6.1.4.1.9.9.576.1.5.1.1 |
cLMobilityGroupMemberIPAddressThis object represents the IP Address of the mobility member
corresponding to cLMobilityGroupMacAddress.The Ip address is
limited to ipv4 and ipv6.ro InetAddress (INET-ADDRESS-MIB) .1.3.6.1.4.1.9.9.576.1.5.1.2 |
cLMobilityGroupMemberControlPathStatusUpThis object represents the control path status of the mobility member
corresponding to cLMobilityGroupMacAddress.ro TruthValue (SNMPv2-TC) .1.3.6.1.4.1.9.9.576.1.5.1.3 |
cLMobilityGroupMemberDataPathStatusUpThis object represents the data path status of the mobility member
corresponding to cLMobilityGroupMacAddress.ro TruthValue (SNMPv2-TC) .1.3.6.1.4.1.9.9.576.1.5.1.4 |
cLMobilityForeignWlcMapTableThis table is used to create 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. SEQUENCE OF CLMobilityForeignWlcMapEntry .1.3.6.1.4.1.9.9.576.1.6 |
cLMobilityForeignWlcMapEntryThis represents a row in the cLMobilityForeignWlcIfMappingTable .
Entries are added and deleted by explicit user driven action. CLMobilityForeignWlcMapEntry .1.3.6.1.4.1.9.9.576.1.6.1 |
cLMobilityForeignWlcMapMacAddressThis object represents the MAC address of the foreign controller,
to which the interface mapping is to be configured. MacAddress (SNMPv2-TC) .1.3.6.1.4.1.9.9.576.1.6.1.1 |
cLMobilityForeignWlcMapIfThis object represents name of the interface/interface group
which would be used for the communication
with the clients connected to the foreign controller,
represented by cLMobilityForeignWlcMapMacAddress .rw SnmpAdminString (SNMP-FRAMEWORK-MIB) .1.3.6.1.4.1.9.9.576.1.6.1.2 |
cLMobilityForeignWlcMapRowStatusThis object represents the row status.rw RowStatus (SNMPv2-TC) .1.3.6.1.4.1.9.9.576.1.6.1.3 |
ciscoLwappMobilityMIBConform OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.576.2 |
ciscoLwappMobilityMIBCompliances OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.576.2.1 |
ciscoLwappMobilityMIBGroups OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.576.2.2 |