Category: QoS

QoS: IPP and DSCP

IP Header is defined in RFC 791, this header includes a 1 byte field called the Type of Service (ToS) byte.  This Tos byte is used to mark the packet for a specific type of treatment or prioritization.

The ToS byte itself is subdivided with the high order 3 bits defined as the IP Precedence field (IPP)

IPPprecedence.PNG

The use of the high order 3 bits IPP in the ToS byte determined prioritization for the packet, later a series of RFCs called Differentiated Services (DiffServ) came along, which required redefining the use of the ToS byte because DiffServ required more than 3 bits.  The ToS byte was renamed the Differentiated Services Field and IPP was replaced with a 6 bit field called Differentiated Services Code Point (DSCP).

Later RFC 3168 defined a use for the last two low order bits in the DiffServ field for use with the QoS Explicit Congestion Notification Feature.

diffserv.PNG

Advertisements

QoS: Policy Routing for Marking

Policy Marking can mark the IPP field or the entire ToS byte using the set command in the route map.  When doing this the following sequence is used:

  • Packets are examined as they enter an interface
  • Route map is used to match subsets of packets
  • Mark either the IPP or ToS byte using the set command
  • the traditional policy routing function of the set command to define the route might also be configured but is not required.

Should only be used where CB Marking is unavailable or when a router needs to use both policy routing and mark packets entering the same interface.

QoS: Pre-Classification

What happens when you have encrypted traffic that requires priority across a network before its encapsulated.  The ToS byte of the original packet is automatically copied to the tunnel header (IPSEC tansport, tunnel mode, and GRE tunnels) but this does not work for features like NBAR.

The problem derives from the fact that tunnel encapsulation prevents a router to take egress QoS actions based on encrypted traffic.  To resolve this, Cisco IOS includes QoS pre-classification.  This allows routers to make egress QoS decisions based on the original traffic, before encapsulation rather than encapsulating the tunnel header.  It works by keeping the original unencrypted traffic in memory until the egress QoS actions are taken.

QoS: Marking using Policers

Traffic policers measure the traffic rate for data entering or exiting an interface with the goal of determining whether a traffic contract has been exceeded.  The traffic contract consists of two components:

  • Traffic Rate configured in bits/second
  • Burst Size: configured as a number of bytes

If traffic is within the contracted rate its considered to be conformed and may pass through.

If traffic exceeds  the contracted rate its subject to being dropped.

However there is a compromise action that takes place in which a policer marks down packets instead of dropping them.  It remarks the exceeded packet using IPP or DSCP to a value that makes the packet more likely to be discarded downstream but still allows the packet to pass through the local router.

QoS: Class Based Marking

  • CB Marking requires CEF
  • Packets are classified based on the logic in the MQC class maps
  • An MQC policy map refers to one or more class maps using the class class-map-name command, packets classified into that class are then marked
  • CB Marking is enabled for packets either entering or exiting an interface using the MQC service policy in/out interface subcommand.
  • A CB marking policy map is processed sequentially, after a packet has matched a class it is marked based on the set commands defined for that class
  • You can configure multiple set commands in one class to set multiple fields
  • Packets that do not explicitly match a defined class are considered to have matched a special class called class-default
  • For any class inside the policy map for which there is no ser command, packets in that class are not marked.

QoS: Multiple Match Commands

The following list summarizes the key points regarding more complex matching options:

  • Up to four CoS and IPP or eight DSCP values can be listed on a single match cos, match precedence, or match dscp command
  • If a class map has multiple match commands in it, the match any or match all parameter on the class map defines whether a logical OR or a logical AND (default) is used between the match commands
  • the match class name command refers to another class map by name, nesting the named class map’s matching logic, the match class name command is considered to match if the referenced class map also results in a match to the traffic it defines.

QoS: Class Maps

Rules for classifying traffic with class maps:

  • the match command has many options for matching packets, including QoS fields, ACLs and MAC addresses
  • class map names are case sensitive
  • the match protocol command means that the IOS uses Network Based Application Recognition to perform the match.
  • Match any command matches any/all packets

QoS: Modular QoS CLI

Cisco created Modular QoS CLI to help resolve problems with a multitude of QoS configuration commands becoming unorganized or standardized.  MQC helps by defining a common set of configuration commands to configure many QoS features in a router or switch.

MQC categorizes classification, marking, and erlated actions into logical groupings in the command line interface. MQC tools all begin with the phrase ‘Class Based’ such as CB Weighted Fair Queue, CB Marking, CB, Policing, CB Shaping, and CB Header compression.

MQC seperates the classification function of a QoS tool from the action (PHB) that it wants to perform.  MQC is seperated into three major commands, with several subordinate commands:

  • Class-Map: command defineds the matching parameters for classifying packets into service classes
  • Policy Map: PHB actions such as Marking, Queueing, and so on are configured under a Policy-map command
  • Service Policy: a Policy Map is enabled on an interface by using the service-policy command.

MQC.PNG

Classifying packets requires the use of class maps to define your traffic.

Setting an action to your defined class-maps is done by referencing the class map within the policy map and setting an appropriate action.

The QoS Policy  that’s been created which defines your traffic, and how you want to treat your traffic is enabled under an interface configuration using the service-policy commands and you can apply those commands on ingress or egress of an interface.

QoS: Marking and Matching

The Rules where CoS, DE, CLP, or EXP can be used are:

  • Classification: On ingress only, and only if the interface supports that particular header field
  • Marking: On egress only, and only if the interface supports that particular header field.

Design Choices:

  • Mark as close to the ingress edge of the network as possible, but not so close to the edge that the marking is made by an untrusted device.
  • Cisco recommends the following markings for traffic:

ciscomarkings.PNG

 

QoS: WAN Marking

Frame Relay and ATM support a single bit that can be set for QoS but this single bit is actually intended for use related to drop probability.  If a Frame Relay device sends a Frame with this bit set to 1, that frame will be considered to be dropped.  This is referred to in Frame Relay as the Discard Eligibility bit (DE) or in ATM Cell Loss Priority (CLP) bit.

MPLS defines a MPLS Experimental bit (EXP) that’s intended for general QoS marking.