Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Extending Service Implementations with Script Services

 

SRC Script Services Overview

You use services to provision policies on a number of systems across a network, including networks that do not contain a router running JunosE or Junos OS. Script services provide an interface to call scripts that supply custom services. You can use script services to create custom service implementations, such as:

  • Provisioning layer 2 devices, such as digital subscriber line access multiplexers (DSLAMs).

  • Setting up network connections, such as MPLS tunnels.

  • Provisioning policies for network devices that do not have a supported SAE device driver.

  • Accessing functionality not currently supported by SAE device drivers but supported by other interfaces, such as RADIUS change of authorization (COA) on routers running JunosE Software and Junos XML protocol management provisioning on routers running Junos OS.

Customizing Service Implementations

Perform the following tasks to customize service implementations:

Writing Scripts for Script Services

The ScriptService service provider interface (SPI) provides a Java interface that a script service implements. For information about the ScriptService interface and the ServiceSessionInfo interface, see the script service documentation in the SAE core API documentation on the Juniper Networks website at https://www.juniper.net/documentation/software/management/src/api-index.html.

The implementation of the ScriptService interface activates the service. The SAE sends authentication and tracking events when it activates, modifies, or deactivates a script service session.

The SAE supports script services written in Java or Jython. For scripts written in Java, you must compile and package the implemented ScriptService to make it available for use by the SAE. A Java implementation can include more than one Java archive (JAR) file.

The SAE synchronizes methods used by the same instance of the ScriptService class. You do not need to provide synchronized implementation of the methods.

Note

The script service implementation can be called by different threads at the same time. If your script uses resources that are shared between different service instances, you are responsible for synchronizing access to those resources.

To write a script to be used by a script service:

  1. Create a class that provides a default constructor and that implements the ScriptService interface.

  2. Manage activation and manipulation of the service session by implementing the following ScriptService methods:

    • activateSession()—Activates the script service session.

    • deactivateSession()—Deactivates the script service session and returns any final accounting data for the script service session.

    • modifySession()—If the counters were reset during the modification, modifies the script service session and returns any accounting data.

    These methods are implemented by the script service. They perform the associated action (activate, deactivate, modify) when the SAE calls the method.

  3. (Optional) Get information about service sessions by using methods on the ServiceSessionInfo interface.

  4. (Optional) Provide accounting data, if used, by using the following ScriptService method:

    getAccountingData()—Polls for current accounting data and returns any current accounting data.

  5. (Optional) Provide service status information by using the following ScriptService method:

    getState()—Returns session data to be stored persistently on the router. The SAE does not use this data but provides it to the script when a service session is restored after failover.

  6. Manage the script service by using the following ScriptService methods:

    • initState()—Initializes a recovered script service session after a state synchronization.

    • discarded()—Provides notification that the service session has been discarded. Service sessions are discarded when the SAE loses connection to a router. A discarded service session continues to exist on the router and is restored after the connection to the router is reestablished by an SAE.

      The script service session releases any resources associated with a discarded session, but must not take any action to disrupt the service session.

You can also use the stopService() method on the ServiceSessionInfo object to stop a service and remove the service from the SAE. For example, consider a script service that monitors a state that it creates outside the SAE. If the script detects that the service is not active, it can stop the service and remove it from the SAE. You could use this type of script service to start a daemon process and monitor the process to make sure that it is alive.

Note

The ScriptService SPI does not provide access to a router driver.

Example: Using the ScriptService SPI in Jython

The following example implements the ScriptService SPI in Jython.

Example: Using the ScriptService SPI in Java

The following example implements the ScriptService SPI in Java.

Configuring Script Services (SRC CLI)

Before you configure a script service, make sure that you know the location of the script file that the service will reference.

Use the following configuration statements to configure a script service in the global service scope:

Use the following configuration statements to configure a script service in a service scope:

To configure a script service:

  1. Configure a normal service, but set the service type to script. See Adding a Normal Service (SRC CLI).

  2. From configuration mode, enter the service script configuration. In this sample procedure, the service called scriptService is configured in the scope configuration.

  3. Configure the type of script that the script service uses.

  4. For Java class and Python script services, configure the name of the class that implements the script service.

  5. Script services of the url script type are written in Java and provided as a Java archive (.jar) file. Configure the URL that specifies the location of the .jar file containing the script service implementation. For other script types, you must load the script service implementation.

  6. For Java class, and Java archive, and Python script services, load the script service implementation by specifying the filename of the local file containing the script service implementation. This file is the uncompiled Python source code or the compiled result of the Java script service (binary .class or .jar file).

  7. (Optional) Verify your configuration.

Restricting Simultaneous Activation of Services

Restricting Simultaneous Activation of Services Overview

A mutex group defines a set of services that are mutually exclusive—services that the SAE cannot simultaneously activate for a particular subscriber. You can assign a service to more than one mutex group. When a subscriber requests activation of a particular service, the SAE determines which mutex groups contain that service. If the subscriber has current activations of other services listed in those mutex groups, the SAE proceeds in one of the following ways, depending on how you configured the mutex groups:

  • Deactivates the other services listed in the mutex groups, and then activates the requested service.

  • Refuses access to the requested service.

If the requested service is not listed in a mutex group, the SAE can activate the service regardless of any other services that the subscriber is using.

Restricting Simultaneous Activation of Persistent or Automatic Services

The SAE uses the following method to prevent simultaneous activation of mutually exclusive services that are configured for persistent activation or that are activated automatically when a subscriber logs in:

  1. If you (or a subscriber) persistently activate an existing service or change a subscription to activate an existing service when a subscriber logs in, the SAE determines whether the service is specified in one or more mutex groups.

  2. The SAE determines how each mutex group that lists the service is configured, and the SRC software acts accordingly.

    • If all the mutex groups that list the service allow automatic deactivation of services, the SRC software removes the persistent activations for the service and changes activate-on-login subscriptions to manual.

    • If any of the mutex groups does not allow automatic deactivation of services, the SRC software will not allow you to:

      • Persistently activate the service.

      • Change the subscription to activate the service when a subscriber logs in.

Adding a Mutex Group (SRC CLI)

Use the following configuration statements to configure a mutex group in the global service scope:

Use the following configuration statements to configure a mutex group in a service scope:

To add a mutex group:

  1. From configuration mode, enter the mutex group configuration. In this sample procedure, the mutex group is called Video.

  2. Configure the method that the SAE uses to manage activation of services defined in this group.

  3. Enter a description for the service.

  4. Configure the lists of services that the mutex group contains.

  5. (Optional) Verify your configuration.