| ciscoFlashDeviceIndex |
.1.3.6.1.4.1.9.9.10.1.1.2.1.1 |
|
Flash 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.
|
| ciscoFlashDeviceSize |
.1.3.6.1.4.1.9.9.10.1.1.2.1.2 |
|
Total size of the Flash device.
For a removable device, the size will be zero if
the device has been removed.
|
| ciscoFlashDeviceMinPartitionSize |
.1.3.6.1.4.1.9.9.10.1.1.2.1.3 |
|
This 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).
|
| ciscoFlashDeviceMaxPartitions |
.1.3.6.1.4.1.9.9.10.1.1.2.1.4 |
|
Max 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.
|
| ciscoFlashDevicePartitions |
.1.3.6.1.4.1.9.9.10.1.1.2.1.5 |
|
Flash 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).
|
| ciscoFlashDeviceChipCount |
.1.3.6.1.4.1.9.9.10.1.1.2.1.6 |
|
Total 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.
|
| ciscoFlashDeviceName |
.1.3.6.1.4.1.9.9.10.1.1.2.1.7 |
|
Flash 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.
|
| ciscoFlashDeviceDescr |
.1.3.6.1.4.1.9.9.10.1.1.2.1.8 |
|
Description 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 ciscoFlashPhyEntIndex 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.
|
| ciscoFlashDeviceController |
.1.3.6.1.4.1.9.9.10.1.1.2.1.9 |
|
Flash 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.
|
| ciscoFlashDeviceCard |
.1.3.6.1.4.1.9.9.10.1.1.2.1.10 |
|
This 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.
|
| ciscoFlashDeviceProgrammingJumper |
.1.3.6.1.4.1.9.9.10.1.1.2.1.11 |
|
This 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.
|
| ciscoFlashDeviceInitTime |
.1.3.6.1.4.1.9.9.10.1.1.2.1.12 |
|
System 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.
|
| ciscoFlashDeviceRemovable |
.1.3.6.1.4.1.9.9.10.1.1.2.1.13 |
|
Whether 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.
|
| ciscoFlashPhyEntIndex |
.1.3.6.1.4.1.9.9.10.1.1.2.1.14 |
|
This object indicates the physical entity index of a
physical entity in entPhysicalTable which the flash
device actually located.
|
| ciscoFlashDeviceNameExtended |
.1.3.6.1.4.1.9.9.10.1.1.2.1.15 |
|
Extended Flash device name whose size can be upto
255 characters. 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.
|
| ciscoFlashChipIndex |
.1.3.6.1.4.1.9.9.10.1.1.3.1.1.1 |
|
Chip 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).
|
| ciscoFlashChipCode |
.1.3.6.1.4.1.9.9.10.1.1.3.1.1.2 |
|
Manufacturer 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).
|
| ciscoFlashChipDescr |
.1.3.6.1.4.1.9.9.10.1.1.3.1.1.3 |
|
Flash 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.
|
| ciscoFlashChipWriteRetries |
.1.3.6.1.4.1.9.9.10.1.1.3.1.1.4 |
|
This 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.
|
| ciscoFlashChipEraseRetries |
.1.3.6.1.4.1.9.9.10.1.1.3.1.1.5 |
|
This 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.
|
| ciscoFlashChipMaxWriteRetries |
.1.3.6.1.4.1.9.9.10.1.1.3.1.1.6 |
|
The maximum number of write retries done at any
single location before declaring a write failure.
|
| ciscoFlashChipMaxEraseRetries |
.1.3.6.1.4.1.9.9.10.1.1.3.1.1.7 |
|
The maximum number of erase retries done within
an erase sector before declaring an erase failure.
|
| ciscoFlashPartitionIndex |
.1.3.6.1.4.1.9.9.10.1.1.4.1.1.1 |
|
Flash partition sequence number used to index within
table of initialized flash partitions.
|
| ciscoFlashPartitionStartChip |
.1.3.6.1.4.1.9.9.10.1.1.4.1.1.2 |
|
Chip sequence number of first chip in partition.
Used as an index into the chip table.
|
| ciscoFlashPartitionEndChip |
.1.3.6.1.4.1.9.9.10.1.1.4.1.1.3 |
|
Chip sequence number of last chip in partition.
Used as an index into the chip table.
|
| ciscoFlashPartitionSize |
.1.3.6.1.4.1.9.9.10.1.1.4.1.1.4 |
|
Flash partition size. It should be an integral
multiple of ciscoFlashDeviceMinPartitionSize.
If there is a single partition, this size will be equal
to ciscoFlashDeviceSize.
|
| ciscoFlashPartitionFreeSpace |
.1.3.6.1.4.1.9.9.10.1.1.4.1.1.5 |
|
Free 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.
|
| ciscoFlashPartitionFileCount |
.1.3.6.1.4.1.9.9.10.1.1.4.1.1.6 |
|
Count of all files in a flash partition. Both
good and bad (deleted or invalid checksum) files
will be included in this count.
|
| ciscoFlashPartitionChecksumAlgorithm |
.1.3.6.1.4.1.9.9.10.1.1.4.1.1.7 |
|
Checksum 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.
|
| ciscoFlashPartitionStatus |
.1.3.6.1.4.1.9.9.10.1.1.4.1.1.8 |
|
Flash 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.
|
| ciscoFlashPartitionUpgradeMethod |
.1.3.6.1.4.1.9.9.10.1.1.4.1.1.9 |
|
Flash 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.
|
| ciscoFlashPartitionName |
.1.3.6.1.4.1.9.9.10.1.1.4.1.1.10 |
|
Flash 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).
|
| ciscoFlashPartitionNeedErasure |
.1.3.6.1.4.1.9.9.10.1.1.4.1.1.11 |
|
This 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.
|
| ciscoFlashPartitionFileNameLength |
.1.3.6.1.4.1.9.9.10.1.1.4.1.1.12 |
|
Maximum 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.
|
| ciscoFlashFileIndex |
.1.3.6.1.4.1.9.9.10.1.1.4.2.1.1.1 |
|
Flash file sequence number used to index within
a Flash partition directory table.
|
| ciscoFlashFileSize |
.1.3.6.1.4.1.9.9.10.1.1.4.2.1.1.2 |
|
Size 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.
|
| ciscoFlashFileChecksum |
.1.3.6.1.4.1.9.9.10.1.1.4.2.1.1.3 |
|
File 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.
|
| ciscoFlashFileStatus |
.1.3.6.1.4.1.9.9.10.1.1.4.2.1.1.4 |
|
Status 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.
|
| ciscoFlashFileName |
.1.3.6.1.4.1.9.9.10.1.1.4.2.1.1.5 |
|
Flash 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.
|
| ciscoFlashFileType |
.1.3.6.1.4.1.9.9.10.1.1.4.2.1.1.6 |
|
Type of the file.
|
| ciscoFlashCopySerialNumber |
.1.3.6.1.4.1.9.9.10.1.2.1.1.1 |
|
Object 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.
|
| ciscoFlashCopyCommand |
.1.3.6.1.4.1.9.9.10.1.2.1.1.2 |
|
The 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)
|
| ciscoFlashCopyProtocol |
.1.3.6.1.4.1.9.9.10.1.2.1.1.3 |
|
The 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.
|
| ciscoFlashCopyServerAddress |
.1.3.6.1.4.1.9.9.10.1.2.1.1.4 |
|
The server address to be used for any copy. Optional.
Will default to 'FFFFFFFF'H (or 255.255.255.255).
|
| ciscoFlashCopySourceName |
.1.3.6.1.4.1.9.9.10.1.2.1.1.5 |
|
Source 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.
|
| ciscoFlashCopyDestinationName |
.1.3.6.1.4.1.9.9.10.1.2.1.1.6 |
|
Destination 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.
|
| ciscoFlashCopyRemoteUserName |
.1.3.6.1.4.1.9.9.10.1.2.1.1.7 |
|
Remote 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.
|
| ciscoFlashCopyStatus |
.1.3.6.1.4.1.9.9.10.1.2.1.1.8 |
|
The 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 unknown
|
| ciscoFlashCopyNotifyOnCompletion |
.1.3.6.1.4.1.9.9.10.1.2.1.1.9 |
|
Specifies 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.
|
| ciscoFlashCopyTime |
.1.3.6.1.4.1.9.9.10.1.2.1.1.10 |
|
Time 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.
|
| ciscoFlashCopyEntryStatus |
.1.3.6.1.4.1.9.9.10.1.2.1.1.11 |
|
The status of this table entry.
|
| ciscoFlashCopyVerify |
.1.3.6.1.4.1.9.9.10.1.2.1.1.12 |
|
Specifies whether the file that is copied need to
be verified for integrity / authenticity, after
copy succeeds. If it is set to true, and if the
file that is copied doesn't have integrity /authenticity
attachement, or the integrity / authenticity check
fails, then the command will be aborted, and the file
that is copied will be deleted from the destination
file system.
|
| ciscoFlashPartitioningSerialNumber |
.1.3.6.1.4.1.9.9.10.1.2.2.1.1 |
|
Object 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.
|
| ciscoFlashPartitioningCommand |
.1.3.6.1.4.1.9.9.10.1.2.2.1.2 |
|
The 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)
|
| ciscoFlashPartitioningDestinationName |
.1.3.6.1.4.1.9.9.10.1.2.2.1.3 |
|
Destination device name. This name will be the value
obtained from FlashDeviceName.
If the name is not specified, the default Flash device
will be assumed.
|
| ciscoFlashPartitioningPartitionCount |
.1.3.6.1.4.1.9.9.10.1.2.2.1.4 |
|
This 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.
|
| ciscoFlashPartitioningPartitionSizes |
.1.3.6.1.4.1.9.9.10.1.2.2.1.5 |
|
This 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 .
|
| ciscoFlashPartitioningStatus |
.1.3.6.1.4.1.9.9.10.1.2.2.1.6 |
|
The 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 unknown
|
| ciscoFlashPartitioningNotifyOnCompletion |
.1.3.6.1.4.1.9.9.10.1.2.2.1.7 |
|
Specifies 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.
|
| ciscoFlashPartitioningTime |
.1.3.6.1.4.1.9.9.10.1.2.2.1.8 |
|
Time 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.
|
| ciscoFlashPartitioningEntryStatus |
.1.3.6.1.4.1.9.9.10.1.2.2.1.9 |
|
The status of this table entry.
|
| ciscoFlashMiscOpSerialNumber |
.1.3.6.1.4.1.9.9.10.1.2.3.1.1 |
|
Object 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.
|
| ciscoFlashMiscOpCommand |
.1.3.6.1.4.1.9.9.10.1.2.3.1.2 |
|
The 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)
|
| ciscoFlashMiscOpDestinationName |
.1.3.6.1.4.1.9.9.10.1.2.3.1.3 |
|
Destination 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>:]
|
| ciscoFlashMiscOpStatus |
.1.3.6.1.4.1.9.9.10.1.2.3.1.4 |
|
The 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 failed
|
| ciscoFlashMiscOpNotifyOnCompletion |
.1.3.6.1.4.1.9.9.10.1.2.3.1.5 |
|
Specifies 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.
|
| ciscoFlashMiscOpTime |
.1.3.6.1.4.1.9.9.10.1.2.3.1.6 |
|
Time 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.
|
| ciscoFlashMiscOpEntryStatus |
.1.3.6.1.4.1.9.9.10.1.2.3.1.7 |
|
The status of this table entry.
|
