mirror of
https://github.com/hsnodgrass/snmp_mib_archive.git
synced 2025-04-17 16:03:04 +00:00
893 lines
30 KiB
Plaintext
893 lines
30 KiB
Plaintext
|
|
-- *******************************************************************
|
|
-- CISCO-LWAPP-MOBILITY-MIB.my
|
|
-- June 2006, Bharat Biswal
|
|
|
|
-- Copyright (c) 2005-2006 by Cisco Systems, Inc.
|
|
-- All rights reserved.
|
|
-- *******************************************************************
|
|
|
|
CISCO-LWAPP-MOBILITY-MIB DEFINITIONS ::= BEGIN
|
|
|
|
IMPORTS
|
|
MODULE-IDENTITY,
|
|
OBJECT-TYPE,
|
|
NOTIFICATION-TYPE,
|
|
Unsigned32,
|
|
Integer32
|
|
FROM SNMPv2-SMI
|
|
MODULE-COMPLIANCE,
|
|
OBJECT-GROUP,
|
|
NOTIFICATION-GROUP
|
|
FROM SNMPv2-CONF
|
|
DisplayString,
|
|
TruthValue,
|
|
RowStatus
|
|
FROM SNMPv2-TC
|
|
InetAddressType,
|
|
InetAddress
|
|
FROM INET-ADDRESS-MIB
|
|
ciscoMgmt
|
|
FROM CISCO-SMI;
|
|
|
|
-- ********************************************************************
|
|
-- * MODULE IDENTITY
|
|
-- ********************************************************************
|
|
|
|
ciscoLwappMobilityMIB MODULE-IDENTITY
|
|
LAST-UPDATED "200607190000Z"
|
|
ORGANIZATION "Cisco Systems Inc."
|
|
CONTACT-INFO
|
|
"Cisco Systems,
|
|
Customer Service
|
|
|
|
Postal: 170 West Tasman Drive
|
|
San Jose, CA 95134
|
|
USA
|
|
|
|
Tel: +1 800 553-NETS
|
|
|
|
Email: cs-snmp@cisco.com"
|
|
DESCRIPTION
|
|
"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. "
|
|
REVISION "200607190000Z"
|
|
DESCRIPTION
|
|
"Initial version of this MIB module."
|
|
::= { ciscoMgmt 576 }
|
|
|
|
|
|
ciscoLwappMobilityMIBNotifs OBJECT IDENTIFIER
|
|
::= { ciscoLwappMobilityMIB 0 }
|
|
|
|
ciscoLwappMobilityMIBObjects OBJECT IDENTIFIER
|
|
::= { ciscoLwappMobilityMIB 1 }
|
|
|
|
ciscoLwappMobilityMIBConform OBJECT IDENTIFIER
|
|
::= { ciscoLwappMobilityMIB 2 }
|
|
|
|
-- *******************************************************************
|
|
-- Per WLAN, anchors table
|
|
-- *******************************************************************
|
|
|
|
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 + ---------->>> + 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 }
|
|
|
|
cLMobilityAnchorEntry OBJECT-TYPE
|
|
SYNTAX CLMobilityAnchorEntry
|
|
MAX-ACCESS not-accessible
|
|
STATUS current
|
|
DESCRIPTION
|
|
"Each entry in this table provides information about
|
|
one 802.11 LWAPP Mobility Anchor configured on a WLAN
|
|
on this controller."
|
|
INDEX {
|
|
cLMobilityAnchorWlanSsid,
|
|
cLMobilityAnchorSwitchAddressType,
|
|
cLMobilityAnchorSwitchAddress
|
|
}
|
|
::= { cLMobilityAnchorTable 1 }
|
|
|
|
CLMobilityAnchorEntry ::= SEQUENCE {
|
|
cLMobilityAnchorWlanSsid DisplayString,
|
|
cLMobilityAnchorSwitchAddressType InetAddressType,
|
|
cLMobilityAnchorSwitchAddress InetAddress,
|
|
cLMobilityAnchorStatus BITS,
|
|
cLMobilityAnchorRowStatus RowStatus
|
|
}
|
|
|
|
cLMobilityAnchorWlanSsid OBJECT-TYPE
|
|
SYNTAX DisplayString (SIZE (1..32))
|
|
MAX-ACCESS not-accessible
|
|
STATUS current
|
|
DESCRIPTION "Local wlan-ssid to connect to Guest/Anchor switch"
|
|
::= { cLMobilityAnchorEntry 1 }
|
|
|
|
cLMobilityAnchorSwitchAddressType OBJECT-TYPE
|
|
SYNTAX InetAddressType
|
|
MAX-ACCESS not-accessible
|
|
STATUS current
|
|
DESCRIPTION "Guest/Anchor switch Address type."
|
|
::= { cLMobilityAnchorEntry 2 }
|
|
|
|
cLMobilityAnchorSwitchAddress OBJECT-TYPE
|
|
SYNTAX InetAddress
|
|
MAX-ACCESS not-accessible
|
|
STATUS current
|
|
DESCRIPTION
|
|
"Guest/Anchor switch Address.
|
|
The IP Address is limited to IPv4 and IPv6."
|
|
::= { cLMobilityAnchorEntry 3 }
|
|
|
|
cLMobilityAnchorStatus OBJECT-TYPE
|
|
SYNTAX BITS {
|
|
controlpath(0),
|
|
datapath(1)
|
|
}
|
|
MAX-ACCESS read-only
|
|
STATUS current
|
|
DESCRIPTION
|
|
"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.
|
|
"
|
|
::= { cLMobilityAnchorEntry 4 }
|
|
|
|
cLMobilityAnchorRowStatus OBJECT-TYPE
|
|
SYNTAX RowStatus
|
|
MAX-ACCESS read-create
|
|
STATUS current
|
|
DESCRIPTION "Row Status"
|
|
::= { cLMobilityAnchorEntry 5 }
|
|
|
|
|
|
-- ********************************************************************
|
|
-- * Global Dot11 Mobility Anchor Configuration
|
|
-- ********************************************************************
|
|
cLMobilityAnchorGlobalDot11Config OBJECT IDENTIFIER
|
|
::= { ciscoLwappMobilityMIBObjects 2 }
|
|
|
|
|
|
cLMobilityAnchorGroupKeepAliveNumber OBJECT-TYPE
|
|
SYNTAX Integer32 (3..20 )
|
|
MAX-ACCESS read-write
|
|
STATUS current
|
|
DESCRIPTION
|
|
"This parameter determines how many successive
|
|
ping attempts to the anchor should fail before
|
|
the anchor is declared DOWN."
|
|
DEFVAL { 3 }
|
|
::= { cLMobilityAnchorGlobalDot11Config 1 }
|
|
|
|
cLMobilityAnchorGroupKeepAliveInterval OBJECT-TYPE
|
|
SYNTAX Integer32 (1..30 )
|
|
MAX-ACCESS read-write
|
|
STATUS current
|
|
DESCRIPTION
|
|
"This parameter determines the time interval
|
|
(in seconds) between two consecutive ping attempts
|
|
to an anchor."
|
|
DEFVAL { 10 }
|
|
::= { cLMobilityAnchorGlobalDot11Config 2 }
|
|
|
|
cLMobilityAnchorSmtStatus OBJECT-TYPE
|
|
SYNTAX TruthValue
|
|
MAX-ACCESS read-write
|
|
STATUS current
|
|
DESCRIPTION
|
|
"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.
|
|
|
|
"
|
|
::= { cLMobilityAnchorGlobalDot11Config 3 }
|
|
|
|
cLMobilityAnchorCurrentSmt OBJECT-TYPE
|
|
SYNTAX TruthValue
|
|
MAX-ACCESS read-only
|
|
STATUS current
|
|
DESCRIPTION
|
|
"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."
|
|
::= { cLMobilityAnchorGlobalDot11Config 4 }
|
|
-- *******************************************************************
|
|
-- * DEFINITION OF OBJECTS ACCESSIBLE FOR NOTIFICATIONS ONLY
|
|
-- *******************************************************************
|
|
cLMobilityTrapVariables OBJECT IDENTIFIER
|
|
::= { ciscoLwappMobilityMIBObjects 3 }
|
|
|
|
|
|
cLMobilityAnchorWlanId OBJECT-TYPE
|
|
SYNTAX Unsigned32
|
|
MAX-ACCESS accessible-for-notify
|
|
STATUS current
|
|
DESCRIPTION
|
|
"This object uniquely identifies one instance of
|
|
a WLAN on the controller."
|
|
::= { cLMobilityTrapVariables 1 }
|
|
|
|
cLMobilityAnchorAddressType OBJECT-TYPE
|
|
SYNTAX InetAddressType
|
|
MAX-ACCESS accessible-for-notify
|
|
STATUS current
|
|
DESCRIPTION "Guest/Anchor switch Address type."
|
|
::= { cLMobilityTrapVariables 2 }
|
|
|
|
cLMobilityAnchorAddress OBJECT-TYPE
|
|
SYNTAX InetAddress
|
|
MAX-ACCESS accessible-for-notify
|
|
STATUS current
|
|
DESCRIPTION
|
|
"Guest/Anchor switch Address.
|
|
The IP Address is limited to IPv4 and IPv6"
|
|
::= { cLMobilityTrapVariables 3 }
|
|
-- *******************************************************************
|
|
-- * END OF - DEFINITION OF OBJECTS ACCESSIBLE FOR NOTIFICATIONS ONLY
|
|
-- *******************************************************************
|
|
|
|
|
|
-- *******************************************************************
|
|
-- * NOTIFICATIONS
|
|
-- *******************************************************************
|
|
|
|
|
|
ciscoLwappMobilityAnchorControlPathDown NOTIFICATION-TYPE
|
|
OBJECTS {
|
|
cLMobilityAnchorAddressType,
|
|
cLMobilityAnchorAddress
|
|
}
|
|
STATUS current
|
|
DESCRIPTION
|
|
"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."
|
|
::= { ciscoLwappMobilityMIBNotifs 1 }
|
|
|
|
|
|
ciscoLwappMobilityAnchorControlPathUp NOTIFICATION-TYPE
|
|
OBJECTS {
|
|
cLMobilityAnchorAddressType,
|
|
cLMobilityAnchorAddress
|
|
}
|
|
STATUS current
|
|
DESCRIPTION
|
|
"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."
|
|
::= { ciscoLwappMobilityMIBNotifs 2 }
|
|
|
|
|
|
ciscoLwappMobilityAnchorDataPathDown NOTIFICATION-TYPE
|
|
OBJECTS {
|
|
cLMobilityAnchorAddressType,
|
|
cLMobilityAnchorAddress
|
|
}
|
|
STATUS current
|
|
DESCRIPTION
|
|
"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."
|
|
::= { ciscoLwappMobilityMIBNotifs 3 }
|
|
|
|
|
|
ciscoLwappMobilityAnchorDataPathUp NOTIFICATION-TYPE
|
|
OBJECTS {
|
|
cLMobilityAnchorAddressType,
|
|
cLMobilityAnchorAddress
|
|
}
|
|
STATUS current
|
|
DESCRIPTION
|
|
"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."
|
|
::= { ciscoLwappMobilityMIBNotifs 4 }
|
|
|
|
|
|
ciscoLwappMobilityAllAnchorsOnWlanDown NOTIFICATION-TYPE
|
|
OBJECTS { cLMobilityAnchorWlanId }
|
|
STATUS current
|
|
DESCRIPTION
|
|
"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."
|
|
::= { ciscoLwappMobilityMIBNotifs 5 }
|
|
|
|
|
|
ciscoLwappMobilityOneAnchorOnWlanUp NOTIFICATION-TYPE
|
|
OBJECTS { cLMobilityAnchorWlanId }
|
|
STATUS current
|
|
DESCRIPTION
|
|
"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."
|
|
::= { ciscoLwappMobilityMIBNotifs 6 }
|
|
-- *******************************************************************
|
|
-- * END OF - NOTIFICATIONS
|
|
-- *******************************************************************
|
|
|
|
-- *******************************************************************
|
|
-- * Compliance statements
|
|
-- *******************************************************************
|
|
ciscoLwappMobilityMIBCompliances OBJECT IDENTIFIER
|
|
::= { ciscoLwappMobilityMIBConform 1 }
|
|
|
|
ciscoLwappMobilityMIBGroups OBJECT IDENTIFIER
|
|
::= { ciscoLwappMobilityMIBConform 2 }
|
|
|
|
|
|
ciscoLwappMobilityMIBCompliance MODULE-COMPLIANCE
|
|
STATUS current
|
|
DESCRIPTION
|
|
"The compliance statement for the SNMP entities that
|
|
implement the ciscoLwappMobilityMIB module."
|
|
MODULE -- this module
|
|
MANDATORY-GROUPS {
|
|
cLNplus1RedundancyRev01ConfigGroup,
|
|
cLNplus1RedundancyRev01StatusGroup,
|
|
cLNplus1RedundancyRev01NotifsGroup,
|
|
cLSymmetricTunnelingRev01ConfigGroup,
|
|
cLSymmetricTunnelingRev01StatusGroup
|
|
}
|
|
::= { ciscoLwappMobilityMIBCompliances 1 }
|
|
|
|
-- *******************************************************************
|
|
-- * Units of conformance
|
|
-- *******************************************************************
|
|
cLNplus1RedundancyRev01ConfigGroup OBJECT-GROUP
|
|
OBJECTS {
|
|
cLMobilityAnchorGroupKeepAliveNumber,
|
|
cLMobilityAnchorGroupKeepAliveInterval
|
|
}
|
|
STATUS current
|
|
DESCRIPTION
|
|
"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."
|
|
::= { ciscoLwappMobilityMIBGroups 1 }
|
|
|
|
cLNplus1RedundancyRev01StatusGroup OBJECT-GROUP
|
|
OBJECTS {
|
|
cLMobilityAnchorStatus,
|
|
cLMobilityAnchorRowStatus,
|
|
cLMobilityAnchorWlanId,
|
|
cLMobilityAnchorAddressType,
|
|
cLMobilityAnchorAddress
|
|
}
|
|
STATUS current
|
|
DESCRIPTION
|
|
"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."
|
|
::= { ciscoLwappMobilityMIBGroups 2 }
|
|
|
|
cLNplus1RedundancyRev01NotifsGroup NOTIFICATION-GROUP
|
|
NOTIFICATIONS {
|
|
ciscoLwappMobilityAnchorControlPathDown,
|
|
ciscoLwappMobilityAnchorControlPathUp,
|
|
ciscoLwappMobilityAnchorDataPathDown,
|
|
ciscoLwappMobilityAnchorDataPathUp,
|
|
ciscoLwappMobilityAllAnchorsOnWlanDown,
|
|
ciscoLwappMobilityOneAnchorOnWlanUp
|
|
}
|
|
STATUS current
|
|
DESCRIPTION
|
|
"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."
|
|
::= { ciscoLwappMobilityMIBGroups 3 }
|
|
|
|
cLSymmetricTunnelingRev01ConfigGroup OBJECT-GROUP
|
|
OBJECTS { cLMobilityAnchorSmtStatus }
|
|
STATUS current
|
|
DESCRIPTION
|
|
"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."
|
|
::= { ciscoLwappMobilityMIBGroups 4 }
|
|
|
|
cLSymmetricTunnelingRev01StatusGroup OBJECT-GROUP
|
|
OBJECTS { cLMobilityAnchorCurrentSmt }
|
|
STATUS current
|
|
DESCRIPTION
|
|
"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."
|
|
::= { ciscoLwappMobilityMIBGroups 5 }
|
|
|
|
END
|
|
|
|
|
|
|