Cisco QOS Basics

Quality of Service (QoS) is a set of technologies that work on network traffic to provide different priority to different applications, users, or data flows. It’s a vital component of modern networks and is often used in businesses and services where data traffic is heavy and needs to be managed effectively. QoS provides better and more predictable network service by:

  1. Reducing packet loss
  2. Lowering network jitter
  3. Increasing application performance

Cisco offers QoS on its various networking devices, including routers and switches. Models vary, but most modern routers and switches from Cisco support QoS.

Band and Delay

Band in networking is a shorthand for bandwidth, which refers to the data transfer capacity of a network. If a network connection has a high bandwidth, more data can be sent over the network in a given amount of time.

Delay, on the other hand, is a measure of the time it takes for a packet of data to travel from one designated point to another in a network. This is often referred to as network latency. High delays can cause problems for certain time-sensitive applications like VoIP or video streaming.

Priority and Bandwidth

Priority and bandwidth are two different ways that network devices manage traffic.

Priority refers to the precedence given to certain packets over others. You might set high-priority packets to be sent first, while lower priority packets are sent later or dropped if the network is busy.

Bandwidth refers to the maximum data transfer capacity of a system. It can be allocated to ensure certain services have enough bandwidth to function effectively.

Police and Shape

Policing and shaping are two methods of managing network traffic.

Policing is a method that drops or marks packets when the defined rate limit is exceeded, effectively reducing the traffic rate. This is a more abrupt way of handling exceeding traffic and can lead to higher packet loss.

Shaping, on the other hand, buffers excess packets to be sent later instead of dropping them. This is a more gentle approach and is generally preferred when the aim is to prevent packet loss.

Recommendations and Best Practices

The recommendations and best practices for QoS vary depending on the specific network environment and use case, but some general guidelines include:

  1. Identify the traffic: You must first identify the different types of traffic on your network before you can manage them effectively.
  2. Define QoS policies: Define your QoS policies based on business priorities. For example, you might give VoIP traffic the highest priority because it’s crucial for business communications.
  3. Avoid unnecessary complexity: While QoS offers a lot of features, avoid unnecessary complexity. Complex QoS policies can be difficult to manage and troubleshoot.
  4. Monitor and adjust: Network conditions change over time, so it’s important to monitor your network and adjust your QoS policies as needed.
  5. Use shaping over policing when possible: As mentioned earlier, shaping tends to be gentler and less likely to cause packet loss than policing. Use shaping when possible, especially for high-priority traffic.

It’s also recommended to take advantage of Cisco’s extensive documentation and support resources when configuring QoS on your devices. Cisco offers a range of materials that can help guide you through the process, including configuration guides and best practices documents.

 

WHEN IS AN INTERFACE CONGESTED AND WHEN DOES QOS KICK IN

The interface queue and FIFO (First-In-First-Out) strategy form the most basic part of QoS. If the interface is not congested and packets are being sent at a rate that is below the interface’s capacity, then packets are processed in the order they arrive, creating a FIFO situation.

However, when the interface becomes congested, the QoS policies come into play. Congestion typically happens when the rate of incoming packets exceeds the rate at which the router can send them out.

QoS operates on a device when the Transmit (TX) Ring and the TX Queue are full. The TX Ring is a small buffer that resides on the network interface card (NIC) itself. When this ring is full, the packets get stored in the software queue (TX Queue). The size of this queue is variable and can be modified according to the network requirements.

If the software queue also gets full (meaning that packets are coming in faster than they are being sent out), the router must make a decision about which packets to send and which to drop. It’s at this point where QoS kicks in.

QoS policies dictate which types of traffic should be prioritized. For instance, voice traffic might be prioritized over email traffic to ensure real-time communication stays fluid. These decisions are made based on QoS settings such as Class of Service (CoS), Differentiated Services Code Point (DSCP), or rate limiting settings that have been configured.

In summary, QoS essentially comes into action when the network is congested and it needs to prioritize certain types of traffic. When the TX-Ring and TX Queue are full, the device starts processing the packets according to the defined QoS policies.

 

MORE DETAILS ABOUT CONGESTION

In networking, congestion occurs when the demand for a resource exceeds the available capacity. For a network interface on a router or switch, congestion usually means that the rate of incoming packets is higher than the rate at which the device can transmit them.

The exact point of congestion can vary depending on the specifics of the device and its configuration. Generally, it occurs when both the Transmit (TX) Ring (a hardware buffer on the network interface card) and the software queue (or TX Queue) are full.

You can think of the TX Ring and TX Queue as two layers of buffering for outgoing packets. When the TX Ring is full, additional packets are stored in the TX Queue. If the rate of incoming packets remains higher than the rate at which the device can send them out, eventually the TX Queue will also fill up. When both the TX Ring and the TX Queue are full, this typically indicates congestion.

You can verify the status of the interface and check for signs of congestion using various show commands on the Cisco IOS:

  1. show interfaces: This command will show the status of all interfaces, including input and output rates, drops, and errors. High rates of output drops can be a sign of congestion.
  2. show controllers ethernet-controller [interface]: This command can show you the status of the TX Ring.
  3. show queue [interface]: This command can show you the status of the software queue.

These commands can give you a real-time snapshot of the interface status. To monitor for congestion over time, consider using a network monitoring tool that can track these statistics and alert you to potential issues.

Remember, congestion is not always a bad thing, and networks are often designed to handle a certain level of congestion. However, chronic or severe congestion can lead to packet loss and reduced network performance. QoS policies are used to manage congestion and ensure that important traffic is prioritized.

 

Again, when an interface is not congested, it operates on a First-In-First-Out (FIFO) basis, meaning that packets are sent out in the order they arrive.

When congestion happens, which means both the Transmit (TX) Ring and the TX Queue are full, QoS policies come into action. The router or switch will then begin prioritizing packets based on these QoS policies. So, essentially, QoS kicks in when the TX Ring and the TX Queue are full due to congestion.

However, it’s also worth noting that some advanced QoS features, like traffic shaping and policing, can also operate before the interface is fully congested. These features can actively control the rate of traffic being sent to the interface, smoothing out traffic bursts and preventing congestion from occurring in the first place. These methods can provide more precise control over traffic rates and can be very useful in scenarios where specific traffic flows need to be guaranteed a certain amount of bandwidth.

But in general terms, it’s correct to say when the Transmit (TX) Ring  and the software queue (or TX Queue) are full, QOS kicks in. QoS typically becomes active when an interface is congested, and that usually means when both the TX Ring and the TX Queue are full.

 

TECHNIQUES FOR IMPLEMENTING QOS

DiffServ (Differentiated Services) and CoS (Class of Service) are both techniques used for implementing Quality of Service (QoS) in a network, but they are used in different scenarios and have different characteristics.

DiffServ (Differentiated Services)

DiffServ is a computer networking architecture that specifies a scalable and coarse-grained mechanism for classifying, managing, and controlling network traffic. This approach provides different levels of service for different types of traffic, which can help ensure that important or time-sensitive data gets the resources it needs.

In DiffServ, packets are classified and marked with a DSCP (Differentiated Services Code Point) value. This value, included in the IP header of each packet, determines the packet’s QoS level. Different types of traffic can be marked with different DSCP values, and routers or switches can then use these values to determine how to handle the traffic.

CoS (Class of Service)

CoS is a 3-bit field that is present in an Ethernet frame header when 802.1Q VLAN tagging is in use. It’s used to prioritize different types of traffic at the data link layer (Layer 2). CoS values range from 0 to 7, with 7 being the highest priority.

Difference between CoS and DSCP

The main difference between CoS and DSCP is the layer at which they operate and how they’re used. CoS operates at the data link layer (Layer 2) and is typically used in LAN environments, while DSCP operates at the network layer (Layer 3) and is used for prioritizing traffic over a wide area network (WAN) or the internet.

CoS markings are only preserved within a single Layer 2 domain – they’re not typically passed from one network to another. This is where DSCP comes in. DSCP markings are preserved end-to-end (as long as the routers in the path are configured to do so), making DSCP more useful in a larger network or when traffic is passing between networks.

In summary, both CoS and DSCP are mechanisms used to prioritize different types of traffic. They operate at different layers and are used in different scenarios, but they both play a critical role in implementing QoS in a network.

 

EXAMPLE

To prioritize SQL traffic over HTTPS traffic, you’d first have to identify each type of traffic. SQL traffic typically uses port 1433 for Microsoft SQL Server, and HTTPS uses port 443.

Here are examples of how you could configure QoS for this using CoS and DSCP markings:

  1. CoS

In a LAN environment, if you’re using VLANs with 802.1Q tagging, you can apply CoS values to prioritize SQL traffic over HTTPS. Here’s an example configuration:

class-map match-any SQL-traffic
match access-group name ACL-SQL

policy-map CoS-Policy
class SQL-traffic
set cos 5

interface GigabitEthernet0/1
service-policy output CoS-Policy

In this example, you’d have to define an access control list (ACL) named “ACL-SQL” to match SQL traffic (port 1433).

  1. DSCP

In a WAN or internet environment, you could use DSCP to prioritize the SQL traffic. Here’s an example configuration:

class-map match-any SQL-traffic
match access-group name ACL-SQL

policy-map DSCP-Policy
class SQL-traffic
set dscp af31

interface GigabitEthernet0/1
service-policy output DSCP-Policy

 

In this example, you’d again define an ACL “ACL-SQL” to match SQL traffic. The policy map “DSCP-Policy” is applied to the interface, and any SQL traffic is marked with the DSCP value “af31“, which is typically used for critical data.

In both cases, you’re prioritizing SQL traffic over HTTPS traffic by giving SQL traffic a higher CoS or DSCP value. You could create similar class-maps for HTTPS traffic and assign them a lower CoS or DSCP value to ensure they have lower priority.

Remember to replace the interface names (GigabitEthernet0/1 in the examples) with the actual interfaces on your device, and make sure your ACLs correctly identify the SQL and HTTPS traffic.