Example: Configure Service Template Automation
This example shows how to use service template automation to provision services across similar platforms running Junos OS.
Requirements
Two MX Series devices running Junos OS Release 12.3 or later.
Overview
This example uses service template automation to provision services on an MX Series router. To use the service template automation service-builder.slax script, you must first copy the script to the /var/db/scripts/op or /config/scripts/op directory and enable the script on the device.
The following process outlines how to use service template automation to provision services:
Create a service template definition.
Execute the service-builder.slax script, and define service-specific instance parameters.
Generate the service interface.
Enable the service interface on each device where the service is required.
Provision systems by invoking the service interface using NETCONF and supplying the service parameter values.
This example creates a new VPN service interface on an MX Series device running Junos OS Release 12.3 and provisions the service on a second MX Series device running Junos OS Release 12.3. You configure service template definitions under the [edit groups] hierarchy level. For this example, the service name is vpn-service, and the template group name is vpn-service-template-group. The load merge terminal configuration mode command loads the service template configuration hierarchies into the candidate configuration, which is then committed.
Once you create the initial service template, you execute the service-builder.slax script. The script prompts for the service name and the template group name, and then reads the service template configuration from the committed configuration.
The service-builder.slax script interface consists of two menus: Main Menu and Hierarchies Menu. Within the Main Menu, you can review the variables defined in the service template configuration, or you can build or enable the service API. The Build Service API menu option displays the Hierarchies Menu, which steps you through the parameterization of the variables. The default is to parameterize every variable, or you can choose to parameterize selected variables. If you must exit the service-builder.slax script while building the service API, you must finish configuring all the parameters for the current hierarchy in order to save that hierarchy configuration when you exit using the Quit option. Then you can finish configuring any incomplete hierarchies at a later time. This example parameterizes two variables: the interface name and the interface description. After the parameters are specified, the service builder script generates the service script.
The Enable Service API menu option enables the service script on the local device. To enable the service script on the second MX Series device, the generated service script is copied to the /var/db/scripts/op directory on the second device, and the script is enabled in the configuration. If the load-scripts-from-flash statement is configured, the script must be copied to the corresponding directory on the flash drive instead.
NETCONF is used to provision the service on the remote MX Series device. The NETCONF remote procedure call (RPC) action depends on whether the service is a new service or an existing service. Supported actions include create, update, and delete. This example creates a new service. If the given service is already provisioned on the device and you are updating or deleting the service parameters, you can alter the RPC to perform these actions.
Configuration
- Storing and Enabling the Service Builder Script
- Configuring the Service Template Definition
- Configuring and Generating the Service Interface
- Verifying the Service Interface
- Enabling the Service Interface
- Provisioning the Service Using NETCONF
- Updating or Deleting Services Using NETCONF
Storing and Enabling the Service Builder Script
Step-by-Step Procedure
The Junos OS installation includes the service-builder.slax script, which is stored in the /usr/libexec/scripts/op/ directory on the device. To use the service-builder.slax script, you must first copy it to the op scripts directory and enable it in the configuration. Only users in the Junos OS superuser login class can access and edit files in these directories.
Copy the service-builder.slax script to the /var/db/scripts/op directory on the hard disk or the /config/scripts/op directory on the flash drive.
user@host> file copy /usr/libexec/scripts/op/service-builder.slax /var/db/scripts/op
Verify that the script is in the correct directory by using the
file listoperational mode command.user@host> file list /var/db/scripts/op /var/db/scripts/op: service-builder.slax*
Enable the script in the configuration.
[edit] user@host# set system scripts op file service-builder.slax
If you store scripts in and load them from flash, configure the
load-scripts-from-flashstatement, if it is not already configured.[edit] user@host# set system scripts load-scripts-from-flash
Commit the configuration.
[edit] user@host# commit
Configuring the Service Template Definition
Step-by-Step Procedure
To create a new service template on a device running Junos OS:
Select a service name.
This example uses
vpn-service.In configuration mode, create a new group, which will contain the hierarchies for the actual service to be provisioned.
[edit] user@host# set groups vpn-service-template-group
Configure the hierarchies for the service.
For this example, the pre-constructed configuration hierarchies are loaded into the candidate configuration using the
load merge terminalcommand.[edit] user@host# load merge terminal groups { vpn-service-template-group { interfaces { ge-2/2/6 { description "connected to customer3-site-1"; unit 0 { family bridge { interface-mode access; vlan-id 300; } } } } protocols { rstp { interface ge-2/3/0; } mvrp { interface ge-2/3/0; } } bridge-domains { bd { vlan-id-list 100; } } } } [Ctrl+D]Verify that the configuration syntax is correct.
[edit] user@host# commit check configuration check succeeds
Commit the configuration.
[edit] user@host# commit
Configuring and Generating the Service Interface
Step-by-Step Procedure
To configure and generate the service interface:
In operational mode, execute the service-builder.slax script, which starts an interactive Service Builder session.
user@host> op service-builder Welcome to Service Builder Script: (v1.0) - Enter the service name :
Enter the service name that was defined in Configuring the Service Template Definition.
Enter the service name : vpn-service
Enter the group name under which the service hierarchies are configured.
This example uses the group name
vpn-service-template-group. The script reads the configuration specified in thevpn-service-template-grouphierarchy and then displays the main menu.Enter the group name : vpn-service-template-group .. reading [edit group vpn-service-template-group] .. [Op Script Builder - Main Menu] ----------------------------------- 1. Show Variables 2. Build Service API 3. Enable Service API Q. Quit ----------------------------------- Enter Selection:>
(Optional) To review the service template variables that you can parameterize, select the
Show Variablesoption.The script translates the template definition in the candidate configuration into a general parameter list grouped by hierarchy level.
[Op Script Builder - Main Menu] ----------------------------------- 1. Show Variables 2. Build Service API 3. Enable Service API Q. Quit ----------------------------------- Enter Selection:> 1 List of variables under each hierarchy to parameterize: - 1. [ edit groups vpn-service-template-group interfaces ] 1.1. interface/name 1.2. interface/description 1.3. interface/unit/name 1.4. interface/unit/family/bridge/interface-mode 1.5. interface/unit/family/bridge/vlan-id - 2. [ edit groups vpn-service-template-group protocols ] 2.1. rstp/interface/name 2.2. mvrp/interface/name - 3. [ edit groups vpn-service-template-group bridge-domains ] 3.1. domain/name 3.2. domain/vlan-id-list -
To build the Service API, select the
Build Service APIoption.[Op Script Builder - Main Menu] ----------------------------------- 1. Show Variables 2. Build Service API 3. Enable Service API Q. Quit ----------------------------------- Enter Selection:> 2
From the
Hierarchies Menu, enter the menu selections for the hierarchies that have variables you want to parameterize, or press Enter to select all hierarchies.[Op Script Builder - Hierarchies Menu] ----------------------------------- 1. interfaces 2. protocols 3. bridge-domains Q. Quit ----------------------------------- Please enter multiple selections separated by a comma (,) only. ----------------------------------- Enter Selection:> [default:all] 1
From the variables list, enter the menu selections for the variables you want to parameterize for the service interface, or press Enter to parameterize all variables within that hierarchy.
List of variables to parameterize: ... [ edit groups vpn-service-template-group interfaces ] ----------------------------------- 1. interfaces/interface/name 2. interfaces/interface/description 3. interfaces/interface/unit/name 4. interfaces/interface/unit/family/bridge/interface-mode 5. interfaces/interface/unit/family/bridge/vlan-id Q. Quit Please enter multiple selections separated by a comma (,) only. ----------------------------------- Enter Selection:> [default:all] 1,2
Configure the selected parameters.
The system prompts for the required information. This example configures the interface name parameter as
ifnameand the interface description parameter asifdesc.Enter parameter name for: 1.interfaces/interface/name **************************** [ edit groups vpn-service-template-group interfaces ] Name for this parameter? ifname Do you want to revise 'ifname'? (yes/no)[no]: no Enter parameter name for: 2.interfaces/interface/description **************************** [ edit groups vpn-service-template-group interfaces ] Name for this parameter? ifdesc Do you want to revise 'ifdesc'? (yes/no)[no]: no
Configure the selected parameters at each hierarchy level.
The script iterates over each selected hierarchy and the specified parameters. If you must exit the service-builder.slax script while building the service API, you must finish configuring all the parameters for the current hierarchy in order to save that hierarchy configuration when you exit using the
Quitoption.Generate the service interface, which creates the service script.
Once all parameters are configured, the script automatically prompts you to generate the service interface. Press Enter or type yes to generate the service interface.
Do you want to commit the previously selected options to create vpn-service script? (yes/no)[yes]: yes Created service script: /var/db/scripts/op/vpn-service.slax
Verifying the Service Interface
Purpose
Verify the creation of the service script. If the load-scripts-from-flash statement is configured, the generated file is stored in flash memory. Otherwise, the generated file is stored on the hard disk.
Action
Issue the file list operational mode command. For this example, the vpn-service.slax script should be present in the /var/db/scripts/op directory. The service-builder.slax script also generates the utility.slax script in the /var/db/scripts/op directory and the vpn-service-builder-info.xml file in the /var/db/scripts/lib directory. These files are used by the service-builder.slax script and should not be deleted.
user@host> file list /var/db/scripts/op /var/db/scripts/op: service-builder.slax utility.slax vpn-service.slax user@host> file list /var/db/scripts/lib /var/db/scripts/lib: vpn-service-builder-info.xml
Enabling the Service Interface
Step-by-Step Procedure
To enable the service interface on a remote device:
Copy the generated service script to the device where you are provisioning the new service.
If the
load-scripts-from-flashstatement is not configured, copy the service script to the /var/db/scripts/op directory on the second device. Otherwise, the script must be copied to the corresponding directory on the flash drive instead.Enable the op script in the configuration.
[edit] user@host2# set system scripts op file vpn-service.slax
Commit the configuration.
[edit] user@host2# commit commit complete
In operational mode, verify that the script is enabled and that the service parameters display as arguments for the script.
user@host2> op vpn-service ? Possible completions: <[Enter]> Execute this command <name> Argument name action Please enter either create/delete/update detail Display detailed output ifdesc Text description of interface ifname Name of interface service-id Service Name | Pipe through a command
Provisioning the Service Using NETCONF
Step-by-Step Procedure
To provision the service:
If it is not already configured, configure NETCONF service over SSH on any devices where you are provisioning the new service.
[edit] user@host2# set system services netconf ssh user@host2# commit
From a configuration management server, establish a NETCONF session with the device where you are provisioning the service.
%ssh -p 830 -s user@host2 netconf user@host2's password: <!-- user user, class super-user --> <hello> <capabilities> <capability>urn:ietf:params:xml:ns:netconf:base:1.0</capability> <capability> urn:ietf:params:xml:ns:netconf:capability:candidate:1.0 </capability> <capability> urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0 </capability> <capability> urn:ietf:params:xml:ns:netconf:capability:validate:1.0 </capability> <capability> urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file </capability> <capability>http://xml.juniper.net/netconf/junos/1.0</capability> <capability>http://xml.juniper.net/dmi/system/1.0</capability> </capabilities> <session-id>28898</session-id> </hello> ]]>]]>If you are provisioning a new service on the device, enter a remote procedure call (RPC) that calls the service op script using the
createaction, and include values for all parameters that require configuring.The value for the
service-idparameter should be identical to the service name.<rpc> <op-script> <script>vpn-service</script> <action>create</action> <service-id>vpn-service</service-id> <ifname>ge-2/0/5,ge-2/0/6</ifname> <ifdesc>connected to customer1-site-1,connected to customer3-site-2</ifdesc> </op-script> </rpc>
Updating or Deleting Services Using NETCONF
Step-by-Step Procedure
To update or delete an existing service:
If it is not already configured, configure NETCONF service over SSH on any devices where you are updating or deleting the service.
[edit] user@host2# set system services netconf ssh user@host2# commit
From a configuration management server, establish a NETCONF session with the device where you are provisioning the service.
%ssh -p 830 -s user@host2 netconf user@host2's password: <!-- user user, class super-user --> <hello> <capabilities> <capability>urn:ietf:params:xml:ns:netconf:base:1.0</capability> <capability> urn:ietf:params:xml:ns:netconf:capability:candidate:1.0 </capability> <capability> urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0 </capability> <capability> urn:ietf:params:xml:ns:netconf:capability:validate:1.0 </capability> <capability> urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file </capability> <capability>http://xml.juniper.net/netconf/junos/1.0</capability> <capability>http://xml.juniper.net/dmi/system/1.0</capability> </capabilities> <session-id>28898</session-id> </hello> ]]>]]>If the given service is already provisioned on the device and you are updating the service, enter an RPC that calls the service op script using the
updateaction, and include values for all parameters that require updating.<rpc> <op-script> <script>vpn-service</script> <action>update</action> <service-id>vpn-service</service-id> <ifname>ge-2/0/5</ifname> <ifdesc>connected to customer1-site-2</ifdesc> </op-script> </rpc>If the given service is already provisioned on the device and you are deleting some or all of the service parameters, enter an RPC that calls the service op script using the
deleteaction, and include any parameters that need to be deleted.<rpc> <op-script> <script>vpn-service</script> <action>update</action> <service-id>vpn-service</service-id> <ifname>ge-2/0/6</ifname> </op-script> </rpc>
Verification
Confirm that the configuration is updated.
Verifying the Commit
Purpose
Verify that the commit is successful.
Action
Issue the show system commit operational mode command to view the recent commits. The most recent commit entry shows that a commit was made through the NETCONF server by user.
user@host2> show system commit 0 2012-05-21 12:15:08 PDT by user via junoscript 1 2012-05-18 09:47:40 PDT by user via other ...
Verifying the Service Configuration
Purpose
Verify that the service configuration is present in the active configuration.
Action
Issue the show configuration | compare rollback num operational mode command to view configuration changes.
user@host2> show configuration | compare rollback 1
[edit interfaces]
+ ge-2/0/5 {
+ description "connected to customer1-site-1";
+ }
+ ge-2/0/6 {
+ description "connected to customer3-site-2";
+ }
Meaning
A comparison of the current configuration with the previous configuration shows that the interfaces and interface descriptions were added to the configuration.
Troubleshooting
Troubleshooting a Failed Commit
Problem
You see the following message when creating, updating, or deleting a service on a device through a NETCONF session:
<output> configuration database modified </output>
The configuration has previously uncommitted changes, and the service script cannot commit the service configuration changes.
Solution
Commit the previous changes or roll back the configuration as appropriate, and then resubmit the service configuration changes.
Troubleshooting a Failed Attempt to Delete Service Parameters
Problem
You see the following message when deleting a service parameter on a device through NETCONF:
<xnm:error xmlns:xnm="http://xml.juniper.net/xnm/1.1/xnm">
<source-daemon>
op-script
</source-daemon>
<message>
xsl:attribute: Cannot add attributes to an element if children have been already added to the element.
</message>
</xnm:error>
Solution
The RPC might include both the parameter and a child element. Remove the child element from the RPC.