Applying Services

There are four configuration tasks in applying services to traffic packets:

• Define the services.
• Create service sets containing the defined services.
• Set the order in which services in the service sets are applied to the traffic.
• Configure the services interface on which the services are to be performed. (Services interfaces are used with a service set type.)

Defining Services for SDK Applications

The JUNOS SDK does not specify how providers must set up their configuration hierarchies. A place in the JUNOS hierarchy is provided in which providers can create their own statements to define SDK application services (external services). This place is the [edit services service-set service-set-name extension-service] hierarchy level.

[edit]
services {
    service-set service-set-name {
        extension-service service-name {
            provider-specific rules;
        }
    }
}

In the native JUNOS Software, services such as stateful firewall, NAT, IDS (that is, internal services) are defined by policies (called rules) or groups of rules (called rule sets) at the [edit services] hierarchy level. A provider might use this model by adding a hierarchy for its SDK application in which it defines services similar to the way internal services are defined.

Note:

For help in architecting their applications, providers should consult JUNOS SDK Developer Support.

Creating Service Sets Using the SDK

A service set is a collection of policies taken from multiple services that can be applied as a unit to traffic coming to the PIC.

Wherever services are configured (see Defining Services for SDK Applications), to include a defined service in a service set for an SDK application, you must reference it using the extension-service statement at the [edit services service-set service-set-name] hierarchy level:

[edit]
services {
    service-set service-set-name {
        extension-service service-name1 {
        extension-service service-name2 {
        service-order {
            forward-flow [ service-name1 service-name2 ];
            reverse-flow [ service-name1 service-name2 ];
        }
    }
}

Note:

If the extension-service statement is specified, the service-order statement is mandatory. For more information, see Setting the Service Order.

Setting the Service Order

The service order defines the order in which services in a service set are applied to traffic coming to the PIC. If the extension-service statement is specified, the service-order statement is mandatory.

To configure the service order, use the service-order statement at the [edit services service-set service-set-name] hierarchy level:

[edit]
services {
    service-set service-set-name {
        extension-service service-name1;
        extension-service service-name2;
        service-order {
            forward-flow [ service-name1 service-name2 ];
            reverse-flow [ service-name1 service-name2 ];
        }
    }
}

The service-order statement must include:

• All services defined in the service set
• The forward-flow statement

In the case that the reverse-flow statement is not specified, the reverse-flow service order is the reverse of the forward-flow service order. If, for example, you want the service order to be the same regardless of the direction of the flow, you need to set the reverse-flow statement as well as the forward-flow statement.

To change the service order, you can delete the service order elements and then add them again in the new order. To change the service order, you can also use the insert command. For more on the insert command, see the JUNOS CLI Configuration Guide.

Up to two SDK plugins are supported per PIC and can be chained together in one service set. For an example, see Service Set Configuration Example.

Service Set Types

In addition to next-hop and interface service sets there is also a sampling service set. Interface and next-hop service sets are explained in the JUNOS Services Interfaces Configuration Guide.

The sampling service set is configured using the sampling-service statement at the [edit services service-set service-set-name] hierarchy level.

[edit]
services {
    service-set service-set-name {
        sampling-service {
            service-interface interface-name;
        }
    }
}

The service interface is the interface the sampling is taken from. In the case of a sampling service set, the service interface must be a MultiServices PIC interface with a subunit number of 0. If the subunit is not specified, 0 will be assumed. The reverse-flow statement is not mandatory in this case. If no reverse flow is configured, all the sampled traffic is considered to be forward traffic.

The next example makes sure that any sampled packet to the ms-6/1/0.0 interface will have the service plugins plugin1 and plugin2 applied to it.

[edit]
services {
    service-set sset1 {
        sampling-service {
            service-interface ms-6/1/0;
        }
        extension-service plugin1;
        extension-service plugin2;
        service-order {
            forward-flow [ plugin1 plugin2 ];
            reverse-flow [ plugin1 plugin2 ];
        }
    }
}

In order to sample traffic there are other tasks that must be done. For more information, see Sampling Traffic in SDK Applications.

Other Configuration Guidelines:

Guidelines for Configuring SDK Applications

See also:

Statement Summary

Configuration Command Summary

Operational Command Reference

SDK CLI Configuration

---