Policies are made up of conditions and actions that cause the router to handle packets in a certain way.
Here are two examples of policies with conditions and actions:
The SRC policy information model is designed to consolidate information models from various devices to provide a standard way to configure policies. This way, similar operations on different devices are represented as a single policy action or condition which is translated to device-specific operations. For example, the SRC policy information model provides an action that forwards traffic. This action is translated into actions such as forward, accept, or simple handoff on various routers. For instances in which policy conditions or actions are significantly different, the model provides support for each type of condition or action. For example, because rate-limiting on routers running JUNOSe Software is significantly different than policing on routers running JUNOS Software, the SRC software provides a rate-limit action for routers running JUNOSe Software and policer action for routers running JUNOS Software.
For routers running JUNOSe Software, SRC policies are translated at the COPS-PR or COPS-XDR level, and at the router level. For routers running JUNOS Software, policies are translated at the JUNOS XML on BEEP level and at the router level.
The SRC policy model also lets you simplify policy configuration for policy conditions that classify traffic. For JUNOSe and PCMM policies, you can combine different conditions that classify traffic and configure these conditions to use a single action. In addition for JUNOSe policies, you can create a condition which actually represents a number of classifiers. The SAE expands the classifier to multiple classifiers before installing them on the router. For routers running JUNOSe Software, you can also configure hierarchical rate limits to provide dynamic bandwidth sharing.
For more information about multiple classifiers and expanded classifiers, see Policy Components.
The SRC policy model is made up of objects that are organized as shown in Figure 7.
Figure 7: Policy Object Organization

The following is a description of these objects:
Routers running JUNOSe Software support IP4 and IPv6 policy rules, PCMM devices support one type of policy rule, and routers running JUNOS Software support five types of policy rules:
Supports stateful firewall and Network Address Translation (NAT) services.
Supports transmission scheduling and rate control parameters on interfaces that support the per-unit scheduler. Schedulers define the priority, bandwidth, delay buffer size, rate control status, and RED drop profiles to be applied to a particular class of traffic.
Supports setting a shaping rate on PICS that support shaping rate and on interfaces that support the per-unit scheduler.
Supports JUNOS firewall filters.
Supports policing, or rate limiting, by enabling you to limit the amount of traffic that passes into or out of an interface. It is an essential component of firewall filters that is designed to thwart denial-of-service attacks.
Policing applies two types of rate limits on the traffic:
The types of conditions and actions that are available for a policy rule depend on the type of rule. Figure 8 shows the types of conditions and actions that are available for JUNOS policy rules. Figure 9 shows the types of conditions and actions that are available for JUNOSe policy rules. Figure 10 shows the types of conditions and actions that are available for PCMM policy rules.
Figure 8: JUNOS Policy Rules with Supported Conditions and Actions

Figure 9: JUNOSe Policy Rules with Supported Conditions and Actions

Figure 10: PCMM Policy Rules with Supported Conditions and Actions

Policy conditions are values or fields that a packet must contain. If a policy rule does not contain a match condition, all packets are considered to match. There are two types of conditions:
See also PCMM Classifiers .
JUNOSe and PCMM policy rules can contain multiple classify-traffic conditions. Having multiple classifiers in a policy rule gives you more flexibility for defining services and allows you to use fewer policy rules for some applications.
If multiple policy rules have the same action, but different classify conditions, you can combine the policy rules into one policy rule. You can also set up one policy rule that has multiple classifiers, each for a different subnet or range of addresses.
If you want to collect accounting data on internal versus external traffic, you can configure one policy rule with a set of classifiers for internal traffic and one policy rule with a set of classifiers for external traffic.
Multiple classifiers give you more flexibility for rate-limiting policies. Without multiple classifiers, you can rate-limit only individual traffic flows. With multiple classifiers, you can rate-limit the aggregate of traffic flows from all sources.
The following example uses multiple classifiers to rate-limit traffic to 1 Mbps for traffic going to two different subnets.
Policy List je-in
Policy Rule rate-limiter
ClassifyTrafficCondition CTC1
SourceNetwork:
any
DestinationNetwork:
ipAddress=172.60.40.0/0.0.0.255
ClassifyTrafficCondition CTC2
SourceNetwork:
any
DestinationNetwork:
ipAddress=172.60.20.0/0.0.0.255
Rate limit action that limits to 1 MbpsPolicy List je-out
Policy Rule forward
ClassifyTrafficCondition
DestinationNetwork:
any
SourceNetwork:
any
Forward actionFor JUNOSe policies, you can create classify-traffic conditions that the SAE expands into multiple classifiers before it installs the policy on the router. You can enter a comma-separated list of values in:
The software creates a classifier for each possible combination of address and port. The software does not expand classifiers for values that are entered as a range.
You would use this feature in policies that are used in IP multimedia subsystem (IMS) environments. You can also use it to simplify the configuration of JUNOSe policies.
For example, the following classify-traffic condition has comma-separated lists for IP address, IP mask, an from port:
[edit policies folder f group g list l rule r traffic-condition tc]
user@host# show
source-network {
network {
ip-address "[192.1.1.0,192.2.1.1]";
ip-mask "[255.255.255.0,255.255.255.255]";
ip-operation "[1,1]";
}
}
tcp-condition {
protocol tcp;
protocol-operation 1;
source-port {
port {
from-port "[80,8080]";
port-operation eq;
}
}
}The sample classify-traffic condition is expanded into four classifiers that have the following combination of source addresses and source ports. Note that JUNOSe policies use wildcard, not subnet, masks.
- 192.1.1.0/0.0.0.255 eq 80
- 192.1.1.0/0.0.0.255 eq 8080
- 192.2.1.1/0.0.0.0 eq 80
- 192.2.1.1/0.0.0.0 eq 8080
JUNOS policy rules and PCMM policy rules can have multiple actions. JUNOSe policy rules can have only one action. The types of actions available for a policy rule depend on the type of rule. See Supported Conditions and Actions. The following table is a description of all actions.
Table 6: Policy Actions
JUNOS policy rules and PCMM policy rules support multiple actions. For example, in PCMM policies, you can combine a mark action with a DOCSIS parameter action, a service schedule action, or a FlowSpec action. In JUNOS policy rules you can combine the forwarding class action, routing instance action, and loss priority action. The result is that packets that match the condition are assigned to a forwarding class, directed to a routing instance on the router, and assigned a packet loss priority.
Only one of the following actions can exist in a policy rule: next-hop action, next-interface action, forward action, filter action, and reject action.
For example, if you add the next-rule action to a policy rule, do not add a next-hop action, next-interface action, forward action, filter action, or reject action to the same policy rule.
Although you can have only one action in a JUNOSe policy rule, you can set up a policy list to take two corresponding actions on a packet. To do so, you create a JUNOSe policy list that has more than one policy rule with the same precedence. For example, you might want a policy rule that marks a packet and a policy rule that forwards the packet to the next interface. Or you could have a policy rule that applies a traffic-class action and a policy rule that forwards the packet to the next hop.