Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Service Sets

Understanding Service Sets

Junos OS enables you to create service sets that define a collection of services to be performed by an Adaptive Services interface (AS) or Multiservices line cards (MS-DPC, MS-MIC, and MS-MPC). You can configure the service set either as an interface-style service set or as a next-hop-style service set.

An interface service set is used as an action modifier across an entire interface. You can use an interface-style service set when you want to apply services to packets passing through an interface.

A next-hop service set is a route-based method of applying a particular service. Only packets destined for a specific next hop are serviced by the creation of explicit static routes. This configuration is useful when services need to be applied to an entire virtual private network (VPN) routing and forwarding (VRF) table, or when routing decisions determine that services need to be performed. When a next-hop service is configured, the service interface is considered to be a two-legged module with one leg configured to be the inside interface (inside the network) and the other configured as the outside interface (outside the network).

In order to avoid packet drop during a service-set deactivate or a service-set delete operation, first bring down the interfaces corresponding to the service-set, wait for sometime , and later deactivate or delete the service-set. However, if the traffic flow is very high, this workaround does not help.

To configure service sets, include the following statements at the [edit services] hierarchy level:

Configuring Service Sets to be Applied to Services Interfaces

You configure a services interface to specify the adaptive services interface on which the service is to be performed. Services interfaces are used with either of the service set types described in the following sections.

Configuring Interface Service Sets

An interface service set is used as an action modifier across an entire interface. To configure the services interface, include the interface-service statement at the [edit services service-set service-set-name] hierarchy level:

Only the device name is needed, because the router software manages logical unit numbers automatically. The services interface must be an adaptive services interface for which you have configured unit 0 family inet at the [edit interfaces interface-name hierarchy level.

When you have defined and grouped the service rules by configuring the service-set definition, you can apply services to one or more interfaces installed on the router. When you apply the service set to an interface, it automatically ensures that packets are directed to the PIC.

To associate a defined service set with an interface, include a service-set statement with the input or output statement at the [edit interfaces interface-name unit logical-unit-number family inet service] hierarchy level:

If a packet is entering the interface, the match direction is input. If a packet is leaving the interface, the match direction is output. The service set retains the input interface information even after services are applied, so that functions such as filter-class forwarding and destination class usage (DCU) that depend on input interface information continue to work.

You configure the same service set on the input and output sides of the interface. You can optionally include filters associated with each service set to refine the target and additionally process the traffic. If you include the service-set statement without a service-filter definition, the router software assumes the match condition is true and selects the service set for processing automatically.

Note:

If you configure service sets with filters, they must be configured on the input and output sides of the interface.

You can include more than one service set definition on each side of the interface. If you include multiple service sets, the router software evaluates them in the order in which they appear in the configuration. The system executes the first service set for which it finds a match in the service filter and ignores the subsequent definitions. A maximum of six service sets can be applied to an interface. When you apply multiple service sets to an interface, you must also configure and apply a service filter to the interface.

An additional statement allows you to specify a filter for processing the traffic after the input service set is executed. To configure this type of filter, include the post-service-filter statement at the [edit interfaces interface-name unit logical-unit-number family inet service input] hierarchy level:

The post-service-filter statement is not supported when the service interface is on an MS-MIC or MS-MPC.

For an example, see Example: Configuring Service Sets.

Note:

With interface-style service sets that are configured with Junos OS extension-provide packages, the traffic fails to get serviced when the ingress interface is part of a VRF instance and the service interface is not part of the same VRF instance.

Note:

When the MultiServices PIC configured for a service set is either administratively taken offline or undergoes a failure, all the traffic entering the configured interface with an IDP service set would be dropped without notification. To avoid this traffic loss, include the bypass-traffic-on-pic-failure statement at the [edit services service-set service-set-name service-set-options] hierarchy level. When this statement is configured, the affected packets are forwarded in the event of a MultiServices PIC failure or offlining, as though interface-style services were not configured. This issue applies only to Junos Application Aware (previously known as Dynamic Application Awareness) configurations using IDP service sets. This forwarding feature worked only with the Packet Forwarding Engine (PFE) initially. Starting with Junos OS Release 11.3, the packet-forwarding feature is extended to packets generated by the Routing Engine for bypass service sets as well.

Configuring Next-Hop Service Sets

A next-hop service set is a route-based method of applying a particular service. Only packets destined for a specific next hop are serviced by the creation of explicit static routes. This configuration is useful when services need to be applied to an entire virtual private network (VPN) routing and forwarding (VRF) table, or when routing decisions determine that services need to be performed.

When a next-hop service is configured, the AS or Multiservices PIC is considered to be a two-legged module with one leg configured to be the inside interface (inside the network) and the other configured as the outside interface (outside the network).

Note:

You can create IFL indexes greater than 8000 only if the interface service set is not configured.

To configure the domain, include the service-domain statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level:

The service-domain setting must match the configuration for the next-hop service inside and outside interfaces. To configure the inside and outside interfaces, include the next-hop-service statement at the [edit services service-set service-set-name] hierarchy level. The interfaces you specify must be logical interfaces on the same AS PIC. You cannot configure unit 0 for this purpose, and the logical interface you choose must not be used by another service set.

Traffic on which the service is applied is forced to the inside interface using a static route. For example:

After the service is applied, traffic exits by way of the outside interface. A lookup is then performed in the Packet Forwarding Engine (PFE) to send the packet out of the AS or Multiservices PIC.

The reverse traffic enters the outside interface, is serviced, and sent to the inside interface. The inside interface forwards the traffic out of the AS or Multiservices PIC.

Determining Traffic Direction

When you configure next-hop service sets, the AS PIC functions as a two-part interface, in which one part is the inside interface and the other part is the outside interface. The following sequence of actions takes place:

  1. To associate the two parts with logical interfaces, you configure two logical interfaces with the service-domain statement, one with the inside value and one with the outside value, to mark them as either an inside or outside service interface.

  2. The router forwards the traffic to be serviced to the inside interface, using the next-hop lookup table.

  3. After the service is applied, the traffic exits from the outside interface. A route lookup is then performed on the packets to be sent out of the router.

  4. When the reverse traffic returns on the outside interface, the applied service is undone; for example, IPsec traffic is decrypted or NAT addresses are unmasked. The serviced packets then emerge on the inside interface, the router performs a route lookup, and the traffic exits the router.

A service rule’s match direction, whether input, output, or input/output, is applied with respect to the traffic flow through the AS PIC, not through a specific inside or outside interface.

When a packet is sent to an AS PIC, packet direction information is carried along with it. This is true for both interface style and next-hop style service sets.

Interface Style Service Sets

Packet direction is determined by whether a packet is entering or leaving any Packet Forwarding Engine interface (with respect to the forwarding plane) on which the interface-service statement is applied. This is similar to the input and output direction for stateless firewall filters.

The match direction can also depend on the network topology. For example, you might route all the external traffic through one interface that is used to protect the other interfaces on the router, and configure various services on this interface specifically. Alternatively, you might use one interface for priority traffic and configure special services on it, but not care about protecting traffic on the other interfaces.

Next-Hop Style Service Sets

Packet direction is determined by the AS PIC interface used to route packets to the AS PIC. If you use the inside-interface statement to route traffic, then the packet direction is input. If you use the outside-interface statement to direct packets to the AS PIC, then the packet direction is output.

The interface to which you apply the service sets affects the match direction. For example, apply the following configuration:

If you configure match-direction input, you include the following statements:

If you configure match-direction output, you include the following statements:

The essential difference between the two configurations is the change in the match direction and the static routes’ next hop, pointing to either the AS PIC's inside or outside interface.

Configuring Service Set Limitations

You can set the following limitations on service set capacity:

  • You can limit the maximum number of flows allowed per service set. To configure the maximum value, include the max-flows statement at the [edit services service-set service-set-name] hierarchy level:

    The max-flows statement permits you to assign a single flow limit value. For IDS service sets only, you can specify various types of flow limits with a finer degree of control. For more information, see the description of the session-limit statement in Configuring IDS Rule Sets on an MS-DPC.

    Note:

    When an aggregated multiservices (AMS) interface is configured as the service interface for a service set, the max-flow value configured for the service set is applied to each of the member interfaces in the AMS interface. That is, if you have configured 1000 as the max-flow value for a service set that uses an AMS interface with four active member interfaces, each of the member interfaces can handle 1000 flows each, resulting in an effective max-flow value of 4000.

  • You can limit the maximum segment size (MSS) allowed by the Transmission Control Protocol (TCP). To configure the maximum value, include the tcp-mss statement at the [edit services service-set service-set-name] hierarchy level:

    The TCP protocol negotiates an MSS value during session connection establishment between two peers. The MSS value negotiated is primarily based on the MTU of the interfaces to which the communicating peers are directly connected to. However in the network, due to variation in link MTU on the path taken by the TCP packets, some packets that are still well within the MSS value may be fragmented when the concerned packet's size exceeds the link's MTU.

    If the router receives a TCP packet with the SYN bit and MSS option set and the MSS option specified in the packet is larger than the MSS value specified by the tcp-mss statement, the router replaces the MSS value in the packet with the lower value specified by the tcp-mss statement. The range for the tcp-mss mss-value parameter is from 536 through 65535.

    To view statistics of SYN packets received and SYN packets whose MSS value, is modified, issue the show services service-sets statistics tcp-mss operational mode command. For more information on this topic, see the Junos OS Administration Library.

  • Starting in Junos OS Release 17.1R1, you can limit the session setup rate per service set for an MS-MPC. To configure the maximum setup rate allowed, include the max-session-setup-rate statement at the [edit services service-set service-set-name] hierarchy level:

    The maximum session setup rate is the maximum number of session setups allowed per second. After this rate is reached, any additional session setup attempts are dropped.

    The range for the max-session-setup-rate number is 1 through 429,496,729. You can also express the setup rate as thousands of sessions by using numberk. Starting in Junos OS Release 18.4R1, 1k=1000 for the max-session-setup-rate. Prior to Junos OS Release 18.4R1, 1k=1024. If you do not include the max-session-setup-rate statement, the session setup rate is not limited.

Example: Configuring Service Sets

Apply two service sets, my-input-service-set and my-output-service-set, on an interface-wide basis. All traffic has my-input-service-set applied to it. After the service set is applied, additional filtering is done using my_post_service_input_filter.

Configuring Service Interface Pools

To configure a service interface pool, include the following statements at the [edit services service-interface-pools] hierarchy level:

Enabling Services PICs to Accept Multicast Traffic

To allow multicast traffic to be sent to the Adaptive Services or Multiservices PIC, include the allow-multicast statement at the [edit services service-set service-set-name] hierarchy level. If this statement is not included, multicast traffic is dropped by default. This statement applies only to multicast traffic using a next-hop service set; interface service set configuration is not supported. Only unidirectional flows are created for multicast packets.

Applying Filters and Services to Interfaces

When you have defined and grouped the service rules by configuring the service-set definition, you can apply services to one or more interfaces on the router. To associate a defined service set with an interface, include the service-set statement with the input or output statement at the [edit interfaces interface-name unit logical-unit-number family inet service] hierarchy level:

Note:

When you enable services on an interface, reverse-path forwarding is not supported. You cannot configure services on the management interface (fxp0) or the loopback interface (lo0).

You can configure different service sets on the input and output sides of the interface. However, for service sets with bidirectional service rules, you must include the same service set definition in both the input and output statements. Any service set you include in the service statement must be configured with the interface-service statement at the [edit services service-set service-set-name] hierarchy level; for more information, see Configuring Service Sets to be Applied to Services Interfaces.

Note:

If you configure an interface with an input firewall filter that includes a reject action and with a service set that includes stateful firewall rules, the router executes the input firewall filter before the stateful firewall rules are run on the packet. As a result, when the Packet Forwarding Engine sends an Internet Control Message Protocol (ICMP) error message out through the interface, the stateful firewall rules might drop the packet because it was not seen in the input direction.

Possible workarounds are to include a forwarding-table filter to perform the reject action, because this type of filter is executed after the stateful firewall in the input direction, or to include an output service filter to prevent the locally generated ICMP packets from going to the stateful firewall service.

Configuring Service Filters

You can optionally include filters associated with each service set to refine the target and additionally process the traffic. If you include the service-set statement without a service-filter definition, the router software assumes that the match condition is true and selects the service set for processing automatically.

To configure service filters, include the firewall statement at the [edit] hierarchy level:

Note:

You must specify inet as the address family to configure a service filter.

You configure service filters in a similar way to firewall filters. Service filters have the same match conditions as firewall filters, but the following specific actions:

  • count—Add the packet to a counter total.

  • log—Log the packet.

  • port-mirror—Port-mirror the packet.

  • sample—Sample the packet.

  • service—Forward the packet for service processing.

  • skip—Omit the packet from service processing.

For more information about configuring firewall filters, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide.

You can also include more than one service set definition on each side of the interface. If you include multiple service sets, the router software evaluates them in the order specified in the configuration. It executes the first service set for which it finds a match in the service filter and ignores the subsequent definitions.

An additional statement allows you to specify a filter for processing the traffic after the input service set is executed. To configure this type of filter, include the post-service-filter statement at the [edit interfaces interface-name unit logical-unit-number family inet service input] hierarchy level:

Note:

The software performs postservice filtering only when it has selected and executed a service set. If the traffic does not meet the match criteria for any of the configured service sets, the postservice filter is ignored. The post-service-filter statement is not supported when the service interface is on an MS-MIC or MS-MPC.

For an example of applying a service set to an interface, see Examples: Configuring Services Interfaces.

For more information on applying filters to interfaces, see the Junos OS Network Interfaces Library for Routing Devices. For general information on filters, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide.

Note:

After NAT processing is applied to packets, they are not subject to output service filters. The service filters affect only untranslated traffic.

Examples: Configuring Services Interfaces

Apply the my-service-set service set on an interface-wide basis. All traffic that is accepted by my_input_filter has my-input-service-set applied to it. After the service set is applied, additional filtering is done using the my_post_service_input_filter filter.

Configure two redundancy interfaces, rsp0 and rsp1, and associated services.

Configuring the Address and Domain for Services Interfaces

On the AS or Multiservices PIC, you configure a source address for system log messages by including the address statement at the [edit interfaces interface-name unit logical-unit-number family inet] hierarchy level:

Assign an IP address to the interface by configuring the address value. The AS or Multiservices PIC generally supports only IP version 4 (IPv4) addresses configured using the family inet statement, but IPsec services support IP version 6 (IPv6) addresses as well, configured using the family inet6 statement.

Note:

If you configure the same address on multiple interfaces in the same routing instance, Junos OS uses only the first configuration, the remaining address configurations are ignored and can leave interfaces without an address. Interfaces that do not have an assigned address cannot be used as a donor interface for an unnumbered Ethernet interface.

For example, in the following configuration the address configuration of interface xe-0/0/1.0 is ignored:

For more information on configuring the same address on multiple interfaces, see Configuring the Interface Address.

For information on other addressing properties you can configure that are not specific to service interfaces, see the Junos OS Network Interfaces Library for Routing Devices.

The service-domain statement specifies whether the interface is used within the network or to communicate with remote devices. The software uses this setting to determine which default stateful firewall rules to apply, and to determine the default direction for service rules. To configure the domain, include the service-domain statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level:

If you are configuring the interface in a next-hop service-set definition, the service-domain setting must match the configuration for the inside-service-interface and outside-service-interface statements; for more information, see Configuring Service Sets to be Applied to Services Interfaces.

Configuring System Logging for Service Sets

You specify properties that control how system log messages are generated for the service set. These values override the values configured at the [edit interfaces interface-name services-options] hierarchy level.

To configure service-set-specific system logging values, include the syslog statement at the [edit services service-set service-set-name] hierarchy level:

Configure the host statement with a hostname or an IP address that specifies the system log target server. The hostname local directs system log messages to the Routing Engine. For external system log servers, the hostname must be reachable from the same routing instance to which the initial data packet (that triggered session establishment) is delivered. You can specify only one system logging hostname. The source-address parameter is supported on the ms, rms, and mams interfaces.

Starting in Junos OS Release 17.4R1, you can configure up to a maximum of four system log servers (combination of local system log hosts and remote system log collectors) for each service set under [edit services service-set service-set-name] hierarchy level.

Note:

Junos OS does not support the exporting of system log messages to an external system log server through the fxp.0 interface; this is because the high transmission rate of system log messages and the limited bandwidth of the fxp.0 interface can cause several problems. The external system log server must be reachable through a routable interface.

Table 1 lists the severity levels that you can specify in configuration statements at the [edit services service-set service-set-name syslog host hostname] hierarchy level. The levels from emergency through info are in order from highest severity (greatest effect on functioning) to lowest.

Table 1: System Log Message Severity Levels

Severity Level

Description

any

Includes all severity levels

emergency

System panic or other condition that causes the router to stop functioning

alert

Conditions that require immediate correction, such as a corrupted system database

critical

Critical conditions, such as hard drive errors

error

Error conditions that generally have less serious consequences than errors in the emergency, alert, and critical levels

warning

Conditions that warrant monitoring

notice

Conditions that are not errors but might warrant special handling

info

Events or non-error conditions of interest

We recommend setting the system logging severity level to error during normal operation. To monitor PIC resource usage, set the level to warning. To gather information about an intrusion attack when an intrusion detection system error is detected, set the level to notice for a specific service set. To debug a configuration or log NAT functionality, set the level to info.

For more information about system log messages, see the System Log Explorer.

To select the class of messages to be logged to the specified system log host, include the class statement at the [edit services service-set service-set-name syslog host hostname] hierarchy level:

To use one particular facility code for all logging to the specified system log host, include the facility-override statement at the [edit services service-set service-set-name syslog host hostname] hierarchy level:

The supported facilities are: authorization, daemon, ftp, kernel, user, and local0 through local7.

To specify a text prefix for all logging to this system log host, include the log-prefix statement at the [edit services service-set service-set-name syslog host hostname] hierarchy level:

Configuring Service Rules

You specify the collection of rules and rule sets that constitute the service set. The router performs rule sets in the order in which they appear in the configuration. You can include only one rule set for each service type. You configure the rule names and content for each service type at the [edit services name] hierarchy level for each type:

To configure the rules and rule sets that constitute a service set, include the following statements at the [edit services service-set service-set-name] hierarchy level:

For each service type, you can include one or more individual rules, or one rule set.

If you configure a service set with IPsec rules, it must not contain rules for any other services. You can, however, configure another service set containing rules for the other services and apply both service sets to the same interface.

Note:

You can also include Junos Application Aware (previously known as Dynamic Application Awareness) functionality within service sets. To do this, you must include an idp-profile statement at the [edit services service-set] hierarchy level, along with application identification (APPID) rules, and, as appropriate, application-aware access list (AACL) rules and a policy-decision-statistics-profile. Only one service sets can be applied to a single interface when Junos Application Aware functionality is used. For more information, see Configuring IDS Rules on an MS-DPC, APPID Overview, and Application Aware Services Interfaces User Guide for Routing Devices.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
18.4R1
Starting in Junos OS Release 18.4R1, 1k=1000 for the max-session-setup-rate.
17.1R1
Starting in Junos OS Release 17.1R1, you can limit the session setup rate per service set for an MS-MPC.