Templates for Netconf Provisioning
NorthStar Controller supports Netconf provisioning only on Juniper
devices. You can customize templates for Juniper devices by adding
or modifying the templates provided in the /opt/northstar/netconfd/templates/ directory on the NorthStar server.
The syntax and semantics used in the template attributes are based on Jinja Templates, a template engine for Python. Help/support for using Jinja Templates is readily available online.
You can also use customized templates to leverage properties you add to the User Properties tab on the Modify LSP window for LSPs provisioned via Netconf.
Overview of Netconf Provisioning Templates
There are two types of templates provided in the templates directory:
Encoding templates are for internal use only and should never be modified or deleted. All of these templates have “encoding” in their names (lsp-modify-encoding.hjson, for example).
Configuration templates are for transforming JSON document keys into device configuration statements. These templates are available for modification and to use as models for creating new templates. Currently, these templates all have “junos” in their names, (lsp-modify-junos.hjson, for example), although, as long as you use the .hjson suffix, you can name new templates according to your preference.
Template Requirements
Keep in mind the following template requirements:
If you create a new template, be sure the PCS user has Unix file permission to read it.
Template files are hjson documents, so their file names must have the .hjson suffix.
The Netconf daemon (NETCONFD) must be restarted for template changes to be applied:
[root@pcs-1 templates]# supervisorctl restart netconf:netconfdnetconf:netconfd: stopped netconf:netconfd: started
Currently, text is the only supported format for device configuration statements (as opposed to XML or JSON formats).
When you upgrade a NorthStar build, the templates provided in the new build replace the ones that were provided with the original build. You can prevent loss of your template changes by backing up your templates to a different directory on the server before upgrading NorthStar, or by saving your modified files with different file names.
Template Structure
Each template has two types of attributes:
Routing-key attributes which describe the type of provisioning for which the template should be used. The value of routing-key is not fixed in NETCONFD, but the following keys are currently agreed upon between NETCONFD and ConfigServer for LSP provisioning:
rest_eventd_request_key
Use for adding a new LSP.
rest_eventd_update_key
Use for modifying an existing LSP.
rest_eventd_delete_key
Use for deleting an LSP
Device profile attributes that define the device to be provisioned when using the template. You can use any device profile attributes (Administration > Device Profile) such as routerType (Vendor field in Device Profile), model, and so on. NETCONFD tries to match the attributes in the template with the attributes in the device profiles of the targeted devices.
Table 1, Table 2, and Table 3 detail the supported JSON document keys for adding LSPs, modifying LSPs, deleting LSPs, and link modification.
Keys that do not “always exist” only exist conditionally. For example:
request[“logical-system”] is used to specify the logical-system name, so it only exists in the JSON document if the provisioning order is for logical-system devices.
request[“p2mp-name”] is used to specify the P2MP name, so it only exists in the JSON document if the provisioning order is for P2MP LSPs.
Table 1: Keys for Adding or Modifying LSPs
Key | Value | Always Exists | Description |
|---|---|---|---|
request.name | text | yes | LSP name |
request.from | IPv4 address | yes | LSP source address |
request.to | IPv4 address | yes | LSP destination address |
request['lsp-path-name'] | text | yes | LSP path name |
request.bandwidth | integer | yes for adding no for modifying | LSP path bandwidth |
request.metric | integer | no | LSP metric |
request.type | [primary |secondary |standby] | yes | LSP path type |
request['path-attributes']['ero'][’ipv4-address’] | IPv4 address | no | LSP path hop |
request['path-attributes']['ero'][’loose'] | [true] | no | LPS path loose flag |
request['path-attributes']['setup-priority'] | [0-7] | yes for adding no for modifying | LSP path setup priority |
request['path-attributes']['reservation-priority'] | [0-7] | yes for adding no for modifying | LSP path reservation priority |
request['logical-system'] | text | no | LSP headend logical system name |
request['p2mp-name'] | text | no | LSP P2MP group name |
request['select-manual'] | [true] | no | LSP path manual selection |
Table 2: Keys for Deleting LSPs
Key | Value | Always Exists | Description |
|---|---|---|---|
request.name | text | yes | LSP name |
request.from | IPv4 address | yes | LSP source address |
request.to | IPv4 address | yes | LSP destination address |
request['lsp-path-name'] | text | no | LSP path name |
request.type | [primary |secondary |standby] | yes | LSP path type |
request.delete | [true] | no | Specifies whether the deletion order is for deleting the LSP (value of “true”) or the LSP path |
request['logical-system'] | text | no | LSP headend logical system name |
Table 3: Keys for Link Modification
Key | Value | Always Exists | Description |
|---|---|---|---|
request.new_interface.name | text | yes | Interface name |
request.new_interface.isis1_metric | integer | no | ISIS level 1 metric |
request.new_interface.isis2_metric | integer | no | ISIS level 2 metric |
request.new_interface.ospf_metric | integer | no | OSPF metric |
request.new_interface.ospf_area_id | integer | no | OSPF area |
request.logical_system | text | no | Router logical system name |
The pcs_provisioning_order_key order is currently used specifically for OSPF/ISIS metric modification.
Template Macros
Jinja Templates supports macros for defining reusable functions. The NorthStar template directory includes the macros listed in Table 4.
Table 4: Template Macros Included in the Template Directory
Macro | Function |
|---|---|
ifexist | Generates a Junos configuration statement if the evaluated key in the JSON document exists. |
Ifnotzero | Generates a Junos configuration statement if the evaluated key in the JSON document has a value that is not equal to zero. |
Ifnotnone | Generates a Junos configuration statement if the evaluated key in the JSON document has any value. |
decodeuserprops | Decodes the user defined properties in the JSON document. |
lsys | Generates a configuration statement for Junos logical system. |