Tải bản đầy đủ - 0 (trang)
Chapter 3. Stateless Filters, Hierarchical Policing, and Tri-Color Marking

Chapter 3. Stateless Filters, Hierarchical Policing, and Tri-Color Marking

Tải bản đầy đủ - 0trang

queuing and packet rewrite operations, or directing the traffic to a specific routing

instance where it can be forwarded differently than nonmatching traffic to achieve what

is known as Filter-Based Forwarding (FBF) in Junos, a concept akin to Policy-Based

Routing (PBR) in other vendors’ equipment.

Policers are used to meter and mark traffic in accordance to bandwidth and burst size

settings. Policing at the edge enforces bandwidth-related SLAs and is a critical aspect

of Differentiated Services (DS) when supporting real-time or high-priority traffic, as

this is the primary mechanism to ensure that excess traffic cannot starve conforming

traffic that is scheduled at a lower priority. In addition to discard actions, policers can

mark (or color) out of conformance traffic, or alter its classification to place it into a

new forwarding class.

Those familiar with the IOS way of doing things quickly recognize that stateless Junos

filters provide functionality that is similar to Access Control Lists (ACLs), whereas

policers provide rate enforcement through a mechanism that is similar to Committed

Access Rate (CAR).

Stateless versus Stateful

Filters are categorized as being stateful or stateless based on whether they maintain

connection or flow state tables versus simply treating each packet in a flow in a standalone manner. As with all things on Earth, there are advantages and disadvantages to

both forms of filtering.


As the name implies, a stateless filter does not maintain flow state or packet context

beyond that of a single packet. There is no flow table, or, for that matter, no concept

of a flow (with a flow being defined by some tuple such as Source Address, Destination

Address, Protocol, and Ports). The upside is relatively low cost and raw performance,

at near wire rate for all but the most complex of filter statements. All MX routers can

perform stateless firewall functionality with no additional hardware or licenses needed.

The downside to a stateless filter is you have to either allow or deny a given packet, and

the decision must be based solely on the information carried in the packet being processed. For example, if you expect to perform ping testing from your router, you will

have to allow inbound ICMP Echo Reply packets in your filter. While you can place

additional constraints on the allowed ICMP response, such as a specific source and

destination addresses, whether fragmented packet replies are allowed, or the specific

ICMP type, you still have to open a hole in the stateless filter for the expected reply

traffic, and this hole remains open whether or not you have recently generated any


154 | Chapter 3: Stateless Filters, Hierarchical Policing, and Tri-Color Marking



A stateful firewall (SFW) tracks session state and is capable of matching specific protocols requests to a corresponding reply. For example, it allows ICMP replies, but only

when in response to a recently sent packet such as an ICMP echo request (ping). Rather

than always allowing incoming ICMP echo replies, a SFW’s flow table is dynamically

created when an allowed outbound ICMP echo reply is detected, which begins a timer

during which the response to that flow is permitted.

The added flow state allows for more sophisticated capabilities such as subjecting certain packets to additional scrutiny, a process known as Deep Packet Inspection, or by

recognizing threats based on general anomaly detection or specific attack signatures,

based on analyzing multiple packets in the context of a flow, something a stateless

firewall can never do.

But, alas, nothing comes for free. An SFW is a high-touch device that requires a significant amount of RAM to house its flow tables, and processing power to plow through

all those tables, which can easily become a performance bottleneck when taxed with

too many flows, or simply too high of a data rate on any individual flow.

Trio-based MPCs can provide in-line services such as NAT and port mirroring without

the need for additional hardware such as a services PIC. More demanding SFW and

services-related function require the MX router be equipped with a MS-DPC to provide

the hardware acceleration and flow state storage needed at scale.

SFW and related services like IPSec are beyond the scope of this book. However, the

good news is that as the MS-DPC and Trio are Junos based, in-line services are configured and monitored using pretty much the same syntax and commands as used on

the J-series Adaptive Service Module (ASM) or the M/T series Advanced Services PIC

(ASP)/Multi-Services PICs, both of which are covered in Junos Enterprise Routing, Second Edition, also published by O’Reilly.

This chapter focuses on MX router support for stateless firewall filtering. Unless otherwise stated, all references to filters in this chapter are assumed to be in the context of

a stateless filter.

Stateless Filter Components

Stateless filters can be broken down into five distinct components. These are filter types,

protocol families, terms, match criteria, and the actions to be performed on matching


Stateless Filter Types

The Junos OS supports three different types of stateless filters: stateless, service filters,

and simple filters. This chapter focuses on the stateless type because they are by far the

Firewall Filter and Policer Overview | 155


most commonly deployed. While a detailed review is outside the scope of this book, a

brief description of the other stateless filters types is provided for completeness.

Service Filter

A service filter is applied to logical interfaces that are configured on a services device

such as a MX router’s MS-DPC. The service filter is used to filter traffic prior to or

after it has been processed by the related service set. Service filters are defined at

the [dynamic-profiles firewall family servicefilter] hierarchy.

Simple Filter

Simple filters are available to provide some level of filtering support on FPCs that

use commercial off-the-shelf (COTS) TCAM for firewall structures, namely IQ2

PICs and the MX’s EQ-DPC, both of which are based on the EZChip. Simple filters

are defined at the [set firewall family inet simple-filter] hierarchy. There are

many restrictions to this type of filter because existing Junos match conditions were

deemed too demanding for a TCAM-based engine; combined with their support

on a limited and now long in the tooth hardware set, this explains why simple filters

are rarely used. The restrictions for simple filters on MX routers are many:

• Simple filters are not supported on Modular Port Concentrator (MPC) interfaces, including Enhanced Queuing MPC interfaces.

• Simple filters are not supported for interfaces in an aggregated Ethernet bundle.

• You can apply simple filters to family inet traffic only. No other protocol family is supported.

• You can apply simple filters to ingress traffic only. Egress traffic is not supported.

• You can apply only a single simple filter to a supported logical interface. Input

lists are not supported.

• On MX Series routers with the Enhanced Queuing DPC, simple filters do not

support the forwarding-class match condition.

• Simple filters support only one source address and one destination address

prefix for each filter term. If you configure multiple prefixes, only the last one

is used.

• Simple filters do not support negated match conditions, such as the protocolexcept match condition or the except keyword.

• Simple filters support a range of values for source and destination port match

conditions only. For example, you can configure source-port 400-500 or des

tination-port 600-700. With a conventional stateless filter you can match

ports as a range, or list, such as destination-port [ 20 73 90 ].

• Simple filters do not support noncontiguous mask values.

156 | Chapter 3: Stateless Filters, Hierarchical Policing, and Tri-Color Marking


Protocol Families

You configure a filter under one of several protocol families to specify the type of traffic

that is to be subjected to the filter. This action indirectly influences the possible match

types, given that some match types are only possible for specific protocols and certain

types of hardware. For example, a number of match conditions for VPLS traffic are

supported only on the MX Series 3D Universal Edge Routers. Table 3-1 lists the protocol families supported by Trio filters:

Table 3-1. Supported Protocol Families for Filtering.

Nature of Traffic

Protocol Family


Protocol Agnostic

family any

All protocol families configured on a logical interface.

Internet Protocol version 4


family inet

The family inet statement is optional for IPv4 as this is the default


Internet Protocol version 6


family inet6

Use for IPv6 traffic.

MPLS/ MPLS-tagged IPv4

family mpls

Use when matching fields in one or more MPLS labels. For MPLStagged IPV4 traffic, family supports matching on IP addresses and

ports in a stack of up to five MPLS labels with the ip-version

ipv4 keyword.

Virtual private LAN service


family vpls

Used to match VPLS traffic being tunneled over GRE or MPLS.

Layer 2 Circuit Cross-Connection

family ccc

Used for CCC style Layer 2 point-to-point connections.

Layer 2 Bridging

family bridge

Supported on MX Series routers only, used for bridged traffic.

Filter Terms

A firewall filter can contain one or many terms; at a minimum, at least one term must

be present. Each term normally consists of two parts: a set of match criteria specified

with a from keyword and a set of actions to be performed for matching traffic defined

with a then keyword.

Consider the following filter named tcp_out:

[edit firewall filter tcp_out]

regress@halfpint# show

term 1 {

from {

protocol tcp;

destination-port [ 23 21 20 ];


then {

count tcp_out;




Firewall Filter and Policer Overview | 157


term 2 {

then count other;


The tcp_out filter consists of two terms. The first term specifies a set of match conditions

as part of the from statement. It’s important to note that a logical AND is performed

for each distinct match within a term, which is to say that all of the conditions shown

on separate lines must be true for a match to be declared. In contrast, when you specify

multiple matches of the same type, for example a sequence or range of destination port

values, the grouping is shown on the same line in brackets and a logical OR function

is performed.

In this case, the filter first tests for the TCP protocol by looking for a 06 in the IP packet’s

protocol field (which is the protocol number assigned to TCP by IANA), and then for

either a 20, 21, or 23 in the destination port field. The nature of this type of match

implies that we have also located an IP protocol packet at Layer 3. In fact, there is no

protocol ip match option for an IPv4 filter; the IPv4 protocol is assumed by virtue of

the filter being of the inet family, which is the default when no protocol family is defined

within a firewall filter.

When a match is declared in the first term, the tcp_out counter is incremented and the

traffic is accepted with no additional filter processing. All non-TCP traffic and all TCP

traffic that does not have one of the specified destination ports will not match the first

term and therefore falls through to the second term.

Note that the first term has both a from condition and a then action, while the second

term only has a then action specified. The lack of a from condition is significant because

it means we have a term with no match criteria, which means all traffic of the associated

family will be deemed a match. In our example, this means that any IP-based traffic

that is not matched in the first term will match the final term, and as a result increments

the other counter.

This seems like a good place for the standard warning about including

a protocol match condition when you are also interested in matching

on a protocol field such as a port. Had the operator not included the

protocol tcp condition along with a port value in the telnet_out filter,

it would be possible to match against UDP, or other non-TCP protocols

such as ICMP, that just so happen to have the specified “port value” as

part of their header or payload. Always take the time to specify as complete a set of match criteria as possible to avoid unpredictable filter behavior that is often very hard to fault isolate.

The Implicit Deny-All Term. It must be stressed that stateless filters always end with an implicit deny-all term that silently discards all traffic that reaches it. Some users may opt

for a security philosophy in which you deny known bad traffic and then allow all else.

In such a case, you must add an explicit accept-all term at the end of your stateless filter

158 | Chapter 3: Stateless Filters, Hierarchical Policing, and Tri-Color Marking


chain to ensure all remaining “good” traffic is accepted before it can hit the implicit


Most users prefer a stronger security model where unknown threats are thwarted by

specifically accepting known good traffic and denying all that remains. While this case

can rely on the implicit deny-all term, most operators prefer to add their own explicit

deny-all term, often with a counter or a log function added to assist in debugging and

attack/anomaly recognition. The extra work involved for a final explicit term is trivial,

but the added clarity can help avoid mistakes that often lead to outages of a valid service

such as your routing or remote access protocols!

Filter Matching

There are a great many possible match criteria supported in Junos. You specify one or

more match criteria within a term using the from keyword. Recall that a term with no

from clause matches everything, and a term with multiple distinct match conditions

results in an AND function, with a match only declared when all evaluate as true. The

choice of filter family can influence what type of matches are available. For example,

on a Trio-based MX router, the following match options are available for family

bridge in release 11.4:

user@r1# set firewall family bridge filter foo term 1 from ?

Possible completions:

+ apply-groups

Groups from which to inherit configuration data

+ apply-groups-except Don't inherit configuration data from these groups

> destination-mac-address Destination MAC address

+ destination-port

Match TCP/UDP destination port

+ destination-port-except Do not match TCP/UDP destination port

> destination-prefix-list Match IP destination prefixes in named list

+ dscp

Match Differentiated Services (DiffServ) code point

+ dscp-except

Do not match Differentiated Services (DiffServ) code point

+ ether-type

Match Ethernet type

+ ether-type-except

Do not match Ethernet type

+ forwarding-class

Match forwarding class

+ forwarding-class-except Do not match forwarding class

+ icmp-code

Match ICMP message code

+ icmp-code-except

Do not match ICMP message code

+ icmp-type

Match ICMP message type

+ icmp-type-except

Do not match ICMP message type

> interface

Match interface name

+ interface-group

Match interface group

+ interface-group-except Do not match interface group

> interface-set

Match interface in set

> ip-address

Match IP source or destination address

> ip-destination-address Match IP destination address

+ ip-precedence

Match IP precedence value

+ ip-precedence-except Do not match IP precedence value

+ ip-protocol

Match IP protocol type

+ ip-protocol-except

Do not match IP protocol type

> ip-source-address

Match IP source address

+ isid

Match Internet Service ID

+ isid-dei

Match Internet Service ID DEI bit

Firewall Filter and Policer Overview | 159






























Do not match Internet Service ID DEI bit


Do not match Internet Service ID

isid-priority-code-point Match Internet Service ID Priority Code Point

isid-priority-code-point-except Do not match Internet Service ID Priority Code Point

learn-vlan-1p-priority Match Learned 802.1p VLAN Priority

learn-vlan-1p-priority-except Do not match Learned 802.1p VLAN Priority


Match User VLAN ID DEI bit

learn-vlan-dei-except Do not match User VLAN ID DEI bit


Match Learnt VLAN ID

learn-vlan-id-except Do not match Learnt VLAN ID


Match Loss Priority

loss-priority-except Do not match Loss Priority


Match TCP/UDP source or destination port


Do not match TCP/UDP source or destination port


Match IP source or destination prefixes in named list


Source MAC address


Match TCP/UDP source port


Do not match TCP/UDP source port


Match IP source prefixes in named list


Match TCP flags


Match Match traffic type

traffic-type-except Do not match Match traffic type

user-vlan-1p-priority Match User 802.1p VLAN Priority

user-vlan-1p-priority-except Do not match User 802.1p VLAN Priority


Match User VLAN ID

user-vlan-id-except Do not match User VLAN ID


Match VLAN Ethernet type

vlan-ether-type-except Do not match VLAN Ethernet type

Certainly a lengthy list of match options, and given that family bridge is a Layer 2

protocol family, one cannot help but be struck by the rich set of protocol match options

at Layer 3 (IP) and Layer 4 (TCP/UDP). Trio’s ability to peer deep (up to 256 bytes)

into Layer 3 traffic, even when functioning as a bridge, really drives home the power

and flexibility of the Trio PFE chipset!

This chapter, as well as others that build on filter or policer functionality, expose the

reader to a variety of match conditions for common protocols families. Given there are

so many options, it just does not make sense to go into all of them here; besides, all are

documented in various user manuals. It bears mentioning that for the bridge family

you specify a user-vlan match type when matching on (C) tags associated with access

ports and the learn-vlan match type for trunk ports when matching on Service Provider

(S) tags. For example, this link takes you to documentation that defines stateless filter

match capabilities for each protocol family, as of Junos release v11.4:



A Word on Bit Field Matching. Many protocol field patterns can be matched using a predefined symbolic name that’s designed to be user-friendly. For example, matching on the

SYN bit in a TCP header can be done with the keyword syn, or a hexadecimal value

0x2. While it may impress your geeky friends to have a hex-based packet filter, it’s

considered best practice to use the symbolic names when they’re available to help im160 | Chapter 3: Stateless Filters, Hierarchical Policing, and Tri-Color Marking


prove filter legibility and lessen the chances of a mistake. Table 3-2 shows some of the

more common bit field match types and their keyword aliases.

Table 3-2. Text Synonyms.

Text Synonym

Match Equivalent

Common Use


Offset = 0, MF = 1

Match on the first fragment of a packet for counting and logging.


Offset does not equal


Protect from fragmented DOS attacks


ack or rst

Allow only established TCP sessions over an interface. This option does not implicitly

check that the protocol is TCP. Combine with a protocol TCP match condition. Known

as established in IOS ACLs.


syn and not ack

Allow TCP sessions to be initiated in the outbound direction only. Combine with a

protocol TCP match condition. Equal to TCP flags of match-all +syn –ack in


Junos also supports a range of boolean operators such as negations and logical AND/

OR functions. Consult the documentation for a complete list of available bit field

matches and supported operations. This information is documented for the v11.4 release at: http://www.juniper.net/techpubs/en_US/junos11.4/topics/concept/firewall-filter


Filter Actions

You use a then statement to list one or more actions that are to be performed on traffic

that matches a filter term. If you omit the then keyword, the default action is to accept

the matching traffic. Besides the basic discard and accept actions, filter can also mark

packets to influence CoS processing, alter the traffic’s drop probability, or count/log

matches to assist in anomaly detection or to aid in troubleshooting filter operation.

With Junos, you have the flexibility of specifying multiple actions in a single term, or

you can use the next-term flow-control action (detailed in a later section) to have the

same traffic match against multiple terms, where each such term has its own specific


Filters versus Routing Policy

Readers familiar with Junos routing policy will recognize many similarities between

filter and policy configuration syntax and processing logic. Both filters and policy

statements can consist of one or more terms (though a policy is allowed to have a single

unnamed term and filters require all terms be explicitly named), with those terms based

on a set of match criteria along with an associated action. They both support the concept of chaining, where you link small pieces of modular code to act as if it were a single,

large piece filter or policy. Both support application for inbound or outbound flows,

Firewall Filter and Policer Overview | 161


in the data and control planes, respectively, and both support the concept of a “default

action” for traffic that’s not been explicitly matched by a preceding term.

While so very similar, routing policy and filters perform two completely different functions that can sometimes achieve similar effects, and so their differences warrant a brief

discussion here. Filters operate in the data plane, whereas policy functions in the Control Plane (CP). Filters can affect transit traffic directly, regardless of whether there is a

viable next-hop for the traffic, by filtering the traffic itself. In contrast, policy can affect

transit traffic indirectly by virtue of allowing a given next-hop, or not, in the routing

table through filtering of route updates. Filters can affect traffic to the router itself, or

transit traffic destined for a remote machine. Policy always acts on traffic destined to

the local host in the form of a routing protocol update. Note that filtering such a route

update at ingress can in turn impact how traffic in the data plane egresses the local

router, but this is indirect compared to a filter’s direct action in the data plane.

With regards to traffic destined to the local host, filters are used primarily for security

whereas policy is used to influence the routing table and to control what routes you

advertise to downstream peers. A comparison of the two features is given in Table 3-3.

Table 3-3. Firewall Filters versus Routing Policies.


Firewall filter

Routing policy

Operates in . . .

Forwarding plane

Control plane

Match keyword



Action keyword



Match attributes

Packet fields

Routes and their attributes

Default action


Depends on default policy of each particular routing


Applied to . . .

Interfaces/Forwarding Tables

Routing protocols/tables

Named terms required



Chains allowed



Absence of from

Match all

Match all

Boolean operations when applied



As a final comparison point, consider the goal of wanting to prevent a given BGP update

from entering your router. You could use a filter to block all BGP, or perhaps just BGP

from a given peer. But this is a heavy hammer, as it affects all the routes that peer can

ever advertise. Policy, on the other hand, operates on the individual routes that are

received via routing protocol update, which in turn allows per-prefix control for filtering or attribute modification.

Like peanut butter and chocolate, the two go great together. You deploy filters to block

unsupported routing protocols while also using policy to filter individual route updates

from within those supported protocols.

162 | Chapter 3: Stateless Filters, Hierarchical Policing, and Tri-Color Marking


Filter Scaling

Everything has a limit, and pushing anything too far will affect its performance, sometimes dramatically. Customers often ask questions like “How many terms can I have

in a filter?” or “How many filters can I apply at any one time?” While reasonable, this

type of question is hard to answer because filtering is only one dimension of system

scaling, and most production networks deploy nodes that must scale in multiple dimensions simultaneously. As is so often true, you cannot have your cake and also keep

it in safe storage for later consumption, which in this case means if you are pushing the

box to scale with large numbers of BGP peers and millions of route prefixes, then there

is a good chance you will hit some issue with filter scaling before the theoretical limit.

It’s always a good idea to monitor system load, and to be on the lookout for error

messages in the logs that warn of impending resource exhaustion, when pushing any

router to high scales.

Each Trio PFE has a large pool of External Data Memory (EDMEM) for storing nexthop FIB entries, filter structures, Layer 2 rewrite data, and so on. While portions of this

memory are reserved for each function, the memory system is flexible and allows areas

with heavy use to expand into unused memory. As a result, it’s not uncommon to check

some resource usage and find it seems alarming high, say 98 percent utilized, only to

find you can keep pushing that scale dimension and later find the pool has been resized


The command shown in the following is used to display the current allocations of

EDMEM on a Trio MPC, which in this example is demonstrated on a system that is

scaled to 3,000 EBGP/OSPF/RIP VRF peers, with each of the 2,000 VRF IFLs using an

input filter for COS classification and policing.

Here, we look at the first PFE on FPC 5 (MPC 5). Note how the request pfe execute

command is used to avoid having to drop to a shell and/or VTY to the desired PFE

component. pretty cool:


regress@halfpint> request pfe execute target fpc5 command "show jnh 0 pool usage"

SENT: Ukern command: show jnh 0 pool usage


GOT: EDMEM overall usage:

GOT: [NH///////////////|FW///|CNTR////////|HASH/////|ENCAPS////|---------------]

GOT: 0

7.0 9.0






GOT: Next Hop

GOT: [***************************************************|--] 7.0M (98% | 2%)


GOT: Firewall

GOT: [|--------------------] 2.0M (1% | 99%)


GOT: Counters

GOT: [|----------------------------------------] 5.0M (1% | 99%)



Firewall Filter and Policer Overview | 163


GOT: [*************************************************************] 7.8M (100% | 0%)



GOT: [*****************************************] 4.1M (100% | 0%)


LOCAL: End of file

This display is based on the allocation of Mega Double Words (MDW), with each word

being 32 bits/4 bytes in length--thus a DMW is 64 bits. In this display, 1 M equates to

1 MDW or 1 M * 8 B, which equals 8 MB (or 64 Mb). Here we can see that the portion

of EDMEM allocated to filter structures is relatively small, at 2 MDW, when compared

to the 7 MDW allocated for next hops. As noted previously, this setup has 2K (interfacespecific) filters and policers in effect, along with a heavy BGP/VRF/route load, and

clearly there is still room to grow with additional filter or policer structures. The current

Trio PFE can allocate up to 88 MB per PFE to hold filter and policer structures.

You can display overall PFE memory usage with the summary option:


regress@halfpint> request pfe execute target fpc5 command "show jnh 0 pool summary"

SENT: Ukern command: show jnh 0 pool summary






% Utilization

















Shared LMEM




LOCAL: End of file

The current scaling limits for Trio-based MPCs are shown in Table 3-4. In some cases,

scale testing is still being conducted so preliminary numbers are listed in the interim.

It’s expected that Trio-based PFEs will outperform I-Chip systems in all dimensions.

Table 3-4. MX Trio versus I-Chip Filter Scale.


Per Trio/MPC/Chassis

Per I-Chip 3.0/DPC/Chassis

Maximum number of interface policers

39 K (per chassis)

39 K (per chassis)

Maximum number of interface filters

16 K

16 K

Maximum 1-tuple terms

256 K

64 K

Maximum 1-tuple terms in a single filter

256 K

250 K

Trio platforms running Junos v11.4 can support up to 128 K policers

per chassis when the policers are called from a firewall filter, as opposed

to being directly applied to the IFL, where the current limit is up to 39

K policers per chassis.

164 | Chapter 3: Stateless Filters, Hierarchical Policing, and Tri-Color Marking


Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Chapter 3. Stateless Filters, Hierarchical Policing, and Tri-Color Marking

Tải bản đầy đủ ngay(0 tr)