Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Selective Class-based Filtering on PTX Routers


Selective Class-based Filtering on PTX Routers

For supported PTX Series routers and line cards, you can filter IPv4 and IPv6 traffic based on the source or destination classification (Source Class Usage, SCU) and (Destination Class Usage, DCU). This is useful because it means you can apply a filter selectively, on a subset of packets in a class, rather than all packets in the class. In addition, the packet flow through the packet forwarding engine (PFE) is optimized, and the filtering is more efficient.

For service providers, class-based filtering allows you to provide advanced services such as:

  • Per-hop behavior manipulation by adjusting the forwarding class of the packet based on the source or destination packet class and other filter criteria.

  • Traffic rate limiting towards certain customer interfaces, with high volume of traffic to drop (for example, under DDoS attack). Normally, you would deploy an outgoing interface filter to rate limit the traffic. However, this may be inefficient because traffic still crosses the fabric in distributed systems and consumes limited fabric bandwidth. The inefficiency becomes even more visible in a Virtual Output Queueing system, like PTX, where admission into the egress queue is happening before the output filter is executed and any subsequent drop action in the output filter requires compensation – more traffic needs to be admitted into the queue, which requires more fabric bandwidth and more egress on-chip buffer space (which is a limited resource). Class-based filters are executed in the ingress pipeline before admission of the packets into the egress queue. This mechanism is recommended over regular output interface filters, if you expect to drop large volumes of traffic towards certain destinations.

Class-based filtering is also effective for "low-and-slow" DoS attacks that target application and server resources by mimicking normal traffic patterns.

To support class-based filtering, two new bind points are introduced at the forwarding table for PTX routers: source-class and destination-class.

The CLI hierarchy is shown here, where src-class-name or dest-class-name is the name of the filter you defined in the corresponding policy.

You can also configure instance-specific filters across multiple SCU and DCU classes. By default, only one set of counters and policers is instantiated for a filter. In the instance-specific filter, separate set of counters and policers is created for each filter attach point.

Understanding Class-based Filtering on PTX Routers

Initially, Source Class Usage (SCU) feature was introduced to provide statistics breakdown of traffic sent towards specific interface per originating prefix (identified by the source class). Destination Class Usage (DCU) was originally introduced to provide statistics breakdown of traffic received on an interface per destination prefix (identified by the destination class).

Both source or destination classes are assigned to the packet in the source or destination lookup process. Therefore, source and destination filter match conditions can be evaluated only if the filter is executed after the lookup.

Juniper routers support multiple filter bind points, those that may leverage the result of the source and destination classification are listed below, with usage guidelines:

  • Output interface filter (set interfaces <interface name> family inet filter <output>. Supported on any PTX platform, but not recommended if it is expected to discard large volumes of traffic in a steady state (for example, when implementing a DDoS attack mitigation filter). Discarded DDoS attack traffic may not be compensated by other traffic not matching DDoS attack criteria due to limited fabric bandwidth and limited egress on-chip buffer space.

  • Filter after forwarding table filter lookup (set forwarding-options family inet filter <filter-name> output). Supported on Express 2 (PE) and Express 3 (ZX) platforms. However, the filters are instantiated in the egress pipeline, therefore the discard behavior is similar to the regular output interface filter.

  • Source or destination class specific bind point (set routing-options forwarding-table source-class src-class-name family [inet | inet6] filter <filter- name>). Supported on Express 2 (PE), Express 3 (ZX) and Express 4 (BT) platforms. This filter is instantiated in the ingress pipeline. This is the recommended option to discard large volumes of traffic. This option is also recommended if you need to override forwarding class and subsequently output queue assignment. In a Virtual Output Queueing system, queue is selected in the ingress pipeline and any override must happen in the ingress pipeline too.

  • Note, these filter actions are not supported in the filter bound to the source or destination class specific bind point:

    • routing-instance

    • next-ip

    • next-interface

    • decapsulate

    • encapsulate

  • Selective class-based filters cannot be applied on host-bound packets.

  • Packets which fail uRPF lookups, but are restored by uRPF fail-filters are not subject to SCU/DCU lookups. Hence, selective class-based filters cannot be applied on such packets.

  • Filters are applied only to packets ingressing on interfaces which have SCU/DCU feature enabled. This means filters would be applied irrespective of whether SCU is configured on output interfaces or not.

  • Packets for which selective class-based filter needs to be applied may cause drop in performance. Performance drop would be function of rate of incoming traffic, average packets size, and amount of traffic subjected to the filters. However, packets on which selective class-based filters are not applied, do not affect performance.

  • DCU accounting is applicable for packets dropped by filters.

  • SCU output accounting is not applicable for packets dropped by filters.

  • Selective class-based filters cannot be used with interface-specific knob because this knob is only applicable to interface-attached filters.

  • Lists (input/output lists) of selective class-based filters are not supported.

  • Logical systems are not supported.

  • Only IPv4 and IPv6 are the supported payload protocols. MPLS is not supported.

  • If a packet matches both SCU and DCU selective class-based filters then only the last filter (i.e., DCU filter) is applied to the packet and but not both filters.

Example: Selective Class Based Filtering (PTX Routers)

This example shows how to apply firewall actions (discard, reject, or police) to IPv4 and IPv6 traffic flows on the basis of source or destination classification. It applies to PTX10001-36MR, PTX10003-160C, PTX10003-80C, PTX10004, and PTX10008 routers running Junos Evolved OS release 21.2, PTX10016 routers running JUNOS Evolved OS release 21.4, or PTX3000, PTX-5000, PTX1000, PTX10002, PTX10008, PTX10016 routers running Junos OS release 21.2 or later software.


This example uses BGP because BGP can be used to exchange routes between devices in a network topology consisting of customer edge, provider edge, and provider routers. Refer BGP Configuration Overview to read more.


This example uses three routing devices: a customer edge (CE) device, a provider edge (PE) device, and a provider core (P) device. The configuration for IPv4 traffic is shown, and includes two sets of SCU and DCU classes, plus the firewall filters. In the following figure, the /32 IP prefixes represent hosts connected to the customer edge (CE) and provider (P) routers respectively.

Figure 1: Sample NetworkSample Network

In this example, we define two classes of traffic: scu-1 and scu-2, the first one is assigned to prefixes in the subnet and the second one is assigned to prefixes in the subnet Other prefixes do not have any class assignments. As shown in the following CLI snippet, routing policy is defined on the PE router to assign prefixes to source-class scu-1 and source-class scu-2.

To account for traffic ingressing PE's interfaces from CE, the policy called dcu-class defined on the PE router uses route filters to place traffic into dcu-1, other prefixes have no class assignments.

The policies are then applied to the forwarding table.

In the next step we configure a filter on the PE router.

And attach that filter to the specific source and destination class bind points on the PE router.



CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI.

The example uses static routes to provide connectivity and loopback interface addresses for testing the operation.

Device CE

Device PE

Device P

Step-by-Step Procedure

To group source and destination prefixes in a forwarding class:

  1. Create the router interfaces on the PE router.

  2. Configure BGP on PE router.

  3. Configure the autonomous system (AS) number of the PE router.

  4. Configure the DCU policy on the PE router.

  5. Configure the SCU policy on the PE router.

  6. Apply the policies to the forwarding table on the PE router.

  7. Create the filter on the PE router.

  8. Bind the filter to the source class and destination class bind points on the PE router.

    Binding the filter to destination class usage.

    Binding the filter to source class usage.

  9. (Optional) Configure a routing policy that advertises direct routes on the PE router.


From configuration mode , confirm your configuration by issuing the show interfaces, show protocols, show policy-options, and show routing-options commands on the PE router. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.