CISCO-FLASH-MIB
AI MIB Summary
The CISCO-FLASH-MIB enables SNMP-based monitoring and management of non-volatile Flash memory devices on Cisco network hardware, exposing metrics for total capacity, available space, and file system status to facilitate storage utilization tracking and alerting.
This MIB provides for the management of Cisco Flash Devices.
117
Objects
Active
Status
5
Dependencies
Imported Objects
Objects
117 total| Object Name |
|---|
ciscoFlashMIB OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10 |
RFC1155-SMI Unknown .1.3.6.1.4.1.9.9.10 |
ciscoFlashMIBObjects OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.1 |
ciscoFlashDevice OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.1.1 |
ciscoFlashDevicesSupportedNumber of Flash devices supported by the system.
If the system does not support any Flash devices, this
MIB will not be loaded on that system. The value of this
object will therefore be atleast 1.ro INTEGER .1.3.6.1.4.1.9.9.10.1.1.1 |
ciscoFlashDeviceTableTable of Flash device properties for each initialized
Flash device. Each Flash device installed in a system
is detected, sized, and initialized when the system
image boots up.
For removable Flash devices, the device properties
will be dynamically deleted and recreated as the
device is removed and inserted. Note that in this
case, the newly inserted device may not be the same as
the earlier removed one. The ciscoFlashDeviceInitTime
object is available for a management station to determine
the time at which a device was initialized, and thereby
detect the change of a removable device.
A removable device that has not been installed will
also have an entry in this table. This is to let a
management station know about a removable device that
has been removed. Since a removed device obviously
cannot be sized and initialized, the table entry for
such a device will have
ciscoFlashDeviceSize equal to zero,
and the following objects will have
an indeterminate value:
ciscoFlashDeviceMinPartitionSize,
ciscoFlashDeviceMaxPartitions,
ciscoFlashDevicePartitions, and
ciscoFlashDeviceChipCount.
ciscoFlashDeviceRemovable will be
true to indicate it is removable. SEQUENCE OF CiscoFlashDeviceEntry .1.3.6.1.4.1.9.9.10.1.1.2 |
ciscoFlashDeviceEntryAn entry in the table of flash device properties for
each initialized flash device.
Each entry can be randomly accessed by using
ciscoFlashDeviceIndex as an index into the table.
Note that removable devices will have an entry in
the table even when they have been removed. However,
a non-removable device that has not been installed
will not have an entry in the table. CiscoFlashDeviceEntry .1.3.6.1.4.1.9.9.10.1.1.2.1 |
ciscoFlashDeviceIndexFlash device sequence number to index within the
table of initialized flash devices.
The lowest value should be 1. The highest should be
less than or equal to the value of the
ciscoFlashDevicesSupported object. INTEGER .1.3.6.1.4.1.9.9.10.1.1.2.1.1 |
ciscoFlashDeviceSizeTotal size of the Flash device.
For a removable device, the size will be zero if
the device has been removed.ro INTEGER -- Units -- bytes .1.3.6.1.4.1.9.9.10.1.1.2.1.2 |
ciscoFlashDeviceMinPartitionSizeThis object will give the minimum partition size
supported for this device. For systems that execute code
directly out of Flash, the minimum partition size needs
to be the bank size. (Bank size is equal to the size of a
chip multiplied by the width of the device. In most cases,
the device width is 4 bytes, and so the bank size would be
four times the size of a chip). This has to be so because
all programming commands affect the operation of an
entire chip (in our case, an entire bank because all
operations are done on the entire width of the device)
even though the actual command may be localized to a small
portion of each chip. So when executing code out of Flash,
one needs to be able to write and erase some portion of
Flash without affecting the code execution.
For systems that execute code out of DRAM or ROM, it is
possible to partition Flash with a finer granularity (for
eg., at erase sector boundaries) if the system code supports
such granularity.
This object will let a management entity know the
minimum partition size as defined by the system.
If the system does not support partitioning, the value
will be equal to the device size in ciscoFlashDeviceSize.
The maximum number of partitions that could be configured
will be equal to the minimum of
ciscoFlashDeviceMaxPartitions
and
(ciscoFlashDeviceSize / ciscoFlashDeviceMinPartitionSize).ro INTEGER -- Units -- bytes .1.3.6.1.4.1.9.9.10.1.1.2.1.3 |
ciscoFlashDeviceMaxPartitionsMax number of partitions supported by the system for
this Flash device. Default will be 1, which actually
means that partitioning is not supported. Note that
this value will be defined by system limitations, not
by the flash device itself (for eg., the system may
impose a limit of 2 partitions even though the device
may be large enough to be partitioned into 4 based on
the smallest partition unit supported).
On systems that execute code out of Flash, partitioning
is a way of creating multiple file systems in the Flash
device so that writing into or erasing of one file system
can be done while executing code residing in another file
system.
For systems executing code out of DRAM, partitioning
gives a way of sub-dividing a large Flash device for
easier management of files.ro INTEGER .1.3.6.1.4.1.9.9.10.1.1.2.1.4 |
ciscoFlashDevicePartitionsFlash device partitions actually present. Number of
partitions cannot exceed the minimum of
ciscoFlashDeviceMaxPartitions
and
(ciscoFlashDeviceSize / ciscoFlashDeviceMinPartitionSize).
Will be equal to at least 1, the case where the partition
spans the entire device (actually no partitioning).
A partition will contain one or more minimum partition
units (where a minimum partition unit is defined by
ciscoFlashDeviceMinPartitionSize).ro INTEGER .1.3.6.1.4.1.9.9.10.1.1.2.1.5 |
ciscoFlashDeviceChipCountTotal number of chips within the Flash device.
The purpose of this object is to provide information
upfront to a management station on how much chip info
to expect and possibly help double check the chip index
against an upper limit when randomly retrieving chip
info for a partition.ro INTEGER .1.3.6.1.4.1.9.9.10.1.1.2.1.6 |
ciscoFlashDeviceNameFlash device name. This name is used to refer to the
device within the system. Flash operations get directed
to a device based on this name.
The system has a concept of a default device.
This would be the primary or most used device in case of
multiple devices. The system directs an operation to the
default device whenever a device name is not specified.
The device name is therefore mandatory except when the
operation is being done on the default device, or,
the system supports only a single Flash device.
The device name will always be available for a
removable device, even when the device has been removed.ro DisplayString .1.3.6.1.4.1.9.9.10.1.1.2.1.7 |
ciscoFlashDeviceDescrDescription of a Flash device. The description is meant
to explain what the Flash device and its purpose is.
Current values are:
System flash - for the primary Flash used to store full
system images.
Boot flash - for the secondary Flash used to store
bootstrap images.
The ciscoFlashDeviceDescr, ciscoFlashDeviceController
(if applicable), and ciscoFlashDeviceCard objects are
expected to collectively give all information about a
Flash device.
The device description will always be available for a
removable device, even when the device has been removed.ro DisplayString .1.3.6.1.4.1.9.9.10.1.1.2.1.8 |
ciscoFlashDeviceControllerFlash device controller. The h/w card that actually
controls Flash read/write/erase. Relevant for the AGS+
systems where Flash may be controlled by the MC+, STR or
the ENVM cards, cards that may not actually contain the
Flash chips.
For systems that have removable PCMCIA flash cards that
are controlled by a PCMCIA controller chip, this object
may contain a description of that controller chip.
Where irrelevant (Flash is a direct memory mapped device
accessed directly by the main processor), this object will
have an empty (NULL) string.ro DisplayString .1.3.6.1.4.1.9.9.10.1.1.2.1.9 |
ciscoFlashDeviceCardThis object will point to an instance of a card entry
in the cardTable. The card entry will give details about
the card on which the Flash device is actually located.
For most systems, this is usually the main processor board.
On the AGS+ systems, Flash is located on a separate multibus
card such as the MC.
This object will therefore be used to essentially index
into cardTable to retrieve details about the card such as
cardDescr, cardSlotNumber, etc.ro InstancePointer -- Rsyntax OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.1.1.2.1.10 |
ciscoFlashDeviceProgrammingJumperThis object gives the state of a jumper (if present and can be
determined) that controls the programming voltage called Vpp
to the Flash device. Vpp is required for programming (erasing
and writing) Flash. For certain older technology chips it is
also required for identifying the chips (which in turn is
required to identify which programming algorithms to use;
different chips require different algorithms and commands).
The purpose of the jumper, on systems where it is available,
is to write protect a Flash device.
On most of the newer remote access routers, this jumper is
unavailable since users are not expected to visit remote sites
just to install and remove the jumpers when upgrading software
in the Flash device. The unknown(3) value will be returned for
such systems and can be interpreted to mean that a programming
jumper is not present or not required on those systems.
On systems where the programming jumper state can be read back
via a hardware register, the installed(1) or notInstalled(2)
value will be returned.
This object is expected to be used in conjunction with the
ciscoFlashPartitionStatus object whenever that object has
the readOnly(1) value. In such a case, this object will
indicate whether the programming jumper is a possible reason
for the readOnly state.ro Enumeration .1.3.6.1.4.1.9.9.10.1.1.2.1.11 |
ciscoFlashDeviceInitTimeSystem time at which device was initialized.
For fixed devices, this will be the system time at
boot up.
For removable devices, it will be the time at which
the device was inserted, which may be boot up time,
or a later time (if device was inserted later).
If a device (fixed or removable) was repartitioned,
it will be the time of repartitioning.
The purpose of this object is to help a management
station determine if a removable device has been
changed. The application should retrieve this
object prior to any operation and compare with
the previously retrieved value.
Note that this time will not be real time but a
running time maintained by the system. This running
time starts from zero when the system boots up.
For a removable device that has been removed, this
value will be zero.ro TimeStamp -- Rsyntax TimeTicks .1.3.6.1.4.1.9.9.10.1.1.2.1.12 |
ciscoFlashDeviceRemovableWhether Flash device is removable. Generally, only PCMCIA
Flash cards will be treated as removable. Socketed Flash
chips and Flash SIMM modules will not be treated as removable.
Simply put, only those Flash devices that can be inserted
or removed without opening the hardware casing will be
considered removable.
Further, removable Flash devices are expected to have
the necessary hardware support -
1. on-line removal and insertion
2. interrupt generation on removal or insertion.ro TruthValue -- Rsyntax INTEGER { -- true(1), -- false(2) -- } .1.3.6.1.4.1.9.9.10.1.1.2.1.13 |
ciscoFlashChips OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.1.1.3 |
ciscoFlashChipTableTable of Flash device chip properties for each
initialized Flash device.
This table is meant primarily for aiding error
diagnosis. SEQUENCE OF CiscoFlashChipEntry .1.3.6.1.4.1.9.9.10.1.1.3.1 |
ciscoFlashChipEntryAn entry in the table of chip info for each
flash device initialized in the system.
An entry is indexed by two objects - the
device index and the chip index within that
device. CiscoFlashChipEntry .1.3.6.1.4.1.9.9.10.1.1.3.1.1 |
ciscoFlashChipIndexChip sequence number within selected flash device.
Used to index within chip info table.
Value starts from 1 and should not be greater than
ciscoFlashDeviceChipCount for that device.
When retrieving chip information for chips within a
partition, the sequence number should lie between
ciscoFlashPartitionStartChip & ciscoFlashPartitionEndChip
(both inclusive). INTEGER .1.3.6.1.4.1.9.9.10.1.1.3.1.1.1 |
ciscoFlashChipCodeManufacturer and device code for a chip.
Lower byte will contain the device code.
Upper byte will contain the manufacturer code.
If a chip code is unknown because it could not
be queried out of the chip, the value of this
object will be 00:00.
Since programming algorithms differ from chip type to
chip type, this chip code should be used to determine
which algorithms to use (and thereby whether the chip
is supported in the first place).ro DisplayString .1.3.6.1.4.1.9.9.10.1.1.3.1.1.2 |
ciscoFlashChipDescrFlash chip name corresponding to the chip code.
The name will contain the manufacturer and the
chip type. It will be of the form :
Intel 27F008SA.
In the case where a chip code is unknown, this
object will be an empty (NULL) string.
In the case where the chip code is known but the
chip is not supported by the system, this object
will be an empty (NULL) string.
A management station is therefore expected to use the
chip code and the chip description in conjunction
to provide additional information whenever the
ciscoFlashPartitionStatus object has the readOnly(1)
value.ro DisplayString .1.3.6.1.4.1.9.9.10.1.1.3.1.1.3 |
ciscoFlashChipWriteRetriesThis object will provide a cumulative count
(since last system boot up or initialization) of
the number of write retries that were done in the chip.
If no writes have been done to Flash, the count
will be zero. Typically, a maximum of 25 retries are
done on a single location before flagging a write
error.
A management station is expected to get this object
for each chip in a partition after a write failure
in that partition. To keep a track of retries for
a given write operation, the management station would
have to retrieve the values for the concerned chips
before and after any write operation.ro Counter .1.3.6.1.4.1.9.9.10.1.1.3.1.1.4 |
ciscoFlashChipEraseRetriesThis object will provide a cumulative count
(since last system boot up or initialization) of
the number of erase retries that were done in the chip.
Typically, a maximum of 2000 retries are done in a
single erase zone (which may be a full chip or a
portion, depending on the chip technology) before
flagging an erase error.
A management station is expected to get this object
for each chip in a partition after an erase failure
in that partition. To keep a track of retries for
a given erase operation, the management station would
have to retrieve the values for the concerned chips
before and after any erase operation.
Note that erase may be done through an independent
command, or through a copy-to-flash command.ro Counter .1.3.6.1.4.1.9.9.10.1.1.3.1.1.5 |
ciscoFlashChipMaxWriteRetriesThe maximum number of write retries done at any
single location before declaring a write failure.ro INTEGER .1.3.6.1.4.1.9.9.10.1.1.3.1.1.6 |
ciscoFlashChipMaxEraseRetriesThe maximum number of erase retries done within
an erase sector before declaring an erase failure.ro INTEGER .1.3.6.1.4.1.9.9.10.1.1.3.1.1.7 |
ciscoFlashPartitions OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.1.1.4 |
ciscoFlashPartitionTableTable of flash device partition properties for each
initialized flash partition. Whenever there is no
explicit partitioning done, a single partition spanning
the entire device will be assumed to exist. There will
therefore always be atleast one partition on a device. SEQUENCE OF CiscoFlashPartitionEntry .1.3.6.1.4.1.9.9.10.1.1.4.1 |
ciscoFlashPartitionEntryAn entry in the table of flash partition properties
for each initialized flash partition. Each entry
will be indexed by a device number and a partition
number within the device. CiscoFlashPartitionEntry .1.3.6.1.4.1.9.9.10.1.1.4.1.1 |
ciscoFlashPartitionIndexFlash partition sequence number used to index within
table of initialized flash partitions. INTEGER .1.3.6.1.4.1.9.9.10.1.1.4.1.1.1 |
ciscoFlashPartitionStartChipChip sequence number of first chip in partition.
Used as an index into the chip table.ro INTEGER .1.3.6.1.4.1.9.9.10.1.1.4.1.1.2 |
ciscoFlashPartitionEndChipChip sequence number of last chip in partition.
Used as an index into the chip table.ro INTEGER .1.3.6.1.4.1.9.9.10.1.1.4.1.1.3 |
ciscoFlashPartitionSizeFlash partition size. It should be an integral
multiple of ciscoFlashDeviceMinPartitionSize.
If there is a single partition, this size will be equal
to ciscoFlashDeviceSize.ro INTEGER -- Units -- bytes .1.3.6.1.4.1.9.9.10.1.1.4.1.1.4 |
ciscoFlashPartitionFreeSpaceFree space within a Flash partition.
Note that the actual size of a file in Flash includes
a small overhead that represents the file system's
file header.
Certain file systems may also have a partition or
device header overhead to be considered when
computing the free space.
Free space will be computed as total partition size
less size of all existing files (valid/invalid/deleted
files and including file header of each file),
less size of any partition header, less size of
header of next file to be copied in. In short, this
object will give the size of the largest file that
can be copied in. The management entity will not be
expected to know or use any overheads such as file
and partition header lengths, since such overheads
may vary from file system to file system.
Deleted files in Flash do not free up space.
A partition may have to be erased in order to reclaim
the space occupied by files.ro Gauge -- Units -- bytes .1.3.6.1.4.1.9.9.10.1.1.4.1.1.5 |
ciscoFlashPartitionFileCountCount of all files in a flash partition. Both
good and bad (deleted or invalid checksum) files
will be included in this count.ro INTEGER .1.3.6.1.4.1.9.9.10.1.1.4.1.1.6 |
ciscoFlashPartitionChecksumAlgorithmChecksum algorithm identifier for checksum method
used by the file system. Normally, this would be
fixed for a particular file system. When a file
system writes a file to Flash, it checksums the
data written. The checksum then serves as a way
to validate the data read back whenever the file
is opened for reading.
Since there is no way, when using TFTP, to guarantee
that a network download has been error free (since
UDP checksums may not have been enabled), this
object together with the ciscoFlashFileChecksum
object provides a method for any management station
to regenerate the checksum of the original file
on the server and compare checksums to ensure that
the file download to Flash was error free.
simpleChecksum represents a simple 1s complement
addition of short word values. Other algorithm
values will be added as necessary.ro Enumeration .1.3.6.1.4.1.9.9.10.1.1.4.1.1.7 |
ciscoFlashPartitionStatusFlash partition status can be :
* readOnly if device is not programmable either because
chips could not be recognized or an erroneous mismatch
of chips was detected. Chip recognition may fail either
because the chips are not supported by the system,
or because the Vpp voltage required to identify chips
has been disabled via the programming jumper.
The ciscoFlashDeviceProgrammingJumper, ciscoFlashChipCode,
and ciscoFlashChipDescr objects can be examined to get
more details on the cause of this status
* runFromFlash (RFF) if current image is running from
this partition.
The ciscoFlashPartitionUpgradeMethod object will then
indicate whether the Flash Load Helper can be used
to write a file to this partition or not.
* readWrite if partition is programmable.ro Enumeration .1.3.6.1.4.1.9.9.10.1.1.4.1.1.8 |
ciscoFlashPartitionUpgradeMethodFlash partition upgrade method, ie., method by which
new files can be downloaded into the partition.
FLH stands for Flash Load Helper, a feature provided
on run-from-Flash systems for upgrading Flash. This
feature uses the bootstrap code in ROMs to help in
automatic download.
This object should be retrieved if the partition
status is runFromFlash(2).
If the partition status is readOnly(1), the upgrade
method would depend on the reason for the readOnly
status. For eg., it may simply be a matter of installing
the programming jumper, or it may require execution of a
later version of software that supports the Flash chips.
unknown - the current system image does not know
how Flash can be programmed. A possible
method would be to reload the ROM image
and perform the upgrade manually.
rxbootFLH - the Flash Load Helper is available to
download files to Flash. A copy-to-flash
command can be used and this system image
will automatically reload the Rxboot image
in ROM and direct it to carry out the
download request.
direct - will be done directly by this image.ro Enumeration .1.3.6.1.4.1.9.9.10.1.1.4.1.1.9 |
ciscoFlashPartitionNameFlash partition name used to refer to a partition
by the system. This can be any alpha-numeric character
string of the form AAAAAAAAnn, where A represents an
optional alpha character and n a numeric character.
Any numeric characters must always form the trailing
part of the string. The system will strip off the alpha
characters and use the numeric portion to map to a
partition index.
Flash operations get directed to a device partition
based on this name.
The system has a concept of a default partition. This
would be the first partition in the device. The system
directs an operation to the default partition whenever
a partition name is not specified.
The partition name is therefore mandatory except when
the operation is being done on the default partition, or
the device has just one partition (is not partitioned).ro DisplayString .1.3.6.1.4.1.9.9.10.1.1.4.1.1.10 |
ciscoFlashPartitionNeedErasureThis object indicates whether a partition requires
erasure before any write operations can be done in it.
A management station should therefore retrieve this
object prior to attempting any write operation.
A partition requires erasure after it becomes full
free space left is less than or equal to the
(filesystem file header size).
A partition also requires erasure if the system does
not find the existence of any file system when it
boots up.
The partition may be erased explicitly through the
erase(5) command, or by using the copyToFlashWithErase(1)
command.
If a copyToFlashWithoutErase(2) command is issued
when this object has the TRUE value, the command
will fail.ro TruthValue -- Rsyntax INTEGER { -- true(1), -- false(2) -- } .1.3.6.1.4.1.9.9.10.1.1.4.1.1.11 |
ciscoFlashPartitionFileNameLengthMaximum file name length supported by the file
system.
Max file name length will depend on the file
system implemented. Today, all file systems
support a max length of at least 48 bytes.
A management entity must use this object when
prompting a user for, or deriving the Flash file
name length.ro INTEGER .1.3.6.1.4.1.9.9.10.1.1.4.1.1.12 |
ciscoFlashFiles OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.1.1.4.2 |
ciscoFlashFileTableTable of information for files in a Flash partition. SEQUENCE OF CiscoFlashFileEntry .1.3.6.1.4.1.9.9.10.1.1.4.2.1 |
ciscoFlashFileEntryAn entry in the table of Flash file properties
for each initialized Flash partition. Each entry
represents a file and gives details about the file.
An entry is indexed using the device number,
partition number within the device, and file
number within the partition. CiscoFlashFileEntry .1.3.6.1.4.1.9.9.10.1.1.4.2.1.1 |
ciscoFlashFileIndexFlash file sequence number used to index within
a Flash partition directory table. INTEGER .1.3.6.1.4.1.9.9.10.1.1.4.2.1.1.1 |
ciscoFlashFileSizeSize of the file in bytes. Note that this size does
not include the size of the filesystem file header.
File size will always be non-zero.ro INTEGER .1.3.6.1.4.1.9.9.10.1.1.4.2.1.1.2 |
ciscoFlashFileChecksumFile checksum stored in the file header. This
checksum is computed and stored when the file is
written into Flash. It serves to validate the data
written into Flash.
Whereas the system will generate and store the checksum
internally in hexadecimal form, this object will
provide the checksum in a string form.
The checksum will be available for all valid and
invalid-checksum files.ro ChecksumString -- Rsyntax OCTET STRING .1.3.6.1.4.1.9.9.10.1.1.4.2.1.1.3 |
ciscoFlashFileStatusStatus of a file.
A file could be explicitly deleted if the file system
supports such a user command facility. Alternately,
an existing good file would be automatically deleted
if another good file with the same name were copied in.
Note that deleted files continue to occupy prime
Flash real estate.
A file is marked as having an invalid checksum if any
checksum mismatch was detected while writing or reading
the file. Incomplete files (files truncated either
because of lack of free space, or a network download
failure) are also written with a bad checksum and
marked as invalid.ro Enumeration .1.3.6.1.4.1.9.9.10.1.1.4.2.1.1.4 |
ciscoFlashFileNameFlash file name as specified by the user copying in
the file. The name should not include the colon (:)
character as it is a special separator character used
to delineate the device name, partition name, and the
file name.ro DisplayString .1.3.6.1.4.1.9.9.10.1.1.4.2.1.1.5 |
ciscoFlashFileTypeType of the file.ro FlashFileType -- Rsyntax INTEGER { -- unknown(1), -- config(2), -- image(3), -- directory(4), -- crashinfo(5) -- } .1.3.6.1.4.1.9.9.10.1.1.4.2.1.1.6 |
ciscoFlashOps OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.1.2 |
ciscoFlashCopyTableA table of Flash copy operation entries. Each
entry represents a Flash copy operation (to or
from Flash) that has been initiated. SEQUENCE OF CiscoFlashCopyEntry .1.3.6.1.4.1.9.9.10.1.2.1 |
ciscoFlashCopyEntryA Flash copy operation entry. Each entry consists
of a command, a source, and optional parameters such
as protocol to be used, a destination, a server address,
etc.
A management station wishing to create an entry should
first generate a pseudo-random serial number to be used
as the index to this sparse table. The station should
then create the associated instance of the row status
object. It must also, either in the same or in successive
PDUs, create the associated instance of the command and
parameter objects. It should also modify the default values
for any of the parameter objects if the defaults are not
appropriate.
Once the appropriate instances of all the command
objects have been created, either by an explicit SNMP
set request or by default, the row status should be set
to active to initiate the operation. Note that this entire
procedure may be initiated via a single set request which
specifies a row status of createAndGo as well as specifies
valid values for the non-defaulted parameter objects.
Once an operation has been activated, it cannot be
stopped.
Once the operation completes, the management station should
retrieve the value of the status object (and time if
desired), and delete the entry. In order to prevent old
entries from clogging the table, entries will be aged out,
but an entry will never be deleted within 5 minutes of
completing. CiscoFlashCopyEntry .1.3.6.1.4.1.9.9.10.1.2.1.1 |
ciscoFlashCopySerialNumberObject which specifies a unique entry in the
table. A management station wishing to initiate a
copy operation should use a pseudo-random value for
this object when creating or modifying an instance of
a ciscoFlashCopyEntry. INTEGER .1.3.6.1.4.1.9.9.10.1.2.1.1.1 |
ciscoFlashCopyCommandThe copy command to be executed. Mandatory.
Note that it is possible for a system to support
multiple file systems (different file systems on
different Flash devices, or different file systems
on different partitions within a device). Each such
file system may support only a subset of these commands.
If a command is unsupported, the invalidOperation(3)
error will be reported in the operation status.
Command Remarks
copyToFlashWithErase Copy a file to flash; erase
flash before copy.
Use the TFTP or rcp protocol.
copyToFlashWithoutErase Copy a file to flash; do not
erase.
Note that this command will fail
if the PartitionNeedErasure
object specifies that the
partition being copied to needs
erasure.
Use the TFTP or rcp protocol.
copyFromFlash Copy a file from flash using
the TFTP, rcp or lex protocol.
Note that the lex protocol
can only be used to copy to a
lex device.
copyFromFlhLog Copy contents of FLH log to
server using TFTP protocol.
Command table Parameters
copyToFlashWithErase CopyProtocol
CopyServerAddress
CopySourceName
CopyDestinationName (opt)
CopyRemoteUserName (opt)
CopyNotifyOnCompletion (opt)
copyToFlashWithoutErase CopyProtocol
CopyServerAddress
CopySourceName
CopyDestinationName (opt)
CopyRemoteUserName (opt)
CopyNotifyOnCompletion (opt)
copyFromFlash CopyProtocol
CopyServerAddress
CopySourceName
CopyDestinationName (opt)
CopyRemoteUserName (opt)
CopyNotifyOnCompletion (opt)
copyFromFlhLog CopyProtocol
CopyServerAddress
CopyDestinationName
CopyNotifyOnCompletion (opt)rw Enumeration .1.3.6.1.4.1.9.9.10.1.2.1.1.2 |
ciscoFlashCopyProtocolThe protocol to be used for any copy. Optional.
Will default to tftp if not specified.
Since feature support depends on a software release,
version number within the release, platform, and
maybe the image type (subset type), a management
station would be expected to somehow determine
the protocol support for a command.rw Enumeration .1.3.6.1.4.1.9.9.10.1.2.1.1.3 |
ciscoFlashCopyServerAddressThe server address to be used for any copy. Optional.
Will default to 'FFFFFFFF'H (or 255.255.255.255).rw IpAddress .1.3.6.1.4.1.9.9.10.1.2.1.1.4 |
ciscoFlashCopySourceNameSource file name, either in Flash or on a server,
depending on the type of copy command. Mandatory.
For a copy from Flash:
File name must be of the form
[device>:][<partition>:]<file>
where <device> is a value obtained from FlashDeviceName,
<partition> is obtained from FlashPartitionName
and <file> is the name of a file in Flash.
A management station could derive its own partition name
as per the description for the ciscoFlashPartitionName
object.
If <device> is not specified, the default Flash device
will be assumed.
If <partition> is not specified, the default partition
will be assumed. If a device is not partitioned into 2
or more partitions, this value may be left out.
For a copy to Flash, the file name will be as per
the file naming conventions and path to the file on
the server.rw DisplayString .1.3.6.1.4.1.9.9.10.1.2.1.1.5 |
ciscoFlashCopyDestinationNameDestination file name.
For a copy to Flash:
File name must be of the form
{device>:][<partition>:]<file>
where <device> is a value obtained from FlashDeviceName,
<partition> is obtained from FlashPartitionName
and <file> is any character string that does not have
embedded colon characters.
A management station could derive its own partition name
as per the description for the ciscoFlashPartitionName
object.
If <device> is not specified, the default Flash device
will be assumed.
If <partition> is not specified, the default partition
will be assumed. If a device is not partitioned into 2
or more partitions, this value may be left out.
If <file> is not specified, it will default to <file>
specified in ciscoFlashCopySourceName.
For a copy from Flash via tftp or rcp, the file name will be
as per the file naming conventions and destination sub-directory
on the server. If not specified, <file> from the source
file name will be used.
For a copy from Flash via lex, this string will consist
of numeric characters specifying the interface on the
lex box that will receive the source flash image.rw DisplayString .1.3.6.1.4.1.9.9.10.1.2.1.1.6 |
ciscoFlashCopyRemoteUserNameRemote user name for copy via rcp protocol. Optional.
This object will be ignored for protocols other than
rcp.
If specified, it will override the remote user-name
configured through the
rcmd remote-username <username>
configuration command.
The remote user-name is sent as the server user-name
in an rcp command request sent by the system to a
remote rcp server.rw DisplayString .1.3.6.1.4.1.9.9.10.1.2.1.1.7 |
ciscoFlashCopyStatusThe status of the specified copy operation.
copyInProgress :
specified operation is active
copyOperationSuccess :
specified operation is supported and
completed successfully
copyInvalidOperation :
command invalid or command-protocol-device
combination unsupported
copyInvalidProtocol :
invalid protocol specified
copyInvalidSourceName :
invalid source file name specified
For the copy from flash to lex operation, this
error code will be returned when the source file
is not a valid lex image.
copyInvalidDestName :
invalid target name (file or partition or
device name) specified
For the copy from flash to lex operation, this
error code will be returned when no lex devices
are connected to the router or when an invalid
lex interface number has been specified in
the destination string.
copyInvalidServerAddress :
invalid server address specified
copyDeviceBusy :
specified device is in use and locked by
another process
copyDeviceOpenError :
invalid device name
copyDeviceError :
device read, write or erase error
copyDeviceNotProgrammable :
device is read-only but a write or erase
operation was specified
copyDeviceFull :
device is filled to capacity
copyFileOpenError :
invalid file name; file not found in partition
copyFileTransferError :
file transfer was unsuccessfull; network failure
copyFileChecksumError :
file checksum in Flash failed
copyNoMemory :
system running low on memory
copyUnknownFailure :
failure unknownro Enumeration .1.3.6.1.4.1.9.9.10.1.2.1.1.8 |
ciscoFlashCopyNotifyOnCompletionSpecifies whether or not a notification should be
generated on the completion of the copy operation.
If specified, ciscoFlashCopyCompletionTrap
will be generated. It is the responsibility of the
management entity to ensure that the SNMP administrative
model is configured in such a way as to allow the
notification to be delivered.rw TruthValue -- Rsyntax INTEGER { -- true(1), -- false(2) -- } .1.3.6.1.4.1.9.9.10.1.2.1.1.9 |
ciscoFlashCopyTimeTime taken for the copy operation. This object will
be like a stopwatch, starting when the operation
starts, stopping when the operation completes.
If a management entity keeps a database of completion
times for various operations, it can then use the
stopwatch capability to display percentage completion
time.ro TimeTicks (SNMPv2-SMI) .1.3.6.1.4.1.9.9.10.1.2.1.1.10 |
ciscoFlashCopyEntryStatusThe status of this table entry.rw RowStatus -- Rsyntax INTEGER { -- active(1), -- notInService(2), -- notReady(3), -- createAndGo(4), -- createAndWait(5), -- destroy(6) -- } .1.3.6.1.4.1.9.9.10.1.2.1.1.11 |
ciscoFlashPartitioningTableA table of Flash partitioning operation entries. Each
entry represents a Flash partitioning operation that
has been initiated. SEQUENCE OF CiscoFlashPartitioningEntry .1.3.6.1.4.1.9.9.10.1.2.2 |
ciscoFlashPartitioningEntryA Flash partitioning operation entry. Each entry
consists of the command, the target device, the
partition count, and optionally the partition sizes.
A management station wishing to create an entry should
first generate a pseudo-random serial number to be used
as the index to this sparse table. The station should
then create the associated instance of the row status
object. It must also, either in the same or in successive
PDUs, create the associated instance of the command and
parameter objects. It should also modify the default values
for any of the parameter objects if the defaults are not
appropriate.
Once the appropriate instances of all the command
objects have been created, either by an explicit SNMP
set request or by default, the row status should be set
to active to initiate the operation. Note that this entire
procedure may be initiated via a single set request which
specifies a row status of createAndGo as well as specifies
valid values for the non-defaulted parameter objects.
Once an operation has been activated, it cannot be
stopped.
Once the operation completes, the management station should
retrieve the value of the status object (and time if
desired), and delete the entry. In order to prevent old
entries from clogging the table, entries will be aged out,
but an entry will never be deleted within 5 minutes of
completing. CiscoFlashPartitioningEntry .1.3.6.1.4.1.9.9.10.1.2.2.1 |
ciscoFlashPartitioningSerialNumberObject which specifies a unique entry in the partitioning
operations table. A management station wishing to initiate
a partitioning operation should use a pseudo-random value
for this object when creating or modifying an instance of
a ciscoFlashPartitioningEntry. INTEGER .1.3.6.1.4.1.9.9.10.1.2.2.1.1 |
ciscoFlashPartitioningCommandThe partitioning command to be executed. Mandatory.
If the command is unsupported, the
partitioningInvalidOperation
error will be reported in the operation status.
Command Remarks
partition Partition a Flash device.
All the prerequisites for
partitioning must be met for
this command to succeed.
Command table Parameters
1) partition PartitioningDestinationName
PartitioningPartitionCount
PartitioningPartitionSizes (opt)
PartitioningNotifyOnCompletion (opt)rw Enumeration .1.3.6.1.4.1.9.9.10.1.2.2.1.2 |
ciscoFlashPartitioningDestinationNameDestination device name. This name will be the value
obtained from FlashDeviceName.
If the name is not specified, the default Flash device
will be assumed.rw DisplayString .1.3.6.1.4.1.9.9.10.1.2.2.1.3 |
ciscoFlashPartitioningPartitionCountThis object is used to specify the number of
partitions to be created. Its value cannot exceed
the value of ciscoFlashDeviceMaxPartitions.
To undo partitioning (revert to a single partition),
this object must have the value 1.rw INTEGER .1.3.6.1.4.1.9.9.10.1.2.2.1.4 |
ciscoFlashPartitioningPartitionSizesThis object is used to explicitly specify the size
of each partition to be created.
The size of each partition will be in units of
ciscoFlashDeviceMinPartitionSize.
The value of this object will be in the form:
<part1>:<part2>...:<partn>
If partition sizes are not specified, the system
will calculate default sizes based on the partition
count, the minimum partition size, and the device
size. Partition size need not be specified when
undoing partitioning (partition count is 1).
If partition sizes are specified, the number of
sizes specified must exactly match the partition
count. If not, the partitioning command will be
rejected with the invalidPartitionSizes error .rw DisplayString -- Rsyntax OCTET STRING .1.3.6.1.4.1.9.9.10.1.2.2.1.5 |
ciscoFlashPartitioningStatusThe status of the specified partitioning operation.
partitioningInProgress :
specified operation is active
partitioningOperationSuccess :
specified operation is supported and completed
successfully
partitioningInvalidOperation :
command invalid or command-protocol-device
combination unsupported
partitioningInvalidDestName :
invalid target name (file or partition or
device name) specified
partitioningInvalidPartitionCount :
invalid partition count specified for the
partitioning command
partitioningInvalidPartitionSizes :
invalid partition size, or invalid count of
partition sizes
partitioningDeviceBusy :
specified device is in use and locked by
another process
partitioningDeviceOpenError :
invalid device name
partitioningDeviceError :
device read, write or erase error
partitioningNoMemory :
system running low on memory
partitioningUnknownFailure :
failure unknownro Enumeration .1.3.6.1.4.1.9.9.10.1.2.2.1.6 |
ciscoFlashPartitioningNotifyOnCompletionSpecifies whether or not a notification should be
generated on the completion of the partitioning operation.
If specified, ciscoFlashPartitioningCompletionTrap
will be generated. It is the responsibility of the
management entity to ensure that the SNMP administrative
model is configured in such a way as to allow the
notification to be delivered.rw TruthValue -- Rsyntax INTEGER { -- true(1), -- false(2) -- } .1.3.6.1.4.1.9.9.10.1.2.2.1.7 |
ciscoFlashPartitioningTimeTime taken for the operation. This object will
be like a stopwatch, starting when the operation
starts, stopping when the operation completes.
If a management entity keeps a database of completion
times for various operations, it can then use the
stopwatch capability to display percentage completion
time.ro TimeTicks (SNMPv2-SMI) .1.3.6.1.4.1.9.9.10.1.2.2.1.8 |
ciscoFlashPartitioningEntryStatusThe status of this table entry.rw RowStatus -- Rsyntax INTEGER { -- active(1), -- notInService(2), -- notReady(3), -- createAndGo(4), -- createAndWait(5), -- destroy(6) -- } .1.3.6.1.4.1.9.9.10.1.2.2.1.9 |
ciscoFlashMiscOpTableA table of misc Flash operation entries. Each
entry represents a Flash operation that
has been initiated. SEQUENCE OF CiscoFlashMiscOpEntry .1.3.6.1.4.1.9.9.10.1.2.3 |
ciscoFlashMiscOpEntryA Flash operation entry. Each entry consists of a
command, a target, and any optional parameters.
A management station wishing to create an entry should
first generate a pseudo-random serial number to be used
as the index to this sparse table. The station should
then create the associated instance of the row status
object. It must also, either in the same or in successive
PDUs, create the associated instance of the command and
parameter objects. It should also modify the default values
for any of the parameter objects if the defaults are not
appropriate.
Once the appropriate instances of all the command
objects have been created, either by an explicit SNMP
set request or by default, the row status should be set
to active to initiate the operation. Note that this entire
procedure may be initiated via a single set request which
specifies a row status of createAndGo as well as specifies
valid values for the non-defaulted parameter objects.
Once an operation has been activated, it cannot be
stopped.
Once the operation completes, the management station should
retrieve the value of the status object (and time if
desired), and delete the entry. In order to prevent old
entries from clogging the table, entries will be aged out,
but an entry will never be deleted within 5 minutes of
completing. CiscoFlashMiscOpEntry .1.3.6.1.4.1.9.9.10.1.2.3.1 |
ciscoFlashMiscOpSerialNumberObject which specifies a unique entry in the
table. A management station wishing to initiate a
flash operation should use a pseudo-random value for
this object when creating or modifying an instance of
a ciscoFlashMiscOpEntry. INTEGER .1.3.6.1.4.1.9.9.10.1.2.3.1.1 |
ciscoFlashMiscOpCommandThe command to be executed. Mandatory.
Note that it is possible for a system to support
multiple file systems (different file systems on
different Flash devices, or different file systems
on different partitions within a device). Each such
file system may support only a subset of these commands.
If a command is unsupported, the miscOpInvalidOperation(3)
error will be reported in the operation status.
Command Remarks
erase Erase flash.
verify Verify flash file checksum.
delete Delete a file.
undelete Revive a deleted file .
Note that there are limits on
the number of times a file can
be deleted and undeleted. When
this limit is exceeded, the
system will return the appropriate
error.
squeeze Recover space occupied by
deleted files. This command
preserves the good files, erases
out the file system, then restores
the preserved good files.
format Format a flash device.
Command table Parameters
erase MiscOpDestinationName
MiscOpNotifyOnCompletion (opt)
verify MiscOpDestinationName
MiscOpNotifyOnCompletion (opt)
delete MiscOpDestinationName
MiscOpNotifyOnCompletion (opt)
undelete MiscOpDestinationName
MiscOpNotifyOnCompletion (opt)
squeeze MiscOpDestinationName
MiscOpNotifyOnCompletion (opt)
format MiscOpDestinationName
MiscOpNotifyOnCompletion (opt)rw Enumeration .1.3.6.1.4.1.9.9.10.1.2.3.1.2 |
ciscoFlashMiscOpDestinationNameDestination file, or partition name.
File name must be of the form
[device>:][<partition>:]<file>
where <device> is a value obtained from FlashDeviceName,
<partition> is obtained from FlashPartitionName
and <file> is the name of a file in Flash.
While leading and/or trailing whitespaces are acceptable,
no whitespaces are allowed within the path itself.
A management station could derive its own partition name
as per the description for the ciscoFlashPartitionName
object.
If <device> is not specified, the default Flash device
will be assumed.
If <partition> is not specified, the default partition
will be assumed. If a device is not partitioned into 2
or more partitions, this value may be left out.
For an operation on a partition, eg., the erase
command, this object would specify the partition name
in the form:
[device>:][<partition>:]rw DisplayString .1.3.6.1.4.1.9.9.10.1.2.3.1.3 |
ciscoFlashMiscOpStatusThe status of the specified operation.
miscOpInProgress :
specified operation is active
miscOpOperationSuccess :
specified operation is supported and completed
successfully
miscOpInvalidOperation :
command invalid or command-protocol-device
combination unsupported
miscOpInvalidDestName :
invalid target name (file or partition or
device name) specified
miscOpDeviceBusy :
specified device is in use and locked by another
process
miscOpDeviceOpenError :
invalid device name
miscOpDeviceError :
device read, write or erase error
miscOpDeviceNotProgrammable :
device is read-only but a write or erase
operation was specified
miscOpFileOpenError :
invalid file name; file not found in partition
miscOpFileDeleteFailure :
file could not be deleted; delete count exceeded
miscOpFileUndeleteFailure :
file could not be undeleted; undelete count
exceeded
miscOpFileChecksumError :
file has a bad checksum
miscOpNoMemory :
system running low on memory
miscOpUnknownFailure :
failure unknown
miscOpSqueezeFailure :
the squeeze operation failed
miscOpNoSuchFile :
a valid but nonexistent file name was specified
miscOpFormatFailure :
the format operation failedro Enumeration .1.3.6.1.4.1.9.9.10.1.2.3.1.4 |
ciscoFlashMiscOpNotifyOnCompletionSpecifies whether or not a notification should be
generated on the completion of an operation.
If specified, ciscoFlashMiscOpCompletionTrap
will be generated. It is the responsibility of the
management entity to ensure that the SNMP administrative
model is configured in such a way as to allow the
notification to be delivered.rw TruthValue -- Rsyntax INTEGER { -- true(1), -- false(2) -- } .1.3.6.1.4.1.9.9.10.1.2.3.1.5 |
ciscoFlashMiscOpTimeTime taken for the operation. This object will
be like a stopwatch, starting when the operation
starts, stopping when the operation completes.
If a management entity keeps a database of completion
times for various operations, it can then use the
stopwatch capability to display percentage completion
time.ro TimeTicks (SNMPv2-SMI) .1.3.6.1.4.1.9.9.10.1.2.3.1.6 |
ciscoFlashMiscOpEntryStatusThe status of this table entry.rw RowStatus -- Rsyntax INTEGER { -- active(1), -- notInService(2), -- notReady(3), -- createAndGo(4), -- createAndWait(5), -- destroy(6) -- } .1.3.6.1.4.1.9.9.10.1.2.3.1.7 |
ciscoFlashMIBTrapPrefix OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.1.3 |
ciscoFlashMIBTraps OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.1.3.0 |
ciscoFlashCopyCompletionTrapA ciscoFlashCopyCompletionTrap is sent at the
completion of a flash copy operation if such a trap
was requested when the operation was initiated. TRAP-TYPE .1.3.6.1.4.1.9.9.10.1.3.0.1 |
ciscoFlashPartitioningCompletionTrapA ciscoFlashPartitioningCompletionTrap is sent at the
completion of a partitioning operation if such a trap
was requested when the operation was initiated. TRAP-TYPE .1.3.6.1.4.1.9.9.10.1.3.0.2 |
ciscoFlashMiscOpCompletionTrapA ciscoFlashMiscOpCompletionTrap is sent at the
completion of a miscellaneous flash operation
(enumerated in ciscoFlashMiscOpCommand) if such a trap
was requested when the operation was initiated. TRAP-TYPE .1.3.6.1.4.1.9.9.10.1.3.0.3 |
ciscoFlashDeviceChangeTrapA ciscoFlashDeviceChangeTrap is sent whenever a
removable Flash device is inserted or removed. TRAP-TYPE .1.3.6.1.4.1.9.9.10.1.3.0.4 |
ciscoFlashDeviceInsertedNotifA ciscoFlashDeviceInsertedNotif notification is sent
whenever a removable Flash device is inserted. TRAP-TYPE .1.3.6.1.4.1.9.9.10.1.3.0.5 |
ciscoFlashDeviceRemovedNotifA ciscoFlashDeviceRemovedNotif notification is sent
whenever a removable Flash device is removed. TRAP-TYPE .1.3.6.1.4.1.9.9.10.1.3.0.6 |
ciscoFlashCfg OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.1.4 |
ciscoFlashCfgDevInsNotifEnableSpecifies whether or not a notification should be
generated on the insertion of a Flash device.
If the value of this object is 'true' then the
ciscoFlashDeviceInsertedNotif notification
will be generated.
If the value of this object is 'false' then the
ciscoFlashDeviceInsertedNotif notification
will not be generated.
It is the responsibility of the management entity to
ensure that the SNMP administrative model is
configured in such a way as to allow the
notification to be delivered.rw TruthValue -- Rsyntax INTEGER { -- true(1), -- false(2) -- } .1.3.6.1.4.1.9.9.10.1.4.1 |
ciscoFlashCfgDevRemNotifEnableSpecifies whether or not a notification should be
generated on the removal of a Flash device.
If the value of this object is 'true' then the
ciscoFlashDeviceRemovedNotif notification
will be generated.
If the value of this object is 'false' then the
ciscoFlashDeviceRemovedNotif notification
will not be generated.
It is the responsibility of the management entity to
ensure that the SNMP administrative model is
configured in such a way as to allow the
notification to be delivered.rw TruthValue -- Rsyntax INTEGER { -- true(1), -- false(2) -- } .1.3.6.1.4.1.9.9.10.1.4.2 |
ciscoFlashMIBConformance OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.2 |
ciscoFlashMIBCompliances OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.2.1 |
ciscoFlashMIBCompliance OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.2.1.1 |
ciscoFlashMIBComplianceRev1 OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.2.1.2 |
ciscoFlashMIBComplianceRev2 OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.2.1.3 |
ciscoFlashMIBGroups OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.2.2 |
ciscoFlashDeviceInfoGroup OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.2.2.1 |
ciscoFlashDeviceOptionalInfoGroup OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.2.2.2 |
ciscoFlashChipInfoGroup OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.2.2.3 |
ciscoFlashPartitionInfoGroup OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.2.2.4 |
ciscoFlashFileInfoGroup OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.2.2.5 |
ciscoFlashCopyOpGroup OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.2.2.6 |
ciscoFlashPartitioningOpGroup OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.2.2.7 |
ciscoFlashMiscOpGroup OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.2.2.8 |
ciscoFlashNotifGroup OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.2.2.9 |
ciscoFlashFileInfoGroupRev1 OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.2.2.10 |
ciscoFlashNotifGroupRev1 OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.2.2.11 |
ciscoFlashDeviceInfoGroupRev1 OBJECT IDENTIFIER .1.3.6.1.4.1.9.9.10.2.2.12 |