Initial commit
This commit is contained in:
794
MIBS/cisco/CISCO-LWAPP-TC-MIB
Normal file
794
MIBS/cisco/CISCO-LWAPP-TC-MIB
Normal file
@ -0,0 +1,794 @@
|
||||
-- *******************************************************************
|
||||
-- CISCO-LWAPP-TC-MIB.my: Cisco LWAPP MIBs Textual Conventions
|
||||
-- March 2006, Prasanna Viswakumar
|
||||
--
|
||||
-- Copyright (c) 2006, 2007, 2010-2011 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 "201906270000Z"
|
||||
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 "201608230000Z"
|
||||
DESCRIPTION
|
||||
"Added new textual conventions CLApMode"
|
||||
REVISION "201109130000Z"
|
||||
DESCRIPTION
|
||||
"Added new textual conventions CcxServiceVersion"
|
||||
REVISION "201002230000Z"
|
||||
DESCRIPTION
|
||||
"Added new textual conventions CLApDot11RadioRole,
|
||||
CLClientPowerSaveMode,and CLApDot11RadioSubband."
|
||||
REVISION "200709110000Z"
|
||||
DESCRIPTION
|
||||
"Added new textual convention CLWebAuthType."
|
||||
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.
|
||||
|
||||
dot11abgn - This value indicates that the radio
|
||||
interface is operating in XOR mode between 802.11a
|
||||
and 802.11bg.
|
||||
|
||||
uwb - This value indicates that this is a Ultra
|
||||
Wideband Interface."
|
||||
|
||||
SYNTAX INTEGER {
|
||||
dot11bg(1),
|
||||
dot11a(2),
|
||||
uwb(3),
|
||||
dot11abgn(4),
|
||||
unknown(5)
|
||||
}
|
||||
|
||||
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)
|
||||
}
|
||||
|
||||
CLWebAuthType ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"Represents either one of the following web auth types
|
||||
internalDefault(1) -
|
||||
The default login page will be
|
||||
presented to the client for authentication.
|
||||
|
||||
internalCustom(2) -
|
||||
The administrator has created and
|
||||
uploaded a custom login page and it will be
|
||||
presented to the clients for authentication.
|
||||
|
||||
external(3) -
|
||||
This value indicates that the login page
|
||||
will be served from the external web server. Note
|
||||
that cLWAWebAuthType can be successfully set to this
|
||||
value when the cLWAExternalWebAuthURL object has been
|
||||
set to string with non-zero length."
|
||||
SYNTAX INTEGER {
|
||||
internalDefault(1),
|
||||
internalCustom(2),
|
||||
external(3)
|
||||
}
|
||||
|
||||
CLClientPowerSaveMode ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"This textual convention defines power management mode
|
||||
of this client.
|
||||
The possible two modes are:
|
||||
active(1) - The client is not in power-save mode
|
||||
and it is actively sending or receiving
|
||||
data.
|
||||
powersave(2) - The client is in power-save mode and it
|
||||
wakes up once a while to check for
|
||||
pending data."
|
||||
SYNTAX INTEGER {
|
||||
active(1),
|
||||
powersave(2)
|
||||
}
|
||||
|
||||
CLApDot11RadioSubband ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"This textual convention defines the possible values
|
||||
of subbands a radio can support.
|
||||
Currently, this information is applicable to
|
||||
A radios.
|
||||
all(1) - This radio is a regular A radio that operates
|
||||
in the full A band spectrum in the frequency
|
||||
range 4940 Mhz - 5850 Mhz.
|
||||
sub49(2) - This is an A radio that operates only in the
|
||||
public safety (4.9 Ghz) sub band in the
|
||||
frequency range 4940 Mhz - 5100 Mhz.
|
||||
sub52(3) - This is an A radio that operates only in the
|
||||
5.2 Ghz sub band in the frequency range
|
||||
5250 Mhz - 5350 Mhz.
|
||||
sub54(4) - This is an A radio that operates only in the
|
||||
5.4 Ghz sub band in the frequency range
|
||||
5470 Mhz - 5725 Mhz.
|
||||
sub58(5) - This is an A radio that operates only in the
|
||||
5.8 Ghz sub band in the frequency range
|
||||
5725 Mhz - 5850 Mhz."
|
||||
SYNTAX INTEGER {
|
||||
all(1),
|
||||
sub49(2),
|
||||
sub52(3),
|
||||
sub54(4),
|
||||
sub58(5)
|
||||
}
|
||||
|
||||
CLApDot11RadioRole ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"This textual convention defines the possible values
|
||||
of role a radio can support.
|
||||
shutdown(0) - This role states that the radio is
|
||||
shut down.
|
||||
upDownlink(1) - This radio provides both uplink
|
||||
and downlink access.
|
||||
uplink(2) - This role is applicable only for Ethernet
|
||||
ports. This radio provides uplink access.
|
||||
downlink(3) - This radio provides downlink access.
|
||||
downlink radio allows child APs to join.
|
||||
access(4) - This radio provides the access to the
|
||||
clients.
|
||||
uplinkAccess(5) - This radio role states that the radio
|
||||
provides the uplink access to the clients.
|
||||
downlinkAccess(6) - This radio role states that the radio
|
||||
provides the downlink access to
|
||||
the clients.
|
||||
upDownlinkAccess(7) - This radio role states that the radio
|
||||
provides both uplink and downlink access
|
||||
to the clients.
|
||||
unknown(8) - This radio role is unknown."
|
||||
SYNTAX INTEGER {
|
||||
shutdown(0),
|
||||
upDownlink(1),
|
||||
uplink(2),
|
||||
downlink(3),
|
||||
access(4),
|
||||
uplinkAccess(5),
|
||||
downlinkAccess(6),
|
||||
upDownlinkAccess(7),
|
||||
unknown(8)
|
||||
}
|
||||
|
||||
CcxServiceVersion ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"This textual convention defines the service versions
|
||||
supported by a CCX Next client. The supported services
|
||||
include foundation, location, management and voice."
|
||||
SYNTAX INTEGER {
|
||||
none(1),
|
||||
version1(2),
|
||||
version2(3)
|
||||
}
|
||||
|
||||
CLApMode ::= TEXTUAL-CONVENTION
|
||||
STATUS current
|
||||
DESCRIPTION
|
||||
"This textual convention defines the working
|
||||
mode of the AP.
|
||||
local(0) - This mode enables the access points
|
||||
to serve the clients.
|
||||
monitor(1) - This mode enables the access points
|
||||
to monitor all of its cycles scanning
|
||||
the channels and looking for rogues.
|
||||
remote(2) - This mode indicates that AP is a remote
|
||||
edge lightweight access point.
|
||||
rogueDetector(3)- This mode enables the access points
|
||||
to detect the rogue access points.
|
||||
sniffer(4) - This mode enables the access points
|
||||
to sniff packets in a particular channel.
|
||||
bridge(5) - This mode indicates that a root access point.
|
||||
is connected
|
||||
seConnect(6) - This mode enables the access points
|
||||
to join Cisco spectrum expert and
|
||||
perform spectrum intelligence."
|
||||
|
||||
SYNTAX INTEGER {
|
||||
local(0),
|
||||
monitor(1),
|
||||
remote(2),
|
||||
rogueDetector(3),
|
||||
sniffer(4),
|
||||
bridge(5),
|
||||
seConnect(6)
|
||||
}
|
||||
|
||||
END
|
||||
|
Reference in New Issue
Block a user