mirror of
https://github.com/hsnodgrass/snmp_mib_archive.git
synced 2025-04-17 16:03:04 +00:00
621 lines
21 KiB
Plaintext
621 lines
21 KiB
Plaintext
-- *******************************************************************
|
|
-- CISCO-LWAPP-TC-MIB.my: Cisco LWAPP MIBs Textual Conventions
|
|
-- March 2006, Prasanna Viswakumar
|
|
--
|
|
-- Copyright (c) 2006,2007 by Cisco Systems, Inc.
|
|
-- All rights reserved.
|
|
-- *******************************************************************
|
|
|
|
CISCO-LWAPP-TC-MIB DEFINITIONS ::= BEGIN
|
|
|
|
IMPORTS
|
|
MODULE-IDENTITY,
|
|
Unsigned32,
|
|
Gauge32
|
|
FROM SNMPv2-SMI
|
|
TEXTUAL-CONVENTION
|
|
FROM SNMPv2-TC
|
|
ciscoMgmt
|
|
FROM CISCO-SMI;
|
|
|
|
-- ********************************************************************
|
|
-- * MODULE IDENTITY
|
|
-- ********************************************************************
|
|
|
|
ciscoLwappTextualConventions MODULE-IDENTITY
|
|
LAST-UPDATED "200702050000Z"
|
|
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-wnbu-snmp@cisco.com"
|
|
DESCRIPTION
|
|
"This module defines textual conventions used
|
|
throughout the Cisco enterprise MIBs
|
|
designed for implementation on Central
|
|
Controllers that terminate the Light Weight
|
|
Access Point Protocol from LWAPP Access
|
|
Points.
|
|
|
|
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.
|
|
|
|
Advanced Encryption Standard ( AES )
|
|
|
|
In cryptography, the Advanced Encryption Standard
|
|
(AES), also known as Rijndael, is a block cipher
|
|
adopted as an encryption standard by the US
|
|
government. It is expected to be used worldwide
|
|
and analysed extensively, as was the case with its
|
|
predecessor, the Data Encryption Standard (DES).
|
|
AES was adopted by National Institute of Standards
|
|
and Technology (NIST) as US FIPS PUB 197 in
|
|
November 2001 after a 5-year standardisation
|
|
process.
|
|
|
|
Central Controller ( CC )
|
|
|
|
The central entity that terminates the LWAPP protocol
|
|
tunnel from the LWAPP APs. Throughout this MIB,
|
|
this entity is 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.
|
|
|
|
Management Frame Protection ( MFP )
|
|
|
|
A proprietary mechanism devised to integrity protect
|
|
the otherwise unprotected management frames of the
|
|
802.11 protocol specification.
|
|
|
|
Message Integrity Check ( MIC )
|
|
|
|
A checksum computed on a sequence of bytes and made
|
|
known to the receiving party in a data communication,
|
|
to let the receiving party make sure the bytes
|
|
received were not compromised enroute.
|
|
|
|
Mobile Node ( MN )
|
|
|
|
A roaming 802.11 wireless device in a wireless
|
|
network associated with an access point.
|
|
|
|
Temporal Key Integrity Protocol ( TKIP )
|
|
|
|
A security protocol defined to enhance the limitations
|
|
of WEP. Message Integrity Check and per-packet keying
|
|
on all WEP-encrypted frames are two significant
|
|
enhancements provided by TKIP to WEP.
|
|
|
|
Wired Equivalent Privacy ( WEP )
|
|
|
|
A security method defined by 802.11. WEP uses a
|
|
symmetric key stream cipher called RC4 to encrypt the
|
|
data packets.
|
|
|
|
802.11n
|
|
|
|
802.11n builds upon previous 802.11 standards by
|
|
adding MIMO (multiple-input multiple-output). MIMO
|
|
uses multiple transmitter and receiver antennas to
|
|
allow for increased data throughput through spatial
|
|
multiplexing and increased range.
|
|
|
|
Control/Extension Channel
|
|
|
|
A single 802.11 channel is 20 MHz wide. 802.11n allows
|
|
the use of channels of width 40 MHz by combining two
|
|
20 MHz channels. The channels are known as the primary
|
|
or control channel and secondary or extension channel.
|
|
Both the channels are used for transmission
|
|
and reception of data.
|
|
|
|
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.
|
|
|
|
[3] Enhanced Wireless Consortium MAC Specification,
|
|
v1.24.
|
|
|
|
[4] Enhanced Wireless Consortium PHY Specification,
|
|
v1.27."
|
|
REVISION "200702050000Z"
|
|
DESCRIPTION
|
|
"Added new textual conventions CLDot11ChannelBandwidth,
|
|
CLDot11Band and CLApAssocFailureReason."
|
|
REVISION "200610310000Z"
|
|
DESCRIPTION
|
|
"Added new textual conventions CLMfpEventSource,
|
|
CLCdpAdvtVersionType and CLDot11ClientStatus."
|
|
REVISION "200604130000Z"
|
|
DESCRIPTION
|
|
"Initial version of this MIB module."
|
|
::= { ciscoMgmt 514 }
|
|
|
|
|
|
-- ********************************************************************
|
|
-- TEXTUAL CONVENTION
|
|
-- ********************************************************************
|
|
|
|
CLApIfType ::= TEXTUAL-CONVENTION
|
|
STATUS current
|
|
DESCRIPTION
|
|
"This textual convention defines the type of a
|
|
wireless interface.
|
|
|
|
The semantics are as follows:
|
|
|
|
dot11bg - This value indicates that the radio
|
|
interface follows 802.11b or 802.11g standard.
|
|
|
|
dot11a - This value indicates that the radio
|
|
interface follows 802.11a standard.
|
|
|
|
uwb - This value indicates that this is a Ultra
|
|
Wideband Interface."
|
|
SYNTAX INTEGER {
|
|
dot11bg(1),
|
|
dot11a(2),
|
|
uwb(3)
|
|
}
|
|
|
|
CLDot11Channel ::= TEXTUAL-CONVENTION
|
|
STATUS current
|
|
DESCRIPTION
|
|
"This textual convention defines the possible channel
|
|
numbers in an 802.11 communication channel. The
|
|
802.11 radio interface of an Access Point operates
|
|
in one of the possible channels at any point of time
|
|
for wireless data communication with 802.11 based
|
|
wireless clients."
|
|
SYNTAX Unsigned32 (1..14 | 34 | 36 | 38 | 40 | 42 | 44 | 46 | 48 | 52 | 56 | 60 | 64 | 149 | 153 | 157 | 161 )
|
|
|
|
CLDot11ClientStatus ::= TEXTUAL-CONVENTION
|
|
STATUS current
|
|
DESCRIPTION
|
|
"This textual convention defines the states
|
|
of an 802.11 client.
|
|
|
|
The semantics are as follows:
|
|
|
|
idle(1) - client is in idle mode.
|
|
|
|
aaaPending(2) - client's authentication is pending.
|
|
Request has been sent to AAA server for authentication.
|
|
|
|
authenticated(3) - client has been authenticated.
|
|
|
|
associated(4) - client is associated, but not
|
|
authenticated.
|
|
|
|
powersave(5) - client is in powersave mode.
|
|
|
|
disassociated(6) - client has dissociated and not in
|
|
any of the 802.11 networks managed by the controller.
|
|
|
|
tobedeleted(7) - client is marked for deletion.
|
|
|
|
probing(8) - state before association. The client
|
|
will be removed if it does not associate.
|
|
|
|
excluded(9) - client has been marked as excluded after fixed
|
|
number of authentication failures."
|
|
SYNTAX INTEGER {
|
|
idle(1),
|
|
aaaPending(2),
|
|
authenticated(3),
|
|
associated(4),
|
|
powersave(5),
|
|
disassociated(6),
|
|
tobedeleted(7),
|
|
probing(8),
|
|
excluded(9)
|
|
}
|
|
|
|
CLEventFrames ::= TEXTUAL-CONVENTION
|
|
STATUS current
|
|
DESCRIPTION
|
|
"This textual convention defines the possible
|
|
802.11 management frame subtypes.
|
|
|
|
cLAssocRequestFrm - 802.11 Association Request
|
|
frame
|
|
|
|
cLAssocResponseFrm - 802.11 Association Response
|
|
frame
|
|
|
|
cLReAssocRequestFrm - 802.11 Reassociation
|
|
Request frame
|
|
|
|
cLReAssocResponseFrm - 802.11 Reassociation
|
|
Response frame
|
|
|
|
cLProbeRequestFrm - 802.11 Probe Request frame
|
|
|
|
cLProbeResponseFrm - 802.11 Probe Response
|
|
frame
|
|
|
|
cLReserved1 - Reserved for future use
|
|
|
|
cLReserved2 - Reserved for future use
|
|
|
|
cLBeaconFrm - 802.11 Beacon frame
|
|
|
|
cLAtimFrm - 802.11 Adhoc Traffic Indication
|
|
Map frame
|
|
|
|
cLDissociationFrm - 802.11 Dissociation
|
|
frame
|
|
|
|
cLAuthenticationFrm - 802.11 Authentication
|
|
frame
|
|
|
|
cLDeAuthenticationFrm - 802.11 Deauthentication
|
|
frame"
|
|
|
|
REFERENCE
|
|
"Part 11 Wireless LAN Medium Access Control ( MAC )
|
|
and Physical Layer ( PHY ) Specifications,
|
|
Section 7.1.3.1.2 - Type and Subtype fields"
|
|
SYNTAX BITS {
|
|
cLAssocRequestFrm(0),
|
|
cLAssocResponseFrm(1),
|
|
cLReAssocRequestFrm(2),
|
|
cLReAssocResponseFrm(3),
|
|
cLProbeRequestFrm(4),
|
|
cLProbeResponseFrm(5),
|
|
cLReserved1(6),
|
|
cLReserved2(7),
|
|
cLBeaconFrm(8),
|
|
cLAtimFrm(9),
|
|
cLDissociationFrm(10),
|
|
cLAuthenticationFrm(11),
|
|
cLDeAuthenticationFrm(12)
|
|
}
|
|
|
|
CLMfpEventType ::= TEXTUAL-CONVENTION
|
|
STATUS current
|
|
DESCRIPTION
|
|
"The type of the MFP anomaly event.
|
|
|
|
invalidMic - The MFP Validation has identified
|
|
that the MIC carried by a particular management
|
|
frame is invalid.
|
|
|
|
invalidSeq - The MFP validation has identified
|
|
that a particular management frame is carrying an
|
|
invalid sequence number. Note that an invalid
|
|
sequence number error can also be detected due to an
|
|
incorrect timestamp in the MFP information element.
|
|
The incorrect timestamp could possibly be due to the
|
|
fact that the detecting AP's time window is not in
|
|
synchronization with that of other APs in the
|
|
MFP framework.
|
|
|
|
noMic - The MFP validation has detected a management
|
|
frame without the MFP information element.
|
|
|
|
unexpectedMic - The MFP validation has detected a
|
|
management frame as carrying a MIC value when
|
|
protection is not enabled on the WLAN.
|
|
|
|
ccmpDecryptError - An MFP frame that was apparently
|
|
received from a client in an AES-CCMP encrypted
|
|
session was rejected by the Access Point because it
|
|
could not be decrypted.
|
|
|
|
ccmpInvalidMhdrIe - An MFP frame that was apparently
|
|
received from a client in an AES-CCMP encrypted
|
|
session was rejected by the Access Point because it
|
|
contained an invalid MHDR information element, or the
|
|
MHDR information element was not present.
|
|
|
|
ccmpInvalidReplayCtr - An MFP frame that was apparently
|
|
received from a client in an AES-CCMP encrypted session
|
|
was rejected by the Access Point because the replay
|
|
counter was not valid.
|
|
|
|
tkipInvalidIcv - An MFP frame that was apparently
|
|
received from a client in a TKIP encrypted session was
|
|
rejected by the Access Point because it contained an
|
|
invalid Integrity Check Value.
|
|
|
|
tkipInvalidMic - An MFP frame that was apparently
|
|
received from a client in a TKIP encrypted session was
|
|
rejected by the Access Point because the message
|
|
integrity check failed.
|
|
|
|
tkipInvalidMhdrIe - An MFP frame that was apparently
|
|
received from a client in a TKIP encrypted session was
|
|
rejected by the Access Point because it contained an
|
|
invalid MHDR information element, or the MHDR
|
|
information element was not present.
|
|
|
|
tkipInvalidReplayCtr - An MFP frame that was apparently
|
|
received from a client in a TKIP encrypted session was
|
|
rejected by the Access Point because it the replay
|
|
counter was not valid.
|
|
|
|
bcastDisassociationFrameRcvd - The Access Point detected
|
|
a broadcast disassociation frame. Broadcast
|
|
disassociation frames are rejected by CCXv5 compliant
|
|
devices.
|
|
|
|
bcastDeauthenticationFrameRcvd - The Access Point
|
|
detected a broadcast deauthentication frame. Broadcast
|
|
deauthentication frames are rejected by CCXv5 compliant
|
|
devices.
|
|
|
|
bcastActionFrameRcvd - The Access Point detected a
|
|
broadcast action frame. Broadcast action frames are
|
|
rejected by CCXv5 compliant devices."
|
|
SYNTAX INTEGER {
|
|
invalidMic(1),
|
|
invalidSeq(2),
|
|
noMic(3),
|
|
unexpectedMic(4),
|
|
ccmpNoEncryptError(16),
|
|
ccmpDecryptError(17),
|
|
ccmpInvalidReplayCtr(19),
|
|
tkipNoEncryptError(20),
|
|
tkipInvalidIcv(21),
|
|
tkipInvalidMic(22),
|
|
tkipInvalidMhdrIe(23),
|
|
tkipInvalidReplayCtr(24),
|
|
bcastDisassociationFrameRcvd(32),
|
|
bcastDeauthenticationFrameRcvd(33),
|
|
bcastActionFrameRcvd(34)
|
|
}
|
|
|
|
CLMfpEventSource ::= TEXTUAL-CONVENTION
|
|
STATUS current
|
|
DESCRIPTION
|
|
"The source of the MFP anomaly event.
|
|
|
|
infrastructureMfp - The source of the MFP event is
|
|
an infrastructure device that implements MFP.
|
|
|
|
clientMfp - The source of the MFP event is a client
|
|
device that implements MFP."
|
|
SYNTAX INTEGER {
|
|
infrastructureMfp(1),
|
|
clientMfp(2)
|
|
}
|
|
|
|
CLMfpVersion ::= TEXTUAL-CONVENTION
|
|
STATUS current
|
|
DESCRIPTION
|
|
"This textual convention lists the versions of
|
|
the MFP protocol."
|
|
SYNTAX INTEGER {
|
|
mfpv1(1),
|
|
mfpv2(2)
|
|
}
|
|
|
|
CLTimeBaseStatus ::= TEXTUAL-CONVENTION
|
|
STATUS current
|
|
DESCRIPTION
|
|
"This textual convention is used to define the
|
|
time synchronization of entities with their
|
|
respective time bases.
|
|
|
|
cTimeBaseInSync - This value indicates that the
|
|
respective entity is in synchronization with
|
|
its time base.
|
|
|
|
cTimeBaseNotInSync - This value indicates that
|
|
the respective entity is not in synchronization
|
|
with its time base."
|
|
SYNTAX INTEGER {
|
|
cTimeBaseInSync(1),
|
|
cTimeBaseNotInSync(2)
|
|
}
|
|
|
|
CLSecEncryptType ::= TEXTUAL-CONVENTION
|
|
STATUS current
|
|
DESCRIPTION
|
|
"This textual convention defines the type of
|
|
encryption to be applied to a WLAN.
|
|
|
|
The semantics are as follows:
|
|
|
|
tkip - This value indicates that TKIP encryption
|
|
is configured for data protection.
|
|
|
|
aes - This value indicates that AES encryption
|
|
is configured for data protection."
|
|
SYNTAX BITS {
|
|
tkip(0),
|
|
aes(1)
|
|
}
|
|
|
|
CLSecKeyFormat ::= TEXTUAL-CONVENTION
|
|
STATUS current
|
|
DESCRIPTION
|
|
"This textual convention defines the type of
|
|
the key configured for encryption."
|
|
SYNTAX INTEGER {
|
|
default(1),
|
|
hex(2),
|
|
ascii(3)
|
|
}
|
|
|
|
CLDot11RfParamMode ::= TEXTUAL-CONVENTION
|
|
STATUS current
|
|
DESCRIPTION
|
|
"This textual convention defines how the RF
|
|
parameters used to manage roaming are chosen
|
|
by the controller.
|
|
|
|
default - controller reverts back to the default
|
|
values specified for the RF parameters.
|
|
|
|
auto - controller determines the RF parameters
|
|
automatically without any input from the end user.
|
|
|
|
custom - controller uses the RF parameters
|
|
configured by the end user. User is allowed to
|
|
configure the parameters only if the mode is set
|
|
to 'custom'."
|
|
SYNTAX INTEGER {
|
|
default(1),
|
|
custom(2),
|
|
auto(3)
|
|
}
|
|
|
|
CLTsmDot11CurrentPackets ::= TEXTUAL-CONVENTION
|
|
STATUS current
|
|
DESCRIPTION
|
|
"The number of packets received over a specified
|
|
period of time."
|
|
SYNTAX Gauge32
|
|
|
|
CLCdpAdvtVersionType ::= TEXTUAL-CONVENTION
|
|
STATUS current
|
|
DESCRIPTION
|
|
"This textual convention lists the versions of
|
|
the CDP protocol in use in LWAPP APs and Controllers."
|
|
SYNTAX INTEGER {
|
|
cdpv1(1),
|
|
cdpv2(2)
|
|
}
|
|
|
|
CLDot11ChannelBandwidth ::= TEXTUAL-CONVENTION
|
|
STATUS current
|
|
DESCRIPTION
|
|
"This textual convention defines the channel
|
|
bandwidth for 802.11n radio interfaces.
|
|
|
|
The semantics are as follows:
|
|
|
|
five - This value indicates that the bandwidth
|
|
is 5 MHz.
|
|
|
|
ten - This value indicates that the bandwidth
|
|
is 10 MHz.
|
|
|
|
twenty - This value indicates that the bandwidth
|
|
is 20 MHz.
|
|
|
|
aboveforty - This value indicates that the bandwidth
|
|
is 40 MHz with the extension channel above the control
|
|
channel.
|
|
|
|
belowforty - This value indicates that the bandwidth
|
|
is 40 MHz with the extension channel below the control
|
|
channel."
|
|
SYNTAX INTEGER {
|
|
five(1),
|
|
ten(2),
|
|
twenty(3),
|
|
aboveforty(4),
|
|
belowforty(5)
|
|
}
|
|
|
|
CLDot11Band ::= TEXTUAL-CONVENTION
|
|
STATUS current
|
|
DESCRIPTION
|
|
"This textual convention defines the 802.11 frequency
|
|
band.
|
|
|
|
The semantics are as follows:
|
|
|
|
band2dot4 - This value indicates that the
|
|
2.4 GHz band is in use.
|
|
|
|
band5 - This value indicates that the
|
|
5 GHz band is in use."
|
|
SYNTAX INTEGER {
|
|
band2dot4(1),
|
|
band5(2)
|
|
}
|
|
|
|
CLApAssocFailureReason ::= TEXTUAL-CONVENTION
|
|
STATUS current
|
|
DESCRIPTION
|
|
"This textual convention defines the possible reasons
|
|
for an AP's failure to get associated to a controller.
|
|
|
|
The semantics are as follows:
|
|
|
|
unknown - The reason for the AP not being able to
|
|
associate is unknown.
|
|
|
|
notSupported - The AP is not supported for management
|
|
by the controller."
|
|
SYNTAX INTEGER {
|
|
unknown(1),
|
|
notSupported(2)
|
|
}
|
|
|
|
END
|
|
|
|
|
|
|