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:
[edit services] service-set service-set-name { (ids-rules rule-names | ids-rule-sets rule-set-name); (ipsec-vpn-rules rule-names | ipsec-vpn-rule-sets rule-set-name); max-session-setup-rate max-setup-rate; (nat-rules rule-names | nat-rule-sets rule-set-name); (pgcp-rules rule-names | pgcp-rule-sets rule-set-name); (ptsp-rules rule-names | ptsp-rule-sets rule-set-name); (stateful-firewall-rules rule-names | stateful-firewall-rule-sets rule-set-name); allow-multicast; extension-service service-name { provider-specific rules; } interface-service { service-interface interface-name; } ipsec-vpn-options { anti-replay-window-size bits; clear-dont-fragment-bit; ike-access-profile profile-name; local-gateway address; no-anti-replay; passive-mode-tunneling; trusted-ca [ ca-profile-names ]; tunnel-mtu bytes; } max-flows number; next-hop-service { inside-service-interface interface-name.unit-number; outside-service-interface interface-name.unit-number; service-interface-pool name; } syslog { host hostname { services severity-level; facility-override facility-name; log-prefix prefix-value; } } } adaptive-services-pics { traceoptions { file filename <files number> <match regex> <size size> <(world-readable | no-world-readable)>; flag flag; } } logging { traceoptions { file filename <files number> <match regex> <size size> <(world-readable | no-world-readable)>; flag flag; } }
See Also
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:
[edit services service-set service-set-name] interface-service { service-interface interface-name; }
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:
[edit interfaces interface-name unit logical-unit-number family inet service]
input {
service-set service-set-name <service-filter filter-name>;
post-service-filter filter-name;
}
output {
service-set service-set-name <service-filter filter-name>;
}
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.
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:
post-service-filter filter-name;
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.
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.
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).
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:
service-domain (inside | outside);
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.
next-hop-service { inside-service-interface interface-name.unit-number; outside-service-interface interface-name.unit-number; }
Traffic on which the service is applied is forced to the inside interface using a static route. For example:
routing-options {
static {
route 10.1.2.3 next-hop sp-1/1/0.1;
}
}
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:
To associate the two parts with logical interfaces, you configure two logical interfaces with the
service-domainstatement, one with theinsidevalue and one with theoutsidevalue, to mark them as either an inside or outside service interface.The router forwards the traffic to be serviced to the inside interface, using the next-hop lookup table.
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.
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:
sp-1/1/0 unit 1 service-domain inside; sp-1/1/0 unit 2 service-domain outside;
If you configure match-direction input, you include
the following statements:
[edit] services service-set test1 next-hop-service inside-service-interface sp-1/0/0.1; services service-set test1 next-hop-service outside-service-interface sp-1/0/0.2; services ipsec-vpn rule test-ipsec-rule match-direction input; routing-options static route 10.0.0.0/24 next-hop sp-1/1/0.1;
If you configure match-direction output, you include
the following statements:
[edit] services service-set test2 next-hop-service inside-service-interface sp-1/0/0.1; services service-set test2 next-hop-service outside-service-interface sp-1/0/0.2; services ipsec-vpn rule test-ipsec-rule match-direction output; routing-options static route 10.0.0.0/24 next-hop sp-1/1/0.2;
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.
See Also
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-flowsstatement at the[edit services service-set service-set-name]hierarchy level:[edit services service-set service-set-name] max-flows number;
The
max-flowsstatement 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 thesession-limitstatement 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-flowvalue 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 themax-flowvalue 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 effectivemax-flowvalue 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-mssstatement at the[edit services service-set service-set-name]hierarchy level:[edit services service-set service-set-name] tcp-mss number;
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-mssstatement, the router replaces the MSS value in the packet with the lower value specified by thetcp-mssstatement. The range for thetcp-mss mss-valueparameter 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-mssoperational 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-ratestatement at the[edit services service-set service-set-name]hierarchy level:[edit services service-set service-set-name] max-session-setup-rate (number | numberk);
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-ratenumber 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 themax-session-setup-rate. Prior to Junos OS Release 18.4R1, 1k=1024. If you do not include themax-session-setup-ratestatement, the session setup rate is not limited.
See Also
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.
[edit interfaces fe-0/1/0]
unit 0 {
family inet {
service {
input {
service-set my-input-service-set;
post-service-filter my_post_service_input_filter;
}
output {
service-set my-output-service-set;
}
}
}
}
Configuring Service Interface Pools
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.
See Also
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:
[edit interfaces interface-name unit logical-unit-number family inet service] input { service-set service-set-name <service-filter filter-name>; post-service-filter filter-name; } output { service-set service-set-name <service-filter filter-name>; }
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.
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:
firewall {
family inet {
service-filter filter-name {
term term-name {
from {
match-conditions;
}
then {
action;
action-modifiers;
}
}
}
}
}
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:
post-service-filter filter-name;
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.
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.
[edit interfaces fe-0/1/0]
unit 0 {
family inet {
filter {
input my_input_filter;
output my_output_filter;
}
service {
input {
service-set my-input-service-set;
post-service-filter my_post_service_input_filter;
}
output {
service-set my-output-service-set;
}
}
}
}
Configure two redundancy interfaces, rsp0 and rsp1, and associated services.
[edit interfaces]
rsp0 {
redundancy-options {
primary sp-0/0/0;
secondary sp-1/3/0;
}
unit 0 {
family inet;
}
unit 30 {
family inet;
service-domain inside;
}
unit 31 {
family inet;
service-domain outside;
}
}
rsp1 {
redundancy-options {
primary sp-0/1/0;
secondary sp-1/3/0;
}
unit 0 {
family inet;
}
unit 20 {
family inet;
service-domain inside;
}
unit 21 {
family inet;
service-domain outside;
}
}
[edit services]
service-set null-sfw-with-nat {
stateful-firewall-rules allow-all;
nat-rules rule1;
next-hop-service {
inside-service-interface rsp0.30;
outside-service-interface rsp0.31;
}
}
[edit routing-instances]
vpna {
interface rsp0.0;
}
See Also
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:
address address { ... }
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.
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:
interfaces {
xe-0/0/0 {
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
xe-0/0/1 {
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
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:
service-domain (inside | outside);
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.
See Also
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:
syslog { host hostname { class class-name facility-override facility-name; log-prefix prefix-value; port port-number services severity-level; source-address source-address } }
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.
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.
Severity Level |
Description |
|---|---|
|
Includes all severity levels |
|
System panic or other condition that causes the router to stop functioning |
|
Conditions that require immediate correction, such as a corrupted system database |
|
Critical conditions, such as hard drive errors |
|
Error conditions that generally have less serious consequences than errors in the emergency, alert, and critical levels |
|
Conditions that warrant monitoring |
|
Conditions that are not errors but might warrant special handling |
|
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:
class class-name;
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:
facility-override facility-name;
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:
log-prefix prefix-value;
See Also
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:
You configure intrusion detection service (IDS) rules at the
[edit services ids]hierarchy level; for more information, see Configuring IDS Rules on an MS-DPC for MS-DPC cards and Configuring Protection Against Network Attacks on an MS-MPC for MS-MPC cards.You configure IP Security (IPsec) rules at the
[edit services ipsec-vpn]hierarchy level; for more information, see Understanding Junos VPN Site Secure..You configure Network Address Translation (NAT) rules at the
[edit services nat]hierarchy level; for more information, see Junos Address Aware Network Addressing Overview..You configure packet-triggered subscribers and policy control (PTSP) rules at the
[edit services ptsp]hierarchy level; for more information, see Configuring PTSP Service Rules.You configure softwire rules for DS-Lite or 6rd softwires at the
[edit services softwire]hierarchy level; for more information, see Configuring Softwire Rules.You configure stateful firewall rules at the
[edit services stateful-firewall]hierarchy level; for more information, see Configuring Stateful Firewall Rules.
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:
([ ids-rules rule-names ] |ids-rule-sets rule-set-name); ([ ipsec-vpn-rules rule-names ] | ipsec-vpn-rule-sets rule-set-name); ([ nat-rules rule-names ] | nat-rule-sets rule-set-name); ([ pgcp-rules rule-names] | pgcp-rule-sets rule-set-name); ([softwire-rules rule-names] | softwire-rule-sets rule-set-name); ([ stateful-firewall-rules rule-names ] | stateful-firewall-rule-sets rule-set-name);
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.
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.
max-session-setup-rate.