Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Example: Configuring and Verifying a Complex Multifield Filter

In this example, SIP signaling (VoIP) messages use TCP/UDP, port 5060, and RTP media channels use UDP with port assignments from 16,384 through 32,767. See the following sections:

Configuring a Complex Multifield Filter

To configure the multifield filter, perform the following actions:

  • Classify SIP signaling messages (VoIP network control traffic) as NC with a firewall filter.

  • Classify VoIP traffic as EF with the same firewall filter.

  • Police all remaining traffic with IP precedence 0 and make it BE.

  • Police BE traffic to 1 Mbps with excess data marked with PLP high.

  • Apply the firewall filter with policer to the interface.

The firewall filter called classify matches on the transport protocol and ports identified in the incoming packets and classifies packets into the forwarding classes specified by your criteria.

The first term, sip, classifies SIP signaling messages as network control messages. The port statement matches any source port or destination port (or both) that is coded to 5060.

Classifying SIP Signaling Messages

The second term, rtp, classifies VoIP media channels that use UDP-based transport.

Classifying VoIP Channels That Use UDP

The policer’s burst tolerance is set to the recommended value for a low-speed interface, which is ten times the interface MTU. For a high-speed interface, the recommended burst size is the transmit rate of the interface times 3 to 5 milliseconds.

Configuring the Policer

The third term, be, ensures that all remaining traffic is policed according to a bandwidth restriction.

Policing All Remaining Traffic

The be term does not include a forwarding-class action modifier. Furthermore, there is no explicit treatment of network control (NC) traffic provided in the classify filter. You can configure explicit classification of NC traffic and all remaining IP traffic, but you do not need to, because the default IP precedence classifier correctly classifies the remaining traffic.

Apply the classify classifier to the fe-0/0/2 interface:

Applying the Classifier

Verifying a Complex Multifield Filter

Before the configuration is committed, display the default classifiers in effect on the interface using the show class-of-service interface interface-name command. The display confirms that the ipprec-compatibility classifier is in effect by default.

Verifying Default Classification

To view the default classifier mappings, use the show class-of-service classifier name name command. The highlighted output confirms that traffic with IP precedence setting of 0 is correctly classified as BE, and NC traffic, with precedence values of 6 or 7, is properly classified as NC.

Displaying Default Classifier Mappings

After your configuration is committed, verify that your multifield classifier is working correctly. You can monitor the queue counters for the router device’s egress interface used when forwarding traffic received from the peer. Displaying the queue counters for the ingress interface (fe-0/0/2) does not allow you to check your ingress classification, because queuing generally occurs only at egress in the Junos OS. (Ingress queuing is supported on Gigabit Ethernet IQ2 PICs and Enhanced IQ2 PICs only.)

To verify the operation of the multifield filter:

  1. To determine which egress interface is used for the traffic, use the traceroute command.

  2. After you identify the egress interface, clear its associated queue counters by issuing the clear interfaces statistics interface-name command.

  3. Confirm the default forwarding class-to-queue number assignment. This allows you to predict which queues are used by the VoIP, NC, and other traffic. To do this, issue the show class-of-service forwarding-class command.

  4. Display the queue counts on the interface by issuing the show interfaces queue command.