ASA CHAPTER 11 (Traffic Policing/Low Latency Queuing)
20. Traffic Policing
• Ensure the ICMP traffic is permitted from the outside.
• In order to reduce the risk of outside users flooding the internal networks
with ICMP packets, limit the traffic-rate to 64Kbps
• Ensure both ingress and egress traffic flows conform to this restriction.
21. Low Latency Queuing
• Provide priority queue service to VoIP traffic going to the inside users.
• Classify the VoIP packets based on RTP port range 16384 32767.
• Set priority queue depth to 5 packets on the inside interface.
Solution:
20. Traffic Policing
• Ensure the ICMP traffic is permitted from the outside.
• In order to reduce the risk of outside users flooding the internal networks
with ICMP packets, limit the traffic-rate to 64Kbps
• Ensure both ingress and egress traffic flows conform to this restriction.
-->
Traffic policing is QoS feature that enforces average traffic rate by dropping
exceeding packets. The main purpose of policing is ensuring that traffic flows
meet the contracted rates. Another useful purpose is limiting the rate of
potentially dangerous traffic, such as ICMP flood, in order to prevent the potential
or actual DoS attack.
Policing applies to traffic matched by a specific L3/L4 class-map. You specify
policing under a policy-map using the syntax:
policy-map POLICY
class TRAFFIC
police {inbound|outbound} CIR [Burst]
Policing applies either ingress or egress on interface. Here CIR(aka Committed
Access Rate) is the average rate enforced in Bps (bits per second). The Burst
value is measured in bytesand defines the maximum amount of traffic that could
be sent/received over interface in given unit of time. This value is not mandatory
and you may omit it – in this case the firewall picks up the “optimal” value
automatically. The larger is the burst, the more averaging the policer does when
metering the traffic, allowing for sudden “spikes” of traffic rate. You can use the
value Tc=Burst/CIRas the reference “averaging interval”. Over this interval the
average rate is always CIR.
You may specify actions for conforming or exceeding traffic using the syntax
police CIR [Burst] conform-action {transmit|drop} exceed-action {transmit|drop}.
Although the ASA cannot remark traffic using the DSCP field, you can use these
actions in two different scenarios:
1) Dropping all packets matching the specific class, e.g.
police 64000 8000 conform-action drop
This could be viewed as alternative to access-list for dropping the unwanted
traffic.
2) Checking if the traffic rate conforms to the contract without affecting traffic flow
(i.e. without dropping any packets), e.g.
police 128000 64000 conform-action transmit exceed-action
transmit.
Policing could be configured in a policy-map that applies either globally or perinterface. When the policy applies globally, it affects all traffic ingress or egress
on all interfaces – depending on the direction of the feature. Remember that
policer drops packets exceeding the average traffic rate. This might severely
affect TCP performance, as this protocol reacts to packet drops by slowing
sending rate. To avoid this effect, try setting Burstto a larger value, based on
the Tcof 1.5-3 seconds of CIR, i.e. Burst = CIR*3/8. However, the optimal
value is usually picked up empirically.
-->
ASA1:
!
access-list ICMP permit icmp any any
!
class-map ICMP
match access-list ICMP
!
policy-map OUTSIDE
class ICMP
police input 64000
police output 64000
!
service-policy OUTSIDE interface outside
!
! Access-list to permit ICMP in/out
!
access-list OUTSIDE_IN permit icmp any any
access-group OUTSIDE_IN in interface outside
!
output:
A(config)# sh service-policy interface outside
Interface outside:
Service-policy: OUTSIDE
Class-map: ICMP
Input police Interface outside:
cir 64000 bps, bc 2000 bytes
conformed 105 packets, 149675 bytes; actions: transmit
exceeded 1 packets, 1514 bytes; actions: drop
conformed 2840 bps, exceed 24 bps
Output police Interface outside:
cir 64000 bps, bc 2000 bytes
conformed 113 packets, 162387 bytes; actions: transmit
exceeded 15 packets, 22710 bytes; actions: drop
conformed 3080 bps, exceed 424 bps
R1#ping 150.1.3.3 size 1500 repeat 100
Type escape sequence to abort.
Sending 100, 1500-byte ICMP Echos to 150.1.3.3, timeout is 2 seconds:
!!!!!!!.!!!!!!.!!!!!!!.!!!!!!!.!!!!!!!.!!!!!!!.!!!!!!!.!!!!!!.!!!!!!!.
!!!!!!!.!!!!!!!.!!!!!!!.!!!!!!
Success rate is 88 percent (88/100), round-trip min/avg/max = 16/26/112 ms
21. Low Latency Queuing
• Provide priority queue service to VoIP traffic going to the inside users.
• Classify the VoIP packets based on RTP port range 16384 32767.
• Set priority queue depth to 5 packets on the inside interface.
-->
Queuing is used to buffer outgoing packets on firewall interfaces when the links
are too congested to accept the traffic. There are two levels of queuing –
hardware queue (aka tx-ring or transmit ring) and software queue, manager by
the firewall. The tx-ring is emptied by the hardware, and when this queue is filled
up, the packets will go to the software queue. The only supported discipline for
the tx-ring is FIFO (first in first out), as this queue is usually serviced pretty fast,
almost at the line rate.
The software queue may hold packets when the physical interface is severely
congested. By default, this queue is serviced in the same FIFO manner as the txring. However, certain types of IP traffic, most notably VoIP bearer packets,
cannot tolerate long delays caused by queuing in software. This is why the
firewall supports the so-called priority or low-latency queuing (LLQ). Priority
software ensures that certain classes of traffic assigned to this queue are always
serviced first and deposited into tx-ring ahead of any other packets.
You may enable priority queue per-interface using the command priorityqueue {iface}in global configuration mode. This will put you in the priorityqueue configuration mode, where you can further set tx-ring size (hardware
queue size in packets) or queue-limit (priority queue depth, in packets). You may
want to lessen the priority-queue depth to limit the effect of priority queue on
other traffic – that is, to prevent bandwidth starvation for non-priority traffic.
However, this might cause excessive packet drops in the priority queue. In
addition to the LLQ, the interface will still have Best Effort (BE) queue assigned,
that services non-priority traffic (after the priority queue has been emptied).
To assign actual traffic to the priority queue, you need to configure and apply a
policy-map to the respective interface. The syntax is as following:
policy-map POLICY
class CLASS
priority
The traffic matching L3/L4 class-map CLASS is serviced using the expedite
(priority) queue on the interface. All other traffic will use the Best Effort queue.
The policy-map could be applied per-interface or globally. In the latter case, it will
have effect on every interface enabled for priority-queue service.
It is common to enable priority-queuing for sensitive, but bandwidth-limited traffic
such as VoIP. However, avoid putting bursty traffic, such as file transfers, in the
priority queue, as this might serious starve other traffic classes. You cannot
police and prioritize the same flow of traffic. When assigning VoIP traffic to
priority queue, you might want to do the following:
a) Police non-prioritized traffic classes, to make sure they don’t fill the tx-ring and
affect VoIP quality.
b) Tune tx-ring size (which is default to 128) to make it shorter. This will force the
software priority queue to be engaged faster and might reduce the VoIP latency.
However, setting tx-ring too small, might affect the overall performance, due to
constant calls for the LLQ scheduler.
Note that the solution below uses special match rtpcommand to classify VoIP
bearer traffic. When using Cisco VoIP solutions, it is common to see VoIP traffic
using RTP port range 16384 32767. However, match rtp command takes two
parameters – initial port, and the “step”, i.e. the number of ports to step up to
cover the RTP port range. Thus the command match rtp 16384 16383
actually covers the default VoIP port range.
-->
ASA1:
!
! Class-map to match voice traffic
!
class-map VOICE
match rtp 16384 16383
!
! LLQ policy-map
!
policy-map LLQ
class VOICE
priority
!
service-policy LLQ interface inside
!
! Tune PQ
!
priority-queue inside
queue-limit 5
!
ASA1(config)# show priority-queue config
<snip>
Priority-Queue Config interface inside
current default range
queue-limit 5 2048 0 - 2048
tx-ring-limit 80 80 3 - 256
Priority-Queue Config interface dmz
current default range
queue-limit 0 2048 0 - 2048
tx-ring-limit -1 80 3 - 256
!
ASA1(config)# show priority-queue statistics
Priority-Queue Statistics interface outside
<snip>
Priority-Queue Statistics interface inside
Queue Type = BE
Packets Dropped = 0
Packets Transmit = 23
Packets Enqueued = 0
Current Q Length = 0
Max Q Length = 0
Queue Type = LLQ
Packets Dropped = 0
Packets Transmit = 0
Packets Enqueued = 0
Current Q Length = 0
Max Q Length = 0
!
20. Traffic Policing
• Ensure the ICMP traffic is permitted from the outside.
• In order to reduce the risk of outside users flooding the internal networks
with ICMP packets, limit the traffic-rate to 64Kbps
• Ensure both ingress and egress traffic flows conform to this restriction.
21. Low Latency Queuing
• Provide priority queue service to VoIP traffic going to the inside users.
• Classify the VoIP packets based on RTP port range 16384 32767.
• Set priority queue depth to 5 packets on the inside interface.
Solution:
20. Traffic Policing
• Ensure the ICMP traffic is permitted from the outside.
• In order to reduce the risk of outside users flooding the internal networks
with ICMP packets, limit the traffic-rate to 64Kbps
• Ensure both ingress and egress traffic flows conform to this restriction.
Traffic policing is QoS feature that enforces average traffic rate by dropping
exceeding packets. The main purpose of policing is ensuring that traffic flows
meet the contracted rates. Another useful purpose is limiting the rate of
potentially dangerous traffic, such as ICMP flood, in order to prevent the potential
or actual DoS attack.
Policing applies to traffic matched by a specific L3/L4 class-map. You specify
policing under a policy-map using the syntax:
policy-map POLICY
class TRAFFIC
police {inbound|outbound} CIR [Burst]
Policing applies either ingress or egress on interface. Here CIR(aka Committed
Access Rate) is the average rate enforced in Bps (bits per second). The Burst
value is measured in bytesand defines the maximum amount of traffic that could
be sent/received over interface in given unit of time. This value is not mandatory
and you may omit it – in this case the firewall picks up the “optimal” value
automatically. The larger is the burst, the more averaging the policer does when
metering the traffic, allowing for sudden “spikes” of traffic rate. You can use the
value Tc=Burst/CIRas the reference “averaging interval”. Over this interval the
average rate is always CIR.
You may specify actions for conforming or exceeding traffic using the syntax
police CIR [Burst] conform-action {transmit|drop} exceed-action {transmit|drop}.
Although the ASA cannot remark traffic using the DSCP field, you can use these
actions in two different scenarios:
1) Dropping all packets matching the specific class, e.g.
police 64000 8000 conform-action drop
This could be viewed as alternative to access-list for dropping the unwanted
traffic.
2) Checking if the traffic rate conforms to the contract without affecting traffic flow
(i.e. without dropping any packets), e.g.
police 128000 64000 conform-action transmit exceed-action
transmit.
Policing could be configured in a policy-map that applies either globally or perinterface. When the policy applies globally, it affects all traffic ingress or egress
on all interfaces – depending on the direction of the feature. Remember that
policer drops packets exceeding the average traffic rate. This might severely
affect TCP performance, as this protocol reacts to packet drops by slowing
sending rate. To avoid this effect, try setting Burstto a larger value, based on
the Tcof 1.5-3 seconds of CIR, i.e. Burst = CIR*3/8. However, the optimal
value is usually picked up empirically.
-->
ASA1:
!
access-list ICMP permit icmp any any
!
class-map ICMP
match access-list ICMP
!
policy-map OUTSIDE
class ICMP
police input 64000
police output 64000
!
service-policy OUTSIDE interface outside
!
! Access-list to permit ICMP in/out
!
access-list OUTSIDE_IN permit icmp any any
access-group OUTSIDE_IN in interface outside
!
output:
A(config)# sh service-policy interface outside
Interface outside:
Service-policy: OUTSIDE
Class-map: ICMP
Input police Interface outside:
cir 64000 bps, bc 2000 bytes
conformed 105 packets, 149675 bytes; actions: transmit
exceeded 1 packets, 1514 bytes; actions: drop
conformed 2840 bps, exceed 24 bps
Output police Interface outside:
cir 64000 bps, bc 2000 bytes
conformed 113 packets, 162387 bytes; actions: transmit
exceeded 15 packets, 22710 bytes; actions: drop
conformed 3080 bps, exceed 424 bps
R1#ping 150.1.3.3 size 1500 repeat 100
Type escape sequence to abort.
Sending 100, 1500-byte ICMP Echos to 150.1.3.3, timeout is 2 seconds:
!!!!!!!.!!!!!!.!!!!!!!.!!!!!!!.!!!!!!!.!!!!!!!.!!!!!!!.!!!!!!.!!!!!!!.
!!!!!!!.!!!!!!!.!!!!!!!.!!!!!!
Success rate is 88 percent (88/100), round-trip min/avg/max = 16/26/112 ms
21. Low Latency Queuing
• Provide priority queue service to VoIP traffic going to the inside users.
• Classify the VoIP packets based on RTP port range 16384 32767.
• Set priority queue depth to 5 packets on the inside interface.
-->
Queuing is used to buffer outgoing packets on firewall interfaces when the links
are too congested to accept the traffic. There are two levels of queuing –
hardware queue (aka tx-ring or transmit ring) and software queue, manager by
the firewall. The tx-ring is emptied by the hardware, and when this queue is filled
up, the packets will go to the software queue. The only supported discipline for
the tx-ring is FIFO (first in first out), as this queue is usually serviced pretty fast,
almost at the line rate.
The software queue may hold packets when the physical interface is severely
congested. By default, this queue is serviced in the same FIFO manner as the txring. However, certain types of IP traffic, most notably VoIP bearer packets,
cannot tolerate long delays caused by queuing in software. This is why the
firewall supports the so-called priority or low-latency queuing (LLQ). Priority
software ensures that certain classes of traffic assigned to this queue are always
serviced first and deposited into tx-ring ahead of any other packets.
You may enable priority queue per-interface using the command priorityqueue {iface}in global configuration mode. This will put you in the priorityqueue configuration mode, where you can further set tx-ring size (hardware
queue size in packets) or queue-limit (priority queue depth, in packets). You may
want to lessen the priority-queue depth to limit the effect of priority queue on
other traffic – that is, to prevent bandwidth starvation for non-priority traffic.
However, this might cause excessive packet drops in the priority queue. In
addition to the LLQ, the interface will still have Best Effort (BE) queue assigned,
that services non-priority traffic (after the priority queue has been emptied).
To assign actual traffic to the priority queue, you need to configure and apply a
policy-map to the respective interface. The syntax is as following:
policy-map POLICY
class CLASS
priority
The traffic matching L3/L4 class-map CLASS is serviced using the expedite
(priority) queue on the interface. All other traffic will use the Best Effort queue.
The policy-map could be applied per-interface or globally. In the latter case, it will
have effect on every interface enabled for priority-queue service.
It is common to enable priority-queuing for sensitive, but bandwidth-limited traffic
such as VoIP. However, avoid putting bursty traffic, such as file transfers, in the
priority queue, as this might serious starve other traffic classes. You cannot
police and prioritize the same flow of traffic. When assigning VoIP traffic to
priority queue, you might want to do the following:
a) Police non-prioritized traffic classes, to make sure they don’t fill the tx-ring and
affect VoIP quality.
b) Tune tx-ring size (which is default to 128) to make it shorter. This will force the
software priority queue to be engaged faster and might reduce the VoIP latency.
However, setting tx-ring too small, might affect the overall performance, due to
constant calls for the LLQ scheduler.
Note that the solution below uses special match rtpcommand to classify VoIP
bearer traffic. When using Cisco VoIP solutions, it is common to see VoIP traffic
using RTP port range 16384 32767. However, match rtp command takes two
parameters – initial port, and the “step”, i.e. the number of ports to step up to
cover the RTP port range. Thus the command match rtp 16384 16383
actually covers the default VoIP port range.
-->
ASA1:
!
! Class-map to match voice traffic
!
class-map VOICE
match rtp 16384 16383
!
! LLQ policy-map
!
policy-map LLQ
class VOICE
priority
!
service-policy LLQ interface inside
!
! Tune PQ
!
priority-queue inside
queue-limit 5
!
ASA1(config)# show priority-queue config
<snip>
Priority-Queue Config interface inside
current default range
queue-limit 5 2048 0 - 2048
tx-ring-limit 80 80 3 - 256
Priority-Queue Config interface dmz
current default range
queue-limit 0 2048 0 - 2048
tx-ring-limit -1 80 3 - 256
!
ASA1(config)# show priority-queue statistics
Priority-Queue Statistics interface outside
<snip>
Priority-Queue Statistics interface inside
Queue Type = BE
Packets Dropped = 0
Packets Transmit = 23
Packets Enqueued = 0
Current Q Length = 0
Max Q Length = 0
Queue Type = LLQ
Packets Dropped = 0
Packets Transmit = 0
Packets Enqueued = 0
Current Q Length = 0
Max Q Length = 0
!
No comments:
Post a Comment