CISCO-LWAPP-MOBILITY-MIB

File: CISCO-LWAPP-MOBILITY-MIB.mib (40220 bytes)

Imported modules

SNMPv2-SMI SNMPv2-CONF SNMPv2-TC
INET-ADDRESS-MIB SNMP-FRAMEWORK-MIB CISCO-SMI

Imported symbols

MODULE-IDENTITY OBJECT-TYPE NOTIFICATION-TYPE
Unsigned32 Integer32 MODULE-COMPLIANCE
OBJECT-GROUP NOTIFICATION-GROUP DisplayString
TruthValue RowStatus MacAddress
InetAddressType InetAddress SnmpAdminString
ciscoMgmt

Defined Types

CLMobilityAnchorEntry  
SEQUENCE    
  cLMobilityAnchorWlanSsid DisplayString
  cLMobilityAnchorSwitchAddressType InetAddressType
  cLMobilityAnchorSwitchAddress InetAddress
  cLMobilityAnchorStatus BITS
  cLMobilityAnchorRowStatus RowStatus

CLMobilityMulticastGroupEntry  
SEQUENCE    
  cLMobilityGroupMacAddress MacAddress
  cLMobilityMulticastGroupIPAddress InetAddress
  cLMobilityMulticastGroupIPAddressType InetAddressType

CLMobilityGroupMembersEntry  
SEQUENCE    
  cLMobilityGroupMemberIPAddressType InetAddressType
  cLMobilityGroupMemberIPAddress InetAddress
  cLMobilityGroupMemberControlPathStatusUp TruthValue
  cLMobilityGroupMemberDataPathStatusUp TruthValue

CLMobilityForeignWlcMapEntry  
SEQUENCE    
  cLMobilityForeignWlcMapMacAddress MacAddress
  cLMobilityForeignWlcMapIf SnmpAdminString
  cLMobilityForeignWlcMapRowStatus RowStatus

Defined Values

ciscoLwappMobilityMIB 1.3.6.1.4.1.9.9.576
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.
MODULE-IDENTITY    

ciscoLwappMobilityMIBNotifs 1.3.6.1.4.1.9.9.576.0
OBJECT IDENTIFIER    

ciscoLwappMobilityMIBObjects 1.3.6.1.4.1.9.9.576.1
OBJECT IDENTIFIER    

ciscoLwappMobilityMIBConform 1.3.6.1.4.1.9.9.576.2
OBJECT IDENTIFIER    

cLMobilityAnchorTable 1.3.6.1.4.1.9.9.576.1.1
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 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).
OBJECT-TYPE    
  SEQUENCE OF  
    CLMobilityAnchorEntry

cLMobilityAnchorEntry 1.3.6.1.4.1.9.9.576.1.1.1
Each entry in this table provides information about one 802.11 LWAPP Mobility Anchor configured on a WLAN on this controller.
OBJECT-TYPE    
  CLMobilityAnchorEntry  

cLMobilityAnchorWlanSsid 1.3.6.1.4.1.9.9.576.1.1.1.1
Local wlan-ssid to connect to Guest/Anchor switch
OBJECT-TYPE    
  DisplayString Size(1..32)  

cLMobilityAnchorSwitchAddressType 1.3.6.1.4.1.9.9.576.1.1.1.2
Guest/Anchor switch Address type.
OBJECT-TYPE    
  InetAddressType  

cLMobilityAnchorSwitchAddress 1.3.6.1.4.1.9.9.576.1.1.1.3
Guest/Anchor switch Address. The IP Address is limited to IPv4 and IPv6.
OBJECT-TYPE    
  InetAddress  

cLMobilityAnchorStatus 1.3.6.1.4.1.9.9.576.1.1.1.4
Operational 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.
OBJECT-TYPE    
  BITS controlpath(0), datapath(1)  

cLMobilityAnchorRowStatus 1.3.6.1.4.1.9.9.576.1.1.1.5
Row Status
OBJECT-TYPE    
  RowStatus  

cLMobilityAnchorGlobalDot11Config 1.3.6.1.4.1.9.9.576.1.2
OBJECT IDENTIFIER    

cLMobilityAnchorGroupKeepAliveNumber 1.3.6.1.4.1.9.9.576.1.2.1
This parameter determines how many successive ping attempts to the anchor should fail before the anchor is declared DOWN.
OBJECT-TYPE    
  Integer32 3..20  

cLMobilityAnchorGroupKeepAliveInterval 1.3.6.1.4.1.9.9.576.1.2.2
This parameter determines the time interval (in seconds) between two consecutive ping attempts to an anchor.
OBJECT-TYPE    
  Integer32 1..30  

cLMobilityAnchorSmtStatus 1.3.6.1.4.1.9.9.576.1.2.3
This 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.
OBJECT-TYPE    
  TruthValue  

cLMobilityAnchorCurrentSmt 1.3.6.1.4.1.9.9.576.1.2.4
This 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.
OBJECT-TYPE    
  TruthValue  

cLMobilityMulticastGroupConfig 1.3.6.1.4.1.9.9.576.1.4
OBJECT IDENTIFIER    

cLMobilityMulticastMessagingEnable 1.3.6.1.4.1.9.9.576.1.4.1
This 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.
OBJECT-TYPE    
  TruthValue  

cLMobilityMulticastGroupTable 1.3.6.1.4.1.9.9.576.1.4.2
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.
OBJECT-TYPE    
  SEQUENCE OF  
    CLMobilityMulticastGroupEntry

cLMobilityMulticastGroupEntry 1.3.6.1.4.1.9.9.576.1.4.2.1
Each entry in this table provides information about multicast group IP address per mobility group.
OBJECT-TYPE    
  CLMobilityMulticastGroupEntry  

cLMobilityGroupMacAddress 1.3.6.1.4.1.9.9.576.1.4.2.1.1
This object represents the mobility group name present on the controller.
OBJECT-TYPE    
  MacAddress  

cLMobilityMulticastGroupIPAddress 1.3.6.1.4.1.9.9.576.1.4.2.1.2
This object represnts the multicast group IP address.The Ip address is limited to ipv4 and ipv6.
OBJECT-TYPE    
  InetAddress  

cLMobilityMulticastGroupIPAddressType 1.3.6.1.4.1.9.9.576.1.4.2.1.3
This used represents the multicast group IP address type.The Ip address is limited to ipv4 and ipv6.
OBJECT-TYPE    
  InetAddressType  

cLMobilityGroupMembersTable 1.3.6.1.4.1.9.9.576.1.5
This object represents the MWAR List (statically configured members of the mobility group).Entries are added to the table when configuring mobility group members.
OBJECT-TYPE    
  SEQUENCE OF  
    CLMobilityGroupMembersEntry

cLMobilityGroupMembersEntry 1.3.6.1.4.1.9.9.576.1.5.1
This object represents an Entry (conceptual row) in the cLMobilityGroupMembers table.
OBJECT-TYPE    
  CLMobilityGroupMembersEntry  

cLMobilityGroupMemberIPAddressType 1.3.6.1.4.1.9.9.576.1.5.1.1
This object represents the IP Address type of the mobility member IP Address represented by cLMobilityGroupMemberIPAddress. The Ip address is limited to ipv4 and ipv6.
OBJECT-TYPE    
  InetAddressType  

cLMobilityGroupMemberIPAddress 1.3.6.1.4.1.9.9.576.1.5.1.2
This object represents the IP Address of the mobility member corresponding to cLMobilityGroupMacAddress.The Ip address is limited to ipv4 and ipv6.
OBJECT-TYPE    
  InetAddress  

cLMobilityGroupMemberControlPathStatusUp 1.3.6.1.4.1.9.9.576.1.5.1.3
This object represents the control path status of the mobility member corresponding to cLMobilityGroupMacAddress.
OBJECT-TYPE    
  TruthValue  

cLMobilityGroupMemberDataPathStatusUp 1.3.6.1.4.1.9.9.576.1.5.1.4
This object represents the data path status of the mobility member corresponding to cLMobilityGroupMacAddress.
OBJECT-TYPE    
  TruthValue  

cLMobilityForeignWlcMapTable 1.3.6.1.4.1.9.9.576.1.6
This 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.
OBJECT-TYPE    
  SEQUENCE OF  
    CLMobilityForeignWlcMapEntry

cLMobilityForeignWlcMapEntry 1.3.6.1.4.1.9.9.576.1.6.1
This represents a row in the cLMobilityForeignWlcIfMappingTable . Entries are added and deleted by explicit user driven action.
OBJECT-TYPE    
  CLMobilityForeignWlcMapEntry  

cLMobilityForeignWlcMapMacAddress 1.3.6.1.4.1.9.9.576.1.6.1.1
This object represents the MAC address of the foreign controller, to which the interface mapping is to be configured.
OBJECT-TYPE    
  MacAddress  

cLMobilityForeignWlcMapIf 1.3.6.1.4.1.9.9.576.1.6.1.2
This 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 .
OBJECT-TYPE    
  SnmpAdminString  

cLMobilityForeignWlcMapRowStatus 1.3.6.1.4.1.9.9.576.1.6.1.3
This object represents the row status.
OBJECT-TYPE    
  RowStatus  

cLMobilityTrapVariables 1.3.6.1.4.1.9.9.576.1.3
OBJECT IDENTIFIER    

cLMobilityAnchorWlanId 1.3.6.1.4.1.9.9.576.1.3.1
This object uniquely identifies one instance of a WLAN on the controller.
OBJECT-TYPE    
  Unsigned32  

cLMobilityAnchorAddressType 1.3.6.1.4.1.9.9.576.1.3.2
Guest/Anchor switch Address type.
OBJECT-TYPE    
  InetAddressType  

cLMobilityAnchorAddress 1.3.6.1.4.1.9.9.576.1.3.3
Guest/Anchor switch Address. The IP Address is limited to IPv4 and IPv6
OBJECT-TYPE    
  InetAddress  

ciscoLwappMobilityAnchorControlPathDown 1.3.6.1.4.1.9.9.576.0.1
This 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    

ciscoLwappMobilityAnchorControlPathUp 1.3.6.1.4.1.9.9.576.0.2
This 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    

ciscoLwappMobilityAnchorDataPathDown 1.3.6.1.4.1.9.9.576.0.3
This 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    

ciscoLwappMobilityAnchorDataPathUp 1.3.6.1.4.1.9.9.576.0.4
This 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    

ciscoLwappMobilityAllAnchorsOnWlanDown 1.3.6.1.4.1.9.9.576.0.5
This 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    

ciscoLwappMobilityOneAnchorOnWlanUp 1.3.6.1.4.1.9.9.576.0.6
This 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    

ciscoLwappMobilityMIBCompliances 1.3.6.1.4.1.9.9.576.2.1
OBJECT IDENTIFIER    

ciscoLwappMobilityMIBGroups 1.3.6.1.4.1.9.9.576.2.2
OBJECT IDENTIFIER    

ciscoLwappMobilityMIBCompliance 1.3.6.1.4.1.9.9.576.2.1.1
The compliance statement for the SNMP entities that implement the ciscoLwappMobilityMIB module.
MODULE-COMPLIANCE    

ciscoLwappMobilityMIBComplianceRev01 1.3.6.1.4.1.9.9.576.2.1.2
The compliance statement for the SNMP entities that implement the ciscoLwappMobilityMIB module.
MODULE-COMPLIANCE    

cLNplus1RedundancyRev01ConfigGroup 1.3.6.1.4.1.9.9.576.2.2.1
This is a collection of objects which can configured to control functional parameters of Guest Tunneling N+1 Redundancy feature in CISCO 4400 / 2006 series of WLAN controllers.
OBJECT-GROUP    

cLNplus1RedundancyRev01StatusGroup 1.3.6.1.4.1.9.9.576.2.2.2
This collection of objects represents the information about the general status attributes of Guest Tunneling N+1 Redundancy in CISCO 4400 / 2006 series of WLAN controllers.
OBJECT-GROUP    

cLNplus1RedundancyRev01NotifsGroup 1.3.6.1.4.1.9.9.576.2.2.3
This is a collection of notifications about the general functional behavior of Guest Tunneling N+1 Redundancy in CISCO 4400 / 2006 series of WLAN controllers.
NOTIFICATION-GROUP    

cLSymmetricTunnelingRev01ConfigGroup 1.3.6.1.4.1.9.9.576.2.2.4
This is a collection of objects which can be configured to control functional parameters of Symmetric Mobility Tunneling feature in CISCO 4400 / 2006 series of WLAN controllers.
OBJECT-GROUP    

cLSymmetricTunnelingRev01StatusGroup 1.3.6.1.4.1.9.9.576.2.2.5
This collection of objects represents the information about the general status attributes of Symmetric Mobility Tunneling feature in CISCO 4400 / 2006 series of WLAN controllers.
OBJECT-GROUP    

cLMobilityGroupRev01ConfigGroup 1.3.6.1.4.1.9.9.576.2.2.6
This collection of objects represents the information about the mobility groups and the interface mappings with foreign controllers.
OBJECT-GROUP