Configlet Context

Execution of scripts and CLI configlets may be required in some case. For example, one might need to restrict the scope of execution of 'disable interface' script to just the interfaces that are enabled. Having a context associated to the script or configlet solves this problem of restricting the scope. Context of an element is basically a unique path which leads to its XML counterpart in the device XML.

For all context related computations, we consolidate the XMLs fetched form the device under one node called device. This includes configuration XML, interface-information XML, chassis-inventory XML, and system-information XML.

An example of a device XML is as follows:

Table 1 shows the commands to view the XML from the CLI of the device.

Table 1: Commands to View XML from the CLI
XML type	Command
Chassis Inventory	> show chassis hardware \| display xml
Interface Information	> show interfaces \| display xml
Configuration	> show configuration \| display xml
System Information	-

Note:

The command for system information XML is not available. An instance of the system information XML is as follows:

Context of an Element

There is a need to have the ability to restrict a script or configlet execution to certain elements of interest. For example, one might need to restrict the scope of execution of 'disable interface' script only to the interfaces that are enabled. Having a context associated with the script or configlet solves this scoping problem.

The context of an element is the XPath that maps to the XML node that represents the element in the device XML. Table 2 lists the type of element, XML referred, and the content path.

Table 2: Context Path and XML node referred for different element types
Element Type	XML Referred	Context Path
Device	N/A	/device
Physical Inventory element	Chassis Inventory	/device/chassis-inventory/*
Physical Interface	Interface Information	/device/interface-information/*
Logical Interface	Configuration	/device/configuration/*

Table 3 lists some examples for XPaths for different elements.

Table 3: XPaths for different elements
Element	Context	Description
Device	/device	The context of a device
Chassis	/device/chassis-inventory/chassis[name='Chassis']	Context of a chassis
Routing Engine	/device/chassis-inventory/chassis[name='Chassis']/chassis-module[name='Routing Engine 0']	The context of a routing engine
FPC	/device/chassis-inventory/chassis[name='Chassis']/chassis-module[name='FPC 1']	The context of an FPC in slot 1
PIC	/device/chassis-inventory/chassis[name='Chassis']/chassis-module[name='FPC 1']/chassis-sub-module[name='PIC 4']	The context of a PIC in slot 4 under FPC in slot 1
Logical Interfaces	device/configuration/interfaces/interface[name='ge-0/0/1]/unit[name='0']	The context of logical interface ge-0/0/1.0
Physical Interfaces	/device/interface-information/physical-interface[name='ge-0/1/1]	The context of a physical interface ge-0/1/1

Context filtering

The context attribute of the script or configlet dictates which elements(inventory component or logical interface or physical interface) it is applicable to.

The rule to check whether the script or configlet is applicable to an element is as follows:

Evaluate the context XPath associated to a script or configlet on the device XML. This results in a set of XML nodes.
If the resultant XML node list contains the XML node representing the subject element, then the script/template entity is considered a match.

Given below are few examples of script or configlet contexts with their descriptions:

/device/chassis-inventory/chassis[name='Chassis']/chassis-module[starts-with(name,'Routing Engine')] - Applicable to all routing engines
/device/chassis-inventory/chassis[name='Chassis']/chassis-module[starts-with(name,'FPC')] - Applicable to all FPCs
/device[starts-with(system-information/os-version,"11")]/interface-information/physical-interface[starts-with(name,"ge")] - Applicable to all interfaces of type 'ge' which has system os-version as 11
/device/interface-information/physical-interface[admin-status=”up”] - Applicable to all physical interfaces with admin status in up state.
/device/chassis-inventory/chassis[name='Chassis']/chassis-module

[starts-with(name,'FPC')]/chassis-sub-module[starts-with(name,'PIC')] | /

device/chassis-inventory/chassis[name='Chassis']/chassis-module

[starts-with(name,'FPC')]/chassis-sub-module[starts-with(name,'MIC')]

/chassis-sub-sub-module[starts-with(name,'PIC')] - Applicable to all PICs

Note:

If we intend to specify the scope of a script as PICs, then we would have to consider two different XPaths the PIC can take (One with MIC in-between and one without). We have to give an OR combination of both the XPaths.

Note:

If no context is associated to a script or configlet, then the context of the script is taken as /device. These scripts or configlets would be listed for execution in devices.
You can execute CLI Configlets on more than 200 devices only if the CLI Configlets do not require XPath processing. CLI Configlets that do not require XPath processing include CLI Configlets without device-specific or entity-specific parameters and with /, //, or /device as context.

Physical Interface Example

Consider the following device XML

Context of an element

Context of physical-interface ge-0/0/0 is /device/interface-information/physical-interface[name='ge-0/0/0']

This XPath maps to the node below. This is the XML counterpart of the interface ge-0/0/0

Physical Interface in “up” state:

If the user wants to write a configlet to set the admin status of an interface down if its up, the context of the script can be set as /device/interface-information/physical-interface[admin-status='up']

This configlet will be enabled only for interfaces with admin status up. Since in our example, ge-0/0/0 satisfies the above condition, this configlet can be executed on it.

ON THIS PAGE

Configlet Context

Context of an Element

Context filtering

Related Documentation