Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Example: Classifying All Traffic from a Remote Device by Configuring Fixed Interface-Based Classification

This example shows the configuration of fixed classification based on the incoming interface. Fixed classification can be based on the physical interface (such as an ATM or Gigabit Ethernet interface) or a logical interface (such as an Ethernet VLAN, a Frame Relay DLCI, or an MPLS tunnel).


To verify this procedure, this example uses a traffic generator. The traffic generator can be hardware-based or it can be software running on a server or host machine.

The functionality in this procedure is widely supported on devices that run Junos OS. The example shown here was tested and verified on SRX Series Firewalls running Junos OS Release 12.1. The SRX Series Firewalls are configured to run as routers.


If you are performing tests on SRX Series Firewalls, you might need to configure the devices to run as unsecured routers in your test environment. You do not typically do this in a production environment.


A fixed interface classifier is the simplest way to classify all packets from a specific interface to a forwarding class. You typically use this approach on edge routers to classify all traffic from a remote router or server to a certain forwarding class and queue. A fixed interface classifier simply looks at the ingress interface on which the packet arrives and assigns all traffic received on that interface to a certain class of service.

The fixed interface classifier cannot set the locally-meaningful packet-loss-priority, which is used by rewrite rules and drop profiles. The implicit packet-loss-priority is low for all fixed interface classifiers.

A fixed interface classifier is inadequate for scenarios in which interfaces receive traffic that belongs to multiple classes of service. However, interface-based classification can be useful when it is combined with other classification processes. Filtering based on the inbound interface can improve the granularity of classification, for example, when combined with filtering based on code point markings. Combining the processes for interface and code point marking classification allows a single code point marking to have different meanings, depending on the interface on which the packet is received. If you want to combine a fixed interface classifier with a code point classifier, this is in effect a multifield classifier.

More Granular Alternative to Fixed Interface Classifier

In Junos OS, you can combine interface-based classification and code-point classification by using a multifield classifier, as follows:

The following Juniper Networks Learning Byte video describes classifiers in more detail.


Figure 1 shows the sample network.

Figure 1: Fixed-Interface Classifier ScenarioFixed-Interface Classifier Scenario

To simulate voice traffic, this example shows TCP packets sent from the host to a downstream device. On Device R2, a fixed interface classifier routes the packets into the queue defined for voice traffic.

The classifier is assigned to interface ge-0/0/0 on Device R2. As always, verification of queue assignment is done on the egress interface, which is ge-0/0/1 on Device R2.

CLI Quick Configuration shows the configuration for all of the Juniper Networks devices in Figure 1. The section Step-by-Step Procedure describes the steps on Device R2.



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 at the [edit] hierarchy level.

Device R1

Device R2

Device R3

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To enable the default DSCP behavior aggregate classifier:

  1. Configure the device interfaces.

  2. Configure an interior gateway protocol (IGP) or static routes.

  3. Configure a set of forwarding classes.

  4. Map all traffic that arrives on ge-0/0/0.0 into the Voice queue.


From configuration mode, confirm your configuration by entering the show interfaces and show class-of-service commands. 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.


Confirm that the configuration is working properly.

Verifying a Fixed-Interface Classifier


Verify that the fixed interface classifier is enabled on the Device R2’s ingress interface. Keep in mind that although the classifier operates on incoming packets, you view the resulting queue assignment on the outgoing (egress) interface.


  1. Clear the interface statistics on Device R2’s egress interface.

  2. Using a packet generator, send TCP packets to a device that is downstream of Device R2.

    This example uses the packet generator hping.

  3. On Device R2, verify that the Voice queue is incrementing.


The output shows that the Voice queue has incremented by 25 packets after sending 25 packets through the ge-0/0/0 interface on Device R2.