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:
vcb uvne add
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
vcb uvne add -sysoid sysoid -clonesysoid clone_sysoid -user username -password password
vcb uvne add -sysoid sysoid -clonedevicefamily devicefamily [-devicetype device type ] -user username -password password
vcb uvne add -sysoid sysoid -softwareversion software-version -clonesoftwareversion clone-softwareversion -clonedevicefamily devicefamily -scheme <product|ipcore > [-devicetype device type name ] -user username -password password
Description
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.
Usage Examples
Example 1
vcb uvne add -sysoid
.1.2.3.4 -template
GenericUVNE -group uvne
-user root -password admin
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).
Example 2
vcb uvne add -sysoid .1.2.3.4 –clonesysoid .1.3.6.1.4.1.9.1.108 -user root -password admin
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.)
Example 3
vcb uvne add -sysoid .1.2.3.4 –softwareversion 12.6(2) –clonesoftwareversion 12.0(23)S2 –clonedevicefamily 100xx –scheme product -user root -password admin
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.)
Example 4
vcb uvne add -sysoid .1.2.3.4 –clonedevicefamily 100xx -user root -password admin
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
|
|
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. |
Note For the list of global options, see Global Command Options.
Error Codes
Table B-4 Error Codes—vcb uvne add
|
|
101 |
The sysOID already exists and is already modeled as a VNE. |
102 |
U-VNE template file not found. |
103 |
No such template name in the templates file. |
104 |
No such device type configuration exists. |
Note For the list of general VCB error codes, see General Error Codes.
vcb uvne view
The vcb uvne view command returns an existing U-VNE configuration.
Syntax
vcb uvne view -sysoid {sysoid | all} -user username -password password [-userdefined][-detail]
vcb uvne view -template { template name | all} -group <template group name> -user username -password password
Description
Use the vcb uvne view command to:
- Display information based on the specified sysOID.
- Display available templates found in the specified group.
Usage Examples
Example 1
vcb uvne view
-sysoid .1.2.3.4
-user root -password admin -userdefined
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
Here is an example of the output:
SysOid......:.9.7.6.5.4.3.1
DeviceFamily:76xx
CloneSysOid.:.1.3.6.1.4.1.9.1.863
Scheme........:product
Module Spec.........:ciscophysicalspec2
Trap Parsing Rule...:cisco-trap-product-parsing-rules
Syslog Parsing Rule.:cisco-syslog-product-parsing-rules
Scheme........:ipcore
Module Spec.........:ciscophysicalspec2
Trap Parsing Rule...:cisco-trap-ipcore-parsing-rules
Syslog Parsing Rule.:cisco-syslog-ipcore-parsing-rules
SysOid.....:.3.4.5.6.7
Template...:GenericUVNE
Group......:uvne
Device Type:UNKNOWN
Scheme........:product
Module Spec.........:N/A
Trap Parsing Rule...:genericuvne-trap-parsing-rules
Syslog Parsing Rule.:genericuvne-syslog-parsing-rules
Options
Table B-5 Options and Arguments—vcb uvne view
|
|
sysoid sysoid |
Returns the configuration of the specified VNE, including the device type, the user-friendly name, and the template (for U-VNEs).
Tip Enter
all as the
sysoid to view the configuration of all sysOIDs (U-VNEs and developed VNEs) configured in the system.
|
group template filename |
Returns the configuration of all sysOIDs and templates contained in the specified group.
Tip Enter
all as the
template filename to view the template associations for each group in the system.
|
userdefined |
Lists the U-Vne created through vcb command only. |
details |
Shows following additional information:
- Module Spec Name associated with the sysoid.
- Syslog and Trap Parsing rule name associated with the sysoid
|
Note For the list of global options, see Global Command Options.
Error Codes
Table B-6 Error Codes—vcb uvne view
|
|
102 |
U-VNE template file not found. |
103 |
No such template name in the templates file. |
104 |
No such device type configuration exists. |
111 |
The SysOID specified does not exist. |
Note For the list of general VCB error codes, see General Error Codes.
vcb uvne modify
The vcb uvne modify command modifies the configuration of an existing U-VNE.
Syntax
vcb uvne modify
-sysoid
sysoid
-template
template name
-group
template filename
-user username -password password
vcb uvne modify
-sysoid
sysoid
-devicetype
device type -user username -password password
vcb uvne modify –sysoid sysoid -clonesysoid sysoid -user username -password password
vcb uvne modify –sysoid sysoid -softwareversion softwareversion -clonesoftwareversion clonesoftwareversion -clonedevicefamily devicefamily -scheme vnescheme -user username -password password
vcb uvne modify –sysoid sysoid -clonedevicefamily devicefamily -user username -password password
Description
Use the vcb uvne modify command to:
- Associate the U-VNE with another U-VNE template.
- Change the device type associated with the U-VNE.
- Change the cloning reference of a U-VNE.
Usage Examples
Example 1
vcb uvne modify -sysoid
.1.2.3.4
-group
uvne-product
-template GenericUVNE
-user root -password admin
Modifies the template of the U-VNE to the newly specified template defined in the given group.
Example 2
vcb uvne modify
-sysoid
.1.2.3.4
-devicetype
CISCO_1760 -user root -password admin
Modifies the device type for the U-VNE with sysOID 1.2.3.4.
Example 3
vcb uvne modify
-sysoid
.1.2.3.4 –clonesysoid .1.3.6.1.4.1.9.1.108 -user root -password admin
Modifies a device, with sysOID.1.2.3.4, to point to a new device family based on the clone sysoid.1.3.6.1.4.1.9.1.108.
Example 4
vcb uvne modify
-sysoid
.1.2.3.4
–clonedevicefamily
12xxx
-user root -password admin
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
|
|
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. |
Note For the list of global options, see Global Command Options.
Error Codes
Table B-8 Error Codes—vcb uvne modify
|
|
102 |
U-VNE template file not found. |
103 |
No such template name in the templates file. |
104 |
No such device type configuration exists. |
112 |
The sysOID does not exist or already exists and is already modeled as a VNE. |
Note For the list of general VCB error codes, see General Error Codes.
vcb uvne delete
The vcb uvne delete command deletes a U-VNE.
Syntax
vcb uvne delete -sysoid sysoid -user username -password password
vcb uvne delete -sysoid sysoid -devicefamily DeviceFamilyName -scheme schemeName -softwareversion “softwareVersionNumber” -user username -password password
Description
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.
Usage Example
Example 1
vcb uvne delete -sysoid
.1.2.3.4 -user root -password admin
Deletes the U-VNE-driver configured for the device with sysOID 1.2.3.4.
Example 2
vcb uvne delete -sysoid .1.2.3.4 -devicefamily 70xx -scheme product -softwareversion “12.0(23)S3”
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:
vcb uvne add -sysoid.1.3.6.1.4.1.9.1.917 -softwareversion "15.1(2)SG1" -clonesoftwareversion "gt 12.2(52)SG" -clonedevicefamily cisco-catalyst-4900-series -scheme product -devicetype CISCO_CATALYST_4900M -override -user root -password admin
then, the vcb uvne delete syntax should be as follows:
vcb uvne delete -sysoid.1.3.6.1.4.1.9.1.917 -devicefamily cisco-catalyst-4900-series -scheme product -softwareversion "15.1(2)SG1" -user root -password admin
Options
Table B-9 Options and Arguments—vcb uvne delete
|
|
sysoid sysoid |
The sysObject ID of the U-VNE configuration that you want to delete. Note Deleting the U-VNE does not delete or otherwise affect the U-VNE template from which the U-VNE was created. |
Note For the list of global options, see Global Command Options.
Error Codes
Table B-10 Error Codes—vcb uvne delete
|
|
112 |
The sysOID does not exist or already exists and is already modeled as a VNE. |
Note For the list of general VCB error codes, see General Error Codes.
VCB CLI Reference: Standard and Pluggable Modules Commands
You can use the VCB CLI to create and manage standard and pluggable modules as described in these topics:
VCB CLI Command Reference: Standard Modules
These topics provide reference information for the vcb module commands you can use to create, view, and delete standard modules:
vcb module add
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.
Usage Examples
Example 1
vcb module add -module
“.1.3.6.1.4.1.9.12.3.1.9.29.99”
-template
“1.2.3.4”
–group
ciscoentitymibspec
–hardwaredesc
cevCat6kWsf6kpfc3b
-user root -password admin
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.
Example 2
vcb module add -module
“.1.3.6.1.4.1.9.12.3.1.9.29.99”
-sysoid “7.7.7”
-template “1.2.3.4”
-scheme product -user root -password admin
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
|
|
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. Note Regular modules and pluggable modules use different module spec files. For information about pluggable modules, see VCB CLI Command Reference: Pluggable Modules. |
sysoid sysoid |
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. |
Note For the list of global options, see Global Command Options.
Error Codes
Table B-20 Error Codes—vcb module add
|
|
103 |
No such template name in the templates file. |
111 |
The SysOID specified does not exist in site.xml. |
401 |
Module already exists in the spec file or in site.xml (thus is already modeled). |
402 |
Module template file not found. |
Note For the list of general VCB error codes, see General Error Codes.
vcb module view
The vcb module view command returns an existing module configuration.
Syntax
vcb module view -sysoid sysoid
-module {
module identifier | all}
-user root -password admin -scheme <scheme>
vcb module view -group module group -module {
module identifier | all}
-user root -password admin
vcb module view -group module group -template {
template name | all}
-user root -password admin
Description
Use the vcb module view command to:
- Display module information based on the driver associated with the defined sysOID.
- Display details about the specified module.
- Display available templates found in the specified module spec file.
Usage Examples
Example 1
vcb module view
-sysoid
.1.2.3.4
-module
all
-user root -password admin -scheme product
Returns the list of supported modules for the device with sysOID 1.2.3.4.
Example 2
vcb module view
-sysoid
.1.2.3.4
-module
50068 -user root -password admin -scheme product
Returns the port layer definitions for module 50068, which was added to the VNE-driver for the device with sysOID 1.2.3.4.
Example 3
vcb module view
-group
ciscophysicalspec2
-module
all -user root -password admin
Returns a list of all supported modules contained in the specified module group.
Example 4
vcb module view
-group
ciscophysicalspec2
-module
20091 -user root -password admin
Returns the port layer definitions for module 20091, which is part of the group ciscophysicalspec2.
Example 5
vcb module view -group ciscoentitymibspec –template all -user root -password admin
Returns a list of all templates defined in the specified module group.
Example 6
vcb module view –group ciscoentitymibspec –template ethernetDefault -user root -password admin
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
|
|
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. |
Note For the list of global options, see Global Command Options.
Error Codes
Table B-22 Error Codes—vcb module view
|
|
103 |
No such template name in the template file |
402 |
Module template file not found |
411 |
SysOID specified does not exist in site.xml or vendor file |
412 |
Module identifier specified does not exist |
Note For the list of general VCB error codes, see General Error Codes.
vcb module modify
Use the vcb module modify command to modify the associated module template.
Syntax
vcb module modify -module module identifier -group module group -template template name [ -hardwaredesc Hardware Description of the Module -user username -password password
vcb module modify -module module identifier -sysoid device sysoid -scheme <ipcore|product> -template template name [ -hardwaredesc Hardware Description of the Module ] -user username -password password
Description
The vcb module modify command can be used to:
- Associate a module with another module template.
- Change the association between a module and its module template for a device specified by its sysOID.
Usage Examples
Example 1
vcb module modify
-module
20091
-group
ciscophysicalspec2 -template
GE-fiberoptic-ethernet-default -user root -password admin
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.
Example 2
vcb module modify
-sysoid
.1.2.3.4
-module
50068 -group
ciscophysicalspec2
-template
oc3-ppp-default
-user root -password admin -scheme product
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
|
|
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 For the list of global options, see Global Command Options.
Error Codes
Table B-24 Error Codes—vcb module modify
|
|
103 |
No such template name in the template file |
402 |
Module template file not found |
411 |
SysOID specified does not exist in site.xml or vendor file |
412 |
Module identifier specified not found or already exists in vendor spec file |
Note For the list of general VCB error codes, see General Error Codes.
vcb module delete
Use the vcb module delete command to delete the association between a module and the implementation defined in a module template.
Syntax
vcb module delete
-module
module identifier -group
module group -user username -password password
vcb module delete
-module
module identifier
-sysoid
device sysoid -scheme <ipcore|product> -user username -password password
Description
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.
Usage Examples
Example 1
vcb module delete
-module 20091
-group
ciscophysicalspec2 -user root -password admin
Deletes the definition for module 20091 from the group ciscophysicalspec2. The module definition is deleted from all devices that contain this module.
Example 2
vcb module delete
-sysoid .1.2.3.4
-module
50068 -user root -password admin -scheme product
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
|
|
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. |
Note For the list of global options, see Global Command Options.
Error Codes
Table B-26 Error Codes—vcb module delete
|
|
402 |
Module template file not found. |
411 |
sysOID does not exist in the site.xml file or vendor spec file. |
412 |
Module identifier not found or already exists in the vendor spec file. |
Note For the list of general VCB error codes, see General Error Codes.
VCB CLI Command Reference: Pluggable Modules
These topics provide reference information for the vcb pluggablemodule commands you can use to create, view, modify, and delete pluggable modules:
Note To add, view, modify, or delete regular modules, see VCB CLI Command Reference: Standard Modules.
vcb pluggablemodule add
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.
Syntax
vcb pluggablemodule add -group groupName -module moduleno -pid pid -mediatype MediaType -pluggabletype pluggableType -user username -password password
vcb pluggablemodule add -group groupName -containeroid containeroid -user username -password password
vcb pluggablemodule add -group groupName -basetype basetype -user username -password password
Description
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.
Usage Example
vcb pluggablemodule add
-module
“.1.3.6.1.4.1.9.12.3.1.9.51.22”
–group
pluggable-ports-spec
–mediatype
fiber
–pluggabletype
SFP -user root -password admin
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.
vcb pluggablemodule add –group pluggable-ports-spec –basetype.1.3.6.1.4.1.9.12.3.1.9.52 -user root -password admin
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.
vcb pluggablemodule add –group pluggable-ports-spec -containeroid.1.3.6.1.4.1.9.12.3.1.5.153 -user root -password admin
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
|
|
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 |
Note For the list of global options, see Global Command Options.
Error Codes
Table B-28 Error Codes—vcb pluggablemodule add
|
|
403 |
Pluggable module spec file not found |
404 |
Invalid pluggable module type |
Note For the list of general VCB error codes, see General Error Codes.
vcb pluggablemodule view
Use the vcb pluggablemodule view command to display details for a pluggable module.
Syntax
vcb pluggablemodule view
-group
groupName
-module
moduleno | all [
-userdefined ]
-user username -password password
vcb pluggablemodule view -group groupName -containeroid oid | all [-userdefined]-user username -password password
vcb pluggablemodule view -group groupName -basetype basetype| all [-userdefined]-user username -password password
Description
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.
Usage Examples
vcb pluggablemodule view –group pluggable-port-spec –module “.1.3.6.1.4.1.9.12.3.1.9.51.22” -user root -password admin
Returns the pluggable module details—such as pid, media type, and pluggable type—for the module with the given vendor oid.
vcb pluggablemodule view –group pluggable-port-spec –containeroid all -user root -password admin
Returns the pluggable module container oid details, if the list has userdefined container oid, it is marked with # after the oid.
vcb pluggablemodule view –group pluggable-port-spec –basetype all -user root -password admin
Returns the pluggable module details.
Options
Table B-29 Options and Arguments—vcb pluggablemodule view
|
|
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.
|
group groupname |
The name of the group. |
Note For the list of global options, see Global Command Options.
Error Codes
Table B-30 Error Codes—vcb pluggablemodule view
|
|
403 |
Pluggable module spec file not found. |
Note For the list of general VCB error codes, see General Error Codes.
vcb pluggablemodule modify
Use the vcb pluggablemodule modify command to change the pluggable module configuration.
Syntax
v cb pluggablemodule modify -group groupName -module moduleno -pid pid {[ -mediatype MediaType ] | [ -pluggabletype pluggabletype ]}
Description
The vcb pluggablemodule modify command enables you to modify the configuration for a pluggable module.
Usage Example
vcb module modify -module “.1.3.6.1.4.1.9.12.3.1.9.51.22” –group pluggable-ports-spec –mediatype “fiber optic” -user root -password admin
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
|
|
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. |
Note For the list of global options, see Global Command Options.
Error Codes
Table B-32 Error Codes—vcb pluggablemodule modify
|
|
403 |
Pluggable module spec file not found |
404 |
Invalid pluggable module type |
Note For the list of general VCB error codes, see General Error Codes.
vcb pluggablemodule delete
Use the vcb pluggablemodule delete command to delete a pluggable module that was previously added using the VCB.
Syntax
vcb pluggablemodule delete
-group pluggableport
groupN
-module
moduleno -user username -password password
vcb pluggablemodule delete -group pluggableportgroup –containeroid container oid -user username -password password
vcb pluggablemodule delete -group pluggableportgroup –basetype basetype oid -user username -password password
Description
Use the vcb pluggablemodule delete command to delete pluggable modules that were created using the VCB.
Note Use the vcb pluggablemodule delete command to enable VNEs to use factory-supplied updates when they are available.
Usage Examples
vcb pluggablemodule delete
-module
“.1.3.6.1.4.1.9.12.3.1.9.51.22”
–group
pluggable-ports-spec -user root -password admin
Removes the definition for the pluggable module with identifier.1.3.6.1.4.1.9.12.3.1.9.51.22.
vcb pluggablemodule delete -basetype “.1.3.6.1.4.1.9.12.3.1.9.52” –group pluggable-ports-spec -user root -password admin
Removes the definition for the pluggable module basetype with identifier.1.3.6.1.4.1.9.12.3.1.9.52.
vcb pluggablemodule delete -containeroid “.1.3.6.1.4.1.9.12.3.1.5.153” –group pluggable-ports-spec -user root -password admin
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
|
|
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. |
Note For the list of global options, see Global Command Options.
VCB CLI Reference: Events Commands
This section describes the CLI commands that can be used to customize events, as follows:
VCB CLI Reference: vcb event Commands
These topics provide reference information for the vcb event commands you can use to create, view, modify, and delete events:
vcb event add
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.
Syntax
vcb event add –eventtype { syslog|trap } –eventname eventName [ -alarmid alarmId ] { -subtype1 subtype1Name [ -ticketable1 ]
[ –severity1 critical|major|minor|warning|info|cleared>]
[ -shortdesc1 short description string ] [ -autoclear1 false |true ]
...
[-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
|
|
eventtype event type |
Type of event. Valid values are:
|
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:
- COMMUNICATIONS
- QOS
- PROCESSING
- EQUIPMENT
- ENVIRONMENTAL
- UNDETERMINED
- INTEGRITYVIOLATION
- OPERATIONALVIOLATION
- PHYSICALVIOLATION
- SECURITYORSERVICEMECHANISMVIOLATION
- TIMEDOMAINVIOLATION
|
Note For the list of global options, see Global Command Options.
Error Codes
Table B-35 Error Codes—vcb event add
|
|
201 |
Event name already exists in Prime Network. |
202 |
Alarm ID already exists in Prime Network. |
Note For the list of general VCB error codes, see General Error Codes.
vcb event view
Use the vcb event view command to list event definition registrations.
Syntax
vcb event view –eventname { eventName | all } [ -substringmatch ]} -user username -password password -eventtype {trap | syslog | service}
vcb event view -genericevents all | trap | syslog [
-ipaddress
vneip ] [
-date
yyyy-mm-dd ] [
-time
hh:mm:ss ] [
-maxrecords
num ]
-user username -password password
vcb event view -mibfile complete-path-mibFilename [
-generatecli -repository ParsingrulesHive - group PatternsHive ]
-user username -password password
Description
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.
vcb event view –eventname bgp –substringmatch -user root -password admin
Returns all BGP event definitions in Prime Network, including those that were added using the VCB.
vcb event view -user root -password admin -eventname bgp -substringmatch -eventtype service
Returns all BGP service events.
vcb event view -mibfile /mibs/IF-MIB –user root –password admin
Returns lists of supported events and unsupported events based on the traps in the IF-MIB file.
vcb event view -mibfile /mibs/IF-MIB -generateeventcli
-group cisco-trap-product-parsing-rules -repository cisco-trap-repository –user root –password admin
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
|
|
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. |
Note For the list of global options, see Global Command Options.
Error Codes
Table B-37 Error Codes—vcb event view
|
|
231 |
No such event exists in the events file |
Note For the list of general VCB error codes, see General Error Codes.
vcb event modify
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.
Syntax
vcb event modify –eventname eventName [ -alarmid alarmId ] [
-override ]
{ -subtype1 subtype1Name {[ -ticketable1 ] [ -autoclear1 false |true ] –severity1 critical|major|minor|warning|info|cleared
-shortdesc1 short description string …
{ -subtypen subtypenName [ -ticketablen ] [ -autoclear1 false |true ]
–severityn critical|major|minor|warning|info|cleared
[ -shortdescn ] short description string -user username -password password
[-eventtype {trap | syslog | service | drop}
Description
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”
-subtype1 “stack switch removed syslog” -severity1 major -ticketable1 -user root -password admin
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.
vcb event modify -eventname “bgp trap” -override -eventtype drop -user root -password admin
Drops the “bgp trap” event. This overrides the system-defined event.
Options
Table B-38 Options and Arguments—vcb event modify
|
|
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:
- COMMUNICATIONS
- QOS
- PROCESSING
- EQUIPMENT
- ENVIRONMENTAL
- UNDETERMINED
- INTEGRITYVIOLATION
- OPERATIONALVIOLATION
- PHYSICALVIOLATION
- SECURITYORSERVICEMECHANISMVIOLATION
- TIMEDOMAINVIOLATION
|
Note For the list of global options, see Global Command Options.
Error Codes
Table B-39 Error Codes—vcb event modify
|
|
202 |
Alarm ID already exists in Prime Network. |
251 |
Event name does not exist in Prime Network. |
252 |
Event subtype name does not exist for the event. |
Note For the list of general VCB error codes, see General Error Codes.
vcb event delete
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.
Syntax
vcb event delete -eventname eventName -user username -password password
Description
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.
Usage Example
vcb event delete –eventname “stack switch status syslog” -user root -password admin
Deletes the event definition. All registry entries added as a part of the event add command are removed from the site.xml file.
Options
Table B-40 Options and Arguments—vcb event delete
|
|
eventname eventName |
Name of the event to be deleted |
Note For the list of global options, see Global Command Options.
Error Codes
Table B-41 Error Codes—vcb event delete
|
|
231 |
No such event exists in the events file |
Note For the list of general VCB error codes, see General Error Codes.
VCB CLI Reference: vcb eventparsingrules Commands
These topics provide reference information for the vcb eventparsingrules commands you can use to create, view, modify, and delete event parsing rules:
vcb eventparsingrules add
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.
Syntax
vcb eventparsingrules add -templates
templateName1, templateName2, …, templateNamen -group
repository
–rulename
rulename [
-enable ]
{ [
-arg1
-arg1Value …
-argN
argNValue ] }
-user username -password password
Description
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.
Usage Example
vcb eventparsingrules add -enable
-templates syslog-identification ,
syslog-subtype-from-expression,create-managedelement-key,create-ana-syslog-event
-group
cisco-syslog-repository
–rulename
stack-switch-status-syslog
-syslog_identification_testmessage “STACKMGR-4-SWITCH_ADDED: Switch 2 has been added to the stack”
-syslog_identification_expression ”STACKMGR-4-SWITCH_%%subtypekey%%: Switch %%uniqueid%% has been.*”
-syslog_subtype_from_expression_replacing_rules ”ADDED-stack switch added syslog,REMOVED-stack switch removed syslog”
-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
|
|
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. |
Note For the list of global options, see Global Command Options.
Error Codes
Table B-43 Error Codes—vcb eventparsingrules add
|
|
211 |
Event template file not found. |
103 |
No such template name in template file. |
212 |
Only one template can be selected from each template category. |
213 |
Invalid expression for syslog. |
Note For the list of general VCB error codes, see General Error Codes.
vcb eventparsingrules view
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
vcb eventparsingrules view -template templateName | all -inputparam -user username -password password
Description
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.
Usage Examples
Example 1
vcb eventparsingrules view
-template
syslog-identification
–inputparam -user root -password admin
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.
Example 2
vcb eventparsingrules view
–group
cisco-syslog-repository –userdefined –rulename
all -user root -password admin
Displays all event parsing rules that were defined using the VCB under the cisco-syslog-repository hive.
Example 3
vcb eventparsingrules view
–group
cisco-syslog-repository
–rulename stack-switch-status-syslog
-user root -password admin
Displays the event parsing rules for the event “stack-switch-status-syslog” which was created using the VCB.
Example 4
vcb eventparsingrules view
–group
cisco-syslog-repository
–rulename
all -user root -password admin
Displays all the event parsing rules present in the hive cisco-syslog-repository, including those added using the VCB.
Options
Table B-44 Options and Arguments—vcb eventparsingrules view
|
|
group repository name |
The trap or syslog repository filename. |
rulename ruleName |
The unique string that is used to represent the event parsing rules.
Tip Enter
all as the
ruleName to display information on all the rules in Prime Network.
|
detail |
(Optional) Lists the entire rule contents including the parsing rule entry details. |
template templateName |
The event template name.
Tip Enter
all as the
templateName to display information on all event templates in Prime Network.
|
inputparam |
(Optional) Lists template definition entries that require user input when creating event parsing rules. |
Note For the list of global options, see Global Command Options.
Error Codes
Table B-45 Error Codes—vcb eventparsingrules view
|
|
103 |
No such template name in the templates file. |
222 |
Parsing rules repository not found. |
231 |
No such rule name in the site.xml. |
vcb eventparsingrules modify
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.
Syntax
vcb eventparsingrules modify -template s templateName1, templateName2, …, templateNamen -group repository –rulename rulename [ -enable ] { [ -arg1 -arg1Value … -argN argNValue ] } -user username -password password
Description
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
|
|
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. |
variable arguments |
Each event template can require different input and a different number of input parameters from none to more than one. See Event Templates Input Summary—Required and Optional Input. |
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.
Error Codes
Table B-47 Error Codes—vcb eventparsingrules modify
|
|
103 |
No such template name in the templates file. |
211 |
Event template file not found. |
212 |
Only one template can be selected from each template category. |
Note For the list of general VCB error codes, see General Error Codes.
vcb eventparsingrules delete
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.
Syntax
vcb eventparsingrules delete –group repository hive –rulename rulename -user username -password password
Description
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.
Usage Example
vcb eventparsingrules delete -group cisco-syslog-repository –rulename stack-new-master-syslog
This example deletes the stack-new-master-syslog rule from the cisco-syslog-repository hive.
Options
Table B-48 Options and Arguments—vcb eventparsingrules delete
|
|
group repository hive |
The hive from which to remove the event parsing rule. |
rulename ruleName |
The rule to delete. |
Note For the list of global options, see Global Command Options.
Error Codes
Table B-49 Error Codes—vcb eventparsingrules delete
|
|
222 |
Parsing rules repository not found. |
241 |
No such rule name in the site.xml. |
Note For the list of general VCB error codes, see General Error Codes.
VCB CLI Reference: vcb eventpattern Commands
These topics provide reference information for the vcb eventpattern commands you can use to create, view, modify, and delete event patterns:
vcb eventpattern add
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.
Syntax
vcb eventpattern add [ -patternid patternId ] -group parsing rules hive
-repository parsing rules repository hive –rulename rulename -user username -password password
Description
The vcb eventpattern add command creates a pointer from the parsing-rules hive to the repository where the actual parsing rules are defined.
Usage Examples
vcb eventpattern add
-patternid 202 -group cisco-syslog-product-parsing-rules
-repository cisco-syslog-repository
–rulename stack-switch-status-syslog -user username -password password
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
|
|
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. |
Note For the list of global options, see Global Command Options.
Error Codes
Table B-51 Error Codes—vcb event pattern add
|
|
221 |
Parsing rules hive not found. |
222 |
Parsing rules repository not found. |
Note For the list of general VCB error codes, see General Error Codes.
vcb eventpattern view
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.
Syntax
vcb eventpattern view -group parsingrules hive –rulename { rulename | all } [ -substringmatch ] [ -full ] -user username -password password
Description
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.
Usage Examples
Example 1
vcb eventpattern view –group cisco-syslog-parsing-rules –rulename stack-switch-status-syslog -user root -password admin
Displays the event pattern definition for the specified rulename; that is, the pattern ID, and the pattern is pointing to the parsing rules repository.
Example 2
vcb eventpattern view –group cisco-syslog-parsing-rules –rulename all -user root -password admin
This example shows all the event pattern definitions in the specified hive.
Example 3
vcb eventpattern view –group cisco-syslog-parsing-rules -userdefined
–rulename bgp –substringmatch -full -user root -password admin
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
|
|
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. |
Note For the list of global options, see Global Command Options.
Error Codes
Table B-53 Error Codes—vcb eventpattern view
|
|
221 |
Parsing rules hive not found. |
241 |
No such rule name in the site.xml. |
Note For the list of general VCB error codes, see General Error Codes.
vcb eventpattern modify
Use the vcb eventpattern modify command to modify the pointer to the parsing rules.
Syntax
vcb eventpattern modify
-patternid patternId
-group
parsing rules hive [
-repository
parsing rules repository hive ] [
–rulename
ruleName ]
-user username -password password
Description
The vcb eventpattern modify command modifies the pointer from the parsing-rules hive to the repository where the actual parsing rules are defined.
Usage Examples
vcb eventpattern modify
-patternid 202
-group cisco-syslog-product-parsing-rules
-repository cisco-router-syslog-repository -user root -password admin
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.
Note Vcb 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
|
|
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. |
Note For the list of global options, see Global Command Options.
Error Codes
Table B-55 Error Codes—vcb eventpattern modify
|
|
221 |
Parsing rules hive not found. |
222 |
Parsing rules repository not found. |
271 |
Pattern with ID not found |
Note For the list of general VCB error codes, see General Error Codes.
vcb eventpattern delete
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.
Syntax
vcb eventpattern delete –group parsing rule hive -patternid pattern ID -user username -password password
Description
The vcb eventpattern delete command removes the pointer to the parsing rule defined in the repository file.
Usage Examples
vcb eventpattern delete –group cisco-syslog-parsing-rules –patternid 202 -user root -password admin
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
|
|
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. |
Note For the list of global options, see Global Command Options.
Error Codes
Table B-57 Error Codes—vcb event pattern delete
|
|
221 |
Parsing rules hive not found. |
271 |
Pattern with ID not found |
Note For the list of general VCB error codes, see General Error Codes.
VCB CLI Reference: vcb eventarg Command
vcb eventarg view
Use the vcb eventarg view command to display event parsing rule arguments and descriptions.
Syntax
vcb eventarg view -user username -password password
Description
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.
For detailed information, see VCB CLI Reference: Events Commands.
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]
########## com.sheer.metrocentral.framework.eventapplication.types.EventData ########
# Id : = 137611826381_1277116869542
# Unique source ID: = null
# Type : = generic syslog
# SubType : = generic syslog
# SourceOID : = {[ManagedElement(Key=10.77.212.205)][Syslog]}
# Event Time : = 1277116869542
# Info : = 7.212.205 %FAN-3-FAN_0K: Fan 3 had earlier reported a rotation error. It is ok now
# CorrelationKeys: =
# CK=(MC.DA-10.77.212.205)-25:52:0:0 [16]
# Adjacent XID : = null
# Source IP interface: = null
###################################################################################
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)]
Event Data :
############## com.sheer.metrocentral.framework.eventapplication.parsing.types
.RawSyslogEventData #############
# Id : = 4311876356_1277116869490
# Unique source ID: = null
# Type : = raw event
# SubType : = raw syslog
# SourceOID : = null
# Event Time : = 1277116869494
# Info : = 7.212.205 %FAN-3-FAN_0K: Fan 3 had earlier reported a rotation error. It is ok now
# syslog = 7.212.205 %FAN-3-FAN_0K: Fan 3 had earlier reported a rotation error. It is ok now
##############################################################################
#################################
java.lang.reflect.InvocationTargetException
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.
Topics include:
U-VNE Templates
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.
For more information, see the following sections:
GenericUVNE Template
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
|
|
|
- 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 |
Note Expedite 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.
See the following sections:
GenericUVNE—Physical Inventory Model
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
|
|
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
|
|
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
|
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 |
|
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
|
|
|
Device Unreachable |
Y |
N |
Discard Packets |
Y |
N |
Dropped Packets |
Y |
N |
Port Flapping |
Y |
N |
Port Down |
Y |
N |
GenericUVNE—Limitations
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
|
|
|
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:
IP
Table B-64 lists the IP attribute support on a U-VNE created using the GenericUVNE template.
Note Table B-64 includes the supported technologies only.
Table B-64 IP Attribute Support on GenericUVNEs
|
|
|
IP Address |
Y |
Subnetwork Mask |
Y |
IP Interface Addresses Array |
|
Interface Name |
|
Interface Description |
Y |
IP Interface State |
Y |
OSPF Interface Cost |
|
Broadcast Address |
|
MTU |
|
Lookup Method |
|
Address Resolution Type |
|
ARP Timeout |
|
Secured ARP |
|
ICMP Mask Reply |
|
IGMP Proxy |
|
HSRP Groups |
|
IP Multiplexing Table |
|
IANA Type |
|
Containing CTPs |
|
Contained CTPs |
|
|
Routing Table |
Y |
ARP Entity |
Y |
Routing Table Changes |
|
Name |
Y |
Logical Sons |
Y |
|
Destination IP Subnet |
Y |
Next Hop IP Address |
Y |
Type |
Y |
Routing Protocol Type |
Y |
Outgoing Interface Name |
Y |
|
ARP Table |
Y |
|
IP Address |
Y |
MAC Address |
Y |
Port |
Y |
Entry Type |
Y |
Ethernet (IEEE 802.3)
Table B-65 lists the Ethernet (IEEE 802.3) attribute support on a U-VNE created using the GenericUVNE template.
Table B-65 Ethernet (IEEE 802.3) Attribute Support on GenericUVNEs
|
|
|
MAC Address |
Y |
Duplex Mode |
|
Output Flow Control |
|
Input Flow Control |
|
IANA Type |
|
Containing CTPs |
|
Contained CTPs |
|
Port Type |
|
Base Logical Components
Table B-66 lists the base logical attribute support on a U-VNE created using the GenericUVNE template.
Note Table B-66 includes the supported technologies only.
Table B-66 Base Logical Components Attribute Support on GenericUVNEs
|
|
|
IP Address |
Y |
Communication State |
Y |
Investigation State |
Y |
Element Category |
Y |
Element Type and Key |
Y |
Device Name |
Y |
System Name |
Y |
System Description |
Y |
Up Time |
Y |
Software Version |
Y |
Vendor Identity |
|
Memory and CPU Usage |
|
DRAM Free |
|
DRAM Used |
|
Flash Device Size |
|
NVRAM Size |
|
Processor DRAM |
|
Sys Contact |
|
Sys Location |
|
Serial Number |
|
File Systems |
|
|
Type |
|
Status |
|
Up Time |
|
Common
Table B-67 lists the common attribute support on a U-VNE created using the GenericUVNE template.
Note Table B-67 includes the supported technologies only.
Table B-67 Common Attribute Support on GenericUVNEs
|
|
|
Media Type |
|
Clocking Source |
|
Maximum Speed |
Y |
Is Internal Port |
|
Discarded Bandwidth |
|
Dropped Bandwidth |
|
Input Bandwidth |
|
Output Bandwidth |
|
Discarded and Received Input Data Counters |
Y |
Dropped and Forward Output Data Counters |
Y |
Administrative Status |
Y |
Operational Status |
Y |
Last Changed |
Y |
IANA Type |
|
Containing CTPs |
|
Contained CTPs |
|
Port Alias |
|
Location |
|
Sending Alarms |
|
Connector Description |
|
Part ID |
|
Connector Serial Num |
|
Product |
|
Status |
|
Managed |
|
|
Destination MAC |
Y |
Outgoing Interface |
Y |
GenericUVNE—Supported Service Events
Table B-68 lists the supported service events on a U-VNE created using the GenericUVNE template.
Table B-68 Supported Service Events for GenericUVNE
|
|
|
Device Unreachable |
Y |
N |
Discard Packets |
Y |
N |
Dropped Packets |
Y |
N |
Port Flapping |
Y |
N |
Port Down |
Y |
N |
Module Templates
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.
This section contains the following topics:
Module Groups and Module Specification Files
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:
- You provide the name of a module specification file as an argument to the -group option. (For more information, see VCB CLI Command Reference: Standard Modules.)
- 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
|
|
|
ciscophysicalspec2 |
Ethernet (Fixed) |
- A10GigaEthernet
- ethernet-default-over-optic
- ethernetDefault
- gigaEthernet
- EthernetChannelSwitchDefault
|
Ethernet (Multiloader) |
- 10Gigaethernet-
- Gigaethernet-Fiber
- GE-fiberoptic-ethernet-default
- ethernetDefault-RJ45-or-Fiber2
- E1orGigabitTechnology2
- GE-over-OC12-pos-default
- GE-over-OC3-pos-default3
- ethernet-or-oc-pos-default3
- ethernet-or-OC12-
- pos-default3
- ethernet-or-oc48-
- pos-default
- DWDMA10GigaEthernet
|
POS (Fixed) |
- PPPdefaultOC48
- PPPdefault
|
POS (Multiloader) |
- POS-OC3-default
- PPPdefaultOC12
- PPPdefaultOC192
- PPPdefaultOC3
- PPPdefaultOC768
- DWDMOC768
|
ciscophysicalspec2 (continued) |
Channelized T1/E1 (Fixed) |
- RJ45-T1E1Channelized
- T1E1Channelized
- T1E1Channelized-ATMorCEM
- E3Default
- E3Loader
- E1Channelized
- E1Default
|
Channelized OCXX (Fixed) |
- ChannelizedOC3
- ChannelizedOC12
- ChannelizedOC12xx
- ChannelizedOCxx
|
ATM (Fixed) |
- atmDefault
- atmOverOC12
- atm-over-e3ds3
- T1E1_ATM-IMA
- ds1Default
- ds3Default
- adslDefault
|
ATM (Multiloader) |
- T3Channelized
- T3Loader
- layer2-over-ds1
- layer2-over-ds3
- layer2-over-ds3-over-bnc
- pppOverDS3Default
- layer2-over-e1
- HSSIDefault
|
Multitechnology |
- 36xxMultiTechnologiesModuleDefault
- 8xxMultiTechnologiesModuleDefault
- MultiTechnologiesModuleLayers
- MultiTechnologiesModuleDefault2
|
Serial |
- PPPwithRJ11
- multichannelDefault
- serialPPPDefault
|
ISDN |
|
ciscophysicalspec2 (continued) |
Generic |
- TSLineDefault
- generic-port1
- voiceEMDefault
|
ciscocatalyst3400spec |
Ethernet (Cisco Catalyst 3400) |
- cisco-3400-MultiTechnologiesModuleDefault
- cisco-3400-ethernetDefault-
- RJ45-or-Fiber
|
cisco-catalyst-spec |
Ethernet (Cisco Catalyst) |
- EthernetDefault
- FastEthernetDefault
- GigaEthernetDefault
- GigaEthernetOnCopper
- giga-ethernet
|
Module Templates by Technology
This section presents module templates organized by technology:
Ethernet (Fixed)
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)
|
|
|
|
|
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.)
Table B-71 Module Templates—Ethernet (Multiloader)
|
|
|
|
|
10Gigaethernet- Gigaethernet-Fiber |
|
EthernetCSMA/CD |
- 10 Gigabit Ethernet
- Gigabit Ethernet
|
- 76-ES+XC-20G3C
- WS-X45-SUP6-E
- WS-X4606-X2-E
|
GE-fiberoptic-ethernet- default |
RJ45 |
EthernetCSMA/CD |
|
catalyst375024ME (cevModuleCat375024M) |
Fiber optic |
|
ethernetDefault-RJ45-or -Fiber 2 |
|
EthernetCSMA/CD |
- Ethernet
- Fast Ethernet
- Gigabit Ethernet
|
- WS-X4232-RJ-XX
- WS-X4524-GB-RJ45V
|
E1orGigabitTechnology 2 |
|
EthernetCSMA/CD |
- Ethernet
- Fast Ethernet
- Gigabit Ethernet
|
Motherboard for 2941 (cevCpu2941) |
|
DS1/E1 |
GE-over-OC12-pos -default |
Fiber optic |
OC12 |
|
OSM-4OC12-POS-SI+ |
EthernetCSMA/CD |
|
GE-over-OC3-pos-default 3 |
Fiber optic |
OC3 |
|
OSM-4OC3-POS-SI+ |
RJ45 |
EthernetCSMA/CD |
|
ethernet-or-oc-pos-default 3 |
Fiber optic |
OC3 |
|
OSM-2+4GE-WAN+ |
EthernetCSMA/CD |
- Fast Ethernet
- Gigabit Ethernet
- 10 Gigabit Ethernet
|
ethernet-or-OC12- pos-default 3 |
Fiber optic |
OC12 |
|
- OSM-2OC12-POS-SI
- OSM-2OC12-POS-SI+
|
EthernetCSMA/CD |
- Fast Ethernet
- Gigabit Ethernet
- 10 Gigabit Ethernet
|
ethernet-or-oc48- pos-default |
Fiber optic |
OC48 |
|
OSM-1OC48-POS-SI+ |
EthernetCSMA/CD |
- Fast Ethernet
- Gigabit Ethernet
- 10 Gigabit Ethernet
|
DWDMA10GigaEthernet |
Fiber optic |
|
10 Gigabit Ethernet |
- 76-ES+XT-2TG3CXL
- 76-ES+XT-4TG3C
|
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)
|
Maximum Transmission Rate (Mbps) Supported
|
|
|
|
|
PPPdefaultOC48 |
2488.32 |
Fiber optic |
OC48 |
|
- SFP-OC48-IR1
- gsr-e-qoc48-sm-lr-sc
- 16OC48-POS/DPT
|
PPPdefault |
155.52 |
Fiber optic |
OC3 |
|
|
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)
|
Maximum Transmission Rate (Mbps) Supported
|
|
|
|
|
POS-OC3-default |
155.52 |
Fiber optic |
OC3 |
|
— |
PPPdefaultOC12 |
622.08 |
Fiber optic |
OC12 |
|
SPA-8XOC12-POS |
PPPdefaultOC192 |
9,953.28 |
Fiber optic |
OC192 |
|
SPA-OC192POS-LR |
PPPdefaultOC3 |
155.52 |
Fiber optic |
OC3 |
|
|
PPPdefaultOC768 |
39,813.12 |
Fiber optic |
OC768 |
|
1OC768-ITU/C |
DWDMOC768 |
39,813.12 |
Fiber optic |
OC768 |
|
— |
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.
Table B-74 Module Templates—Channelized T1/E1 (Fixed)
|
Maximum Transmission Rate (Mbps) Supported
|
|
|
|
|
RJ45-T1E1Channelized |
1.544 |
RJ45 |
T1E1 |
— |
SPA-8XCHT1/E1 |
T1E1Channelized |
1.544 |
RJ48 |
T1E1 |
— |
|
T1E1Channelized-ATMorCEM |
1.544 |
RJ48 |
T1E1 |
— |
HWIC-4T1/E1 |
E3Default |
44.736 |
BNC |
DS3 |
— |
ESR-8E3/DS3 |
E3Loader |
44.736 |
BNC |
DS3 |
— |
— |
E1Channelized |
1.544 |
RJ48 |
E1 |
— |
PA-8CE1 |
E1Default |
1.544 |
RJ45 |
E1T1 |
— |
VWIC2-1MFT-T1E1 |
Channelized OCXX (Fixed)
Table B-75 lists templates for Optical Carrier modules where port layers are fixed.
Module Group
These templates are defined in the ciscophysicalspec2 module group.
Table B-75 Module Templates—Channelized OCXX (Fixed)
|
Maximum Transmission Rate (Mbps) Supported
|
|
|
|
|
ChannelizedOC3 |
155.52 |
Fiber optic |
OC3 |
— |
— |
ChannelizedOC12 |
622.08 |
Fiber optic |
OC12 |
— |
— |
ChannelizedOC12xx |
622.08 |
Fiber optic |
OC12 |
— |
SPA-1XCHOC12/DS0 |
ChannelizedOCxx |
155.52 |
Fiber optic |
OC3 |
— |
- SPA-1XCHSTM1/OC3
- SPA-CHOC3-CE-ATM
|
ATM (Fixed)
Table B-76 lists templates for ATM modules where port layers are fixed.
Module Group
These templates are defined in the ciscophysicalspec2 module group.
Table B-76 Module Templates—ATM (Fixed)
|
Maximum Transmission Rate (Mbps) Supported
|
|
|
|
|
atmDefault |
155.52 |
Fiber optic |
OC3 |
ATM |
GSR-SFC12410 |
atmOverOC12 |
— |
Fiber optic |
OC12 |
ATM |
- SPA-1XOC12-ATM-V2
- SPA-1XOC12-ATM
|
atm-over-e3ds3 |
— |
RJ48 |
DS3 |
ATM |
— |
T1E1_ATM-IMA |
1.544 |
RJ48 |
T1E1 |
ATM |
— |
ds1Default |
— |
BNC |
DS1 |
ATM |
— |
ds3Default |
— |
BNC |
DS3 |
ATM |
PA-A3-T3 |
adslDefault |
— |
RJ11 |
ADSL |
ATM |
- WIC-1SHDSL
- WIC-1ADSL
- WIC-1ADSL-DG
|
ATM (Multiloader)
Table B-77 lists templates for ATM modules with multiple Layer 2 options.
Module Group
These templates are defined in the ciscophysicalspec2 module group.
Table B-77 Module Templates—ATM (Multiloader)
|
Maximum Transmission Rate (Mbps) Supported
|
|
|
|
|
T3Channelized |
— |
BNC |
DS3 |
|
- SPA-2XCT3/DS0
- PA-2T3/E3-EC
|
T3Loader |
— |
BNC |
DS3 |
|
— |
layer2-over-ds1 |
1.544 |
RJ48 |
DS1 |
|
VWIC-2MFT-T1-DIR |
layer2-over-ds3 |
44.736 |
RJ48 |
DS3 |
|
|
layer2-over-ds3-over-bnc |
44.736 |
BNC |
DS3 |
|
— |
pppOverDS3Default |
44.736 |
BNC |
DS3 |
|
- copper-6ds3
- copper-12ds3
- 2DS3-SMB
- NM-4T
|
layer2-over-e1 |
1.544 |
RJ48 |
E1 |
|
NM-1CE1T1-PRI |
HSSIDefault |
— |
DB50 |
HSSI |
|
— |
Multitechnology
Table B-78 lists multitechnology templates, including the following, which support modules where the connector type is not determined:
- MultiTechnologiesModuleLayers
- MultiTechnologiesModuleDefault
Note Do not use these templates unless no other template matches the modules to be added.
Module Group
These templates are defined in the ciscophysicalspec2 module group.
Table B-78 Module Templates—Multitechnology
|
|
|
|
|
36xxMultiTechnologiesModuleDefault |
RJ45 |
|
- Fast Ethernet
- Gigabit Ethernet
|
— |
|
|
8xxMultiTechnologiesModuleDefault |
RJ45 |
|
- Fast Ethernet
- Gigabit Ethernet
|
— |
|
|
MultiTechnologiesModule Layers |
- RJ11
- RJ45
- RJ48
- Fiber optic
- DB60
|
- EthernetCSMA/CD
- DS1
- E1
- OC3
- ADSL
- Serial
|
- Fast Ethernet
- Gigabit Ethernet
- PPP
- HDLC
- Frame relay
- ATM
|
OSM-1CHOC12/T3-SI |
MultiTechnologiesModule Default 2 |
- RJ11
- RJ45
- RJ48
- Fiber optic
- DB60
|
- EthernetCSMA/CD
- DS1
- E1
- OC3
- ADSL
- Serial
|
- Fast Ethernet
- Gigabit Ethernet
- PPP
- HDLC
- Frame relay
- ATM
|
gsr-sfc16-oc192 |
Serial
Table B-79 lists templates that provide support for modules with serial interfaces when the information for Layer 1 is not clear.
Module Group
These templates are defined in the ciscophysicalspec2 module group.
Table B-79 Module Templates—Serial
|
|
|
|
|
PPPwithRJ11 |
RJ11 |
Serial |
PPP |
WIC-1AM-V2 |
multichannelDefault |
RJ48 |
Serial |
PPP |
— |
serialPPPDefault |
- RJ45
- RJ48
- Fiber optic
- DB60
- Generic connector
|
Serial |
|
- HWIC-4T
- NM-2W
- WIC-SERIAL-1T
|
ISDN
Table B-80 lists templates for ISDN modules.
Module Group
These templates are defined in the ciscophysicalspec2 module group.
Table B-80 Module Templates—ISDN
|
Maximum Transmission Rate (kbps) Supported
|
|
|
|
|
ds1T1Default |
— |
- RJ45
- RJ48
- DB60
- Fiber optic
|
|
ISDN |
— |
BRIDefault |
64 |
RJ45 |
ISDN layer 1 |
ISDN layer 2 |
WIC-1B-U-V2 |
Generic
Table B-81 lists generic templates. Use them to configure modules for technologies that Prime Network does not support.
Module Group
These templates are defined in the ciscophysicalspec2 module group.
Table B-81 Module Templates—Generic
|
|
|
|
|
TSLineDefault |
Generic connector |
Generic Layer 1 |
— |
|
generic-port 1 |
Generic connector |
Generic Layer 1 |
Generic Layer 2 |
— |
voiceEMDefault |
RJ45 |
Generic Layer 1 |
Generic Layer 2 |
|
Ethernet (Cisco Catalyst 3400)
Table B-82 lists templates that support modules for the Cisco Catalyst 3400 device group.
Module Group
These templates are defined in the ciscocatalyst3400spec module group.
Table B-82 Module Templates—Ethernet (Cisco Catalyst 3400)
|
|
|
|
|
cisco-3400-MultiTechnologiesModuleDefault Note Not recommended for 10/100/1000 Ethernet ports. Instead, use cisco-3400-ethernetDefault-RJ45-or-Fiber. |
RJ45 |
EthernetCSMA/CD |
Ethernet |
3400 fixed modules |
cisco-3400-ethernetDefault- RJ45-or-Fiber |
|
EthernetCSMA/CD |
- Ethernet
- FastEthernet
- GigaEthernet
|
3400 fixed modules |
Ethernet (Cisco Catalyst)
Note For modules in the Cisco Catalyst 3400 device group, see Ethernet (Cisco Catalyst 3400).
Table B-83 lists templates that support modules for Cisco Catalyst devices.
Module Group
These templates are defined in the cisco-catalyst-spec module group.
Table B-83 Module Templates—Ethernet (Cisco Catalyst)
|
|
|
|
|
EthernetDefault |
RJ45 |
EthernetCSMA/CD |
Ethernet |
- WS-C3560G-24TS
- WS-SUP720-3BXL
|
FastEthernetDefault |
RJ45 |
EthernetCSMA/CD |
FastEthernet |
- WS-X4148-RJ
- ws-c2924-xl-v
|
GigaEthernetDefault |
RJ45 |
EthernetCSMA/CD |
GigaEthernet |
- WS-F6K-MSFC2A
- OSM-2+4GE-WAN+
|
GigaEthernetOnCopper |
UTP |
EthernetCSMS/CD |
GigaEthernet |
Catalyst 6500 Supervisor Module 720 base board |
giga-ethernet |
Fiber optic |
EthernetCSMA/CD |
GigaEthernet |
- cat6k-wsx-6066-slb-apc
- wsx6ksup1a2ge
- wsx6ksup22ge
|
Event Templates
Event templates work together to extract information from a syslog or a trap and to generate the keys and the location ID for associating a Prime Network event with a managed element device component. For more information, see the following sections:
For information about specific template types, see the following sections:
Terminology Used in Event Templates
The following terms are used in the tables in this section.
Entity ID
The entity ID identifies the entity in the VNE with which to associate the event. For example, for interface-based events, ifIndex or ifName can be used as the entity ID.
Unique ID
The unique ID is used to create a unique location for the event when association to the exact entity is not possible. For example, when associating BGP traps to the Managed Element, the neighbor IP address can be used as the unique ID.
Supported Interface Types
The VCB can automatically identify the following interface types and associates events to them:
- Ether Channel
- GRE Tunnel
- DSO Bundle
- MPLSTunnel
- IMA Group
- MLPPP
- CEM Group
- IpInterface (Loopback, Vlan, all other subinterfaces)
For other interface types, the VCB associates the event to the layer 1 device component.
Event Templates Functional Summary
Event templates extract information and generate keys to associate an event with the correct VNE or U-VNE component. Table B-84 lists event templates (by type) and explains what each template does.
Table B-84 Event Template Functions
|
Performs This Function for a...
|
|
|
Event Identification Templates—Mandatory. Use one.
|
snmp-trap-identification |
— |
Extracts information that identifies an event |
syslog-identification |
Extracts:
|
— |
Event Subtype Templates—Optional. Use one if there are subtypes for the event.
|
snmp-trap-subtype-from-oid |
— |
- Extracts subtype information from the event
- Maps the subtype values to the event subtypes defined in Prime Network
|
snmp-trap-subtype-from-trapoid |
snmp-trap-subtype-from-value |
syslog-subtype-from-expression |
Maps the subtype values—extracted by the syslog-identification template—to the event subtypes defined in Prime Network |
— |
Unique ID Templates—Optional. Use one when you cannot associate the event to an exact entity.
|
snmp-trap-identifier-from-oid |
— |
Extracts the Unique ID |
snmp-trap-identifier-from-value |
Entity ID Templates—Optional. Use one when you can associate the event to an exact entity.
|
snmp-trap-entity-from-oid |
— |
Extracts the Entity ID |
snmp-trap-entity-from-value |
Entity Key Templates—Mandatory. Use one.
|
create-managedelement-key |
- Creates the device component key
- Associates the event with the Managed Element device component
|
create-interface-key-from-ifindex |
— |
Creates the interface device component key from the ifIndex, using the entity ID that was extracted by an entity ID template (snmp-trap-entity-from-oid or snmp-trap-entity-from-value) Associates the event with the appropriate interface layer; see Supported Interface Types |
create-interface-key-from-ifname |
- Creates the interface device component key from the ifname, using the entity ID that was extracted by:
– syslog-identification template for a syslog – an entity ID template (snmp-trap-entity-from-oid or snmp-trap-entity-from-value) for a trap
Note This template is more frequently used with syslogs than with traps. |
Prime Network Event Templates—Mandatory. Use one.
|
create-ana-trap-event |
— |
Creates both of the following:
- A unique location for the event, based on the Entity ID (device component key) or the Unique ID (extracted by an entity ID or a unique ID template)
- Prime Network event, using subtypes extracted by an event subtype template:
– snmp-trap-subtype-from-oid – snmp-trap-subtype-from-trapoid – snmp-trap-subtype-from-value |
create-ana-syslog-event |
Creates both of the following:
- A unique location for the event, based on Entity ID (device component key) or Unique ID (extracted by the syslog-identification template).
- Prime Network event, using subtypes extracted by the syslog-identification template
|
— |
For the input required for each template, see Event Templates Input Summary—Required and Optional Input.
Event Templates Input Summary—Required and Optional Input
Table B-85 summarizes event templates and the mandatory and optional input arguments for them.
Table B-85 Event Template Variables
|
|
|
|
Event Identification Templates
|
syslog-identification |
expression |
Mandatory |
Regular expression to match against the incoming syslog message. |
testmessage |
Optional |
String that is an example of the actual syslog message. |
snmp-trap-identification |
oid |
Mandatory |
SNMP trap OID. |
|
snmp-trap-identifier-from-oid |
inOID |
Mandatory |
Partial string that uniquely identifies the required OID in the varbind list. |
index |
Optional |
Used to create a unique location ID for the event when association to the exact entity is not possible. Default value is 1. |
snmp-trap-identifier-from-value |
inOID |
Mandatory |
Partial string that uniquely identifies the required OID in the varbind list. |
|
snmp-trap-subtype-from-oid |
inOID |
Mandatory |
Partial string that uniquely identifies the required OID in the varbind list. |
replacing-rules |
Defines mapping between event subtype and value in the trap that indicates the subtype. The subtype names provided in replacing-rules must match the subtype names used to add the event using the vcb event add command. To view event subtypes, use the vcb event view command. |
index |
Optional |
Used to create a unique location ID for the event when association to the exact entity is not possible. Default value is 1. |
snmp-trap-subtype-from-trapoid |
replacing-rules |
Mandatory |
Defines the mapping between event subtype and value in the trap that indicates the subtype. |
snmp-trap-subtype-from-value |
inOID |
Mandatory |
Partial string that uniquely identifies the required OID in the varbind list. |
replacing-rules |
Defines the mapping between event subtype and value in the trap that indicates the subtype. |
syslog-subtype-from-expression |
replacing-rules |
Mandatory |
Defines the mapping between event subtype and value in the trap that indicates the subtype. |
|
snmp-trap-entity-from-oid |
inOID |
Mandatory |
Partial string that uniquely identifies the required OID in the varbind list. |
index |
Optional |
Used to create a unique location ID for the event when association to the exact entity is not possible. Default value is 1. |
snmp-trap-entity-from-value |
inOID |
Mandatory |
Partial string that uniquely identifies the required OID in the varbind list. |
|
create-interface-key-from-ifindex |
— |
— |
— |
create-interface-key-from-ifname |
— |
— |
— |
create-managedelement-key |
— |
— |
— |
Prime Network Event Templates
|
create-ana-trap-event |
type |
Mandatory |
Event name, a string that must match the event name used to create the Prime Network event using the vcb event add command. |
subtype |
Mandatory for INFO events only |
Event subtype name, a string that must match the subtype name used to create the Prime Network event using the vcb event add command. |
create-ana-syslog-event |
type |
Mandatory |
Event name, a string that must match the event name used to create the Prime Network event using the vcb event add command. |
subtype |
Mandatory for INFO events only |
Event subtype name, a string that must match the subtype name used to create the Prime Network event using the vcb event add command. |
Event Identification Templates
Event identification templates are mandatory. You must use one of these templates:
snmp-trap-identification
This template supports SNMP V1, V2, and V3 traps. Any incoming SNMP V1 traps are converted automatically to SNMP V2 and then parsed as SNMP V2 traps. (The first rule in this template is the conversion rule.)
Mandatory Input
oid —The trap OID. Table B-86 describes how to format the OID for different traps.
Table B-86 Template Input—snmp-trap-identification
|
Format Input Like This...
|
|
Is for a V1 trap |
Supply the enterprise OID appended by 0 and then by the specific type. |
— |
Contains subtype information as these do:
- mplsLdpLibLspUp - 1.3.6.1.4.1.9.10.65.2.0.5
- mplsLdpLibLspDown - 1.3.6.1.4.1.9.10.65.2.0.6
|
Remove subtype information from the input string. |
1.3.6.1.4.1.9.10.65.2.0 |
Is an informational trap as this one is: mplsLdpPathVectorLimitMismatch - 1.3.6.1.4.1.9.10.65.2.0.2 |
Supply the entire OID. |
1.3.6.1.4.1.9.10.65.2.0.2 |
Does not contain subtype information; however, subtype information is contained in one of the varbinds: demandNbrLayer2Change - 1.3.6.1.4.1.9.9.26.2.0.3 The subtype for this trap is a varbind: isdnLapdOperStatus. |
Supply the entire OID. |
1.3.6.1.4.1.9.9.26.2.0.3 |
syslog-identification
This template supports syslogs. This template contains a single rule that extracts not only event identification information, but also subtype, unique ID, and entity ID when they are available for the event.
Mandatory Input
expression —A regular expression to be matched against the incoming syslog message.
The input string need not be a complete regular expression. It can be a partial syslog message with the parameters in which you are interested marked using keywords. Replace event-specific parameters in the syslog message with the following keywords:
- %%subtypekey%%—Use when the substring represents an event subtype.
- %%uniqueid%%—Use when the substring represents a parameter that uniquely identifies the event.
- %%entityid%%—Use when the substring represents the associated entity of the event.
For example, for the following syslogs:
%C6KENV-4-CLOCKFAILED: clock [dec] failed
%C6KENV-4-CLOCKOK: clock [dec] operational
you could provide the following input string:
%C6KENV-4-CLOCK%%subtypekey%%: clock %%uniqueid%%
There are no %%entityid%% parameters in this example, because this syslog must be associated with the ManagedElement device component.
The VCB uses the input string to automatically create a regular expression: “.*%C6KENV-4-CLOCK(\S+):clock (\S+).*”
There are instance when we require more than one input to uniquely identify the entity in the VNE. VCB allows you to subscript the keywords %%entityid%% and %%uniqueid%% with integers in order to specify more than one input that constitutes the entityid, for example, %%entityid1%%, %%entityid2%%.
For example, for EFP syslogs:
%ETHER_SERVICE-6-UPDOWN: Service instance 111 on interface GigabitEthernet10/0/3 changed to down.
Here, service instance id and interface name are inputs required to uniquely identify the EFP instance in the VNE. Read the template documentation to determine which variable should be marked as entityid1 and which should be marked entityid2.
Optional Input
testmessage —An input string that supplies an example of the actual syslog message. For example:
%C6KENV-4-CLOCKFAILED: clock 1 failed
If supplied, VCB checks this test message against the automatically created regular expression.
Input Format
-syslog_identification_expression regular_expression
-syslog_identification_testmessage message
Unique ID Templates—for Traps Only
Note For syslogs, unique ID information is extracted by the event identification template. For more information, see Event Identification Templates.
The unique ID differentiates a particular instance of an event from other events of the same type. This parameter is required when:
- It is not possible to associate the event to the appropriate device component in the VNE for some reason, possibly one of the following:
– The device component is not modeled due to lack of technology support.
– The corresponding key generation template is not available.
- A unique ID is not required at this time. For example, when Prime Network associates interface traps to a managed element device component, the ifIndex or ifName is the unique ID. Prime Network automatically appends this unique ID to the location, thereby creating a unique location for each interface despite associating the event with a common entity, the managed element device component.
These templates differ in the way the information is extracted from the trap; select and use only one of the following:
snmp-trap-identifier-from-oid
The rules in this template extract the unique identifier from one of the OIDs in the varbind list of the trap.
Mandatory Input
inOID —A partial string that uniquely identifies the required OID in the varbind list.
Optional Input
index —The location of the required value from the end of the OID. Default value is 1.
Input Format
-snmp_trap_identifier_from_oid_inOID OID
-snmp_trap_identifier_from_oid_index indexValue
snmp-trap-identifier-from-value
The rules in this template extract the unique identifier from the value of one of the OIDs in the varbind list.
Mandatory Input
inOID —A partial string that uniquely identifies the required OID in the varbind list.
Input Format
-snmp_trap_identifier_from_value_inOID OID
Event Subtype Templates
Use an event subtype template when configuring a trap or a syslog that includes event subtypes. For example, you should use an event subtype template when events arrive as a multistatus set or in asserted and cleared pairs, as is the case with link status traps. Link status traps send Link Down and Link Up traps, two subevents that are related to the same event:
- An asserted event indicates that the link is down.
- A clearing event indicates that the link status has changed to up.
Event subtype templates do the following:
- Extract event subtype information for traps. (For syslogs, event subtype information is extracted by the syslog-identification template; see syslog-identification.)
- Map the subtype value to the event subtype name defined in Prime Network.
When subtypes exist for a trap, use one of these event subtype templates:
When subtypes exist for a syslog, use this template:
snmp-trap-subtype-from-oid
The rules in this template extract event subtype information from one of the OIDs in the varbind list of the trap.
Mandatory Input
inOID —A partial string that uniquely identifies the required OID in the varbind list.
replacing-rules —Replacing rules define the mapping between the event subtype and the value in the trap that indicates the subtype.
The format for a rule is value-event subtype. The hyphen between the value and the event subtype is mandatory. Rules must be comma-separated.
Note Supply the same event subtype that was defined for the event with the vcb event add command. Use the vcb event view command to obtain a list of subtypes.
Optional Input
index —The location of the required value from the end of the OID. Default value is 1.
Input Format
-snmp_trap_subtype_from_oid_inOID OID
-snmp_trap_subtype_from_oid_index indexValue
-snmp_trap_subtype_from_oid_replacing_rules value-subtype, value-subtype, value-subtype
Note The hyphen between value and subtype is required.
snmp-trap-subtype-from-trapoid
The rules in this template extract event subtype information from one of the OIDs in the varbind list of the trap.
Mandatory Input
replacing-rules —Replacing rules define the mapping between the event subtype and the value in the trap that indicates the subtype.
The format for a rule is value-event subtype. Rules must be comma-separated.
Note Supply the same event subtype that was defined for the event with the vcb event add command. Use the vcb event view command to obtain a list of subtypes.
Input Format
-snmp_trap_subtype_from_trapoid_replacing_rules value-subtype, value-subtype, value-subtype
snmp-trap-subtype-from-value
The rules in this template extract the event subtype information from the value of one of the OIDs in the varbind list.
Mandatory Input
- inOID —A partial string that uniquely identifies the required OID in the varbind list.
- replacing-rules —Replacing rules define the mapping between the event subtype and the value in the trap that indicates the subtype.
The format for a rule is value-event subtype. Rules must be comma-separated.
Note Supply the same event subtype that was defined for the event with the vcb event add command. Use the vcb event view command to obtain a list of subtypes.
Input Format
-snmp_trap_subtype_from_value_inOID inOID
-snmp_trap_subtype_from_value_replacing_rules value-subtype, value-subtype, value-subtype
syslog-subtype-from-expression
The rules in this template extract the event subtype information from the value of one of the OIDs in the varbind list.
Mandatory Input
replacing-rules —Replacing rules define the mapping between the event subtype and the value in the trap that indicates the subtype.
The format for a rule is value-event subtype. Rules must be comma-separated.
Note Supply the same event subtype that was defined for the event with the vcb event add command. use the vcb event view command to obtain a list of subtypes.
Input Format
-syslog_subtype_from_expression_replacing_rules value-subtype, value-subtype, value-subtype
Entity ID Templates—for Traps Only
Note For syslogs, entity ID information is extracted by an event identification template. For more information, see Event Identification Templates.
The entity ID specifies the device component to which the event should be associated in the VNE. These templates differ in the way that the information is extracted from the trap:
snmp-trap-entity-from-oid
The rules in this template extract the entityID from the one of OIDs in the varbind list of the trap.
Mandatory Input
inOID —A partial string that uniquely identifies the required OID in the varbind list
Optional Input
index —The location of the required value from the end of the OID. Default value is 1.
Input Format
-snmp_trap_entity_from_oid_inOID inOID
snmp-trap-entity-from-value
The rules in this template extract the entity ID from the value of one of the OIDs in the varbind list.
Mandatory Input
inOID —A partial string that uniquely identifies the required OID in the varbind list
Input Format
-snmp_trap_entity_from_value_inOID inOID
Entity Key Templates
Selecting a template from this category is mandatory. Entity key templates use the entity ID information—extracted using other templates—to generate a key to uniquely identify the device component in the VNE. The event is later associated with the corresponding device component.
For templates that extract the entity ID, see syslog-identification and Entity ID Templates—for Traps Only.
Select one of the following templates:
create-interface-key-from-ifindex
This template creates the interface device component key from the ifIndex and associates the event with the appropriate interface layer.
No input is required.
create-interface-key-from-ifname
This template creates the interface device component key from an ifName and associates the event with the appropriate interface layer.
No input is required.
create-managedelement-key
This template creates the managed element device component key, associating the event with the managed element device component.
No input is required.
create-efp-key-from-ifname-serviceid
This template creates the EFP DC key from the Service Instance+ifName.
Note The service instance ID should be marked as %%entityid1%% and interface name as %%entityid2%% in the syslog expression given by the user.
The event will be associated with particular EFP DC. For example, consider the following:
Syslog Feb 8 11:04:18 MSK: %ETHER_SERVICE-6-UPDOWN: Service instance 214 on interface TenGigabitEthernet3/3 changed to up
The syslog expression for this should be given as %ETHER_SERVICE-6-UPDOWN: Service instance %%entityid1%% on interface %%entityid2%% change to %%subtypekey%%.
No input is required.
create-logical-container-key
This template associates syslog/trap events to the designated containers, as preferred.
Containers list: CfmService,BfdService,MPBgp,REPService,StpService,SbcService,EthernetLMI,ISISSystem,LSE,ClockService. Provide the desired logical container string, from the containers list.
Requires mandatory user input.
create-moduleDC-key-given-entPhysicalIndex
This template associates trap events to the designated moduleDC, when its observed entPhysicalIndex of Entity-MIB, through mib instrumentation queries from the device; Is given as the input for the desired module entity.
No input is required.
create-moduleDC-with-slotSubslot-value-key
This template associates syslog events to the corresponding module, knowing the residing slot number. For example, Syslog message "%OIR-6-REMCARD: Card removed from slot 4, interfaces disabled" USER_INPUT_MANDATORY <- %OIR-6-REMCARDCARD: Card removed from slot%%entityid%%, interfaces disabled entityid <- 4
No input is required.
create-pw-interface-key-from-tunnelindex
This template associates trap events to the designated pseudowire tunnel interface. To achieve this, provide the appropriate oid of the var bind for the trap to be associated with this pseudowire tunnel interface while providing inputs for "snmp-trap-entity-from-oid" template. The tunnel interface index provided by "snmp-trap-entity-from-oid" template, becomes the automatic input to the current "create-pw-interface-key-from-tunnelindex" template.
No input is required.
Prime Network Event Templates
These templates create a unique location ID for the event using the device component key and unique ID information created in the previous rules.
create-ana-trap-event
Template to create a unique location ID for a Prime Network trap event.
Mandatory Input
type —A string that specifies the event name.
Note This string should match the event name that was used to create the Prime Network event using the vcb event add command. View the event name using the vcb event view command.
Optional Input
subtype —A string that specifies the event subtype name.
Note The subtype parameter is mandatory for INFO events because INFO events do not have subtypes. For events that have subtypes, the subtype parameter is not needed.
Input Format
-create_ana_trap_event_type type
-create_ana_trap_event_subtype subtype
create-ana-syslog-event
Template to create a unique location ID for a Prime Network syslog event.
Mandatory Input
type —A string that specifies the event name. Mandatory for an INFO event only.
Note This string should match the event name used for creating the Prime Network event using the vcb event add command.
Optional Input
subtype —A string that specifies the event subtype name.
Note The subtype parameter is mandatory for INFO events because INFO events do not have subtypes. For events that have subtypes, the subtype parameter is not needed.
Input Format
-create_ana_syslog_event_type type
-create_ana_syslog_event_subtype subtype
Note For more information about vcb eventparsingrules commands, see VCB CLI Reference: vcb eventparsingrules Commands.