Chapter 25. Quality of Service

This chapter covers the following topics:

QoS types

QoS architecture

Configuring QoS

QoS deployment scenario

Monitoring QoS

In a standard IP network, all packets are processed identically, based on best effort. The network devices usually ignore the importance or criticality of the data that is passing through the network. This creates problems in deployments where time-sensitive traffic, such as voice and video packets, is delayed or dropped because the network devices do not prioritize it over other traffic. The feature of prioritizing some traffic over other traffic is known as quality of service (QoS).

Imagine a long-distance phone call that involves a satellite connection. If the conversation is interrupted with brief, but perceptible, gaps at odd intervals, the ability to communicate is adversely affected. Using QoS, you can prioritize the VoIP traffic to prevent against bandwidth hogging and protect time-sensitive traffic.

QoS is useful in almost any network deployment, including the following:

You run voice, video, and data traffic on the same network. Because voice and video streams are time sensitive and do not tolerate network delays, QoS policies must be implemented to ensure traffic prioritization.

You run data applications such as time-sensitive databases that require traffic prioritization if there is congestion on the network.

You want to prioritize management traffic, such as Telnet or SSH, so that you do not lose access to the network devices if there is an outbreak of a new virus in the local network.

You are a service provider and want to offer different classes of service (CoS) to your customers, based on their needs.

You have virtual private networks (VPN) deployed and you want to prioritize or rate-limit traffic going over the VPN tunnel.

Many different types of QoS mechanisms are available in the Cisco devices, such as:

Traffic policing

Traffic prioritization

Traffic shaping

Traffic marking

Table 25-1 displays QoS compatibility on the security appliance when other features, such as a transparent firewall, are implemented.

Traffic prioritization

Traffic policing

Traffic shaping

You configure all these methods by using the robust Modular Policy Framework (MPF), discussed briefly in Chapter 13, “Application Inspection.”

In the current implementation of Cisco ASA, two classes of traffic prioritization are supported: priority QoS and nonpriority QoS. With priority QoS, packets are prioritized over regular traffic, whereas with nonpriority QoS, packets are processed by the rate limiter, discussed in the next section.

When traffic is classified as priority, it gets express-forwarded without passing through the rate limiter. The traffic is then flagged to take the priority queue at the egress interface level.

To ensure priority forwarding of traffic at the interface, the security appliance looks at the flag for the priority queue and sends the packet for immediate transmission unless the transmit ring is congested. In that case, traffic is queued to the high-priority queue. As soon as the transmit ring has room available, the security appliance services the priority queue and transmits the packet.

In Cisco ASA, if traffic is not classified as “priority,” as discussed in the preceding “Traffic Prioritization” section, it is processed through the rate limiter. The security appliance tags the packet for rate limiting and sends the packet to the QoS engine for processing. The packet passes through the rate limiter, which determines whether the packet conforms to the configured rate. If it does not, then the packet can be forwarded for additional processing or can be dropped based on the policies. If it conforms to the configured rate, the packet is flagged to take the nonpriority queue. Figure 25-1 illustrates how a packet is processed in the security appliance when it passes through the QoS engine.

When traffic leaves the QoS engine, it is forwarded to the egress interface for physical transmission. The security appliance implements another level of QoS processing at the interface to guarantee traffic with a nonpriority flag gets proper handling. Packet processing at the interface depends on the depth of the queue and the conditions of the transmit ring. The transmit ring is the buffer space used by the security appliance to hold packets before transmitting them at the driver level. If the ring is congested, the packet is queued. If the transmit ring has room, the nonprioritized packet is sent immediately after ensuring that the priority queue is empty. If the priority queue has traffic to send, the transmit ring services it first.

With QoS rate limiting, the security appliance implements a tail drop mechanism when a packet does not conform to the configured profile. The tail drop mechanism drops the packets at the end of the queue if the queue is already full. Cisco ASA logs this event through syslog locally in the buffer or to an external server.

Traffic shaping is implemented when a packet is about to be transmitted on an outbound interface. This includes shaping both through-the-box and from-the-box traffic. With traffic shaping, you cannot

Shape traffic in any traffic selection class, other than the default class.

Shape traffic on multiple VLAN interfaces defined under a physical interface. Traffic shaping is allowed only on the physical interface or, in the case of a Cisco ASA 5505, on a VLAN interface.

Shape traffic on the multiprocessor platforms such as the Cisco ASA 5580 or the new ASA 5500-X series. Traffic shaping is supported only on the ASA 5505, 5510, 5520, 5540, and 5550.

In the current implementation, Cisco ASA enables you to configure limited hierarchical QoS policies. This allows you to shape traffic on an interface, and within the shaped traffic, you can prioritize specific traffic such as VoIP. The hierarchical QoS policy support permits you to shape traffic only at the top level and then provide priority queuing at the next level. With this implementation, you cannot

Prioritize traffic and then shape it.

Police traffic and then shape it.

Shape traffic and then police it.

Using the hierarchical QoS policy, the prioritized packets are always queued at the head of the shaped traffic, and therefore prioritized packets are transmitted ahead of any other traffic. Similarly, the prioritized packets are never dropped from the shaped queue unless the sustained rate of the prioritized traffic exceeds the shaped traffic rate.

Additionally, Cisco ASA does not allow you to shape specific traffic flows. For example, you cannot shape the outbound SSH traffic on the outside interface to 1 Mbps.

1. The packet arrives at the ingress interface. If it is the first packet of the flow, the security appliance attempts to route the packet out to the proper interface and creates a flow for the subsequent packets. The flow contains the rules and actions associated with the packets.

2. Based on the QoS rules, the security appliance takes one of the following actions:

a. If the packet matches the priority queue, it is directed to the prioritized queue for express handling. For the priority queue, there is no rate limiting on the packets.

b. If rate limiting is configured on the security appliance, the packet is checked to see whether a flow for QoS is already established. If there is none, a flow is created based on the source and destination IP address, source and destination ports, IP protocol, and the interfaces forwarding the packets. The security appliance checks that it conforms to the configured rate-limiting parameters. If traffic matches a rate-limiting policy but exceeds the threshold, the security appliance drops the packet. If traffic does not match a rate-limiting policy and a default class is defined with traffic shaping, the security appliance shapes traffic based on the configured parameters and buffer burst traffic in the queue.

3. At this point, the QoS flow is up and the packet is forwarded to the egress interface for physical transmission.

4. The egress interface has two allocated queues for QoS. One is used for the prioritized traffic and the other is used for the nonprioritized traffic. If traffic is rate-limited and there are packets to be sent in the prioritized queue, the security appliance services the prioritized queue first and then processes the rate-limited queue.

5. The security appliance transmits the packet over the physical interface.

Table 25-2 lists all the IP precedence bits along with their IP precedence names as defined in RFC 791.

DSCP provides backward compatibility to IP precedence. Table 25-3 lists the IP precedence values with the corresponding DSCP values.

As shown in Table 25-3, DSCP offers fine granularity to packet identification by using the additional three bits. The Internet Engineering Task Force (IETF) has divided the DSCP bits into four service concepts:

Default Forwarding (DF), defined as 000 000, offers best-effort packet switching through the network devices.

Class Selector (CS) provides backward-compatibility bits, shown in Table 25-3. All the DSCP bits shown in the table belong to this service.

Expedited Forwarding (EF) per-hop behavior (PHB), with the DSCP bit of 101 110, defines the premium service for the IP packets.

Assured Forwarding (AF) PHB, with four different classes and three different class levels, defines a total of 12 code points for packet classification.

Example 25-1 lists the well known DSCP bits supported by Cisco ASA.

Example 25-1 Available DSCP Options in Class Maps

Click here to view code image

---

Chicago(config-cmap)# match dscp ?
  <0-63>   Differentiated services codepoint value
  af11     Match packets with AF11 dscp (001010)
  af12     Match packets with AF12 dscp (001100)
  af13     Match packets with AF13 dscp (001110)
  af21     Match packets with AF21 dscp (010010)
  af22     Match packets with AF22 dscp (010100)
  af23     Match packets with AF23 dscp (010110)
  af31     Match packets with AF31 dscp (011010)
  af32     Match packets with AF32 dscp (011100)
  af33     Match packets with AF33 dscp (011110)
  af41     Match packets with AF41 dscp (100010)
  af42     Match packets with AF42 dscp (100100)
  af43     Match packets with AF43 dscp (100110)
  cs1      Match packets with CS1(precedence 1) dscp (001000)
  cs2      Match packets with CS2(precedence 2) dscp (010000)
  cs3      Match packets with CS3(precedence 3) dscp (011000)
  cs4      Match packets with CS4(precedence 4) dscp (100000)
  cs5      Match packets with CS5(precedence 5) dscp (101000)
  cs6      Match packets with CS6(precedence 6) dscp (110000)
  cs7      Match packets with CS7(precedence 7) dscp (111000)
  default  Match packets with default dscp (000000)
  ef       Match packets with EF dscp (101110)

---

Destination IP address

Source IP address

Destination port

Source port

IP protocol field

In Cisco ASA, flow-based classification is done based on the destination IP address. That means that if the traffic is destined to an IP address, an IP flow is created and the appropriate policies are applied to it.

When both QoS and VPN engines are set up on the security appliance, the following events can occur during device configuration:

New QoS policy is set up for existing tunnels: If a QoS policy is applied to an interface with an active VPN tunnel, the security appliance invokes the IPsec engine to apply the appropriate QoS parameters to the IPsec SAs.

Tunnel goes down for QoS-enabled group: When a VPN tunnel goes down (whether a user deletes the connection or the administrator clears the established SA), the security appliance invokes the QoS process to delete the appropriate QoS parameters for that particular IPsec SA.

QoS policy is removed for the group: When the VPN commands are removed from the QoS configuration, the security appliance invokes the QoS engine to clear up relevant parameters. The security appliance also makes sure not to call the QoS engine for the future VPN tunnels.

QoS configuration via ASDM

QoS configuration via the CLI

In Figure 25-5, SecureMe (SecureMeInc.org) has designed a Cisco ASA to classify traffic sourced from the 192.168.10.0/24 subnet and destined to a mail server, 209.165.201.1. The administrator of the security appliance also prefers to identify the Voice over IP (VoIP) traffic passing through the security appliance.

To design a QoS policy, follow the steps described in the following sections.

Define the transmit ring and the depth of the priority queues to minimize the delay for the high-priority packets. The transmit ring specifies the number of packets allowed into the interface driver’s transmit queue. The depth of the priority queues specifies the maximum number of packets that can be lined up to a priority queue before packets start getting dropped.

The queue’s upper limit and the transmission ring are dynamically determined at run time. The main factor is the amount of memory available on the device to support the queues. When both queues are full and the QoS engine is forwarding more traffic than the queues can handle, the security appliance simply drops the received data. Moreover, it processes the transmit ring first before servicing the priority queues.

To tune a priority queue for an interface, navigate to Configuration > Device Management > Advanced > Priority Queue, click Add, and then choose the interface you want to adjust from the Interface drop-down menu. In Figure 25-6, the administrator of the security appliance has fine-tuned the priority queue parameters on the outside interface. The transmit-ring limit is changed to hold up to 200 packets in the queue, whereas the high- and low-priority queue depth is set up to hold 2000 packets. This allows the priority queue to be processed efficiently with minimum latency caused by the transmit ring.

Interface: Choose this option to create a QoS policy for a specific interface. Interface policies takes precedence over global policies, as discussed in Chapter 13. An interface-specific policy is useful if, for example, you want to prioritize all VPN traffic on the outside interface. In this case, apply the QoS policies on the outside interface. You can define all types of QoS policies (traffic prioritization, traffic shaping, and traffic policing) to an interface-based service policy.

Global–Applies to All Interfaces: Choose this option if you prefer to apply a QoS policy on all interfaces. A global policy is useful if, for example, you want to prioritize all VoIP traffic on all interfaces. In this case, apply the QoS policies globally on the Cisco ASA. You cannot define a traffic-shaping policy to the global policy.

In Figure 25-7, a new service policy, called Traffic-Map-Outside, is applied on the outside interface. A description of Service Policy for Outside Interface is also added to this policy. After you complete this step, click Next.

Table 25-4 defines all the methods available for traffic selection criteria.

Figure 25-8 shows that a new traffic classification criterion is defined as mail-class. The goal in this example is to identify the mail server located at 209.165.201.1. To achieve this objective, an ACL (Source and Destination IP Addresses) is used to identity interesting traffic for the service policy. Click Next when you are finished.

In the next wizard window, Traffic Match, specify the source and destination IP addresses to be used for traffic classification. In Figure 25-9, the source network is 192.168.10.0/24, whereas the destination is a mail server located at 209.165.201.1. The destination service is TCP/SMTP, and a description has been added to indicate that the purpose of the ACL is to identify outbound mail traffic. Click Next when you are finished.

In addition to the traffic classification criteria, the security appliance has a default class that can be used in situations where you to catch all traffic. Any traffic that is not explicitly matched by the classification criteria can be caught by this default class. You can apply appropriate actions (traffic prioritization, shaping, or policing) to the default class. Traffic shaping can be applied only to a default class. To enable the default class for QoS policies, choose Use Class-Default as the Traffic Class.

Traffic prioritization

Traffic policing

Traffic shaping

The burst size is the amount of instantaneous burst that the security appliance can send at any given time without applying the action specified in the Exceed Action field. The following formula can be used to configure the burst size:

burst size = (policing rate) × 1.5 / 8

For example, if traffic needs to be limited to a police rate of 56,000 bps, the burst size is 10,500 bytes. The valid range for burst size is from 1000 to 512,000,000 bytes.

In Figure 25-11, the security appliance is configured to rate-limit the identified traffic to 56,000 bps in the outbound direction, with a burst size of 10,500 bytes. If traffic falls within this range, the security appliance transmits it as it conforms to the configured policy. Otherwise, traffic that exceeds these rates is dropped.

The default for Conform Action is used to transmit traffic, whereas the default for Exceed Action is employed to drop it.

The security appliance, optionally, enables you to specify the average size of burst that can be transmitted in a time interval. The following formula can be used to calculate the time interval:

time interval (t) = (average burst size) / (average rate of shaped traffic)

The effect of the burst size and the time interval can be best explained by an example. If you want to shape traffic at 2 Mbps on a 100-Mbps interface and specify 500 kbps as the burst size, the time interval is 250 ms. What that means is, every 250 ms the security appliance sends 500 kbps of traffic. Because the outbound interface is a 100-Mbps interface, it sends 500 kbps of traffic in the first 5 milliseconds (ms), and then the link is idle for the remaining 245 ms until the next time interval. If the time interval is too large, delay-sensitive traffic such as voice or video can be severely impacted.

As shown on the QoS tab in Figure 25-12, the security appliance is configured to shape traffic at 2 Mbps with an average burst size of 16 kbps so that the time interval is 8 ms.

As mentioned earlier in the chapter, the security appliance supports concurrent interface shaping and priority queuing on an interface by using the hierarchical QoS policies. You can shape traffic on an interface and then prioritize specific data packets within the shaped traffic. In Figure 25-12, the security appliance is configured to prioritize some data-based TCP and UDP ports within the shaped traffic. This can be achieved by selecting “Enforce priority to selected shaped traffic” and then clicking the Configure option.

1. Tune the priority queue.

2. Set up a class map.

3. Configure a policy map.

4. Apply the policy map on the interface.

Example 25-2 Configuration of Priority Queue

Click here to view code image

---

Chicago(config)# priority-queue outside
Chicago(priority-queue)# tx-ring-limit 200
Chicago(priority-queue)# queue-limit 2000

---

Example 25-3 shows how to configure a class map for identifying mail and VoIP packets. An ACL named mail-traffic is configured to specify the source and destination IP addresses and the TCP destination port 25 (SMTP). This ACL is mapped to a class map called mail-class. One additional class map, voip-class, is set up to identify VoIP packets. VoIP uses DSCP values af31 and ef for voice signaling and RTP streams, respectively.

Example 25-3 Class Maps to Identify Mail and VoIP Traffic

Click here to view code image

---

Chicago(config)# access-list mail-traffic extended permit tcp
192.168.10.0   255.255.255.0 host 209.165.201.1 eq smtp
Chicago(config)# class-map mail-class
Chicago(config-cmap)# match access-list mail-traffic
Chicago(config-cmap)# exit
Chicago(config)# class-map voip-class
Chicago(config-cmap)# match dscp af31 ef

---

The security appliance can also match traffic destined to go over a tunnel. By using the match tunnel-group command, you can identify packets if they match against a VPN connection. In Example 25-4, the administrator has configured a class map called tunnel-class to identify traffic destined to go over a VPN group called SecureMeGroup. The administrator also uses destination-based IP flow to match traffic.

Example 25-4 Class Maps to Identify Tunnel Traffic

Click here to view code image

---

Chicago(config)# class-map tunnel-class
Chicago(config-cmap)# match flow ip destination-address
Chicago(config-cmap)# match tunnel-group SecureMeGroup

---

Example 25-5 Configuration of Policy Maps in the Security Appliance

Click here to view code image

---

Chicago(config)# policy-map Traffic-Map-Outside
Chicago(config-pmap)# class voip-class

---

After mapping the class and the policy maps, Cisco ASA needs to be configured for an action that can be applied to the identified traffic. In Example 25-6, the security appliance is configured to prioritize VoIP traffic by the priority statement.

Example 25-6 Traffic Prioritization for the VoIP Traffic

Click here to view code image

---

Chicago(config)# policy-map Traffic-Map-Outside
Chicago(config-pmap)# class voip-class
Chicago(config-pmap-c)# priority

---

In Example 25-7, the security appliance is configured to rate-limit the tunnel traffic to 56 kbps, with a burst size of 10,500 bytes. If traffic falls within this range, the security appliance transmits it because it conforms to the configured policy. Otherwise, traffic that exceeds these rates is dropped.

Example 25-7 Rate-Limiting of Tunnel Traffic

Click here to view code image

---

Chicago(config)# policy-map Traffic-Map-Outside
Chicago(config-pmap)# class tunnel-class
Chicago(config-pmap-c)# police 56000 10500 conform-action transmit exceed-action drop

---

The security appliance also has a default class configured to match all the remaining traffic. This class is used for shaping traffic at an average rate. In Example 25-8, a default traffic class is configured to shape traffic at 2 Mbps with 16 kbps as the average burst size. Within this class, another policy map called DM_INLINE_Child-Policy3 is defined to prioritize SMTP traffic.

Example 25-8 Traffic Shaping and Hierarchical Traffic Priority

Click here to view code image

---

Chicago(config)# class-map DM_INLINE_Child-Class3
Chicago(config-cmap)# match port tcp eq smtp
Chicago(config-cmap)# policy-map DM_INLINE_Child-Policy3
Chicago(config-pmap)# class DM_INLINE_Child-Class3
Chicago(config-pmap-c)#  priority
Chicago(config-pmap-c)#  policy-map TCP-Map-Outside
Chicago(config-pmap)#  class class-default
Chicago(config-pmap-c)#  shape average 2000000 16000
Chicago(config-pmap-c)#  service-policy DM_INLINE_Child-Policy3
Chicago(config-pmap-c)#  exit
Chicago(config-pmap)#  exit
Chicago(config)#  service-policy TCP-Map-Outside interface outside

---

Example 25-9 Applying QoS on the Outside Interface

Click here to view code image

---

Chicago(config)# service-policy Traffic-Map-Outside interface outside

---

Cisco ASA supports policing, shaping, and prioritizing traffic in the outbound direction. However, traffic policing is also supported in the inbound direction. That means that if the service policy is applied to the outside interface in the inbound direction, then the classified packets can be inspected in the ingress direction.

SecureMe’s IT group is responsible for providing network services to its internal users. The IT group hosts an email server and uses Cisco IP phones for telecommunications. SecureMe management has some specific requirements that the IT group is obliged to meet:

Internal clients must have full Internet access. They must get bandwidth based on best effort and should be restricted to 56 kbps.

For VoIP calls, there should not be any network-related delays.

Internet email users should not be allowed to fully utilize the bandwidth when they use POP3 to download their email. They should be restricted to have up to 56 kbps bandwidth. Additionally, users should be restricted to 56 kbps when they upload their email via SMTP.

All the system-generated syslog messages should be logged to a server.

Figure 25-13 shows the SecureMe topology that is used to meet the network requirements.

The administrator has performed the following to meet the requirements:

Set up four class maps to identify traffic:

mail-smtp: Identifies SMTP traffic from the email users to the email server when they upload their emails. The email server is translated to 209.165.200.231.

mail-pop3: Classifies all the packet sources from the mail server to the email users when users download their emails with POP3.

web: Classifies the web traffic destined to the Internet. The internal hosts are translated to the public interface’s IP address.

VoIP: Identifies VoIP traffic.

Linked the mail-pop3 and mail-smtp class maps to a policy map called InsideQoSPolicy, and mapped the web and VoIP class maps to a policy map called OutsideQoSPolicy.

The OutsideQoSPolicy policy map is applied to the outside interface, and the InsideQoSPolicy policy map is applied to the inside interface.

1. Navigate to Configuration > Device Management > Advanced > Priority Queue. Click Add and specify the following attributes in the Add Priority Queue dialog box:

Interface: outside

Queue Limit: 2000 packets

Transmission Ring Limit: 200 packets

Click OK to close the Add Priority Queue dialog box.

2. Click Add again and specify the following attributes:

Interface: inside

Queue Limit: 2000 packets

Transmission Ring Limit: 200 packets

Click OK to close the Add Priority Queue dialog box.

3. Navigate to Configuration > Firewall > Service Policy Rules and choose Add > Add Service Policy Rules. Configure the following service policy rule in the first step of the wizard:

Interface: inside–(create new service policy)

Policy Name: InsideQoSPolicy

Description: Policy for Mail on Inside Interface

Click Next.

4. On the Traffic Classification Criteria screen, click Create a New Traffic Class and specify a traffic class name of mail-smtp. In the Traffic Match Criteria area, check the Source and Destination IP Addresses (Uses ACL) check box and then click Next.

5. On the Traffic Match screen, configure the ACL using the following information:

Action: Match

Source: any

Destination: 192.168.10.11/32

Service: tcp/smtp

Click Next.

6. On the Rule Actions screen, click the QoS tab and check the Enable Policing option. Specify the following information:

Output Policing: Checked

Committed Rate: 56000 bits/second

Confirm Action: transmit

Exceed Action: drop

Burst Size: 10500 bytes

Click Finish.

7. Navigate to Configuration > Firewall > Service Policy Rules and select the previously defined policy map. Choose Add > Insert After. Configure the following service policy rule:

Interface: inside–InsideQoSPolicy

Click Next.

8. On the Traffic Classification Criteria screen, click Create a New Traffic Class and specify a traffic class name of mail-pop3. In the Traffic Match Criteria area, check Source and Destination IP Addresses (Uses ACL) and then click Next.

9. On the Traffic Match screen, configure the ACL using the following information:

Action: Match

Source: 192.168.10.11/32

Destination: any

Service: tcp

More Options > Source Service: tcp/pop3

Click Next.

10. On the Rule Actions screen, click the QoS tab and check the Enable Policing option. Specify the following information:

Input policing: Checked

Committed Rate: 56000 bits/second

Confirm Action: transmit

Exceed Action: drop

Burst Size: 10500 bytes

Click Finish.

11. Navigate to Configuration > Firewall > Service Policy Rules and choose Add > Add Service Policy Rules. Configure the following service policy rule:

Interface: outside–(create new service policy)

Policy Name: OutsideQoSPolicy

Description: Policy for Web, VoIP Traffic on Outside Interface

Click Next.

12. On the Traffic Classification Criteria screen, click Create a New Traffic Class and specify a traffic class name of web. In the Traffic Match Criteria area, check Source and Destination IP Addresses (Uses ACL) and then click Next.

13. On the Traffic Match screen, configure the ACL using the following information:

Action: Match

Source: 209.165.200.225

Destination: any

Service: tcp/http

Click Next.

14. On the Rule Actions screen, click the QoS tab and check the Enable Policing option. Specify the following information:

Output Policing: Checked

Committed Rate: 56000 bits/second

Confirm Action: transmit

Exceed Action: drop

Burst Size: 10500 bytes

Click Finish.

15. Navigate to Configuration > Firewall > Service Policy Rules and select the previously defined policy map. Choose Add > Insert After. Configure the following service policy rule:

Interface: outside–OutsideQoSPolicy

Click Next.

16. On the Traffic Classification Criteria screen, click Create a New Traffic Class and specify a traffic class name of VoIP. In the Traffic Match Criteria area, check IP DiffServ CodePoints (DSCP) and then click Next.

17. On the next screen to match traffic based on DSCP, add af31 and ef to the Match on DSCP list. Click Next.

18. On the Rule Actions screen, click the QoS tab and check the Enable Priority for this Flow check box. Click Finish to complete the setup.

19. Navigate to Configuration > Device Management > Logging > Logging Setup and check the Enable Logging check box.

20. Navigate to Configuration > Device Management > Logging > Syslog Servers and click Add. Specify the following:

Interface: inside

IP Address: 192.168.10.101

Protocol: UDP

Port: 514

Click OK when you are finished.

21. Navigate to Configuration > Device Management > Logging > Logging Filters, select Syslog Servers, and click Edit. Click Filter on Severity and choose Informational from the drop-down menu.

Example 25-10 ASA’s Full Configuration Showing QoS for VoIP, Mail, and Web

Click here to view code image

---

SecureMeIncOrg# show running
ASA Version 9.1(4)
! ip address on the outside interface                                              
interface GigabitEthernet0/0
 nameif outside
 security-level 0
 ip address 209.165.200.225 255.255.255.224
! ip address on the inside interface                                               
interface GigabitEthernet0/1
 nameif inside
 security-level 100
 ip address 192.168.10.1 255.255.255.0
!
hostname SecureMeIncOrg
!Access-list to classify Mail-traffic. SecureMe uses SMTP to upload emails         
access-list mail-smtp-acl extended permit tcp any host 192.168.10.11 eq smtp
!Access-list to classify Mail-traffic. SecureMe uses POP3 to download emails       
access-list mail-pop3-acl extended permit tcp host 192.168.10.11 eq pop3 any
!Access-list to classify Web-traffic to the internet.                              
access-list web-acl extended permit tcp host 209.165.200.225 any eq http
!Syslog Server information to log the dropped packets.                             
logging enable
logging trap informational
logging host inside 192.168.10.101
!Object Definitions for Inside Network and PAT configuration for Internet Connectivity
object network Inside-Network
 host 192.168.10.0
!
object network Inside-Network
 nat (inside,outside) dynamic interface
!Object Definitions and NAT for Mail-Server                                        
object network Mail-Server
 host 192.168.10.11
object network Mail-Translated
 host 209.165.200.231
!
object network Mail-Server
 nat (inside,outside) static Mail-Translated
!
route outside 0.0.0.0 0.0.0.0 209.165.200.230 1
!Class-map to classify Mail traffic in the inbound direction                       
class-map mail-smtp
 match access-list mail-smtp-acl
class-map mail-pop3
 match access-list mail-pop3-acl
!Class-map to classify Web traffic in the outbound direction                       
class-map web
 match access-list web-acl
!Class-maps to classify VoIP traffic                                               
class-map VoIP
 match dscp 26 46
! Policy-map to define rules applied on traffic-class                              
policy-map OutsideQoSPolicy
 description Policy for Web, VoIP traffic on Outside Interface
! Web-mail is rate-limited to 56 kbps                                              
  class web
   police output 56000 10500 conform-action transmit exceed-action drop
! VoIP signal is prioritized                                                       
  class VoIP
    priority
policy-map InsideQoSPolicy
  description Policy for Mail on Inside Interface
! POP and SMTP mail is rate-limited to 56 kbps                                     
  class mail-smtp
    police output 56000 10500 conform-action transmit exceed-action drop
  class mail-pop
    police input 56000 10500 conform-action transmit exceed-action drop
! Default Inspection Policies                                                      
policy-map global_policy
 class inspection_default
  inspect ctiqbe
  inspect http
<snip>
  inspect icmp
! Global Policy – applied for traffic inspection                                  
service-policy global_policy global
! QoS policy is applied to the outside interface                                   
service-policy OutsideQoSPolicy interface outside
! QoS policy is applied to the inside interface                                    
service-policy InsideQoSPolicy interface inside
! Priority Queue is setup on the inside and outside interface for QoS efficiency   
priority-queue inside
 tx-ring-limit 200
 queue-limit 2000
priority-queue outside
 tx-ring-limit 200
 queue-limit 2000

---

Example 25-11 Options Available in the show service-policy Command

Click here to view code image

---

Chicago# show service-policy ?
csc        Show status/statistics of Content Security and Control policy
flow       Show all policies that are enabled on a flow
global     show status/statistics of the global policy
inspect    Show status/statistics of 'inspect' policy
interface  show status/statistics of an interface policy
ips        Show status/statistics of 'ips' policy
police     Show status/statistics of 'police' policy
priority   Show status/statistics of 'priority' policy
set        Show status/statistics of 'set' policy
shape      Show status/statistics of 'shape' policy
|          Output modifiers
<cr>

---

The show service-policy interface command displays the QoS interface policy name of the class map, along with the configured policies within each class. In Example 25-12, two class maps are configured: VPNQoSClass and web-traffic. The VPNQoSClass class is configured to rate-limit the traffic to 256,000 bps with burst size of 48,000 bytes. The security appliance dropped 6 packets because they exceeded the rate-limiting policies, and transmitted 128 packets. On the other hand, the web-traffic class, being the priority class, transmitted 250 packets.

Example 25-12 Output of show service-policy interface outside Command

Click here to view code image

---

Chicago# show service-policy interface outside
Interface outside:
  Service-policy: OutsideQoSPolicy
    Class-map: web-traffic
      Priority:
        Interface outside: aggregate drop 0, aggregate transmit 250
    Class-map: VPNQoSClass
      Output police Interface outside:
        cir 256000 bps, bc 48000 bytes
        conformed 128 packets, 137472 bytes; actions:  transmit
        exceeded 6 packets, 6444 bytes; actions:  drop
        conformed 0 bps, exceed 0 bps
    Class-map: class-default

---

The robust CLI of the security appliance enables you to monitor the depth of interface priority queues. As shown in Example 25-13, show priority-queue statistics displays the queue statistics of the inside and outside interfaces. There are two queue types for each interface: one for the priority traffic (LLQ) and the other for best-effort (BE) traffic. The outside interface best-effort queue transmitted 84,792 packets and dropped 1056. The priority queue, shown as LLQ, forwarded 6589 packet and dropped none. The inside interface transmitted 44,902 packets on the best-effort queue.

Example 25-13 Output of show priority-queue statistics Command

Click here to view code image

---

Chicago# show priority-queue statistics
Priority-Queue Statistics interface outside
Queue Type      = BE
Packets Dropped   = 1056                                                           
Packets Transmit  = 84792                                                          
Packets Enqueued  = 0
Current Q Length  = 0
Max Q Length      = 0

Queue Type      = LLQ
Packets Dropped   = 0                                                              
Packets Transmit  = 6589                                                           
Packets Enqueued  = 0
Current Q Length  = 0
Max Q Length      = 0

Priority-Queue Statistics interface inside
Queue Type      = BE
Packets Dropped   = 0
Packets Transmit  = 44902                                                          
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
Chicago#

---