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:
<device> <interface-information>.....</interface-information> <system-information>.....</system-information> <chassis-inventory>.....</chassis-inventory> <configuration>....</configuration> .... </device>
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 | - |
The command for system information XML is not available. An instance of the system information XML is as follows:
<system-information> <hardware-model>ex4200-24t</hardware-model> <os-name>junos-ex</os-name> <os-version>11.3R2.4</os-version> <serial-number>BM0210293858</serial-number> <host-name>EX4200-200</host-name> <virtual-chassis/> </system-information>
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
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.
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.
Physical Interface Example
Consider the following device XML
<device> <interface-information> <physical-interface> <name>ge-0/0/0</name> <admin-status>up</admin-status> .... </physical-interface> <physical-interface> <name>ge-0/0/1</name> <admin-status>down</admin-status> .... </physical-interface> ..... </interface-information> .... <!-- ALL THE OTHER NODES --> .... </device>
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> <name>ge-0/0/0</name> <admin-status>up</admin-status> .... </physical-interface>
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.
To view the contexts for writing CLI configlet scripts for different service types, refer Table 4.
Table 4: CLI Configlets Contexts for Different Service Types
Service Type | Context |
|---|---|
P2P | @CONTEXT = "/device/configuration/protocols/l2circuit/neighbor/interface" Example : /device[name="MX80-NGCE-1"]/configuration/protocols/l2circuit/neighbor[name="30.1.2.8"]/interface[name="ge-0/1/5.784"] |
L3VPN | /*@CONTEXT = "/device/configuration/routing-instances/instance/interface" */ Example : /device[name="kochin"]/configuration/routing-instances/instance[name="SO62441630" and instance-type="vrf"]/interface[name="ge-0/1/3.934"] |
VPLS | /* @CONTEXT = "/device/configuration/routing-instances/instance/interface" */ Example : /device[name="kochin"]/configuration/routing-instances/instance[name="SO62441630" and instance-type="vpls"]/interface[name="ge-0/1/3.945"] |
P2P or L3VPN with L2E | /* @CONTEXT = "/device/configuration/protocols/connections/interface-switch/interface" */ Example: /device[name="MX80-1"]/configuration/protocols/connections/interface-switch/interface[name="ge-1/0/0.1801"] |
P2P (Local switching) | /* @CONTEXT = "/device/configuration/protocols/l2circuit/local-switching/interface/end-interface" */ Example /device[name="MX80-1"]/configuration/protocols/l2circuit/local-switching/interface[name="ge-1/0/0.1801"]/end-interface[interface="ge-1/2/2.1881"] |
NPS (Network peering) | /* @CONTEXT = "/device/configuration/protocols/bgp/group" */ Example /device[name="MX80-1"]/configuration/protocols/bgp/group[type="external"] |