Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Example: Configuring and Verifying a Complex Multifield Filter

Configuring a Complex Multifield Filter

• 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.

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

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.

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

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:

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.

Physical interface: fe-0/0/2, Index: 135
Queues supported: 8, Queues in use: 4
  Scheduler map: <default>, Index: 2032638653
 
  Logical interface: fe-0/0/2.0, Index: 68
    Shaping rate: 32000
    Object         Name                   Type                       Index
    Scheduler-map  <default>                                            27
    Rewrite        exp-default            exp                           21
    Classifier     exp-default            exp                            5
    Classifier     ipprec-compatibility   ip                             8

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.

Classifier: ipprec-compatibility, Code point type: inet-precedence, Index: 12
  Code point          Forwarding class                     Loss priority
  000                 best-effort                          low
  001                 best-effort                          high
  010                 best-effort                          low
  011                 best-effort                          high
  100                 best-effort                          low
  101                 best-effort                          high
  110                 network-control                      low
  111                 network-control                      high

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.)

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.