Supported Platforms
Example: Service Template Automation
Service Template Automation Overview
Starting with Junos OS Release 12.3, you can use service template
automation (STA) to provision services such as VPLS VLAN, Layer 2
and Layer 3 VPNs, and IPsec across similar platforms running Junos OS.
Service template automation uses the service-builder.slax op script to transform a user-defined service template definition
into a uniform API, which you can then use to configure and provision
services on similar platforms running Junos OS. This permits you to
create a service template on one device, generalize the parameters,
and then quickly and uniformly provision that service on other devices.
This decreases the time required to configure the same service on
multiple devices, and reduces configuration errors associated with
manually configuring each device.
The following process outlines how to use service template automation to provision services:
- Create a service template definition.
- Execute the
service-builder.slaxscript and define service-specific instance parameters. - Generate the service interface, which automatically builds the required interface (API) from the template.
- 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.
You create a new service template by configuring the hierarchies for the actual service to be provisioned on a device running Junos OS. Service template hierarchies are configured at the [edit groups] hierarchy level. When creating the service template:
- Do not include apply-groups or apply-macro statements.
- Do not include any statements that are supported on the current device that are not also supported on the devices where the service will be provisioned (for example dual Routing Engine versus single Routing Engine).
- Commit the configuration. The service template group configuration is read from the committed configuration.
Once you create the basic service template definition, you invoke
the service-builder.slax op script.
The script reads the service template information from the committed
configuration and uses an interactive interface to help you build
and generate the service API. You have the option to parameterize
every variable in the service template or only selected variables.
For each selected variable, you create a generic service template
parameter. The service-builder.slax script guides you through the creation and configuration of each
parameter.
After you define the service template parameters, you generate
the service interface. This creates a platform-specific service op
script. If the load-scripts-from-flash statement is configured,
the generated service script is stored in the /config/scripts/op directory in flash memory. Otherwise, the generated script is stored
in the /var/db/scripts/op directory
on the hard disk.
To
enable the service interface on a device, you enable the generated
service script in the configuration as you would any op script. You
can enable the service interface on the local device using the service-builder.slax script or by manually updating
the configuration. To enable the service interface on a similar platform,
you must copy the generated service script to the corresponding directory
on the new device and enable the service script in the configuration.
To provision the service on a device, invoke the service interface using NETCONF, and supply the necessary values for each parameter. Alternatively, you can invoke the service interface in the CLI by executing the service script and supplying the necessary values for each parameter as command-line arguments to the script. You can direct the service script to create a new service configuration, or update or delete an existing service configuration. The service script makes the changes to the candidate configuration and then commits the configuration. The service script does not support the context-sensitive help and auto-completion features available in the Junos OS CLI.
Example: Configuring 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.slaxscript, 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.slaxscript to the/var/db/scripts/opdirectory on the hard disk or the/config/scripts/opdirectory on the flash drive.user@host> file copy /usr/libexec/scripts/op/service-builder.slax /var/db/scripts/opVerify that the script is in the correct directory by using the file list operational 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-flash statement, 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-groupConfigure the hierarchies for the service.
For this example, the pre-constructed configuration hierarchies are loaded into the candidate configuration using the load merge terminal command.
[edit]user@host# load merge terminalgroups {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 checkconfiguration check succeedsCommit 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.slaxscript, which starts an interactive Service Builder session.user@host> op service-builderWelcome 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 the vpn-service-template-group hierarchy 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 Variables option.
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 API option.
[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 ifname and the interface description parameter as ifdesc.
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.slaxscript 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. - 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-flash statement is not configured, copy the service script to the
/var/db/scripts/opdirectory on the second device. Otherwise, the script must be copied to the corresponding directory on the flash drive instead.Copy the service script to the
/var/db/scripts/opdirectory on the second device. Enable the op script in the configuration.
[edit]user@host2# set system scripts op file vpn-service.slaxCommit the configuration.
[edit]user@host2# commitcommit completeIn 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 sshuser@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 create action, and include values for all parameters that require configuring.
The value for the service-id parameter 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 sshuser@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 update action, 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 delete action, 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 Service Configuration
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 commit0 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.
