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.

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.

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.

• Requirements
• Overview
• Configuration

Overview

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 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 172.16.2.0/24 and the second one is assigned to prefixes in the subnet 172.16.3.0/24. 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.