[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]

Configuring Multifield Classifiers for Policing

Multifield classifiers take action on incoming or outgoing packets, depending whether the firewall rule is applied as an input filter or an output filter. When TCM is enabled, T-series and M320 platforms support four multifield classifier packet loss priority (PLP) designations: low, medium-low, medium-high, and high.

To configure the PLP for a multifield classifier, include the loss-priority statement in a policer or firewall filter that you configure at the [edit firewall] hierarchy level:

[edit firewall]
family family-name {
filter filter-name {
term term-name {
from {
match-conditions;
}
then {
loss-priority (low | medium-low | medium-high | high);
forwarding-class class-name;
}
}
}
}

The inputs (match conditions) for a multifield classifier are one or more of the six packet header fields: destination address, source address, IP protocol, source port, destination port, or DSCP. The outputs for a multifield classifier are the forwarding class, the PLP, or both. In other words, a multifield classifier sets the forwarding class and the PLP for each packet entering or exiting the interface with a specific destination address, source address, IP protocol, source port, destination port, or DSCP.

For example, in the following configuration, the forwarding class expedited-forwarding and PLP medium-high are assigned to all IPv4 packets with the 10.1.1.0/24 or 10.1.2.0/24 source address:

firewall {
family inet {
filter classify-customers {
term isp1-customers {
from {
source-address 10.1.1.0/24;
source-address 10.1.2.0/24;
}
then {
loss-priority medium-high;
forwarding-class expedited-forwarding;
}
}
}
}
}

To use this classifier, you must configure the settings for the expedited-forwarding forwarding class at the [edit class-of-service forwarding-classes queue queue-number expedited-forwarding] hierarchy level.

Note: Because the policer is executed before the filter, if an input policer is also configured on the logical interface, it cannot use the forwarding class and PLP of a multifield classifier associated with the interface.

You can configure multifield classifiers within a firewall filter to set the packet’s forwarding class and packet loss priority. You can also apply policers to packets matching some classification term. The policing action might affect the resulting forwarding class, packet loss priority, and accept or drop status. For more information, see the JUNOS Class of Service Configuration Guide.

To configure the forwarding class and loss priority, include the then statement:

then {
loss-priority;
forwarding-class class-name;
}

You can include the statement at the following hierarchy levels:

You can specify one or both of the following actions:

For more information about forwarding class and loss priority, see the JUNOS Class of Service Configuration Guide. For more information about policers, see the following sections:

Configuring Filter-Specific Policers

You can configure filter-specific policers within the firewall configuration. Filter-specific policers allow you to configure policers and counters for a specific filter name.

When you configure the filter-specific statement, a single policer set is created for the entire filter. All traffic matching the terms of the firewall filter with the action policer goes through that single policer. The default is a term-specific policer in which a single policer set is created for each term within the filter. All traffic matching the terms of the firewall filter with the action policer goes through the part of the policer that is specific to that term.

To configure filter-specific policers, include the filter-specific statement at the [edit firewall policer policer-name] hierarchy level:

[edit firewall policer policer-name]
filter-specific;

If the filter-specific statement is not configured, then the policer defaults to a term-specific policer.

You can apply the filter-specific policers to the family inet.

Configuring Policer Actions for Specific Address Prefixes

You can configure prefix-specific actions within the firewall configuration. Prefix-specific actions allow you to configure policers and counters for specific addresses or ranges of addresses. This allows you to essentially create policers and counters on a per-prefix level.

To configure prefix-specific actions, include the prefix-action name statement at the [edit firewall family inet] hierarchy level:

[edit firewall family inet]
prefix-action name {
count;
destination-prefix-length prefix-length;
policer policer-name;
source-prefix-length prefix-length;
subnet-prefix-length prefix-length;
}

The following formula determines the number of prefix-specific actions created:

Number = 2 ^ (source/destination-prefix-length - subnet-prefix-length)

The subnet-prefix-length statement allows for more control for the flexibility offered by prefix-specific actions, allowing the policers to be more applicable and powerful. For example, if you want to filter all Transmission Control Protocol (TCP) packets and define two policers, all packets ending with 0 in the last address bit increment the first policer, while all packets ending with 1 in the address bit increment the second policer. As another example, if you want to filter all TCP packets and define 256 policers, matching is based on the last octet of the destination address field. You achieve both cases by specifying an appropriate subnet prefix length.

Prefix-specific action is supported for the IP version 4 (IPv4) inet address family.

To configure prefix-specific actions, include the prefix-action statement and specify an action name.

To enable a prefix-specific counter, include the count statement.

To configure the destination address range specified for a prefix-specific policer or counter, include the destination-prefix-length statement.

To enable a set of prefix-specific policers, include the policer statement and specify the policer name.

To configure the source address range specified for a prefix-specific policer or counter, include the source-prefix-length statement.

To configure the total address range of the subnet supported, include the subnet-prefix-length statement. The source or destination prefix length must be larger than the subnet prefix length.

Prefix-specific action applies to a specific prefix length, and not to a specific interface. You can add an interface policer polices at the aggregate level for a specific interface. You could also use the next term action to configure all Hypertext Transfer Protocol (HTTP) traffic to each host to transmit at 500 Kbps and have the total HTTP traffic limited to 1 Mbps.

The maximum number of policers you can configure for one subnet is 65,536. If you configure more than 65,536 policers, you receive an error message.

Note: J-series Services Routers do not support prefix-specific actions.

Examples: Configuring Policer Actions for Specific Address Prefixes

Create a prefix-specific policer operating on the source address and apply it to the input interface:

[edit]
firewall {
policer host-policer {
filter-specific;
if-exceeding {
bandwidth-limit bps;
burst-size-limit bytes;
}
then {
discard;
}
}
family inet {
prefix-action ftp-policer-set {
count;
destination-prefix-length 32;
policer host-policer;
subnet-prefix-length 24;
}
filter filter-ftp {
term term1{
from {
destination-address 10.10.10/24;
destination-port ftp;
}
then {
prefix-action ftp-policer-set;
}
}
}
}
}

Filter all packets going to the /24 subnet, letting them pass to the prefix-specific action policers. In the policer set, the last octet of the source address field of the packet is used to index into the respective prefix-specific action policers.

[edit]
firewall {
policer 1Mbps-policer {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 63k;
}
}
family inet {
prefix-action per-source-policer {
policer 1Mbps-policer;
subnet-prefix-length 24;
source-prefix-length 32;
}
}
filter limit-all-hosts {
term one {
from {
source-address {
10.10.10.0/24;
}
}
then prefix-action per-source-policer;
}
}
}

In the preceding case, all packets are subjected to the prefix-specific action policing. The last octet of the source address field of the packet is used to index into the corresponding policer. In other words, all packets ending with 0x(xxxx0000) match the first policer and all packets ending in 0x(xxxx0001) match the second policer.

Therefore, 256 policers are created and shared by all addresses. In this case, 10.1.1.1, 10.2.2.1, 10.4.5.1 ... 10.x.x.1 share the same 1-Mbps policer; 10.1.1.2, 10.2.2.2, 10.4.5.2 ... 10.x.x.2 share another 1-Mbps policer, and so on.

Subject packets belonging to the 10.10.10.0/24 subnet are subject to policing by the prefix-specific action policers. Because 128 policers defined in the policer set, the /24 subnet can be thought of as being split into two /25 subnets, both of them sharing the same prefix-specific action set. Therefore, 10.10.10.1 and 10.10.10.129 share the same 1-Mbps policer, 10.10.10.2 and 10.10.10.130 share another 1-Mbps policer, and so on.

[edit]
firewall {
policer 1Mbps-policer {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 63k;
}
}
family inet {
prefix-action per-source-policer {
policer 1Mbps-policer;
subnet-prefix-length 25;
source-prefix-length 32;
}
}
filter limit-all-hosts {
term one {
from {
source-address {
10.10.10.0/24;
}
}
then prefix-action per-source-policer;
}
}
}

Define 256 policers based on the last octet of the source address field. However, you are only allowing a subset of that to pass through the match condition. As a result, only the lower half of the set is used.

[edit]
firewall {
policer 1Mbps-policer {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 63k;
}
}
family inet {
prefix-action per-source-policer {
policer 1Mbps-policer;
subnet-prefix-length 24;
source-prefix-length 32;
}
}
filter limit-all-hosts {
term one {
from {
source-address {
10.10.10.0/25;
}
}
then prefix-action per-source-policer;
}
}
}

Accept packets from 10.10.10/24 and 10.11/16 subnets and subject them to policing by the same set of prefix-specific action policers. The policers are shared by packets across both subnets. There is a one-to-one correspondence between the 10.10.10/24 subnet. For 10.11/16, there is a many-to-one correspondence, as explained in the previous examples. Each of the 10.11.0/24, 10.11.1/24, 10.11.2/24 ... 10.11.255/24 subnets share the same prefix-specific action set.

Thus, 10.10.10.1, 10.11.1.1, 10.11.2.1 ... 10.11.x.1 share the same 1-Mbps policer; 10.10.10.2, 10.11.1.2, 10.11.2.2 ... 10.11.x.2 share another 1-Mbps policer, and so on.

[edit]
firewall {
policer 1Mbps-policer {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 63k;
}
}
family inet {
prefix-action per-source-policer {
policer 1Mbps-policer;
subnet-prefix-length 24;
source-prefix-length 32;
}
}
filter limit-all-hosts {
term one {
from {
source-address {
10.10.10/24;
10.11/16;
}
}
then prefix-action per-source-policer;
}
}
}

Examples: Classifying Traffic

Classify expedited forwarding traffic:

[edit]
firewall {
policer ef-policer {
if-exceeding {
bandwidth-limit 300k;
burst-size-limit 50k;
}
then {
discard;
}
}
term ef-multifield {
then {
loss-priority low;
forwarding-class expedited-forwarding;
policer ef-policer;
}
}
}

Classify assured forwarding traffic:

firewall {
policer af-policer {
if-exceeding {
bandwidth-limit 300k;
burst-size-limit 500k;
}
then {
loss-priority high;
}
}
term af-multifield {
then {
loss-priority low;
forwarding-class assured-forwarding;
policer af-policer;
}
}
}
[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]

[an error occurred while processing this directive]