«
»

ONT Chapter 3 – Classification, Marking, and NBAR

Also available as a PDF here

Classification and Marking

  • Packets should be marked (colored) after the first classification
    • Usually performed at the edge of the network
  • The match statement in a class map can refer to either a:
    • Traffic descriptor
    • Access list
    • NBAR protocol
  • Packets should be marked as close to the source as possible
  • What gets marked depends on whether you want to mark the L2 frame or the L3 packet
  • Layer 2 markings include
    • CoS (on ISL or 802.1q header)
    • EXP (MPLS)
    • DE on FR header (Discard eligibility)
    • CLP on ATM cell header
  • Layer 3 markings include
    • IP precedence
    • or DSCP  on the IP header

Layer 2 QoS: CoS on 802.1Q/P Ethernet Frame

  • A 3 bit user priority (PRI) field is contained in the 4 byte 802.1q header and is called CoS – 8 values possible
  • Values are only present when frames are being trunked
CoS (bits) CoS in Decimal IETF RFC791 Application
000 0 Routine Best-effort data
001 1 Priority Medium priority data
010 2 Immediate High priority data
011 3 Flash Call signaling
100 4 Flash-Override Video Conferencing
101 5 Critical Voice bearer
110 6 Internet Reserved (Internetwork control)
111 7 Network Reserved (Network control)
  • In an IPT network, the IP phone sends 802.1q/p frames to the switch with the VLAN ID set and their priority (CoS) set to decimal 5 (or 101 in binary)
    • The switch sees these frames as critical or voice-bearing frames

Layer 2 QoS: DE  (Discard eligibility) & CLP (cell loss priority) on FR & ATM

  • Frame relay has a 1 bit DE field
  • ATM has a 1 bit CLP field
  • These fields notify the transit devices that the cell is a good candidate for dropping if needed

Layer 2.5 QoS: MPLS EXP Field

  1. MPLS packets are IP packets with an MPLS header
  2. The MPLS packets are encapsulated into a L2 frame
  3. The 3 bit EXP (experimental) field within the MPLS header is read for QoS purposes
    • EXP field was designed to be compatible with the 3 bit IP precedence field in an IP header and also with the 3 bit CoS field in an 802.1q header

L2.5 Marking Process

  1. An  IP packet enters the MPLS domain
  2. The edge LSR copies the 3 most significant bits from the type of service (ToS) field in the IP header to the EXP field in the MPLS header
    1. The three most significant bits in the ToS byte are called the IP precedence bits
    2. The ToS byte is now called the DiffServ field
    3. The six most significant bits of DiffServ are the DSCP (differentiated services code point)

Note: The edge LSR admin can configure it to set the EXP to a desired value – this allows the customer to set the bits they want and the ISP to set the bits the way they want

The DiffServ Mode, DSCP, and Per-Hop Behavior

  • Marking the IP packet by setting the six DSCP bits on the IP header is standard practice
  • Some network devices cannot check L3 QoS fields, only L2 CoS bits
  • Each 6 bit combination is designed to cause a network device in the path to respond in a certain way and provide a particular QoS treatment
  • A group of packets with a common DSCP value is called a behavior aggregate
    • No “per flow” state because the packets could be from different flows
  • If marking of the packet is on a device that you administer, the device is considered “trusted”
  • Provides specific services and QoS to groups of packets with common DSCP values (BA’s)

IP Precedence and DSCP

  • The 3 most significant bits on the ToS byte are called the IP precedence bits
  • User applications have 6 IP precedence values to use (7th and 8th values are network control traffic and not useable by applications)

IP Header ToS Byte and IP Prec Values

IP Prec Decimal IP Prec Binary IP Prec Name
0 000 Routine
1 001 Priority
2 010 Immediate
3 011 Flash
4 100 Flash-Override
5 (highest assignable value) 101 Critical
6 110 Internetwork Control
7 111 Network Control
  • The ToS byte has been renamed to the DiffServ field
    • 6 most significant bits are the DSCP
    • 2 least sign bits are used for explicit congestion notification

The 8 DSCP bits are

AF AF AF CS CS CS ECN ECN

1    2    3    4    5     6     7        8

  • Current DSCP value definitions include 4 per-hop behaviors
    • Class selector PHB – 3 least significant bits set to 000 – provides backward compatibility with ToS IP prec
      • When DSCP compliant devices receive packets from a non-DSCP compliant device, they can be configured to process only the IP prec bits
      • When DSCP compliant devices send to non-DSCP compliant devices, the 3 most significant bits in the DiffServ field are set, the rest are 0
    • Default PHB – 3 most significant bits in the DiffServer/DSCP field are set to 000 and best-effort service is used
    • Assured Forwarding (AF) PHB – If 3 most significant bits of DSCP field set to 001, 010, 011, or 100 (AF1, AF2, AF3, AF4) – then AF PHB is used for guaranteed bandwidth service
    • Expedited Forwarding (EF) – The 3 most significant bits set to 101 (the DSCP field is set to 1011110 (46 decimal), the EF PHB provides low delay service
      • Provides bandwidth guarantee
      • Minimizes jitter and loss but the bandwidth allocated to EF must be capped so other classes have bw available
      • The queue that is dedicated to EF must be the highest priority
  • Non-DSCP compliant apps set the IP prec values to 101 (decimal 5) for delay sensitive traffic
    • This is backward compatible with the binary 101 IP prec (critical) setting

Assured Forwarding (AF) has 4 queues – 1 per traffic class

  • AFxy where X is the class and y is the drop precedence
  • AF1y, AF2y, AF3y, AF4y
    • “y” specifies the drop preference (or probability) of the packet
    • Value can be 01, 10, or 11 (bigger numbers = higher drop preference)
    • High, medium, or low drop preference
  • Each queue has a prescribed bandwidth reserved
  • If queue fills up, packet drop occur
  • Deploy congestion avoidance techniques (such as WRED)

Class 1
Low Drop        = AF11 — DSCP Value (dec.) = 10 — DSCP Value (Binary) = 001010
Medium Drop   = AF12 –DSCP Value (dec.) = 12 — DSCP Value (Binary) = 001100
High Drop        = AF13 –DSCP Value (dec.) = 14 — DSCP Value (Binary) = 001110

Class 2
Low Drop        = AF21 –DSCP Value (dec.) = 18 — DSCP Value (Binary) = 010010
Medium Drop   = AF22 –DSCP Value (dec.) = 20 — DSCP Value (Binary) = 010100
High Drop        = AF23 –DSCP Value (dec.) = 22 — DSCP Value (Binary) = 010110

Class 3
Low Drop        = AF31 — DSCP Value (dec.) = 26 — DSCP Value (Binary) = 011010
Medium Drop   = AF32 — DSCP Value (dec.) = 28 — DSCP Value (Binary) = 011100
High Drop        = AF33 — DSCP Value (dec.) = 30 — DSCP Value (Binary) = 011110

Class 4
Low Drop        = AF41 — DSCP Value (dec.) = 34 — DSCP Value (Binary) = 100010
Medium Drop   = AF42 — DSCP Value (dec.) = 36 — DSCP Value (Binary) = 100100
High Drop        = AF43 — DSCP Value (dec.) = 38 — DSCP Value (Binary) = 100110

AF Key Facts

  • Of the 4 classes, they have no advantage over the other
    • queues can be configured as needed for bandwidth min and max
  • DSCP Value of AFxy (in decimal) = 8x + 2y
    • For example DSCP value for AF31 = (8*3) + (2*1) = 26
  • Each AFx class maps to a single IP prec value x
    • For example AF1y = IP prec 1
  • You must reserve enough bandwidth per queue to avoid delays and drops
  • If bandwidth is available and the queue is not policed, it can consume more bandwidth than the amount reserved

QoS Service Class

  • 3 Main Steps to Implementing QoS
    • Identify network traffic and its requirements
    • Divide the identified traffic into classes
    • Define QoS policies for each class
  • Must define a mapping/translation table between CoS, DSCP, IP precedence, PHB and class selector name
Cisco Auto Qos Class Layer 2 CoS or IP Precedence DSCP Value in Decimal DSCP Value in Binary Code Name
Best Effort 0 0 000000 BE (Best Effort)
Scavenger 1 8 001000 CS1 (Class selector 1)
Bulk Data 1 10

12

14

 001010

001100

001110

 AF11

AF12

AF13
Network Management 2 16 010000 CS2 (Class selector 2)
Etc. See page 108

Trust Boundaries

  • Identifies the point where your network begins to trust the incoming QoS values
    • Devices inside this boundary that mark packets are trusted
    • Devices outside this boundary have their incoming QoS values checked, if not remarked
  • Always try to place trust boundary as close to the network edge as possible
  • Trust boundary is implemented at either of these 3 points:
    • End systems – generally not trusted except for IP phone or video devices
    • Access switch – usually configured to trust the markings from the IP phone only
    • Distribution switch – If the access switch doesn’t have any or enough QoS features, the distribution switch may need to be the trust boundary
  • Switches and IP phones should have CDP enabled
    • If the switch recognizes an IP phone on the link, it will extend the trust boundary to the phone
    • If CDP isn’t running, the switch will be the trust boundary

Network Based Application Recognition

  • Performs 3 functions on OSI layers 4 -7
    • Protocol discovery (per interface basis)
    • Traffic statistics collection
    • Traffic classification
  • Can categorize traffic based on:
    • Protocol
    • Port number
    • Payload content (up to 400 bytes)
  • Recognizes a limited number of protocols
    • You can add new protocols by loading protocol description language modules (PDLMs) published by Cisco
    • PDLMs contain rules that identify protocol and applications
    • Loaded into flash memory
  • NBAR can inpsect bytes above the network and transport layer headers and classify traffic using those statistics
    • For example, NBAR can classify traffic based on the URL in an HTTP request
  • Limitations of NBAR include:
    • Does not function on the Fast EtherChannel logical interface
    • Can only handle 24 concurrent URLs, hosts, or MIME types
    • Only analyzes first 400 bytes of a packet
    • Only supports CEF
    • Cannot recognize traffic generated by the router it is running on
    • Cannot recognize traffic that is destined for the router that it’s running on
    • Cannot recognize MPLS, https, multicast, or fragmented packets
  • NBAR can recognize and classify apps with static port numbers as well
    • Enable NBAR discovery
    • Configure a traffic class using the MQC class map
    • Configure a QoS policy using the MQC policy map
    • Apply the policy to the interface
    • Expand the NBAR protocol ports or PDLM protocols as needed
  • To configure NBAR for stateful protocols (that negotiate port numbers during initiation)
    • Configure a class map using MQC class map
    • Configure a QoS policy using MQC policy map
    • Apply the policy to the interface

Cisco IOS Commands to Configure NBAR

Adding an PDLM

router(config)#ip nbar pdlm pdlm-name

Example:

router(config)#ip nbar pdlm flash://citrix.pdlm

Add/Modify a port number associated with a protocol

Note: You can specify up to 16 additional port numbers

router(config)#ip nbar port-map protocol-name [tcp | udp] port-number

Displaying NBAR protocol to port mappings

router# sh ip nbar portmap [protocol-name]

Enabling NBAR discovery on an interface

router(config-if)#ip nbar protocol discovery

Show discovered protocols and statistics

router#sh ip nbar protocol-discovery


This entry was posted on July 3, 2009 at 6:36 pm and is filed under General Announcements with tags , , . You can follow any responses to this entry through the RSS 2.0 feed You can leave a response, or trackback from your own site.

Leave a Reply