Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

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:

  1. Create a service template definition.
  2. Execute the service-builder.slax script, and define service-specific instance parameters.
  3. Generate the service interface.
  4. Enable the service interface on each device where the service is required.
  5. 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

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.

  1. 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.

  2. Verify that the script is in the correct directory by using the file list operational mode command.

    user@host> file list /var/db/scripts/op
  3. Enable the script in the configuration.

  4. If you store scripts in and load them from flash, configure the load-scripts-from-flash statement, if it is not already configured.
  5. Commit the configuration.

Configuring the Service Template Definition

Step-by-Step Procedure

To create a new service template on a device running Junos OS:

  1. Select a service name.

    This example uses vpn-service.

  2. In configuration mode, create a new group, which will contain the hierarchies for the actual service to be provisioned.

  3. Configure 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.

  4. Verify that the configuration syntax is correct.

  5. Commit the configuration.

Configuring and Generating the Service Interface

Step-by-Step Procedure

To configure and generate the service interface:

  1. In operational mode, execute the service-builder.slax script, which starts an interactive Service Builder session.
    user@host> op service-builder
  2. Enter the service name that was defined in Configuring the Service Template Definition.

  3. 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.

  4. (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.

  5. To build the Service API, select the Build Service API option.

  6. 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.

  7. 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.

  8. 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.

  9. 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 Quit option.

  10. 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.

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
user@host> file list /var/db/scripts/lib

Enabling the Service Interface

Step-by-Step Procedure

To enable the service interface on a remote device:

  1. 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/op directory on the second device. Otherwise, the script must be copied to the corresponding directory on the flash drive instead.

  2. Enable the op script in the configuration.

  3. Commit the configuration.

  4. In operational mode, verify that the script is enabled and that the service parameters display as arguments for the script.

Provisioning the Service Using NETCONF

Step-by-Step Procedure

To provision the service:

  1. If it is not already configured, configure NETCONF service over SSH on any devices where you are provisioning the new service.
  2. From a configuration management server, establish a NETCONF session with the device where you are provisioning the service.
  3. 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.

Updating or Deleting Services Using NETCONF

Step-by-Step Procedure

To update or delete an existing service:

  1. If it is not already configured, configure NETCONF service over SSH on any devices where you are updating or deleting the service.
  2. From a configuration management server, establish a NETCONF session with the device where you are provisioning the service.
  3. 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.

  4. 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.

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 commit

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

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:

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:

Solution

The RPC might include both the parameter and a child element. Remove the child element from the RPC.