S03M01 Policy Language

Section 3 Module 1
Policy Language
(SandScript)
Module Objectives
On completion of this module you will have an

understanding about policy language used on PTS
systems. You will be able to:
Describe the fundamentals of policy language and policy groups
Describe the use of node qualifiers
Explain and use of policy language conditions and actions
Initialize policy rules
PTS Operation Course (Part 2) Section 1 Module 1 - Policy Language slide 3

Lesson: Introduction to Policy Language
Learning Objectives
On successful completion of this lesson, you will demonstrate an
understanding of policy language used on PTS systems. You will be
able to:
 Describe the fundamentals of policy language
 Describe the use of conditions and actions
 Describe policy groups

PTS Configuration Files
rc.conf subnets.txt policy.conf
Define:
• PTS-specific hardware Define text-based IP Define policy
properties map of the network. enforcement rules
• Remote configuration
parameters
• Inline/offline mode
• Traffic shunting
• Physical Topology
 Policies are used for various purposes:

• To configure statistics collection and reporting
• To select traffic on which to perform specific actions
• To take action based on particular network events and conditions
 As with rc.conf and subnets.txt, to apply changes to
policy.conf you must first save the file, exit and issue an
svreload.
Overview
 PTS policy language is flexible and user friendly.

 Traffic management rules are created and held in:
/usr/local/sandvine/etc/policy.conf
 Every flow evaluated by the PTS is tested against these rules.

 PTS policy language is written based on conditions and actions using the
syntax:
if <condition(s)> then <action(s)>
Policy language example:
if protocol “bittorrent" then shape …
condition action

Conditions
Conditions are used to identify when you want to do something.
Valid conditions:
 attribute  protocol
 class  provider
 expr()  time
 ip_addr  tcp_port
 layer4protocol  true
 udp_port

Actions
Actions are used to identify what you want to do once the conditions have
been met.
Valid actions:
 allow  increment
 block  mark
 captive_portal  set
 continue  set_attribute
 count  shape
 decrement  tcp_reset
 Diameter actions  tee
 divert  Timer actions
 http_response
Sandvine Essentials Training Section 3 Module 1 - Policy Language slide 8

Policy Language – Rules Syntax
 A rule is a single command line string

 Use ‘\’ to split across multiple lines (ignore end of line <cr>)
 Rules always start with the text “if”
 Lines starting with the pound sign (#) are commented out and
ignored
 White space is ignored
 Contents of rules are case sensitive
 By convention, protocols and keywords are lower case with an
underscore (_) separating the words (i.e. http_get ,
delay_time)
 The logical operators “and”, “or” & “not” can be used to
create complex rules

Use of “and” & “or” in Policy Language
 Order of operations is “and” before “or”

• e.g. “A or B and C” is equivalent to “A or (B and C)”
 Use parentheses to set order of operations: anything in

parentheses will be done first.
• e.g. “(A or B) and C” may be required
 Actions may include “and” but not “or”
Example:
if (protocol “edonkey” or protocol “bittorrent”) and \

(client class “ISP1” or client class “ISP2”) \
then count subscriber basic and \
shape to subscriber shaper “P2P”

Policy Logic
 Every rule is evaluated for every flow being inspected.

 Rules are vetted in the order they appear in policy.conf.
 A cumulative list of compatible actions is built from rules whose
conditions the flow has met.
 If the flow satisfies the conditions for more than one rule it will
execute the corresponding actions in order if possible.
 If an action is incompatible with an earlier action, then only the
compatible actions are applied in the order they appear.

Incompatible Actions

Incompatible Actions
 Precedence is used to resolve incompatible action

conflicts.
 For example, divert and tcp_reset are incompatible
actions.
 If the conditions are met for both actions, the order of the
statements determines which action will be applied:
if protocol "bittorrent" then divert

. . . .
. . . .
if protocol "bittorrent" then tcp_reset
 In the above example, all bittorrent flows will get diverted

as the divert action appears first in the policy file.
 The tcp_reset action will be quietly (no warnings, errors
or alarms) discarded.

Policy Groups
 Policy Groups make policy more efficient by providing “exit after first match”
logic. To implement “if then elseif “ logic.
If this condition is true, then we know that the
Without a policy group: following three conditions must evaluate to false.
if protocol “bittorrent” then <action 1>

if protocol “gnutella” then <action 2>
if protocol “edonkey” then <action 3> These condition
checks are wasted.
if protocol “fasttrack” then <action 4>
With a policy group: Within a PolicyGroup, if this condition is true we

will stop evaluating subsequent rules and exit.
PolicyGroup
{
if protocol “bittorrent” then <action 1>
if protocol “gnutella” then <action 2>
These condition
if protocol “edonkey” then <action 3>
checks are skipped.
if protocol “fasttrack” then <action 4>
}
…evaluation continues here.

Using Policy Groups
 By using the “true” condition in the last rule of a Policy Group, a default
action can be established:
PolicyGroup
{
if protocol “skype” then <action 1>
if protocol “http” then <action 2> If none of the other rules evaluate to
if true then block true, we will always block the flow.
}
 Caution must be used when nesting Policy Groups:

A Policy Group with no condition for entry is really a
PolicyGroup Policy Group with an implicit “true” condition.
{
Since the default behaviour is to
PolicyGroup
exit after first match and the inner
{ Policy Group always matches, this
<rule(s) within nested policy group> statement will never be evaluated.
}
if <condition(s) then <action(s)>
}
Policy Groups – Grouping Common Conditions
 Policy Groups provide a means of grouping rules together that have
common conditions.
 Organizing rules into Policy Groups makes policy more efficient and
provides greater control over the path of evaluation.
 Policy Groups:
• Are evaluated in the order they appear.
• Support multiple levels of nesting.
Syntax:
PolicyGroup [condition(s)]
{
<policy rule(s) and/or nested policy group(s)>
}
 If the entry conditions are met (true), the path of evaluation goes into
the policy group and the rules are executed.
 If the entry conditions are not met (false), the entire contents of the
policy group are skipped.

Using Policy Groups
 Policy Groups can be used to make policy more efficient by evaluating

conditions that are common to a set of rules only once.
Without a policy group:
if (time hours 0800-1700) and protocol “skype” then <action 1>

if (time hours 0800-1700) and protocol “http” then <action 2>
 In the above example, we unnecessarily evaluate the time condition

twice.
With a policy group:

PolicyGroup (time hours 0800-1700)
{
if protocol “http” then <action 2>
}

Policy Groups: Use of the “all” keyword
Default behavior:
 Only the first match is executed and all subsequent rules in the group are
skipped
Modified behavior:
 The “all” option ignores the default action of halting on the first match.
 “all” forces all rules to be read and processed in order
Example:
PolicyGroup time hours 0800-1700 all
{
if subscriber “tier” = “gold” then <action 2>
}

Policy Groups – Summary of Usage
Policy Groups can be used in 3 ways:

Exit After First
Condition(s) Example
Match
PolicyGroup <condition(s)>
{
Yes Yes
...
}
PolicyGroup
{
No Yes
...
}
PolicyGroup <condition(s)> all
{
Yes No
...
}

Lesson: Introduction to Node Qualifiers
Learning Objectives
understanding of node qualifiers and how they relate to internal and
external PTS's in a network. You will know how to:
 Describe the difference between
• client / server
• sender / receiver
• subscriber / internet
 Understand how to use node qualifiers in policy to specify direction

Node Qualifiers – Motivation
 Certain policy conditions and actions require the use of a
node qualifier.
 Other times we may want to control the direction of traffic
that we’re affecting.
Consider this policy statement:
if protocol “bittorrent” then <action>
 It does not differentiate between upstream and downstream

traffic – it will apply <action> to both directions.
 We can modify the above statement using a node qualifier so
that <action> only gets applied in the upstream or the
downstream direction.

Node Qualifiers - Endpoints
 Every flow is defined by two endpoints – the source IP/port and
destination IP/port.
 For traffic flowing through the PTS, one endpoint will typically*
be internal and the other external to the network:
Internal External
 To use node qualifiers in policy, we write conditions such as:

• “If the traffic is going to/from a certain endpoint.”
• “If the endpoint is in a certain network or policy class.”
 By writing conditions such as these, we can describe the specific
direction of traffic we want to affect.

Node Qualifiers – client & server
When we use the client and server node qualifiers, which endpoint
the client/server represents depends on who initiates the TCP
session*.
 The client endpoint is always the initiator of the TCP session. (The
side that sends the TCP SYN packet.)
 The server endpoint is always the acceptor of the TCP session. (The
side that responds with the SYN ACK packet.)
Always the initiator of the session

(sends the SYN in TCP)
“client”
Always the acceptor of the session (sends

the SYN-ACK in TCP)
“server”
Node Qualifiers – client & server
 When using the client/server node qualifiers, if we write policy
that says “to client”, is it upstream or downstream traffic?
Internal External
TCP SYN
TCP SYN-ACK
client “to client” = downstream server
 It could be either – depending on whether the initiator of the

session is internal or external to the network!
Internal
TCP SYN External
TCP SYN-ACK
server client
“to client” = upstream

Node Qualifiers – sender & receiver
When we use the sender and receiver node qualifiers, which endpoint
the sender/receiver represents depends on the transfer direction
of the flow.
 The sender endpoint is the side of the flow that is primarily
transmitting data.
 The receiver endpoint is the side of the flow that is primarily
receiving data.
The host that is transmitting data
“sender”
The host that is receiving data
“receiver”
Node Qualifiers – sender & receiver
As with the client/server node qualifiers, the sender and the
receiver can be either internal or external.
 With client/server it depends on who initiates the session.
 With sender/receiver it depends on the direction of transfer.
Internal External
Bulk Data Flow
Data ACKs
sender “to sender” = downstream receiver
Internal
Bulk Data Flow External
Data ACKs
receiver “to sender” = upstream sender

Node Qualifiers – subscriber & internet
 The subscriber and internet node qualifiers neither depend on
who establishes the connection nor the direction of data transfer.
 With subscriber and internet, the endpoint refers to the type of
port to which it is physically connected.
The side of the flow that transmits and

SetPortRole 1-1 subscriber receives to and from an INTERNET port
Internal on the PTS (an EVEN numbered port)
External
“internet”
“subscriber”
SetPortRole 1-2 internet
The side of the flow that transmits &
receives to and from a SUBSCRIBER port
on the PTS (an ODD numbered port)

Which Node Qualifiers Should I Use?
 The subscriber and internet node qualifiers are by far the
simplest and best to use for several reasons:
• They never change. The subscriber endpoint is always
internal to the network and the internet endpoint is always
external to the network.
• When used they required half the policy of client/server or
sender/receiver to accomplish the same thing.
• Policy written using the subscriber/internet node
qualifiers is easier to read and understand.
 Mini Quiz:
• Is “to subscriber” upstream or downstream? downstream
• Is “to internet” upstream or downstream? upstream
• Is “from subscriber” upstream or downstream? upstream
• Is “from internet” upstream or downstream? downstream

 The client/server and sender/receiver node qualifiers
can be internal or external.
• If you use them you are required to write twice as much policy
to accomplish the same thing as subscriber/internet.
 Example: Let’s say we want to shape downstream traffic using
the client/server node qualifiers:
If the client is external then the server must be internal so to

shape downstream traffic we must shape towards the server.
PolicyGroup
{
if client class “external” then \
shape to server shaper “Downstream”
if server class “external” then \
shape to client shaper “Downstream”
}
If the server is external then the client must be internal so to

shape downstream traffic we must shape towards the client.

 Example: Let’s say we want to shape downstream traffic using
the subscriber / internet node qualifiers:
PolicyGroup
{
if true then \
shape to subscriber shaper “Downstream”
}

 Caution must be taken when using the sender and receiver node
qualifiers.
 These node qualifiers should only be used with unidirectional
protocols.
 Why? Because bidirectional P2P protocols can send data in both
directions, presenting ambiguity for the Sender-Receiver node pair.
Internal External
Data
Sender
receiver
Data ACK + Data
Data
receiver Sender
Data ACK + Data

Bidirectional Protocols – Node Qualifier Ambiguity
 What happens in policy if you use the sender/receiver node qualifiers

with a bidirectional protocol?
Example: Consider the case where we attempt to shape downstream
bittorrent traffic using the sender and receiver node qualifiers:
if protocol “bittorrent” and sender class “external” then \

shape to receiver shaper “Downstream”
Internal External
Data A
Sender
receiver sender
receiver
ACK + Data B
 If the volume of Data B sent with the ACK packet is greater than the
volume of Data A, then the sender and receiver nodes can flip around
mid-flow.
 Should this occur, the above policy will stop working. (Why?)
Node Qualifiers - Summary
 When deciding which node qualifiers to use, follow these rules:
• Always use the subscriber/internet node qualifiers if possible.
• If you cannot use the subscriber/internet node qualifiers, choose
client/server for policy that applies to bidirectional protocols.
• If you cannot use the subscriber/internet node qualifiers and you
are writing policy for unidirectional protocols, you can use either
client/server or sender/receiver.
 Which of the following would you rather write and maintain?
PolicyGroup protocol “bittorrent” {

if client class “external” then \
shape to server shaper “Down”
if server class “external” then \ OR
shape to client shaper “Down”
}
if protocol “bittorrent” then \

shape to subscriber shaper “Down”
Lesson: Language Conditions
Learning Objectives
understanding of language conditions used in Policy.

Valid Conditions
 Conditions are used to determine when you want to affect

subscribers or flows.
• All condition evaluations ultimately result in a boolean value
of true or false.
• If the conditions are met (true), the corresponding actions
will be applied.
 Valid conditions:
• attribute • protocol
• class • provider
• expr() • tcp_port
• ip_addr • time
• layer4protocol • true
• udp_port

attribute
 The attribute condition matches a subscriber attribute.

 Any attributes used with this condition must first be declared.
 Subscriber to IP mapping must be configured.
Syntax:
if <node qualifier> attribute <name> = <value> then …
 The attribute condition must be preceded by a node qualifier:

sender|receiver|client|server|subscriber
Example:
if subscriber attribute “tier” = “bronze” …

attribute
 Note that the internet node qualifier is not available with the attribute
keyword. (Why?)
 When using the client/server or sender/receiver node qualifiers with
the attribute condition, it is important to understand how they interact:
if client “plan” = “Residential-1” then…
 This condition implicitly states that the client endpoint of the flow must be
on the internal side and correspond to a subscriber.
Internal External
client server
 If the client endpoint is external, it will not correspond to a subscriber and

will therefore not have an attribute.
class
 The class condition refers to the name of a network or policy class

as defined in subnets.txt.
Syntax:
if <node qualifier> class “class name” …
 Network and Policy classes must be predefined in the subnets.txt

file.
 “class name” must match the name of the network or policy class
exactly.
 The class condition must be preceded by one of the following node
qualifiers:
sender|receiver|client|server|subscriber|internet

class Example
 Assume subnets.txt has the following definition in it:
sub_1 10 internal
4.0.0.0/19
 How would this line of policy actually work?
if client class “sub_1” then <action>
 What the above line says is: If the client endpoint of the flow is
internal and its IP address falls in the range 4.0.0.0/19 then the
condition will be true.
 If the client endpoint of the flow is external, or if it is internal
but the IP address isn’t in the range 4.0.0.0/19, the condition
will be false.

expr
 The expression condition is used with Policy Assembly Language

(PAL).
 PAL is a controlled method that exposes more of the information
the PTS has on flows, subscribers, and the policy itself.
• It will be covered in more detail in a later lesson.
Syntax:
if expr(PAL expression) then <action>
Example:
if expr(Flow.Age > 3600) then <action>

ip_addr
 Matches the specified endpoint to an IP address or a subnet.
Syntax:
if <node qualifier> ip_addr then <action>
 The ip_addr condition must be preceded by one of the following

node qualifiers:
Examples:
if server ip_addr 128.255.200.25 then <action>

if subscriber ip_addr 70.25.40.0/24 then <action>

layer4protocol
 This condition is used to target flows that use a particular layer 4

protocol.
 The protocol in this case refers to the protocol field in the IP
header:
Syntax:
if layer4protocol <IANA#/keyword> then <action>
Example: TCP
if layer4protocol 6 then <action>

if layer4protocol TCP then <action>

protocol
 The protocol condition specifies the layer 7 (application)

protocol to act on.
 Possible actions vary with differing protocols.
Syntax:
if protocol <“protocol name”> then <action>
 When specifying “protocol name”, you must ensure that what

is in quotes matches exactly what the PTS expects.
Example:
if protocol “skype” then <action>

protocol Syntax
Review via man protocols
# man protocols
protocols(1) FreeBSD General Commands
Manual protocols(1)
NAME
protocols - Sandvine Traffic Matching Library
DESCRIPTION
The protocols package provides a protocol definition library to the
ptsd
application. The ptsd loads this package on startup which allows rules
to be written in the policy.conf about the supported protocols.
SUPPORTED PROTOCOLS
The protocols supported in this package are:
6to4
abacast
alibaba
aol2
aoluncut
appleJuice
ares
ares_download

Loadable Traffic Identification Package Guide
Network
Category Protocol Sub-protocol Policy Keyword
Demographics
AppleJuice … AppleJuice AppleJuice
… ares Ares
Ares Control ares_control Ares Control
Ares
Ares Download ares_download Ares
Ares UDP ares_udp Ares UDP
BitTorrent … bittorrent BitTorrent
Peer-to-
Peer BitTorrent
BitTorrent Encrypted bittorent_encryted
Encrypted
BitTorrent UDP bittorrent_udp BitTorrent UDP
Blubster … blubster Blubster
Direct Connect … directconnect Direct Connect
Earthstation 5 … earthstation5 Earthstation 5
Earthstation 5
earthstation5_control Earthstation 5
Control

Parent Protocols vs. Sub-Protocols
 For some protocols in the LTIP Guide, you will see a parent
protocol and a list of sub-protocols.
Example – for bittorrent, we see the following:
bittorrent Parent protocol
bittorrent_encrypted
Sub-protocols
bittorrent_udp
 If we use the parent protocol with the protocol condition, all sub-
protocols will be affected too:
if protocol “bittorrent” then <action>
 If we use a sub-protocol with the protocol condition, only that
specific sub-protocol will be affected:
if protocol “bittorrent_udp” then <action>
Would not affect bittorrent_encrypted flows.
provider
 Matches the specified provider URI or DNS string in the packets

used for a VoIP call setup.
 It only works with Skype, SIP and MGCP protocol-based
applications.
 The provider identifier name is case sensitive and must be placed
within quotes (“”) in the rule.
 Use the command “show service protocol voip
providers” to see a list of current valid provider names.
Syntax :
if provider <“provider name”> then <action>
Example:
if provider “Lingo” then <action>

Unknown provider
 If the PTS is unable to identify the provider in the VoIP call

it will classify the provider as an “unknown VoIP provider”.
 A listing of unknown VoIP providers can be viewed by using
the command:
“show service protocol voip unknown-providers”
This list and the associated hit counters for each entry can be
cleared by using the command:
“clear service protocol voip unknown-providers”

Additional VoIP Providers
 Over a hundred providers have been configured and exist in
/usr/local/sandvine/etc/rc.conf.default.providers.
 It is possible to track minutes and calls for VoIP providers not
identified in rc.conf.default.providers by manually
adding signatures rc.conf*:
Must be present or default list is overridden.
providersTable=“myprovider1 $providersTable”
myprovider1__uri=“^pulver.fwd.net$”
myprovider1__name=“Free World Dialup”
Regular expression used

to identify the provider.
Name of the provider.

tcp_port
 The tcp_port condition lets you limit an action to a range of TCP

ports.
Syntax:
if <node qualifier> tcp_port <port|port_range> then …
 One of the following node qualifiers must be used to identify the

endpoint whose TCP port must match the specified number or range:
Example:
if client tcp_port 1400-1450 then <action>

time
 The time of day condition lets you limit an action to a specific time frame.
Syntax:
time wday wday_list

time wday wday_list hours hhmm-hhmm [hours hhmm-hhmm]…
time hours hhmm-hhmm [hours hhmm-hhmm]…
 Specifying days of the week (wday_list):

• Days of the week are specified using a three character abbreviation for the day
(Mon) or by spelling out the entire day (Monday).
• The first character in the string can be either upper or lower case, with the
remaining character being lower case.
• Week day abbreviations are Mon, Tue, Wed, Thu, Fri, Sat and Sun.
• A range of days is specified using a dash (Mon-Fri, Friday-Monday).
• Use a comma-separated list to specify multiple individual days.

time
Specifying the time of day (hhmm-hhmm):
 Hours (hh) are in 24 hour format.

 Time conditions may be followed by GMT which indicates that days and
times are in Coordinated Universal Time (UTC).
 When GMT is not present, local time is assumed.
 Only local time and UTC are supported.
Examples:
if time wday saturday,sunday then …

if time wday mon-fri hours 1800-2300 then …
if time hours 0600-1000 hours 1200-1600 then …
if time hours 0900-1700 GMT then …

time – Tips ‘n’ Tricks
 If a weekday and hours are both specified, the hours can extend
beyond the specified day.
if time wday Fri hours 1800-0200 then …
 In the above condition, the period will start at 6pm on Friday and
extend to 2 AM on Saturday.
 Don’t forget that you can use the boolean “not” operator for
conditions outside a certain time frame.
Example: “primetime” is between 5pm and 11pm every day and you
want to apply certain actions in the hours outside primetime:
if time hours 0000-1659 hours 2301-2359 then …
if not time hours 1700-2300 then … Much easier!

true
 Every condition evaluation, no matter how complex, ultimately

results in a value of true or false.
 The true keyword is a special condition that allows us to say “I
always want to perform this action.”
Syntax:
if true then <action>
Example – the first line of nearly every policy.conf file is:
if true then count and count demographic
 This line tells the policy engine to always execute the “count”
and “count demographic” actions.
udp_port
 The udp_port condition lets you limit an action to a range of UDP

ports.
Syntax:
if <node qualifier> udp_port <port|port_range> then …
 One of the following node qualifiers must be used to identify the

endpoint whose UDP port must match the specified number or
range:
Example:
if client udp_port 100-999 then <action>

Lesson: Actions
Learning Objectives
understanding of policy language actions.
Section 1 - Module 1 - Policy Language slide 59

Valid Actions
 allow  mark
 block  reevaluate
 captive_portal  set_attribute
 count  shape
 divert  tcp_reset
 limit  tee

allow & block Action
allow
 Permits specified traffic to flow unimpeded and unhindered through the PTS.
 It will then pass straight thru the box and will show up in reports.
Example:
if protocol “http_get” then allow
block
 Stops specified traffic from flowing through the PTS.
 Packets are dropped.
Example:
if protocol “some_protocol” then block

captive_portal
Captive Portal allows you to re-direct a subscriber’s HTTP session to a set URL.
This example redirects a top-talker to a captive portal:
PolicyGroup {
if protocol "http_get" and server class "portal" then allow
if protocol "http_get" and client "abuser"="true" then \
captive_portal "http://myportal.domain.com/abuser.rvt"
}

count
The count action can be used to collect four types of statistics:

 count - port based transmit/receive statistics
 count demographic - Network class based statistics, including
protocol
 count subscriber
• Statistics relating to a particular node qualifier, protocol and/or

subscriber in addition to port statistics.
• Subscriber to IP mapping must be enabled
 count voip_qoe
• Enables the VoIP feature which analyses VoIP calls.

• Collects a variety of information relevant to the call, as well as a variety
of quality of experience (QoE) results.

count - Examples
 count example:
if true then count

 count demographic example:
if true then count demographic

 count subscriber syntax:
if true then count client|server|sender|receiver

subscriber basic|protocol
 count subscriber example:
if server class “internal” then count server \

subscriber protocol
 count voip_qoe example:
if protocol “sip” then count voip_qoe

divert
Original
Server
Subscriber
Divert redirects the flow to an alternate destination (server)
ISP Network DATA
DATA
Full divert
Half divert
Divert host(s)
divert
The PTS redirects the flow to a different host.
Syntax:
destination “name” divert ip address \

[reset_server true|false][max_connections n] \
[tcp_syn true|false]
if <condition> then \
divert destination “name”
Example:
destination “Advertising” divert ip 5.6.7.8 \

reset_server false tcp_syn true
if protocol “http” then divert destination “Advertising”

limit
Restricts to a maximum number of sessions by inserting tcp_resets.
Example:
if protocol “ares” and sender class “pop1” \

then limit 10
In this example it will limit the number

of Ares upload connections to ten.

mark
 Sets the TOS field in the IP header to a specified value.
 Used by downstream network equipment to identify it for specific uses and
priorities, e.g. QoS.
Syntax:
mark <mask value> | dscp <value>
Examples: Mask value
if protocol "edonkey" then mark 255 10 value
if protocol "fasttrack" then mark dscp 62 Mask value = 252
PolicyGroup {
if protocol “ps2_callofduty” then mark dscp 34
if protocol “skype” then mark 248 6
if true mark dscp 6
}

reevaluate
 Force a flow to be reevaluated after a set period of time or when the

direction of data transfer in the flow changes.
 Only for bi-directional protocols such as bit torrent and edonkey.
Unidirectional protocols won’t change direction. Allows you to keep an
eye on flows that you believe may change direction and affect
bandwidth on your network.
Example:
if protocol “edonkey” then reevaluate flow on \

DataTransferDirection
if server class “special” then reevaluate flow after \

45 seconds

set_attribute
 This will set a specified attribute for a subscriber locally on the

PTS or in the database.
 A node qualifier must be used to specify the subscriber in the
flow for whom the attribute will be set.
Syntax:
set_attribute node_qualifier “attribute_name" = "value“

for time period
Example:
if ip_addr 192.168.2.1 then \
set_attribute subscriber “abuser” = “true” for 2 days

shape
Controls the amount of bandwidth available to a flow based on specified

conditions:
Syntax:
shaper “<shaper name>” <rate> <buffer>
if <condition> then shape to <node qualifier> shaper

“<shaper name>”
Shaper definition
Example:
Policy statement
shaper "simple" 20Kbps 5Kbytes
if protocol “ares" then \

shape to subscriber shaper "simple"

tcp_reset
Terminates TCP based connections by injecting a TCP reset into the flow.
Syntax:
if <condition> then tcp_reset
Example:
if protocol "gnutella" and server class "external" \

then tcp_reset

tee
Original
Server
Subscriber
Tee copies the flow to an alternate destination (file or server)
ISP Network
DATA
Copy of data
Tee host
tee
Sends a copy of selected packets to another host or file.
Syntax:
destination “<name>” \
divert|tee|file|group|ipmap <args>
if <condition> then \
tee to|from client|server destination “name”
Example:
destination “T1” file “CaptureFile”
if protocol "unknownTCP" \
then tee from client destination “T1" \
and tee from server destination “T1”
This policy will cause a file to be written to the PTS: /d2/var/captures/CaptureFile

‘include’ Statement - Nesting Policy files
Use the ‘include’ statement as a pointer to separate policy files in
order to:
 Keep the policy organized
 Break out or organize policies of related type
 Test and troubleshoot

‘include’ Statement - Nesting Policy files
Example:
include “/usr/local/sandvine/ptsd/policy2.conf”
Example used with Top Talkers:
include "/usr/local/sandvine/etc/policy.conf.top_talker“
policy2.conf
policy.conf
policy.conf.test
include “policy2.conf.test”
include “policy2.conf”
include “policy.conf.toptalker”
policy.conf.toptalker

Initializing Policy Rules
When the policy.conf file has been changed, you must run this command:
# svreload
Then check to ensure the processes are running:
# show system services

Name AdminStatus OperStatus AdminStarts AdminStops Faults
-------- ----------- ------------ ----------- ---------- ------
sfcd [up] [online} 1 0 0
ptsd [up] [online] 1 0 1
ptsm [up] [online] 1 0 0
cnd [up] [online] 1 0 0
scdpd [up] [online] 0 0 0
svbgpd [down] [disabled] 1 1 1

Checking Policy Errors
/var/log/svlog Check for errors by examining the log file:
Example:
#less policy.conf
if protocol "skype" then count
if protocol sipdata" then count demographic
Results in the following errors:
# tail /var/log/svlog
Apr 6 14:41:56 TSE1 ptsd: svlog01;0000007640;0000008689:Sandvine libprotocols: `4.22.0014:
20060113_22:47:57`
Apr 6 14:41:59 TSE1 ptsd: svlog01;0000007640;0000007390:Error loading policy: Èrror on
line `2`: Ùnexpected character: s``
Apr 6 14:41:59 TSE1 ptsd: svlog01;0000007640;0000008725:Error on line `2`: Ùnexpected
character: s`
Apr 6 14:41:59 TSE1 ptsd: svlog01;0000007640;0000008691:Error Loading Policy Configuration
Apr 6 14:41:59 TSE1 ptsd: svlog01;0000007162;0000011662:Loading policy files complete
Apr 6 14:41:59 TSE1 ptsd: svlog01;0000006467;0000008687:PTSD System Startup Completed

#less policy.conf
if protocol "sipdata" then count demographic
Results in the following errors:
Apr 6 14:49:49 TSE1 ptsd: svlog01;0000007640;0000008596:Line `2`: Ignoring unsupported

rule
Apr 6 14:49:49 TSE1 ptsd: svlog01;0000007640;0000007607:Loaded policy file:

`/usr/local/sandvine/etc/policy.conf`
Apr 6 14:49:49 TSE1 ptsd: svlog01;0000007640;0000008077:Error loading policy file

Apr 6 14:49:49 TSE1 ptsd: svlog01;0000007640;0000008691:Error Loading Policy

Configuration
Apr 6 14:49:49 TSE1 ptsd: svlog01;0000007162;0000011662:Loading policy files complete
Apr 6 14:49:50 TSE1 ptsd: svlog01;0000006467;0000008687:PTSD System Startup Completed

#less policy.conf
if protocol "sip_data" then count demographic
Results in no errors:
Apr 6 14:54:30 TSE1 ptsd: svlog01;0000007640;0000008689:Sandvine libprotocols:
`4.22.0014: 20060113_22:47:57`
Apr 6 14:54:33 TSE1 ptsd: svlog01;0000007640;0000007607:Loaded policy file:
Apr 6 14:54:33 TSE1 ptsd: svlog01;0000007640;0000008690:Policy Configuration Loaded
Apr 6 14:54:33 TSE1 ptsd: svlog01;0000007642;0000008052:Created tracker for `SIP
Control`
Apr 6 14:54:33 TSE1 ptsd: svlog01;0000007162;0000011662:Loading policy files
complete
Apr 6 14:54:33 TSE1 ptsd: svlog01;0000006467;0000008687:PTSD System Startup
Completed

Lesson: Policy Language Exercises
Learning Objectives
On successful completion of this exercise, you will demonstrate an
ability to write simple policy.

Policy Language Exercise – Tasks: 1
Write a policy that will track all interface based and network
class stats for all protocol types:
if true then count and count demographic

Write a policy that will block all traffic with the exception of HTTP:
if not protocol “http” then block

Write a policy that will block http, fasttrack, winmx and gnutella
downloads by subscribers.
if receiver class “internal” and (protocol “http” or \

protocol “winmx” or protocol “fasttrack” or \
protocol “gnutella”) then block
Why is the 2nd option preferable?
or…
if sender class “external” and (protocol “http” or \

protocol “winmx” or protocol “fasttrack” or \
protocol “gnutella”) then block

Write a policy that will limit the number of upload connections to the
internet to 10 connections for the FastTrack protocol:
if protocol “fasttrack” and receiver class external”\

then limit 10
Which option preferable?
or…
if protocol “fasttrack” and sender class “internal”\

then limit 10

Write a policy that will mark SIP Data traffic as dscp 6 between
0800 and 1700 hours Monday through Friday:
if protocol “sip_data” and (time wday mon-fri hours 0800-1700) \

then mark dscp 6

Summary
You now know how to carry out system operation and use policy language.
You are now able to:
Describe the fundamentals of policy language
Describe policy groups
Describe the use of node qualifiers
Explain and use policy language conditions and actions
Initialize policy rules
PTS Operation Course (Part 2) Section 1 Module 1 - Policy Language Slide 87

S03M01 Policy Language

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

S03M01 Policy Language

Uploaded by

Copyright:

Available Formats

Section 3 Module 1

On completion of this module you will have an

PTS Operation Course (Part 2) Section 1 Module 1 - Policy Language slide 3

PTS Operation Course (Part 2) Section 1 Module 1 - Policy Language slide 4

rc.conf subnets.txt policy.conf

 Policies are used for various purposes:

 PTS policy language is flexible and user friendly.

 Every flow evaluated by the PTS is tested against these rules.

if <condition(s)> then <action(s)>

Policy language example:

if protocol “bittorrent" then shape …

PTS Operation Course (Part 2) Section 1 Module 1 - Policy Language slide 6

Conditions are used to identify when you want to do something.

PTS Operation Course (Part 2) Section 1 Module 1 - Policy Language slide 7

Sandvine Essentials Training Section 3 Module 1 - Policy Language slide 8

 A rule is a single command line string

PTS Operation Course (Part 2) Section 1 Module 1 - Policy Language slide 9

 Order of operations is “and” before “or”

 Use parentheses to set order of operations: anything in

 Actions may include “and” but not “or”

if (protocol “edonkey” or protocol “bittorrent”) and \

PTS Operation Course (Part 2) Section 1 Module 1 - Policy Language slide 10

 Every rule is evaluated for every flow being inspected.

PTS Operation Course (Part 2) Section 1 Module 1 - Policy Language slide 11

PTS Operation Course (Part 2) Section 1 Module 1 - Policy Language slide 12

 Precedence is used to resolve incompatible action

if protocol "bittorrent" then divert

 In the above example, all bittorrent flows will get diverted

Sandvine Essentials Training Section 3 Module 1 - Policy Language slide 13

if protocol “bittorrent” then <action 1>

With a policy group: Within a PolicyGroup, if this condition is true we

Sandvine Essentials Training Section 3 Module 1 - Policy Language slide 14

 Caution must be used when nesting Policy Groups:

Sandvine Essentials Training Section 3 Module 1 - Policy Language slide 16

 Policy Groups can be used to make policy more efficient by evaluating

Without a policy group:

if (time hours 0800-1700) and protocol “skype” then <action 1>

 In the above example, we unnecessarily evaluate the time condition

With a policy group:

Sandvine Essentials Training Section 3 Module 1 - Policy Language slide 17

Sandvine Essentials Training Section 3 Module 1 - Policy Language slide 18

Policy Groups can be used in 3 ways:

Sandvine Essentials Training Section 3 Module 1 - Policy Language slide 19

 Understand how to use node qualifiers in policy to specify direction

PTS Operation Course (Part 2) Section 1 Module 1 - Policy Language slide 20

Consider this policy statement:

if protocol “bittorrent” then <action>

 It does not differentiate between upstream and downstream

PTS Operation Course (Part 2) Section 1 Module 1 - Policy Language slide 22

 To use node qualifiers in policy, we write conditions such as:

PTS Operation Course (Part 2) Section 1 Module 1 - Policy Language slide 23

Always the initiator of the session

Always the acceptor of the session (sends

client “to client” = downstream server

 It could be either – depending on whether the initiator of the

PTS Operation Course (Part 2) Section 1 Module 1 - Policy Language slide 25

The host that is transmitting data

The host that is receiving data

sender “to sender” = downstream receiver

receiver “to sender” = upstream sender

PTS Operation Course (Part 2) Section 1 Module 1 - Policy Language slide 27

The side of the flow that transmits and

PTS Operation Course (Part 2) Section 1 Module 1 - Policy Language slide 28

• Is “to internet” upstream or downstream? upstream