Policy Applications
The following sections describe several practical applications of policy management.
Policy Routing
Policy routing allows the router to classify a packet on ingress and make a forwarding decision based on that classification, without performing the normal routing table processing. This feature provides superior performance for real-time applications.
For IP policy lists, policy rules are available to allow you to make a forwarding decision that includes the next interface and next hop:
- Forward next interface—Causes an interface to forward all packets that satisfy the classification associated with that rule to the next interface specified
- Forward next hop—Causes an interface to forward all packets that satisfy the classification associated with that rule to the next-hop address specified
For example, you can route packets arriving at IP interface ATM 0/0.0 so that they area handled as indicated:
- Packets from source 1.1.1.1 are forwarded out of interface ATM 0/0.1.
- Packets from source 2.2.2.2 are forwarded out of interface ATM 2/1.1.
- All other packets are dropped.
To configure this routing policy, issue the following commands:
host1(config)#ip classifier-list claclA ip host 1.1.1.1 any
host1(config)#ip classifier-list claclB ip host 2.2.2.2 any
host1(config)#ip policy-list IpPolicy100
host1(config-policy-list)#classifier-group claclA
host1(config-policy-list-classifier-group)#forward interface atm 0/0.1
host1(config-policy-list-classifier-group)#exit
host1(config-policy-list)#classifier-group claclB
host1(config-policy-list-classifier-group)#forward interface atm 2/1.1
host1(config-policy-list-classifier-group)#exit host1(config-policy-list)#classifier-group *
host1(config-policy-list-classifier-group)#filter
host1(config-policy-list-classifier-group)#exit
host1(config)#interface atm 0/0.0
host1(config-subif)#ip policy input IpPolicy100 statistics enabled
Security
You can configure policy management to provide a level of network security by using policy rules that selectively forward or filter packet flows:
- Forward—Causes the packet flows that satisfy the classification associated with the rule to be routed by the virtual router
- Filter—Causes the interface to drop all packets of the packet flow that satisfy the classification associated with the rule
To stop a denial-of-service attack, you can use a policy with a filter rule. You need to construct the classifier list associated with the filter rule so that it isolates the attacker's traffic into a flow. You should determine the criteria for this classifier list by analyzing the traffic received on an interface. Packet Flow Monitoring, describes how to capture packets into a log.
For example, you can route packets entering an IP interface (ATM 0/0.0) so that they are handled as indicated:
- Packets from source 1.1.1.1 are routed.
- TCP packets from source 2.2.2.2 with the IP fragmentation offset set to one are dropped.
- All other TCP packets are routed.
- All other packets are dropped.
To configure this policy, issue the following commands:
host1(config)#ip classifier-list claclA ip host 1.1.1.1 any
host1(config)#ip classifier-list claclB tcp host 2.2.2.2 any ip-frag-offset eq 1
host1(config)#ip classifier-list claclC tcp any any
host1(config)#ip policy-list IpPolicy100
host1(config-policy-list)#classifier-group claclA
host1(config-policy-list-classifier-group)#forward
host1(config-policy-list-classifier-group)#exit
host1(config-policy-list)#classifier-group claclB
host1(config-policy-list-classifier-group)#filter
host1(config-policy-list-classifier-group)#exit
host1(config-policy-list)#classifier-group claclC
host1(config-policy-list-classifier-group)#forward
host1(config-policy-list-classifier-group)#exit
host1(config-policy-list)#classifier-group *
host1(config-policy-list-classifier-group)#filter
host1(config-policy-list-classifier-group)#exit
host1(config)#interface atm 0/0.0
host1(config-subif)#ip policy input IpPolicy100 statistics enabled
Bandwidth Management
To enforce ingress data rates below the physical line rate of a port, you can rate limit a classified packet flow at ingress. A rate-limit profile with a policy rate-limit profile rule provides this capability. The rate-limit profile defines the attributes of the desired rate.
You can set an action based on one rate or two rates. These actions include drop, transmit, or mark. The default is to transmit committed and conformed packets, and to drop exceeded packets.
A color-coded tag is added automatically to each packet based on the following categories:
The queuing system uses drop eligibility to select packets for dropping when there is congestion on an egress interface. This method is called dynamic color-based threshold dropping. Each packet queue has two color-based thresholds as well as a queue limit:
- Red packets are dropped when congestion causes the queue to fill above the red threshold.
- Yellow packets are dropped when the yellow threshold is reached.
- Green packets are dropped when the queue limit is reached.
Figure 2 illustrates congestion management.
One-Rate Rate-Limit Profile
A one-rate rate-limit profile can be configured for hard tail drop rate-limit or TCP-friendly behavior. Packets can be categorized as committed, conformed, or exceeded.
Example 1
You can configure a one-rate rate-limit profile to hard limit a packet flow to a specified rate. To rate limit the traffic on an interface from source IP address 1.1.1.1 to 1 Mbps, issue the following commands:
host1#configure terminal
host1(config)#ip rate-limit-profile oneMegRlp one-rate
host1(config-rate-limit-profile)#committed-rate 1000000
host1(config-rate-limit-profile)#exit
host1(config)#ip classifier-list claclA ip host 1.1.1.1 any
host1(config)#ip policy-list testPolicy
host1(config-policy-list)#classifier-group claclA
host1(config-policy-list-classifier-group)#rate-limit-profile oneMegRlp
host1(config-policy-list-classifier-group)#exit
host1(config-policy-list)#exit
host1(config)#interface atm 0/0.0
host1(config-subif)#ip policy input testPolicy statistics enabled
Example 2
You can also configure a one-rate rate-limit profile to provide a TCP-friendly rate limiter. To configure a rate limiter with TCP-friendly characteristics, we recommend that you set the committed burst to allow for 1 second of data at the specified rate, and the excess burst to allow 1.5 seconds of data at the specified committed rate plus the committed burst. For example:
host1(config)#ip rate-limit-profile tcpFriendly8MB one-rate
host1(config-rate-limit-profile)#committed-rate 8000000
host1(config-rate-limit-profile)#committed-burst 1000000
host1(config-rate-limit-profile)#excess-burst 2500000
host1(config-rate-limit-profile)#committed-action transmit
host1(config-rate-limit-profile)#exceeded-action drop
Two-Rate Rate-Limit Profile
You can configure a two-rate rate-limit profile for two different rates, committed and peak, that are used to define a two-rate, three-color marking mechanism. You can categorize packets as committed, conformed, or exceeded:
- Up to the committed rate, packets are considered to be committed.
- From the committed to peak rate, packets are considered to be conformed.
- After the peak rate, packets are considered to be exceeded.
This configuration is implemented with token buckets. See RFC 2698 for more details.
Example
The following example rate limits traffic on an interface from source IP address 1.1.1.1 so that traffic at a rate up to 1 Mbps is colored green and transmitted, traffic at a rate from 1 Mbps to 2 Mbps is colored yellow and transmitted, and traffic at a rate above 2 Mbps is dropped.
host1(config)#ip rate-limit-profile 1MbRLP
host1(config-rate-limit-profile)#committed-rate 1000000
host1(config-rate-limit-profile)#peak-rate 2000000
host1(config-rate-limit-profile)#committed-action transmit
host1(config-rate-limit-profile)#conformed-action transmit
host1(config-rate-limit-profile)#exceeded-action drop
host1(config-rate-limit-profile)#exit
host1(config)#ip classifier-list claclA ip host 1.1.1.1 any
host1(config)#ip policy-list testPolicy
host1(config-policy-list)#classifier-group claclA
host1(config-policy-list-classifier-group)#rate-limit-profile 1MbRLP
host1(config-policy-list-classifier-grouip)#exit
host1(config-policy-list)#exit
host1(config)#interface atm 0/0.0
host1(config-subif)#ip policy input testPolicy statistics enabled
Rate Limiting Individual or Aggregate Packet Flows
You can construct policies to provide rate limiting for individual packet flows or for the aggregate of multiple packet flows. For example, if you have traffic from multiple sources, you can either rate limit each traffic flow individually, or you can rate limit the aggregate flow for the traffic from all sources.
- To rate limit individual packet flows, use a separate classifier list to classify each flow. See Example 1: Individual Packet Flows.
- To rate limit the aggregate of multiple traffic flows, use a single classifier list for the multiple entries. See Example 2: Multiple Traffic Flows.
Example 1: Individual Packet Flows
In the following example, interface ATM 3/1.1 classifies on three traffic flows from different sources. Each traffic flow is rate limited to 1MB (which is defined by the rate-limit profile rl1Meg).
host1(config)#classifier-list clFlow1 ip host 10.1.1.1 any
host1(config)#classifier-list clFlow2 ip host 10.1.1.2 any
host1(config)#classifier-list clFlow3 ip host 10.1.1.3 any
host1(config)#policy-list plRateLimit
host1(config-policy-list)#classifier-group clFlow1
host1(config-policy-list-classifier-group)#rate-limit-profile rl1Meg
host1(config-policy-list-classifier-group)#exit
host1(config-policy-list)#classifier-group clFlow2
host1(config-policy-list-classifier-group)#rate-limit-profile rl1Meg
host1(config-policy-list-classifier-group)#exit
host1(config-policy-list)#classifier-group clFlow3
host1(config-policy-list-classifier-group)#rate-limit-profile rl1Meg
host1(config-policy-list-classifier-group)#exit
host1(config-policy-list)#exit
host1(config)#interface atm 3/1.1
host1(config-subif)#ip policy input plRateLimit statistics enabled
host1(config-subif)#exit
host1(config)#
Example 2: Multiple Traffic Flows
In the following example, interface ATM 3/1.1 again classifies on three traffic flows; however, this policy rate limits the aggregate of the three flows to 1MB.
host1(config)#classifier-list clFlowAll ip host 10.1.1.1 any
host1(config)#classifier-list clFlowAll ip host 10.1.1.2 any
host1(config)#classifier-list clFlowAll ip host 10.1.1.3 any
host1(config)#policy-list plRateLimit
host1(config-policy-list)#classifier-group clFlowAll
host1(config-policy-list-classifier-group)#exit
host1(config-policy-list)#exit
host1(config)#interface atm 3/1.1
host1(config-subif)#ip policy input plRateLimit statistics enabled
host1(config-subif)#exit
host1(config)#
Packet Tagging
You can use the traffic-class rule in policies to tag a packet flow so that the QoS application can provide traffic-class queuing. Policies can perform both in-band and out-of-band packet tagging:
- Policies perform in-band tagging by using their respective mark rule to modify a packet header field. For example, IP policies use the mark rule to modify an IP packet heard ToS field, and Frame Relay policies use the mark-de rule to modify the DE bit.
- Policies perform out-of-band tagging by using the traffic class or color rule. Explicit packet coloring lets you configure prioritized packet flows without having to configure a rate-limit profile. The router uses the color to queue packets for egress queue threshold dropping as described in Bandwidth Management.
Example
Suppose an Internet service provider (ISP) provides a Broadband Remote Access Server (B-RAS) service that has both video and data components, and the ISP wants to guarantee that the video traffic gets priority treatment relative to the data traffic. The ISP's users have a 1.5 Mbps virtual circuit (VC) terminating on a digital subscriber line access multiplexer (DSLAM). The ISP wants to allocate 800 Kbps of this link for video, if there is a video stream.
The ISP creates a classifier list to define a video packet flow, creates a policy to color the packets, and applies the policy to the interface:
host1(config)#ip classifier-list video ip any any dsfield 16
host1(config)#ip classifier-list data ip any any dsfield 32
host1(config)#ip policy-list colorVideoGreen
host1(config-policy-list)#classifier-group video
host1(config-policy-list-classifier-group)#color green
host1(config-policy-list-classifier-group)#exit
host1(config-policy-list)#classifier-group data
host1(config-policy-list-classifier-group)#color yellow
host1(config-policy-list-classifier-group)#exit
host1(config-policy-list)#exit
host1(config)#interface atm 12/1.1
host1(config-if)#ip policy input colorVideoGreen statistics enabled
Packet Flow Monitoring
The policy log rule provides a way to monitor a packet flow by capturing a sample of the packets that satisfy the classification of the rule in the system log. See JUNOSe System Basics Configuration Guide, Chapter 13, Logging System Events for information about logging.
To capture the interface, protocol, source address, destination address, source port, and destination port, set the policyMgrPacketLog event category to log at severity info and at low verbosity. To capture the version, ToS, len ID, flags, time to live (TTL), protocol, and checksum in addition to the information captured at low verbosity, set the verbosity to medium or high.
When the policy is configured, all packets are examined and the matching packets are placed in the log. No more than 512 packets will be logged every three seconds. The router maintains a count of the total number of matching packets. This count is incremented even if the packet cannot be stored in the log (for example, because the count exceeds the 512-packet threshold).
Example 1: Logging Ingress Packets on an Interface
This example shows how you might use classification to specify the ingress packets that are logged on an interface.
host1(config)#ip policy-list testPolicy
host1(config-policy-list)#classifier-group logA
host1(config-policy-list-classifier-group)#log
host1(config-policy-list-classifier-group)#exit
host1(config-policy-list)#exit
host1(config)#interface atm 0/0.0
host1(config-subif)#ip policy input testPolicy statistics enabled
host1(config-subif)#exit
host1(config)#log destination console severity info
host1(config)#log severity info policyMgrPacketLog
host1(config)#log verbosity low policyMgrPacketLog
host1(config)#log here
Example 2: Logging a Ping Attack
This example provides a more detailed procedure that an ISP might use to log information during a ping attack on the network. The procedure includes the creation of the classifier and policy lists to specify the desired packet flow to monitor, the logging of the output of the classification operation, and the output of the show command.
In this example, a customer has reported to their ISP that an attack is occurring on their internal servers. The attack is a simple ping flood.
- The ISP creates a classifier list to define an ICMP echo request packet flow.
- The ISP configures standard logging on the E-series router.
- The ISP displays statistics for the interface.
host1:vr2(config)#classifier-list icmpEchoReq icmp any any 8 0
host1:vr2(config)#policy-list pingAttack
host1:vr2(config-policy-list)#classifier-group icmpEchoReq
host1:vr2(config-policy-list-classifier-group)#log
host1:vr2(config-policy-list-classifier-group)#exit
host1:vr2(config-policy-list)#exit
host1:vr2(config)#interface gigabitEthernet 2/0
host1:vr2(config-if)#ip address 10.10.10.2 255.255.255.0
host1:vr2(config-if)#exit
host1:vr2(config)#virtual-router vr1
host1:vr1(config)#interface gigabitEthernet 0/0
host1:vr1(config-if)#ip address 10.10.10.1 255.255.255.0
host1:vr1(config-if)#ip policy input pingAttack statistics enabled
host1:vr1(config-if)#exit
host1:vr1(config)#exit
host1(config)#log destination console severity info
host1(config)#log severity info policyMgrPacketLog
host1(config)#log here
INFO 12/16/2003 12:59:47 policyMgrPacketLog ():
icmpEchoReq icmp GigabitEthernet0/0 10.10.10.2 10.10.10.1 forwarded
INFO 12/16/2003 12:59:47 policyMgrPacketLog ():
icmpEchoReq GigabitEthernet0/0 number of hits = 21551
INFO 12/16/2003 12:59:50 policyMgrPacketLog ():
icmpEchoReq icmp GigabitEthernet0/0 10.10.10.2 10.10.10.1 forwarded
INFO 12/16/2003 12:59:50 policyMgrPacketLog ():
icmpEchoReq GigabitEthernet0/0 number of hits = 21851
INFO 12/16/2003 12:59:53 policyMgrPacketLog ():
icmpEchoReq icmp GigabitEthernet0/0 10.10.10.2 10.10.10.1 forwarded
INFO 12/16/2003 12:59:53 policyMgrPacketLog ():
icmpEchoReq GigabitEthernet0/0 number of hits = 22151
host1:vr1#show ip interface gigabitEthernet 0/0
GigabitEthernet0/0 line protocol Ethernet is up, ip is up
Network Protocols: IP
Internet address is 10.10.10.1/255.255.255.0
Broadcast address is 255.255.255.255
Operational MTU = 1500 Administrative MTU = 0
Operational speed = 1000000000 Administrative speed = 0
Discontinuity Time = 1092358
Router advertisement = disabled
Proxy Arp = enabled
Network Address Translation is disabled
Administrative debounce-time = disabled
Operational debounce-time = disabled
Access routing = disabled
Multipath mode = hashed
Auto Configure = disabled
Auto Detect = disabled
Inactivity Timer = disabled
In Received Packets 488421, Bytes 62517888
Unicast Packets 488421, Bytes 62517888
Multicast Packets 0, Bytes 0
In Policed Packets 0, Bytes 0
In Error Packets 0
In Invalid Source Address Packets 0
In Discarded Packets 0
Out Forwarded Packets 486152, Bytes 62232048
Unicast Packets 486152, Bytes 62232048
Multicast Routed Packets 0, Bytes 0
Out Scheduler Dropped Packets 0, Bytes 0
Out Policed Packets 0, Bytes 0
Out Discarded Packets 2269
IP policy input pingAttack
classifier-group icmpEchoReq entry 1
488421 packets, 69355782 bytes
log
queue 0: traffic class best-effort, bound to ip GigabitEthernet0/0
Queue length 0 bytes
Forwarded packets 485988, bytes 70954248
Dropped committed packets 0, bytes 0
Dropped conformed packets 0, bytes 0
Dropped exceeded packets 0, bytes 0