The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Table B-1 describes the global options and arguments that are common to all
vcb
commands and subcommands.
Table B-1 Global Options and Arguments—vcb
Option
Argument
Description
help
Displays online help about the command.Use this option for each subcommand.
debuglevel
Determines which messages are logged based on the message severity. Valid values are: error, warn (default), info, and debug.
For example, if debuglevel is set to warn, all warning and error messages are saved to the log file.
logfile
logfile
Logs the CLI output to the file specified in the
logfile
argument.
userdefined
Displays the registrations that have been added to the site.xml file using the VCB or any other tool.
user
username
BQL username.
password
password
BQL password.
Description
Use the
vcb
command to create and update VNE registry configuration files. Use the
vcb
command to add, delete, view, and modify information in these files, based on the subcommands that are used with it.
The
vcb
command performs the following high-level operations:
Executes Prime Network administrator-level operations. It also provides a service to handle authorization errors. VCB users must have the Prime Network admin user role and associated privileges in order to perform registry configuration commands.
Verifies that the expected version of Prime Network is running.
Provides help information for each command.
Logs all internal commands.
Centralizes error handling for exceptions.
General Error Codes
Table B-2 General Error Codes—vcb
Code
Description
0
Signifies OK.
10
Operation not permitted. An attempt was made to perform an operation limited to processes with appropriate privileges or to the owner of a file or other resources.
11
User does not have Prime Network admin privileges.
20
No such file or directory. A component of a specified pathname did not exist, or the pathname was an empty string.
This might occur when the argument is a DSP or to a registry hive.
30
Failed to connect to Prime Network server.
40
I/O error. Some physical input or output error occurred.
50
Invalid argument. Some invalid argument was supplied.
60
Incompatible Prime Network version of VCB; expected $vcb_expected_version$ and found Prime Network $ana_running_version$.
70
Bad procedure for program. A Remote Procedure Call (RPC) call was attempted for a procedure which does not exist in the VCB program.
80
Function not implemented. Attempted a system call that is not available on this system.
vcb sitechanges
The
vcb sitechanges
command affects all extensions in the local site.xml file—displaying, exporting, or deleting them—whether the extensions were created by the VCB or by other Prime Network utilities.
Use the
vcb sitechanges
command to view all customizations that were made to the site.xml registry file whether by the VCB or by other Prime Network utilities. Use the
vcb sitechanges
command also to write all customizations to script files that enable you to import changes to another system or to delete all changes, returning the system to factory default.
Because the VCB does not differentiate between changes made by the VCB and changes made by other Prime Network utilities, the
vcb sitechanges export
and
vcb sitechanges delete
commands create script files to enable you to inspect commands before you execute them. Edit the script files before running them to ensure that only the customizations that you are interested in are acted upon.
VCB CLI Reference: U-VNEs Commands
These topics provide reference information for the
vcb uvne
commands you can use to create, view, modify, and delete U-VNEs:
The
vcb uvne add
command creates a U-VNE by associating a U-VNE template with the device type associated with the given sysOID, or by cloning from an existing device or device family.
Syntax
vcb uvne add -sysoid
sysoid
-template
template name
-group
template filename
[-devicetype
device type name
] -user
username
-password
password
The
vcb uvne add
command creates a U-VNE-driver for the device type associated with the given sysOID using the specified U-VNE template. Creating a U-VNE-driver enables the Auto Detect feature in Prime Network to associate a device with this sysOID with the VNE-driver implementation defined by the template.
This command creates a separate registry configuration for the U-VNE. Any configuration setting given in the command parameters affect this copy.
Note This command does not create the device category for the device. For more information, see vcb devicetype add.
Enables discovery of the device with sysOID 1.2.3.4 using the GenericUVNE template, which is located in group uvne-product.
The command does not create any device attributes for the newly added device. To assign the device a user-friendly name and the correct device category, use the
-devicetype
option (see the “vcb devicetype add” section).
Enables discovery of a new device (with sysOID .1.2.3.4) that points to registration—scheme and instrumentation commands—of the already supported sysOID .1.3.6.1.4.1.9.1.108.
(To create a list of already supported VNEs, see vcb uvne view.)
Adds support for a new device (with sysOID .1.2.3.4) based on the device family 100xx. Also adds support for the new software version for this device family. (For a list of already supported software versions, see vcb uvne view.)
Enables discovery of a new device (with sysOID .1.2.3.4), that points to registrations—scheme and instrumentation commands—for the device family 100xx.
Options
Table B-3 Options and Arguments—vcb uvne add
Option
Argument
Description
sysoid
sysoid
The sysObject ID of the device for which to create a U-VNE-driver using the implementation defined in the U-VNE template.
Note Each sysOID value in the system must be unique.
template
template name
The name of the U-VNE template from which to create the U-VNE-driver. See U-VNE Templates.
Note This option is mutually exclusive with the -clonesysoid and -clonedevicefamily options.
group
template filename
The name of the file in which the U-VNE template is located. U-VNE templates are located in the uvne-product file.
Note Use this option with the -template option only.
devicetype
device type name
(Optional) The U-VNE device type name. If not specified, the device type is:
Defined as Unknown when the option is not specified.
Inherited from the device or device family when you use the
-clonesysoid
option.
The device type name appears in the UI and is associated with a category; its category determines which icon is displayed, and other presentation aspects are derived from this reference. To use a new device type name, first add it using the
vcb devicetype add
command. For more information, see vcb devicetype add.
clonesysoid
clone-sysoid
The sysObject ID of an already supported VNE. To view sysOIDs for supported VNEs, use the
vcb uvne view -sysoid
all command.
softwareversion
software-version
The software version that you want to add for a U-VNE. To obtain the software version string, use the
show version
command.
clonesoftwareversion
clone-softwareversion
An already supported software version that you want to clone. The software version must already be supported for a particular device family.
For a list of supported software versions, use the command
vcb uvne view -scheme <ipcore|product> -devicefamily <device family> -user user -password password.
For more information, see vcb uvne view.
clonedevicefamily
devicefamily
A supported device family. For a list of supported device families, use the command
vcb uvne view –scheme
<ipcore|product>
–devicefamily
devicefamily
–user
user
-password
password
. For more information, see vcb uvne view.
Note This option is mutually exclusive with the -template option.
Returns the configuration of the VNE with the sysOID 1.2.3.4, including the U-VNE template (or the device family for a developed VNE). If device-type associations are defined (using the
vcb devicetype add
command), these associations are also displayed.
Example 2
vcb uvne view
-sysoid
all
-user
root
-password
admin
Returns all the sysoid supported in Prime Network.
Example 3
vcb uvne view -sysoid
all -user
root
-password
admin
-detail
Returns all known configured sysOIDs (regular VNEs) and also this command would show following additional informations
Module Spec Name associated with the sysoid.
Syslog and Trap Parsing rule name associated with the sysoid
Modifies support for a new device, with sysOID .1.2.3.4, to point to registrations—scheme and instrumentation commands—of the device family 12xxx.
Options
Table B-7 Options and Arguments—vcb uvne modify
Option
Argument
Description
sysoid
sysoid
The sysObject ID of the U-VNE-driver configuration that you want to modify.
template
template name
The name of the U-VNE template to which the U-VNE should be associated. Use this option to modify the U-VNE template from which the U-VNE-driver derives its configuration.
Note Using this option does not overwrite other configuration changes made with the VCB, such as user-experience attributes that are defined with the vcb devicetype add command.
group
template filename
The name of the group that includes the U-VNE template, such as uvne-product.
devicetype
device type
The device type associated with the U-VNE.
clonesysoid
clone-sysoid
The sysObject ID of an already supported VNE. To view sysOIDs for supported VNEs, use the
vcb uvne view -sysoid
all command.
softwareversion
software-version
The software version that you want to support for a U-VNE. To obtain the software version string, use the
show version
command.
clonesoftwareversion
clone-softwareversion
An already supported software version that you want to clone. The software version must already be supported for a particular device family.
clonedevicefamily
deviceFamily
A supported device family. For a list of supported device families, use the command
vcb uvne view –sysoid all –user
user
-password
password
. For more information, see vcb uvne view.
The
vcb uvne delete
command is useful when migrating from a U-VNE to a developed VNE. If, in an upgrade, Prime Network provides a DSP that contains a developed VNE to support the device type, the need for the U-VNE is eliminated. You must delete the U-VNE before Prime Network can use the developed VNE to model and manage the device.
Deleting a template-based U-VNE has no effect on the U-VNE template from which it derives its implementation.
Deletes the software configuration for U-VNE driver configured for the device with sysOID .1.2.3.4. Use the command in Example 1 to delete the U-VNE.
Note that the vcb uvne delete syntax should match the vcb uvne add syntax to avoid items being left in the site.xml after the delete action. For example, if the vcb uvne add syntax is as follows:
These topics provide reference information for the
vcb devicetype
commands you can use to create, view, modify, and delete user-experience attributes for device types:
The
vcb devicetype add
command creates new user-experience attributes for the specified device type. Each device type is associated with a user-friendly name, icon, and device grouping.
Syntax
vcb devicetype add -devicetype
device type
-category
prime
network device category
-name
device name
[
-key
device type key
]
-user
root
-password
admin
Description
The
vcb devicetype add
command creates user-experience attributes that affect how a device type is managed and displayed in Prime Network.
Note This command is typically used before adding a new U-VNE using the vcb uvne add command. For more information, see vcb uvne add.
Adds a device-type definition for the Cisco 1760 router, including the device category and user-friendly name that will appear in the Prime Network UI. Reference this definition when adding U-VNE definitions for a Cisco 1760 device using the
vcb uvne add
command.
Options
Table B-11 Options and Arguments—vcb devicetype add
Option
Argument
Description
devicetype
device type
The name to assign to the new device type. Each name must be unique. To see existing device types, use the
vcb devicetype view
command.
category
prime network device category
The category to assign to the new device type, entered as a string (router, switch, unknown, and so on).
By default, the device category defined in the U-VNE template is used.
name
device name
The name to display for this device type in Prime Network.
By default, the name is empty.
Note The name need not be unique. The VCB does not enforce a naming convention for this value.
key
device type key
(Optional) The unique ID of the new device type. This value is not displayed in Prime Network.
Note We recommend that you not use this option, and let the VCB define the key instead.
The
vcb devicetype modify
command modifies the user-experience attributes associated with specific device types.
Syntax
vcb devicetype modify -devicetype
device type name
[
-category
prime network device category
] [
-name
device name
] [
-key
device type key
]
-user
username
-password
password
Description
The
vcb devicetype modify
command overwrites the user-experience settings defined for a device type, including the name, icon, and device category as they appear in Prime Network.
Modifies the category and name assigned to the specified device type. Any VNE that uses the U-VNE-driver associated with this device type inherits these modified user-experience attributes.
Options
Table B-15 Options and Arguments—vcb devicetype modify
Option
Argument
Description
devicetype
device type
The name of the device type user-experience attributes that you want to modify.
category
prime network device category
(Optional) Modifies the category assigned to the device type. Enter the category as a string (router, switch, unknown, and so on).
name
device name
(Optional) Modifies the name that is displayed for this device type in Prime Network.
key
device type key
(Optional) Modifies the unique ID of the device type. This value is not displayed in Prime Network.
Note We recommend that you not use this option, and let the VCB define the key instead.
The
vcb devicetype delete
command deletes the user-friendly name, icon, and grouping that were defined for the specified device type from the site.xml file. It does not delete or otherwise modify the U-VNE template from which the U-VNE for this device type was created.
The
vcb module add
command adds support for a new module type by creating a new registration from the specified template. This support enables VNEs that contain this module to properly recognize and model it in Prime Network.
Syntax
vcb module add -module
module identifier
-template
template name
-group
module group
[
-hardwaredesc
Hardware Description of the Module
]
-user
username
-password
password
vcb module add -module module identifier -template template name -sysoid <sysobject ID devicefamily under which module should be supported> -scheme <ipcore|product> [ -hardwaredesc Hardware Description of the Module ] -user username -password password
Description
The
vcb module add
command enables the VNE to automatically detect a physical module based on an implementation defined in a module template. It can be used to:
Create a module definition based on the module identifier. When this option is used, any VNE that uses the same spec file for its module definitions can model the new module.
Create a module definition based on an extension to the definition used by the driver of a specific device (defined by its sysOID). When this option is used, only this particular device can model the new module.
This command updates the site.xml file, in which customizations are stored. Doing so enables the tool to differentiate between factory defaults (changes supplied from DSPs) and changes initiated by the VCB.
Adds support for a module with the module ID .1.3.6.1.4.1.9.12.3.1.9.29.99, based on the 1.2.3.4 module template, which is listed in the spec group, ciscoentitymibspec. The hardware description is cevCat6kWsf6kpfc3b.
Adds support for a module with the ID .1.3.6.1.4.1.9.12.3.1.9.29.99, based on module template 1.2.3.4. The VCB looks up the module spec used by the VNE-driver with the sysOID 7.7.7, and registers the new module for this device only (not for all devices that share the same module spec file).
Options
Table B-19 Options and Arguments—vcb module add
Option
Argument
Description
module
module identifier
The module identifier, a number, string, or OID. The module identifier should be unique and new.
Note The value specified for this argument must match the value returned from the physical command investigation.
group
module group
The module group is a repository that might be shared across multiple device types. It specifies where the template is located. For the module groups that you can extend, see Module Groups and Module Specification Files.
The sysObjectID of the device that belongs to particular device family for which a concrete module is created using the implementation defined in the template.
Note This sysObjectID must already exist in the system.
scheme scheme
Scheme name which will be used while adding the VNE.
template
template name
The name of the template that contains the implementation of the physical investigation of this module.
Tip The template option need not be specified if the module does not support any ports; SIP and other carrier cards are examples of modules that do not support ports.
hardwaredesc
hardware description
(Optional) Hardware description of the given module.
Returns the port layer definitions of the template if it is defined in the specified module group.
Options
Table B-21 Options and Arguments—vcb module view
Option
Argument
Description
sysoid
sysoid
The sysOID of the device that contains the module configuration that you want to view.
module
module identifier
The module whose port layer configuration you want to view. The identifier can be a number, string, or OID, depending on the type of identifier used by the relevant device type.
Tip Enter all as the module identifier to return a list of all modules in the defined device or group, listed by identifier.
group
module group
The module spec group associated with the module or template whose details you want to view.
template
template name
The name of the module template whose port layer configuration you want to view.
Tip Enter all as the template name to return the list of all module templates contained in the specified module spec group.
- scheme scheme
Scheme name which will be used while adding the VNE.
Modifies the registration for module 20091 by associating it with module template GE-fiberoptic-ethernet-default, which is part of group ciscophysicalspec2. This module definition replaces the one obtained from the template that was specified when the module was first added. This change affects all devices that contain this module.
Modifies the registration for module 50068 by associating it with module template cc3-ppp-default. This change affects only the device with sysOID 1.2.3.4.
Options
Table B-23 Options and Arguments—vcb module modify
Option
Argument
Description
module
module identifier
The module configuration that you want to modify. The identifier can be a number, string, or OID, depending on the type of identifier used by the relevant device type.
Note The value specified for this argument must match the value returned by the device when investigating this module.
group
module group
The name of the group that contains the module template to apply to the module.
sysoid
sysoid
The sysObject ID of the device that contains the module configuration that you want to modify.
Note You must specify a sysoid that was added using the VCB.
template
template name
The name of the module template with which the defined module should be associated. Use this option to change the module template from which the module derives its configuration.
hardwaredesc
hardware description
(Optional) Hardware description of the given module.
scheme scheme
Scheme name which will be used while adding the VNE.
Note Use the vcb module delete command to enable VNEs to use factory-supplied updates if they become available.
The
vcb module delete
command is useful when migrating from an interim solution to a more complete implementation. Removing the association to the module from the site.xml file enables Prime Network to automatically detect a deployed implementation in a DSP.
Use the
vcb module delete
command:
To delete the association between a module and its implementation on a specific device based on a defined sysOID. Other VNEs that use this implementation will still be able to identify the module.
To delete the association between a module and its implementation on all devices that use the module as specified by the relevant group name. When the
-group
option is used, any VNEs that used this implementation will no longer be able to identify the module.
Note • You can delete only those modules that were originally added using the VCB. Module definitions added as part of a developed VNE cannot be deleted.
You can delete the module association on a specific device only when the association was created for that specific device.
Deleting the module configuration does not delete or otherwise affect the template from which the configuration was created.
Deletes the definition for module 50068 from the device with sysOID 1.2.3.4. Other devices that contain this module are unaffected.
Options
Table B-25 Options and Arguments—vcb module delete
Option
Argument
Description
module
module identifier
The module configuration that you want to delete. The identifier can be a number, string, or OID, depending on the type of identifier used by the relevant device type.
sysoid
device sysoid
The sysObject ID of the device that contains the module configuration that you want to delete.
group
module group
The module spec group that contains the template whose implementation you want to delete from the module.
scheme scheme
Scheme name which will be used while adding the VNE.
Use the
vcb pluggablemodule add
command to create a pluggable module definition that is associated using the module identifier. Use this command for pluggable modules such as SFPs and XFPs.
Prime Network does not model pluggable modules, only the ports on them. Configuration details that are entered using this command are displayed at the port level to differentiate between pluggable and regular ports. Changes made through this command apply to all VNEs that use the same spec file for pluggable ports.
The container oid and base type value are additional configuration information needed to model pluggable module properly. When you add new pluggable module make sure that container oid and base type values are added in the system.
Adds support for a pluggable module of type SFP with the module ID .1.3.6.1.4.1.9.12.3.1.9.51.22, to the pluggable-ports-spec module specification file. The media type is fiber optic.
Add pluggable module base type configuration with the base type value .1.3.6.1.4.1.9.12.3.1.9.52, to the pluggable-ports-spec module specification file.
Add pluggable module container oid configuration with the container oid .1.3.6.1.4.1.9.12.3.1.9.52, to the pluggable-ports-spec module specification file.
Options
Table B-27 Options and Arguments—vcb pluggablemodule add
Option
Argument
Description
module
moduleno
The identifier for the module that you want to add. The identifier can be a number, string, or OID, depending on the type of identifier used by the relevant device type.
Note The value specified for this argument must match the value returned by the device when investigating this module.
group
pluggable port group
The name of the group.
pid
pid
The pid for the module.
mediatype
MediaType
The media type of the port on the pluggable module.
pluggable type
pluggableType
The type of the pluggable module; one of SFP, XFP, X2, XENPAK.
containeroid
The oid of a pluggable module container where the pluggable module will be inserted.
basetype
The oid of a pluggable module without the last octet in the oid
For example, if the oid of a pluggable module is .1.3.6.1.4.1.9.12.3.1.9.52.10 then the basetype oid would be .1.3.6.1.4.1.9.12.3.1.9.52
Use the
vcb pluggablemodule view
command to display the pluggable module details—such as pid, media type, and pluggable type—for one or all modules in the given pluggable port group.
Table B-29 Options and Arguments—vcb pluggablemodule view
Option
Argument
Description
module
moduleno
The identifier for the module that you want to view. The identifier can be a number, string, or OID, depending on the type of identifier used by the relevant device type.
Tip Enter all as the module no to return the list of all modules contained in the specified pluggable port group.
Modifies the mediaType attribute of the pluggable module with identifier .1.3.6.1.4.1.9.12.3.1.9.51.22.
Options
Table B-31 Options and Arguments—vcb pluggablemodule modify
Option
Argument
Description
module
moduleno
The identifier for the pluggable module configuration that you want to modify. The identifier can be a number, string, or OID, depending on the type of identifier used by the relevant device type.
group
pluggable port group
The name of the group.
pid
pid
The pid for the module.
mediatype
MediaType
(Optional) The media type of the port on the pluggable module.
pluggable type
pluggableType
(Optional) The type of the pluggable module; one of SFP, XFP, X2, AND XENPAK.
Removes the definition for the pluggable module container oid with identifier .1.3.6.1.4.1.9.12.3.1.5.153.
Options
Table B-33 Options and Arguments—vcb pluggablemodule delete
Option
Argument
Description
module
moduleno
The identifier for the pluggable module that you want to delete. The identifier can be a number, string, or OID, depending on the type of identifier used by the relevant device type.
group
pluggable port group
The name of the group from which to delete the pluggable module.
Use the
vcb event add
command to create an event definition for a syslog or a trap in Prime Network based on user input.
Note To create a script to add unsupported traps from a MIB, use the e vcb event view command with the -generatecli option.To list the traps in a MIB that are supported and those that are not, use the vcb event view command with the -mibfile option. For more information, see vcb event view.
. . .
[-subtypen
subtypenName
] [
-ticketablen
][
–severityn
critical|major|minor|warning|info|cleared
]
[
-shortdesc
n
short description string
] [
-autoclear
n
false
|true
]
-user
username
-password
password
Description
The
vcb event add
command creates an event definition in Prime Network based on the user input. Afterwards, the VNE-driver can create specific instances of this event for incoming traps or syslogs, persist them in the event database, and forward them to interested clients.
Usage Example
vcb event add –eventtype
syslog
-eventname
“stack switch status syslog”
-subtype1
“stack switch removed syslog”
-severity1
minor
-subtype2
“stack switch added syslog”
-severity2
cleared
-user
root
-password
admin
-faultnature
ADAC
-faultcategory
“QOS”
Adds a syslog event definition with the name “stack switch status syslog”. Two subtypes are added: “stack switch removed syslog” with severity minor and “stack switch added syslog” with severity cleared. By default, the subevents are not ticketable.
The syslog for which the event definition was added is:
STACKMGR-4-SWITCH_[ADDED|REMOVED]: Switch [dec] has been [ADDED to|REMOVED from] the stack.
A device sends one syslog when a switch is added to a stacked device (clear alarm) and another syslog when a switch is removed from a stacked device (asserted minor alarm).
Options
Table B-34 Options and Arguments—vcb event add
Option
Argument
Description
eventtype
event type
Type of event. Valid values are:
syslog
trap
eventname
event name
Unique string that identifies the event within Prime Network.
alarmid
alarm ID
(Optional) Unique integer identifier for the event.
Note Recommendation—Do not provide this argument; the VCB automatically generates a unique number.
subtypen
subtypen name
Unique string that identifies the subevent with the Prime Network event.
ticketablen
(Optional) Optional parameter for subtype. If specified, indicates that a ticket should be generated for this subevent.
By default, no ticket is generated for the subtype.
-autoclearn
false
|
true
(Optional) Optional parameter for subtype. If the event is ticketable, setting autoclear to false causes the subevent to remain asserted until the clear alarm arrives or the user manually acknowledges or clears the subevent.
Note Root cause events are not autocleared even when autoclear is set to false.
By default, autoclear is true for user-defined event definitions.
severityn
severity level
Optional parameter for subtype. The severity of the subevent. Possible values are critical, major, minor, warning, info, and cleared.
Info is the default severity value for a subevent.
shortdescn
short description
Optional parameter for subtype. A short description of the subevent. This string is stored in the event database.
By default, the subtype value is used as the default shortdesc value.
-faultnature
Parameter that indicates how the fault is cleared, either manually or automatically. Possible values are:
ADAC (Automatically Detected Automatically Cleared) - The event is automatically detected and automatically cleared by the system. For example, “link down” event.
ADMC (Automatically Detected Manually Cleared - The event must be manually cleared by the user. For example, “DWDM fatal error” syslog.
-faultcategory
Event category (3GPP standards). Possible values are:
The
vcb event view
command enables you to view event definitions including event properties such as alarm ID, event subtypes, severity, and ticketability.
Usage Examples
vcb event view –userdefined –eventname
all
-user
root
-password
admin
Returns all the event definitions that were added to Prime Network using the VCB.
Creates, but does not run, a script /Main/VcbEventCommand.sh. The script contains three
vcb
commands for each unsupported trap; the commands add an event (and provide an event ID), event parsing rules, and an event pattern. Optionally, edit the script.
To run the script, change permissions on the file to ensure that it is executable and supply a username and password as input; see this example:
chmod 755 VcbEventCommand.sh
./VcbEventCommand.sh -user
root
-password
admin
Note The Prime Network gateway maintains a known list of MIBs that are used to provide translation for trap varbinds when displayed in the UI. When an event is added from a MIB that is unknown to the gateway, the VCB does not add the MIB to the known MIB list. As a result, the varbinds for this trap might not be translated to user-friendly names.
Options
Table B-36 Options and Arguments—vcb event view
Option
Argument
Description
eventname
eventName
Unique string that represents the event.
Tip Enter all as the eventName to display information on all the event definitions in Prime Network. Use this argument with caution because the number of events can potentially be very large.
substringmatch
(Optional) Indicates that the event name argument is not an exact match.
eventtype
trap | syslog | service
Displays events of a specific type - traps, syslogs or service events.
genericevents
generic event type
Displays all events from the Prime Network database (in raw format).
Tip Enter all as the generic event type to display information on all the events in Prime Network.
ipaddress
neip
(Optional) Generic events filter. IP address for the NE for which you want to see generic events.
date
yyyy-mm-dd
(Optional) Generic events filter. The date after which the events arrived.(Returns events that arrived after the given day.)
time
hh:mm:ss
(Optional) Generic events filter. The time after which the events arrived. (Returns events that arrived after the given time.)
maxrecords
num
(Optional) Generic events filter. The maximum number of events that you want to display. The default value is 100.
mibfile
complete-path-
mibFilename
Loads MIB modules and compares the traps defined in the MIB against the events that are supported in Prime Network. Displays lists of supported traps and unsupported traps.
Note Before using this command option, copy the MIB and dependent MIB files to a local folder. Rename each MIB file, removing the .my file extension from it.
generatecli
(Optional) When provided, produces a script,
NETWORKHOME
/Main/VcbEventCommand.sh. The script contains commands to add basic event support for each unsupported trap that was identified through the
-mibfile
option.
repository
ParsingrulesHive
Mandatory
-generatecli
option. Hive that includes event parsing rules for traps.
group
PatternsHive
Mandatory
-generatecli
option. Hive that includes event patterns for traps.
Use the
vcb event modify
command to modify events that were previously defined using the VCB or to modify event attributes for factory-defined events (by using the
-override
option). This command can also be used to drop events.
The
vcb event modify
command modifies an event definition in Prime Network. It can also be used to instruct the system to drop a specific event.
Note Support for modifying an event is limited due to the complexity involved. When additional changes are required—such as changing the name of an event or a subtype—the supported procedure is to delete the entire event definition and add it afresh:
Delete the event, event pattern, and associated event parsing rules.
Add the event, event pattern, and event parsing rules.
Usage Examples
vcb event modify -eventname
“stack switch status syslog”
Updates the event definition for the stack switch status syslog, changing the severity of the specified subtype to major and making the subtype ticketable. For a corresponding example of how this event was added, see Usage Example for the
vcb event add
.
Drops the “bgp trap” event. This overrides the system-defined event.
Options
Table B-38 Options and Arguments—vcb event modify
Option
Argument
Description
eventname
eventName
Unique string identifies the event within Prime Network.
eventtype trap | syslog | service | drop
Modifies an event of a specific type or instructs the system to drop an event.
alarmid
alarmId
(Optional) Unique integer identifier for the event. If not provided, the VCB automatically generates a unique number.
Note We recommend that you do not provide an input alarm ID.
subtype
n subtypenName
Unique string that identifies the subevent with the Prime Network event.
To retain ticketability for any ticketable subtype—whether you want to modify the subtype or not —you must enter the subtype option and argument along with the ticketable option (below).
ticketable
n
(Optional) Parameter for subtype. Indicates whether a ticket should be generated for this subtype. If not specified, no ticket is generated.
Note To retain ticketability, supply the ticketable option for all subtypes that are currently defined as ticketable events (even for subtypes that you do not intend to modify). Otherwise, the subtypes are modified to be non-ticketable events.
-autoclearn
false
|
true
(Optional) Parameter for subtype. If the event is ticketable, setting autoclear to false causes the subevent to remain asserted until the clear alarm arrives or the user manually acknowledges or clears the subevent.
Note Root cause events are not autocleared even when autoclear is set to false.
By default, autoclear is true for user-defined event definitions.
severity
n
value
(Optional) Parameter for subtype. Specifies the severity of the subevent. Possible values are critical, major, minor, warning, info, and cleared.
shortdesc
n
short description string
(Optional) Parameter for subtype. A short description.
override
(Optional) Indicates that you expect to override attributes for a factory-defined event.
-faultnature
Parameter that indicates how the fault is cleared, either manually or automatically. Possible values are:
ADAC (Automatically Detected Automatically Cleared) - The event is automatically detected and automatically cleared by the system. For example, “link down” event.
ADMC (Automatically Detected Manually Cleared - The event must be manually cleared by the user. For example, “DWDM fatal error” syslog.
-faultcategory
Event category (3GPP standards). Possible values are:
Use the
vcb event delete
command to delete an event definition. The
vcb event delete
does not delete or change the event template from which the event definition was cloned.
The
vcb event delete
command removes event definitions created using the VCB and removes event attribute overrides from factory-defined events. Deleting a factory-defined event removes event attribute overrides only and not the event itself; the original event attributes are then applied to future events.
Use the
vcb eventparsingrules add
command to create a VNE-driver registration for adding parsing rules to support a new trap or syslog by customizing a specified set of event templates.
The
vcb eventparsingrules add
command creates a VNE-driver event registration based on the templates chosen by the user. This enables Prime Network to identify and associate the event to a particular device component instead of classifying the event as a generic event.
The command does the following:
Creates a separate registry configuration (a copy) for customizing the event. Parameters that you input using the command affect the copy.
Creates rules for handling the event based on the event template and user input.
Updates the site.xml file, so that Prime Network can differentiate customizations created using the VCB from changes supplied in VNE-driver registration files.
-create_ana_syslog_event_type
“stack switch status syslog”
-user
root
-password
admin
Adds parsing rules to identify the syslog correctly, associates it with the correct device component, and creates the corresponding Prime Network event and subevent.
Four event templates are entered:
syslog-identification—Rules that pertain to syslog identification.
syslog-subtype-from-expression—Rules that map the syslog values (in this case, ADDED and REMOVED) to the event subtype names: stack switch added syslog, stack switch removed syslog. The example includes two rules, separated by commas.
Note Rules must be comma-separated. Each rule must include a value and event subtype, separated by a hyphen: value-event subtype.
create-managedelement-key—Indicates that the syslog should be associated with the managed element. (There are no input parameters for this template.)
create-ana-syslog-event—Provides rules for creating instances of the corresponding Prime Network event (defined with the
vcb event add
command).
Input parameters for the event templates are variable arguments that depend on the templates selected.
syslog_identification_expression—The actual syslog message with input that is of interest to the user and is masked with special keys, such as %%subtypekey%%, %%uniqueid%%, and %%entityid%%, depending on which is applicable. In the previous example, only subtypekey and uniqueid parameters are relevant.
Note Only a substring of the message is used in the example, because whatever comes afterward is of no interest to the user.
syslog_subtype_from_expression_replacing_rules—Specifies the mapping from the subtypekey to the subevent name. The subevent string should exactly match one of the subevent names that was defined using the
vcb event add
command.
create_ana_syslog_event_type—Specifies the event name.
Note This parameter should exactly match the event name defined using the vcb event add command.
Options
Table B-42 Options and Arguments—vcb eventparsingrules add
Option
Argument
Description
templates
template name1, ... template namen
Comma-separated list of event template names. Event templates are divided into categories that correspond to the function they fulfill (identification, association, and so on.) Depending upon the trap or syslog that you are adding, select no more than one template from each template category.
group
repository
Specifies the vendor-specific trap or syslog repository file under which the customizations should be made.
rule
rulename
String that is used as a key name for event rule definition.
enable
(Optional) Indicates whether the rule is enabled or disabled. Only enabled rules are used to parse incoming traps and syslogs.
variable arguments
Arguments vary from one event template to another event template.
syslog_identification_
testmessage
(Optional) Parameter valid for syslogs only. An example syslog message used to check the correctness of the regular expression that the VCB creates automatically based on user input.
The
vcb eventparsingrules view
command displays event registrations. Use it to verify that you successfully added an event parsing rule or to view parameters (to fill them in based on the example).
Syntax
vcb eventparsingrules view
-group
repository name
–rulename
{
rulename
| all } [
-detail
]
[-userdefined]
-user
username
-password
password
The
vcb eventparsingrules view
command shows configuration settings. Use it to list:
Details of the events repository for a particular rulename or for all the events in the file. The information displayed includes the parsing rules and important parameters in each rule.
Input parameters in the event template specified by -template option. If all is specified, the user input parameters of all the templates are displayed.
Displays the syslog-identification event template definition, including a detailed description of the input parameters required when using the template to add event parsing rules.
Use the
vcb eventparsingrules modify
to modify the parsing rule definitions. The most common use case for this command is to select one or more different templates because the certification of the customization failed.
The
vcb eventparsingrules modify
command changes parsing rule definitions based on the templates chosen by the user. The command can also be used to add parsing rules that were inadvertently omitted when adding the parsing rule. For example, use the command to add the rules for extracting the uniqueid parameter.
Options
Table B-46 Options and Arguments—vcb eventparsingrules modify
Option
Argument
Description
templates
template name1, ... template namen
Comma-separated list of event template names. Event templates are divided into categories that correspond to the function they fulfill (identification, association, and so on.) Depending upon the trap or syslog that you are adding, select no more than one template from each template category.
group
repository
The hive under which the customizations should be made. The hive is the vendor-specific trap or syslog repository file.
rulename
ruleName
String that is used as a key name for event rule definition.
enable
(Optional) Indicates whether the rule should be enabled or disabled. Only enabled rules are used to parse incoming traps and syslogs.
Note vcb eventparsingrules modify command is not supported in Prime Network. To modify the parsing rules use repository and rule name option. For the list of global options, see Global Command Options.
Use the
vcb eventparsingrules delete
command to delete the parsing rule definitions of an event. Doing so does not delete or change the event template from which that event definition was cloned.
The
vcb eventparsingrules delete
command removes event parsing rule definitions created from an event template. It does not change or delete the event template itself.
Use the
vcb eventpattern add
command to create a VNE-driver registration that points from the parsing rules hive, which is scheme or VNE-specific, to the parsing rules defined in the repository file.
Note Only those events that have this pointer are deemed as supported events. Other events are deemed generic events despite having parsing rules and event definitions.
Adds a pointer from the parsing rules file to the actual definitions in the parsing-rules hive with pattern ID 202. It points to the key (rule) named stack-switch-status-syslog in the cisco-syslog-repository file.
Options
Table B-50 Options and Arguments—vcb eventpattern add
Option
Argument
Description
patternid
patternId
(Optional) (Recommendation: do not provide.) Unique integer to identify the supported event to VNEs. If not provided, VCB generates this number automatically.
Note Omitting this option and argument enables the VCB to ensure that the patternid is unique and that it does not overlap with other file definitions due to registry inheritance.
group
parsing rules hive
The hive to which this pattern should be added. The parsing-rules hives are generally scheme-specific. Device type-specific definitions can also be made.
repository
parsing rules repository hive
The trap or syslog repository where the actual parsing rules are defined.
Note Enter the same hive that was specified when creating parsing rules registrations using the vcb eventparsingrules add command.
rulename
rulename
String that is used as a key name for event rule definition.
Note Enter exactly the same string as the one that was specified when creating parsing rules registrations using the vcb eventparsingrules add command.
Use the
vcb eventpattern view
command to display event registrations. It is useful when you need to verify successful completion of an add command or to help find a similar case for filling in parameters on other commands.
The
vcb eventpattern view
command shows the actual set of events that are supported by a particular NE type or scheme. It displays the pattern ID and the repository file where the event parsing rules are defined. When the substringmatch option is used, only rules that contain a certain substring are displayed; use this option, for example, to obtain rules for a technology name such as MPLS.
Displays the event pattern definition for the specified rulename; that is, the pattern ID, and the pattern is pointing to the parsing rules repository.
This example shows the entire event definition for all BGP events (including those defined using the VCB) defined in the cisco-syslog-parsing-rules hive. The following information is displayed:
Pattern definitions—Parsing rules repository, pattern ID
Parsing rules definitions—All rules in the definition that require user input, and the values set for these parameters
Event definitions—Event attributes such as eventname, subevent names, ticketability, severity and so on
Options
Table B-52 Options and Arguments—vcb eventpattern view
Option
Argument
Description
group
parsingrules hive
The parsing-rules filename used by the NE type or scheme.
rulename
rule name
Unique string that represents the event parsing rules.
Tip Enter all as the rule name to list all event parsing rules defined in the repository.
substringmatch
(Optional) Indicates that the rule name provided is not an exact match. This option is useful when you want to know the names of all rules that belong to a particular technology, such as BGP.
full
(Optional) Displays the entire details of the event, from the pattern definition and parsing rules to the event definition. Provides the complete picture of the how an event is supported in Prime Network.
Note Avoid this option when using the “all” argument because it can result in a very large output.
This example assumes that we are starting with the eventpattern with ID 202 that points to the cisco-syslog-repository (as shown in Usage Examples
for the
vcb eventpattern add
command). In this example, we modify the repository for the eventpattern with ID 202 to the cisco-router-syslog-repository.
NoteVcb eventpattern modify cannot be performed on the group as this is the identifier for the pattern. You can modify only the repository or rule name.
Options
Table B-54 Options and Arguments—vcb eventpattern modify
Option
Argument
Description
patternid
patternId
Unique integer to identify the supported event to a VNE.
group
parsing rules hive
The hive in which this pattern is to be modified. The parsing-rules hives are generally scheme-specific. VNE-specific definitions can also be made using this hive.
repository
parsing rules repository hive
(Optional) The hive where the actual parsing rules are defined (the trap/syslog repository).
Enter the same hive that was specified when creating parsing rules registrations using the
vcb eventparsingrules add
command.
rulename
ruleName
String that is used as a key name for event rule definition.
Note Enter exactly the same string as the one that was specified when creating parsing rules registrations using the vcb eventparsingrules add command.
Use the
vcb eventpattern delete
command to delete the parsing rule from the list of supported event patterns. Doing so does not delete the parsing rules in the repository file.
Deletes the parsing rules pattern with ID 202. All registry entries added as a part of the
vcb eventpattern add
command will be removed from site.xml.
Options
Table B-56 Options and Arguments—vcb eventpattern delete
Argument
Description
patternid
pattern ID
Unique integer to identify the supported event to a VNE.
group
parsing rules hive
The hive in which this pattern is to be modified. The parsing-rules hives are generally scheme-specific. VNE-specific definitions can also be made using this hive.
The
vcb eventarg view
command option displays all the VCB event parsing rules template variable arguments along with descriptions.
Troubleshooting Event Customization Using the VCB CLI
Errors that you receive from the VCB CLI are self-explanatory. Most errors make very clear what you need to do to correct the problem that has occurred. For example, if an event name already exists, you must enter a different event name. If an alarm ID or pattern ID is already in use, you should omit the related option and argument from your command and allow the VCB to generate a unique ID for you.
Note To get more information, add the -debug option to any vcb command; for more information, see Global Command Options.
Errors that occur in the server are not as obvious. If a newly supported event does not appear in Prime Network Events or Prime Network Vision, you need to perform some troubleshooting, as follows:
Step 1 Ensure that the device is configured to send events to Prime Network gateway. Use any tool to snoop and check whether the simulated network events that you are sending are actually arriving at the Prime Network gateway. If not, fix the issue whether it is connectivity, firewall and so on, then proceed to next step.
Step 2 Enable debug for event processing in the VNE. Execute the following commands for the AVM that has the VNE that you will be testing.
runRegTool.sh -gs localhost set 127.0.0.1 avm<avmid>/services/logger/log4j.category.com.sheer.metrocentral.framework.eventapplication.eventcorrelation.SendAlarmMessageUtil DEBUG
runRegTool.sh -gs localhost set 127.0.0.1 avm<avmid>/services/logger/log4j.category.com.sheer.metrocentral.framework.eventmanager.EventManager DEBUG
runRegTool.sh -gs localhost set 127.0.0.1 avm<avmid>/services/logger/log4j.category.com.sheer.metrocentral.framework.eventapplication.parsing.ParsingApplication DEBUG
Step 3 Allow the VNE to come up, then open the log file for the AVM. Check whether the newly added pattern is being loaded at VNE startup. Look for an entry in the log file that is similar to the following text:
DEBUG [06 21 2010 12:19:59.524 IST] - ParsingApplication.buildRulesMatrix - pattern ATMLC-6-CLOCKING with index 5001 in the registry is now mapped into index 123 in the parsing application.
The above DEBUG statement includes both the rulename (ATMLC-6-CLOCKING with) and the pattern id (5001) of the newly added event. If a similar statement is not printed for the newly added event, go to Step 4; otherwise, go to Step 5.
Step 4 Review the
vcb eventparsingrules add
command that you used, checking whether you enabled the event using the
-enable
option. If the command was issued without the
-enable
option, delete the event parsing rules using the
vcb eventparsingrules delete
command and add the event parsing rules again, ensuring that you use with the
-enable
option.
Step 5 Check statically whether the links between event pattern, event parsing rules, and event are OK. To perform this check, use the
vcb eventpattern view
command with the
-full
option (see Example 3). The output should display details of all the three customizations. A typo in the rulename, event type name, or event subtype name can prevent the links from being established and result in a partial display. For example, if the rulename in the
vcb eventpattern
command does not match that used in the
vcb eventparsingrules
command, only event pattern details will be displayed; details for event parsing rules and the event will not be displayed.
If the output is OK (that is, it includes details for all three customizations), go to Step 7. Otherwise, go to Step 6.
Step 6 Review the commands that have been issued and re-add or modify the customizations as required. Then go back to Step 5.
Step 7 After the static verification that you perform in step 5 succeeds, check whether the parsing itself is failing. Put a tail on the AVM log file and resend the simulated event. When parsing fails, the event is classed as a generic event. Log output similar to the following will appear.
DEBUG [06 21 2010 16:11:09.623 IST] - EventManager.filterEventApplications - Event has been dropped by application [com.sheer.metrocentral.framework.eventapplication.filter.GenericSyslogTypeFilterApp]
Step 8 Open the log file and go backwards from the end of the file until you come to the place where logs pertaining to the actual parsing process are available. Search for the string 'Testing pattern: handle
rulename
', where rulename is the string you used in the
vcb eventpattern add
command. Here you will find logs that report the results of testing each rule. Identify the rule that failed as shown in the following log.
DEBUG [06 21 2010 16:11:09.622 IST] - ParsingApplication.processEvent - Exception during parsing correlation rules, at pattern-125, rule-2
Stack:[(uniqueid=>3),(syslog=>7.212.205 %FAN-3-FAN_0K: Fan 3 had earlier reported a rotation error. It is ok now),(subtypekey=>0K),(.prulescache=>[]),(counter=>0)]
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sheer.metrocentral.framework.correlation.parsing.ChangeArgumentValue.execute
(ChangeArgumentValue.java:68)
In the above example, the parsing rule that failed is ChangeArgumentValue. The failure implies that the replacing rules that map the network event parameters to the Prime Network event subtypes are failing. Review the replacing_rules arguments used in the
vcb eventparsingrules
command and make the necessary changes.
The list of parsing rules (classes) and the corresponding option in vcb are given in the following table. Review the parameter values of the failing option and make appropriate changes.
Repeat the above steps until all errors are resolved and the event is parsed correctly and the Prime Network event is generated as expected.
VCB Template Reference
Use the information in this section to determine which template best matches the device, module, or event that you want to manage with Prime Network. Information in this section is also useful when you test the customizations that you have made.
Features, advantages, and limitations of template-based U-VNEs are template-dependent. The GenericUVNE template uses the same set of MIB-II based instrumentation for logical inventory discovery as is used by the Prime Network Generic SNMP VNE. The advantage of the U-VNE—created using the VCB and the GenericUVNE template—over the Generic SNMP VNE is that you can identify the device type for the U-VNE and further extend the U-VNE for additional event recognition using the VCB.
The GenericUVNE template is applicable to Cisco and non-Cisco NEs and supports event customization with event association to Managed Element only.
Use the GenericUVNE template to model any NE that is not currently supported by Prime Network. A U-VNE created this way is very similar to the Generic SNMP VNE. It provides basic information, such as the physical interfaces available on the device and their status, rudimentary logical modeling, and parsing of basic traps; see GenericUVNE—Supported Traps. Using the VCB, however, you can configure additional traps and syslog recognition for a U-VNE created using the GenericUVNE template.
This U-VNE models NEs using SNMP MIB-II, which is the most generic and widely used management interface. This U-VNE does not consider the device vendor, device type, or software version of the NE that it models. Using the VCB, however, you can update device type attributes for a U-VNE created using the GenericUVNE template.
Table B-58 summarize the features and advantages of the GenericUVNE template.
Table B-58 GenericUVNE Summary
Features
Advantages
Limitations
Same physical and logical inventory as a Generic SNMP VNE.
Applicable to Cisco and non-Cisco NEs.
User-defined device type attributes:
– Device category—Determines the icon that is displayed.
– Element type.
Event recognition, enabling Prime Network to forward events from unsupported devices to OSS applications.
When compared with a Generic SNMP VNE, this U-VNE provides:
Simplified trap and syslog recognition (using the VCB).
Application of soft properties to a specific U-VNE (as opposed to a device type).
Event association to Managed Element only
NoteExpedite Legend—The Expedited column in the service event tables in this chapter can contain these values: Y—Indicates that the service event is expedited by a syslog or trap generated by the device. This means that the syslog or trap causes the VNE to poll the device without waiting for the usual polling cycle, thus enabling quicker detection of the event. N —Indicates that the service event is not expedited. The service event is not expedited.This means that the VNE will poll this device during the next regularly scheduled polling cycle.
Note In some of the following tables, attributes, protocols, technologies, etc. are listed as supported. Supported denotes that SNMP queries are made to the NE for those attributes, etc. Whether values are available in response to the queries depends on whether the instrumentation supported in the NE works.
A U-VNE created using the GenericUVNE template uses a static model for the device chassis. The rest of the physical inventory is modeled using the ifTable. Since modules are not modeled, this U-VNE creates a single generic module on which all of the physical interfaces reside.
Table B-59 describes which MIB tables are used to model the physical inventory components that are supported by a U-VNE created using the GenericUVNE template.
Table B-59 MIBs Used for Physical Inventory Model of GenericUVNE
Logical Component
MIB Table
Columns/Tables Used For Modeling
Interfaces
ifTable
ifDescr
ifType
ifOperStatus
Ports
Port status
Port speed
MAC address
ifTable
ifTable
ifTable
ifOperStatus and ifAdminStatus
ifSpeed
ifPhysAddress (Ethernet ports)
Note Certain general properties on the managed element, such as system description, are modeled using the RFC1213-MIB.
GenericUVNE—Logical Inventory Model
Table B-60 describes which MIB tables are used to model the logical inventory components that are supported by a U-VNE created using the GenericUVNE template. Attributes in
Table B-60 are taken from MIB-II.
Table B-60 MIBs Used for Logical Inventory Model of GenericUVNE
Logical Component
MIB Table
Columns/Tables Used For Modeling
IP Interfaces
ipAddrTable
ipAdEntIfIndex
ipAdEntNetMask
ARP table
ipNetToMediaTable
ipNetToMediaPhysAddress
ipNetToMediaType
Routing table
ipRouteTable
ipRouteDest
ipRouteIfIndex
ipRouteNextHop
ipRouteType
ipRouteMask
Bridging table
dot1dTpFdbTable
—
Default bridge
dot1dBridge
dot1dBaseBridgeAddress
dot1dBaseType
GenericUVNE—Supported Traps
A U-VNE created using the GenericUVNE template can parse the standard MIB-II and Bridge-MIB traps listed in
Table B-61.
Table B-61 Supported Traps for GenericUVNE
Standard MIB-II Traps
authenticationFailure
mplsTunnelReoptimized
bgpBackwardTransition
mplsTunnelRerouted
bgpEstablished
mplsTunnelUp
coldStart
ospfIfAuthFailure
entConfigChange
ospfIfConfigError
linkDown
ospfIfRxBadPacket
linkUp
ospfIfStateChange (down)
mplsL3VpnVrfDown
ospfIfStateChange (up)
mplsL3VpnVrfNumVrfRouteMaxThreshExceeded
ospfMaxAgeLsa
mplsL3VpnVrfRouteMidThreshExceeded
ospfNbrStateChange (down)
mplsL3VpnVrfUp
ospfNbrStateChange (up)
mplsLdpInitSessionThresholdExceeded
ospf-if-packet-retransmit
mplsLdpSessionDown
ospfOriginateLsa
mplsLdpSessionUp
ospfTxRetransmit
mplsTunnelDown
warmStart
Bridge-MIB Traps
dot1dBaseBridgeAddress
dot1dBaseType
A U-VNE created using the GenericUVNE template can identify traps, but it cannot correlate them. This is because this U-VNE does not include the model entities required by higher trap parsing levels.
For example, if Prime Network receives an mplsTunnelDown trap from a device modeled with the GenericUVNE template, Prime Network can identify the Tunnel Down trap, but it cannot perform correlation on the trap. The reason is that th is U-VNE does not investigate tunnels, which means that there is no Device Component in the model to which Prime Network can attach a correlation flow.
For this U-VNE, event association is always to the
Managed Element
.
GenericUVNE—Supported Events
A U-VNE created using the GenericUVNE template supports the service events listed in
Table B-62.
Table B-62 Supported Service Events for GenericUVNE
A U-VNE created using the GenericUVNE template uses MIB2 to cover the widest possible range of NEs. Although MIB2 is a widely accepted industry standard, most network equipment vendors augment MIB2 with other Management Interfaces such as private MIBs, Telnet, XML, and so on. In addition, different vendors sometimes have different implementations of standard MIBs. As a result, even the limited model created by this U-VNE is dependent on the vendor’s adherence to general network management standards.
GenericUVNE—Supported Topologies
A U-VNE created using the GenericUVNE template supports the topologies listed in
Table B-63.
Table B-63 Supported Topologies for GenericUVNE
Topology Type
Link Type
Supported
Ethernet
Ethernet
Y
Physical Layer
Ethernet
Y
GenericUVNEs—Supported Technologies
The following sections list the objects and attributes that are recognized on a U-VNE created using the GenericUVNE template, per technology:
Module templates define a set of port layers—from the connector at Layer 0 to encapsulation at Layer 2—that are applicable to a module. These templates ensure that each port is modeled with the correct port layer information based on the ifType obtained from the SNMP MIB output.
Module templates are applicable to standard modules only (not pluggable modules). You do not need to use a module template to add a pluggable module.
When adding support for a new module using the VCB, you must identify the module template that matches the capabilities of the module.
For example, the atm-default module template contains the following port layer definitiions, which are typical port layers for an OC3 ATM card:
Layer 0—Fiber optic
Layer 1—OC3
Layer 2—ATM
These definitions make this template suitable for modules with ports that:
Use fiber optic cable.
Support the OC-3 data transfer rates over SONET.
Use ATM encapsulation for transporting IP traffic between two peers.
Note You cannot add modules to a U-VNE created using the GenericUVNE template.
Module templates are collected into groups, such as the ciscophysicalspec2 group for Cisco modules. The information contained in the module specification files is summarized in the Module Groups and Module Specification Files.
Note Module definitions that you create with the VCB are added to the module group that contains the template on which the definition is based.
After you obtain the module identifier and research the capabilities of the module, use Module Templates by Technology to identify the module template that best matches the module. You can then add support for the module using the VCB.
Note Unlike the modeling that Prime Network does for standard modules, Prime Network models only the ports for pluggable modules. The only module group for pluggable modules is the pluggable-ports-spec file. The remainder of this section applies to standard modules only (not pluggable modules).
A module group is the name of a vendor-specific module specification file that is stored in the Prime Network registry. A module specification file is an XML file that lists supported modules and other properties, such as port layers and sysOID. When you use
vcb module
commands to add, modify, or delete a module:
The VCB modifies the module specification file: adding, updating, or deleting the module definition.
Note The VCB allows you to update and delete only those modules that you added using the VCB.
Prime Network enables you to extend the following module specification files:
ciscophysicalspec2
ciscocatalyst3400spec
cisco-catalyst-spec
Table B-69 summarizes the technologies that are supported and the module templates that are provided in the module specification files. For more information about a module template, use the link in the Technologies column.
Table B-69 Module Group Summary for Standard Modules
Table B-70 lists module templates that support EthernetCSMA/CD at Layer 1 and a single connector type at Layer 0. When there is more than one Layer 2 option, Layer 2 is modeled based on transmission rate.
Module Group
These templates are defined in the ciscophysicalspec2 module group.
Table B-70 Module Templates—Ethernet (Fixed)
Template Name
Layer 0
Layer 1
Layer 2
Example Modules
A10GigaEthernet
Fiber optic
EthernetCSMA/CD
10 Gigabit Ethernet
WS-SUP32-10GE-3B
7600-ES+2TG
ethernet-default-over-optic
Fiber optic
EthernetCSMA/CD
Ethernet
Fast Ethernet
Gigabit Ethernet
WS-6700-DFC3B
WS-6700-DFC3BXL
ethernetDefault
RJ45
EthernetCSMA/CD
Ethernet
Fast Ethernet
Gigabit Ethernet
8FE-TX-RJ45
SPA-8X1FE-TX-V2
gigaEthernet
Fiber optic
EthernetCSMA/CD
Gigabit Ethernet
WS-X4624-SFP-E
7600-ES+3C
EthernetChannelSwitchDefault
RJ45
EthernetCSMA/CD
EtherChannel
NM-16ESW
Ethernet (Multiloader)
Table B-71 lists Ethernet module templates that support multiple options at more than one port layer.
Module Group
These templates are defined in the ciscophysicalspec2 module group.
Note In addition to Ethernet, some module templates in Table B-71 also support POS or DWDM ports. (See the footnotes for Table B-71.)
1.The connector type is modeled as RJ45 only for a Gigabit Ethernet port that is not pluggable. The connector type for other Gigabit Ethernet and 10 Gigabit Ethernet ports is modeled as fiber optic.
2.The connector type is modeled based on transmission rate.
3.This module template supports either Ethernet or POS ports.
4.This module template supports either Ethernet or DWDM ports.
POS (Fixed)
Table B-72 lists POS module templates that support fixed Layer 0 (fiber optic) and Layer 1 (OC3, OC12, or OC48) options.
Module Group
These templates are defined in the ciscophysicalspec2 module group.
Table B-72 Module Templates—POS (Fixed)
Template Name
Maximum Transmission Rate (Mbps) Supported
Layer 0
Layer 1
Layer 2
Example Modules
PPPdefaultOC48
2488.32
Fiber optic
OC48
PPP
HDLC
Frame relay
SFP-OC48-IR1
gsr-e-qoc48-sm-lr-sc
16OC48-POS/DPT
PPPdefault
155.52
Fiber optic
OC3
PPP
HDLC
Frame relay
GSR-SFC6
GSR-CSC
POS (Multiloader)
Table B-73 lists templates for POS modules with multiple Layer 2 options.
Module Group
These templates are defined in the ciscophysicalspec2 module group.
Table B-73 Module Templates—POS (Multiloader)
Template Name
Maximum Transmission Rate (Mbps) Supported
Layer 0
Layer 1
Layer 2
Example Modules
POS-OC3-default
155.52
Fiber optic
OC3
PPP
HDLC
Frame Relay
—
PPPdefaultOC12
622.08
Fiber optic
OC12
PPP
HDLC
Frame Relay
SPA-8XOC12-POS
PPPdefaultOC192
9,953.28
Fiber optic
OC192
PPP
HDLC
SPA-OC192POS-LR
PPPdefaultOC3
155.52
Fiber optic
OC3
PPP
HDLC
Frame Relay
SFP-OC3-SR
SFP-OC3-IR1
PPPdefaultOC768
39,813.12
Fiber optic
OC768
PPP
HDLC
Frame Relay
1OC768-ITU/C
DWDMOC768
39,813.12
Fiber optic
OC768
PPP
HDLC
—
Channelized T1/E1 (Fixed)
Table B-74 lists templates for channelized T1/E1 modules where port layers are fixed.
Module Group
These templates are defined in the ciscophysicalspec2 module group.