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
0and 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
firewall {
family inet {
filter classify {
interface-specific;
term sip {
from {
protocol [ udp tcp ];
port 5060;
}
then {
forwarding-class network-control;
accept;
}
}
}
}
}
The second term, rtp, classifies VoIP media channels
that use UDP-based transport.
Classifying VoIP Channels That Use UDP
term rtp {
from {
protocol udp;
port 16384-32767;
}
then {
forwarding-class expedited-forwarding;
accept;
}
}
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
policer be-policer {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 15k;
}
then loss-priority high;
}
The third term, be, ensures that all remaining traffic
is policed according to a bandwidth restriction.
Policing All Remaining Traffic
term be {
then policer be-policer;
}
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
interfaces {
fe-0/0/2 {
unit 0 {
family inet {
filter {
input classify;
}
address 10.12.0.13/30;
}
}
}
}
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
user@host> show class-of-service fe-0/0/2
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.
Displaying Default Classifier Mappings
user@host> show class-of-service classifier name ipprec-compatibility 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.)
To verify the operation of the multifield filter:
To determine which egress interface is used for the traffic, use the
traceroutecommand.After you identify the egress interface, clear its associated queue counters by issuing the
clear interfaces statistics interface-namecommand.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-classcommand.Display the queue counts on the interface by issuing the
show interfaces queuecommand.