You create a service set definition in your configuration that indicates whether the service set is next-hop style, interface style, or sampling style, as well as which Multiservices PIC the service set should be applied to. Your configuration extends the edit services service-set hierarchy level in the CLI configuration. You define the actions for your own service sets under the extension-service hierarchy in your configuration DDL. The system does not parse this hierarchy.
Using plugins, you can chain services in any order you configure. For details, see Plugin Configuration.
ge-0/0/0.0). After applying the service set, packets can be reinjected back to the packet forwarding engine for regular forwarding.The interface-style hierarchy is defined as follows:
services {
service-set <service-set-name> {
extension-service <service-name> {
<customer-specific-rules>;
}
}
// Existing hierarchy
interface-service { // Indicates the interface style
service-interface {
ms-x/y/0.0; // Specifies which Multiservices PIC to load this
// policy on.
}
}
}
}
This service-set can be attached to any media interface with family inet. For example:
interfaces { // Existing hierarchy
ge-0/0/0 {
unit 0 {
family inet {
service {
input {
service-set sset1; // Attach service set
}
output {
service-set sset1; // To output as well.
}
}
}
}
}
}
The hierarchy for next-hop-style services looks like this:
services {
service-set sset1 {
extension-service <service-name> {
<customer-specific-rules-here>;
}
}
// Existing hierarchy
next-hop-service { // Indicates a nexthop-style service
inside-service-interface ms-1/2/0.1; // More on this follows
outside-service-interface ms-1/2/0.2;
}
}
}
This service set cannot be attached to an interface; instead, the administrator adds two routes to direct traffic to the Multiservices PIC:
inet0, route 100.100.100.0/24 directs traffic to ms-1/2/0.1. The media interface ge-1/0/1.0 is also configured in inet0.vrf1, the default route directs traffic to ms-1/2/0.2. The media interface ge-1/0/1.1 is also configured in vrf1.
ms- subunits that inject traffic from the external network. You must ensure that these VRFs are configured; otherwise, the PIC will stop passing traffic because it will bounce all packets back to the Packet Forwarding Engine.For additional details on configuring traffic sampling for SDK applications, see Sampling Traffic in SDK Applications, under Guidelines for Configuring SDK Applications in the SDK CLI Configuration section of this documentation. For information about sampling using the native JUNOS software, see the JUNOS Policy Framework Configuration Guide and the JUNOS Services Interfaces Configuration Guide.
Configuring sampling involves the following tasks:
sample action. The following configuration creates firewall filter to sample all ICMP-based transit traffic.
[edit firewall]
filter foo {
from {
protocol icmp;
}
then {
sample;
accept;
}
}
\verbatim
\subsection firewall-attach Attaching the Firewall Filter to an INGRESS Interface
The firewall filter must be attached to an interface that receives
\c INGRESS traffic. For example, the following configuration specifies that any \c INGRESS \c ICMP traffic to interface
<code>fe-1/0/0.0</code> should be sampled and sent to <code>ms-6/1/0</code>:
\verbatim
[edit interface fe-1/0/0 unit 0 family inet]
filter {
input foo;
}
You can configure the sampling service set without configuring the sampling to send the traffic to the ms- interface. However, if you do this, the ms- interface does not receive any sampled traffic, and the sampling service set associated with that ms- interface has no effect.
ms- interface should be serviced by plugin1 and plugin2. The service-order section specifies the order in which the plugins service the sampled packets.
[edit services]
service-set ssetX {
sampling-service {
service-interface ms-6/1/0.0;
}
extension-service plugin1;
extension-service plugin2;
service-order {
forward-flow [ plugin1 plugin2 ];
reverse-flow [ plugin1 plugin 2];
}
}
The service interface must be a Multiservices PIC interface with subunit number 0. If the subunit is not specified, subunit 0 is assumed.
Unlike interface style service sets, it is not mandatory to configure a reverse-flow knob; you need to configure a reverse flow only if the services implemented in the plugins need one to be created for the sampled traffic (for example, passive IDP requires a reverse flow.) If you do not specify a reverse flow, all the sampled traffic is treated as forward traffic.
For traffic monitoring, you must specify sending the sampled traffic to the PIC associated with the monitoring service set. For example, the following sampling configuration instructs the Packet Forwarding Engine to forward a duplicate copy of every packet to ms-6/1/0.0 .
[edit forwarding-options]
sampling {
input {
family inet {
rate 1;
}
}
output {
interface ms-6/1/0.0
}
}
The system supports multiple sampling destinations (as many as the PFEs in the chassis), with multiple protocol families supported for each sampling destination. The complete configuration syntax for sampling is as follows:
[edit forwarding-options]#
sampling {
input {
rate <>; # common input parameters for all families
run-length <>;# in the global instance
}
family (inet | inet6 | mpls) { # current global instance
output {
flow-server <> {
version <9> template <template-name>;
version <5> <extension>; # for V500 support
}
interface sp-0/2/0.0 {
source-address <>;
}
}
}
instance samp1 { # named instances of sampling parameters
input { # common input parameters for all families of this instance
rate <>;
run-length <>;
}
family (inet | inet6 | mpls) {
output {
interface [next-hop];
flow-server <> {;
version <9> template <template-name>;
version <5> <extension>; # for V500 support
}
}
} # family
} # instance samp1
...
} # sampling
You can also configure port mirroring with the mirror-once option, as follows:
[edit forwarding-options]#
sampling {
+ mirror-once; # mirror only once
...
}
This is the only option currently supported.
For more information about configuring port mirroring under family vpls and family bridge in JUNOS, see the JUNOS® Software MX-Series Layer 2 Configuration Guide in your JUNOS software documentation set.
service-set-name --> { unique-global-id per service set,
next-hop index for the incoming direction
next-hop index for the outgoing direction.
}
After receiving this information, your management daemon combines it with the policy information it has already parsed and sends the information to the Multiservices PIC using the libconn functions. (For more information on libconn, see IP Socket-Based Inter-Process Communication.)
On the Multiservices PIC, policies can be set up in shared memory to map the service set ID to the service set name, policy list, type of service set, and interface name.
The service set ID is encoded in the packet cookie for interface-style service sets. After your data daemon looks up a policy based on this ID, the daemon can forward packets back to the forwarding plane using libmp-sdk functions (see Using the Services SDK Data Handling Functions).
For next-hop-style services, the service set parsing is the same. However, there are the following differences in installation:
subunit_number --> service-set-id --> policies
In the example, on PIC ms-1/2/0:
subunit_0 --> sset1 --> policies (inside)
subunit_1 --> sset1 --> policies (outside)
ms-1/2/0.1 are reinjected back on ms-1/2/0.2 after application processing.
ms-1/2/0.2 are reinjected back on ms-1/2/0.1.