More QoS Fun!!

Today, let's recap briefly about policy maps before moving on. The command show policy-map interface displays statistical information about the # of bytes, # of packets, 5 minute offer rate, drop rate, match command type (all or any), and the QoS PHB set for packets matching a class. Syntax options let you specify an interface, DLCI, VCI, or a particular class map.

Keep in mind that the load-interval for an interface affects your QoS statistics. The default load measurement interval is 5 minutes but can be dropped as low as 30 seconds. One other thing to keep in mind is that policy maps are processed JUST LIKE ACLs- if you put broad match statements first you may not be properly matching traffic. A final note- interfaces with 802.1Q enabled are the only ones that will accept service-policy commands that reference CoS in policy maps or class maps.

Class Based Marking using NBAR
Packet marking is normally done as close to the ingress point as possible. CB Marking is meant to simplify the other QoS tools by setting packet markings in a uniform manner. 

Once you've applied the command ip nbar protocol-discovery to an interface, you can display statistics with the command show ip nbar. These statistics will be independent of ones created by class based marking.

PDLMs (Packet Description Language Modules) are used to upgrade NBAR and allow recognition of more protocols. You load a new PDLM with the command ip nbar pdlm pdlm-name.

CB Marking Design Choices
When deciding whether to trust QoS markings already on packets during ingress, you may have to override what is present already in them. In that case, the following markings are what are usually agreed on for various packet types.


Traffic Type                       CoS                  IPP                   DSCP
Voice Payload                      5                       5                       EF
Video Payload                      4                       4                       AF41
Voice/video                          3                       3                       CS3
Mission Critical Data             3                       3                       AF31, AF32, AF33
Transactional Data                2                        2                      AF21, AF22, AF23
Bulk Data                             1                        1                      AF11, AF12, AF13
Best-effort Data                    0                        0                     BE
Scavenger                             0                        0                     2, 4, 6

Marking with Policers
The concept of a traffic contract is that you've agreed on certain values for data traffic transmission, namely the traffic rate (measured in bits/second) and the burst size (measured in bytes). If either value is exceeded, the data is subject to policing QoS actions.Note that we have two classes of data and hence two different policing policies can be applied!!

The simplest policing action is to just drop excessive traffic. However, IOS allows for a compromise action where traffic is re-marked. Cisco recommends you use CB Marking where marking requirements allow. They also state that if a traffic contract is agreed on you MUST mark with CB policers to ensure you are marking packets for compliance/exceed status.

QoS Pre-classification
When traffic is put through an encrypted tunnel, the ToS byte is the only indicator of QoS (it's copied to the new header). Features like NBAR are broken when dealing with encrypted traffic. This also affects the ability to take egress actions. To mitigate the problem, Cisco came up with QoS pre-classification.

By encrypting traffic after QoS changes are made you regain the flexibility to mark egress traffic. There are several places in the CLI where you can configure pre-classification: tunnel interface config mode, virtual-template config mode, and crypto-map config mode. The command used is qos pre-classify. A reference for where to use the command and why follows.

Config Mode                                             VPN Type
tunnel interface                                            GRE or IPIP
virtual-template                                           L2F or L2TP
crypto-map                                                 IPSEC

To view the results of the command, use show interface and show crypto-map. In the output of the former, you'll see the "queuing strategy" section has a comment about qos pre-classification. In the output of the show crypto-map command the same comment will be on its own line.

Policy Routing and Marking
Policy routing uses route maps for packet classification. A set command is used to define the route. Policy routing with marking can also mark the IPP field or entire ToS byte using set commands. The logic sequence involved is:

1. Packets enter an interface and are examined.
2. A route-map is used to match packets (all or some subset)
3. Marking is done as per the set command option already chosen

The traditional routing policy option can be used to set the route, but it is not a requirement in this instance. Cisco recommends marking packets via policy routing only when CB Marking is unavailable or when you have a defined need to both policy route and mark packets entering the same interface.


AutoQOS
Basically a macro that will configure your QoS for you. Best practice includes reviewing automatically generated configs though, to make sure you understand what's being done and so you can fine tune the config to meet your needs. Benefits of using it include:

• Simpler QoS deployment
• Fewer operator errors
• Cheaper QoS deployment because of reduced staff time creating configs
• Faster QoS deployment

The Cisco press book also states that deploying QoS without having any in-depth knowledge is a benefit. I'll leave that to you to decide. AutoQOS is further divided into two types- AutoQoS for VOIP and AutoQoS for Enterprise.

AutoQoS for VOIP
Supported on most switches and routers, this is used for both VOIP and video. CDP can be used on edge interfaces to detect the presence of a Cisco VOIP phone and auto-implement the needed configuration. On uplink or trunk ports this AutoQoS will trust the received markings for CoS or DSCP.


AutoQoS VOIP on switches
Once it is enabled for any interface, IOS configures AutoQoS globally. The access interface-level configuration command is auto qos voip { cisco-phone | cisco-softphone }. Unless a phone or softphone is discovered through CDP, all traffic is marked DSCP 0 by default. If a phone is found, the switch trusts markings received from it.

By default on ingress traffic, the following data types go to the priority queue: voice/video control traffic, real-time video traffic, voice traffic, routing protocol traffic, and STP BPDU traffic. All other traffic is queued in the normal ingress queue. On egress, voice traffic goes to the priority queue and all other traffic is distributed amongst other queues as per the QoS configuration.

You enable AutoQoS on an uplink port using the command auto qos voip trust. The trust option specifies that CoS markings (L2 interface) or DSCP settings (Layer 3 interface) from the far end are to be trusted.

A summary of the config put in place by AutoQoS includes:

• Globally enabling QoS
• Create CoS-to-DSCP and DSCP-to-CoS mappings
• Enable priority ingress and egress queues
• Map CoS values to ingress and egress queues and thresholds
• Map DSCP values to ingress and egress queues and thresholds
• Create class and policy maps for voice traffic and applies them to interfaces

Finally, you should always enable AutoQoS before any other QoS. Then go back and fine tune the configuration afterwards.

Ch 12 part deux- MQC and how Cisco marks traffic

In today's blog I'll be covering how Cisco marks traffic. While most people might turn NBAR on and run AutoQoS, that doesn't cut it for a CCIE. A deeper understanding of the tools and methodology is what separates the men from the boys.

Cisco's MQC was a long-overdue integration of multiple QoS configuration methods into a better organized set of processes. Now you have names that all start with "Class Based," which indicates you are configuring some QoS item with MQC. Those tool names include: CB Marking, CB Weighted Fair-Queuing, CB Shaping, CB Policing, and CB Header Compression.

MQC separates the marking functionality from the PHB (policy) function. This gives us 3 configuration areas in MQC: class maps for marking, policy maps for PHB setup, and the service-policy command to implement the policy config on an interface.

The class-map command uses the sub-command match to identify packets for marking. There are multiple syntax options for this command-

match [ip] precedence precedence_value [precedence_value precedence_value]
         Matches IPv4 packets when the ip parameter is included, or IPv4 and IPv6 commands when not used

match access-group  [access-group | name access-group-name]
        Matches packets via an access list name or number

match any

match class-map class-map-name
      Matches based on another class-map

match cos cos-value [cos-value cos-value]
     Matches based on CoS value


match destination-address mac mac-address
      Matches based on destination MAC address

match fr-dlci dlci-number
      Matches based on Frame Relay DLCI number

match input-interface interface-name
       Matches packets that ingress a particular interface


match [ip] dscp ip-dscp-value [ip-dscp-value ip-dscp-value]
       Matches IPv4 packets only if ip command used; otherwise both IPv4 and v6 are matched.


 match ip rtp starting-port-number port-range
        The port-range option tells you how many ports are covered by this match; it is NOT the ending port number

match mpls experimental number
       Matches an experimental number value

match mpls experimental topmost number
      Used when multiple labels are applied to match only the topmost or outermost label EXP value


match not match-criteria
     Reverses the matching logic


match packet length {max max-length-value [min minimum-length-value] | min minimum-length-value [ max max-length-value]}
      Matches based on max length, minimum length, or both

match protocol citrix app app-name-string
     Matches Citrix applications

match protocol http [ url url-string | host hostname-string | mime mime-type ]
       Matches a hostname, URL, or MIME type

match protocol protocol-name
       Matches an NBAR protocol type (hence, NBAR must be enabled)

match protocol rtp [ audio | video | payload-type payload-string ]
      Matches RTP traffic based on the payload type (audio, video, etc)

match qos-group group-value
      Matches a QoS group value, which is a locally defined value that offers additional flexibility for PHB setup. Basically you assign a value through a class map and can then identify those packets by the group value and perform special behavior modification on only them. Works well in a complex environment.

match source-address mac source-mac-address
       Matches a source mac address for packets.

If you need to match >1 item in a packet to classify it, class maps can use multiple match commands as well as nest inside each other. Up to four (CoS or IPP) or eight (DSCP) values can be specified in a particular match cos, match precedence, or match dscp command, respectively.

match any is the default behavior on a class map. match all defines a logical AND for the match statements.

http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfmcli2.html#wp1020290

The above is a decent reference for MQC configuration, particularly syntax options that may appear on the test.

NBAR
NBAR helps to classify traffic, particularly where it is difficult to use normal methods to do so. Some examples include ephemeral ports, P2P file sharing, and MIME types. This is called deep packet inspection and looks beyond just the header information. Separately from QoS, NBAR functions include tracking traffic (counters) and use by the NAT process.

Class Based Marking
Major points to remember about CB Marking:

• It requires CEF
• It is applied using the subinterface command service-policy in | out policy-map-name
• CB marking is applied sequentially, like an ACL
• You can configure multiple set commands in a single class map to mark the packet in several fields (ex: CoS and DSCP)
• Packets that don't match a class are considered to match the class-default class
• If any class doesn't have a set command configured, packets matching that class won't be marked

Command Reference for CB Marking

set [ip] precedence precedence-value
set [ip] dscp dscp-value
set cos cos-value
set qos-group group-id
set atm-clp
set fr-de


EXEC Command Reference for CB Marking
show policy-map policy-map-name
        Shows the configuration information about a policy-map

show policy-map interface-spec [ input | output ] class class-name
        Displays the statistics about a policy map that is enabled on an interface

Jumping Ahead

As a result of me wanting to brush up on my QoS skills, I'm jumping ahead to Chapter 12 in the book this week. And so begins "Classification and Marking," a saga in two parts, where our hero sets out to study the fields that can be marked, the mechanics of MQC (modular QoS CLI), and Cisco's tools such as Class-Based Marking.

First, though, let me briefly introduce some ideas about how queuing tool concepts will be working together. Classification is for marking packets so you can determine which queue they'll go into. This feature doesn't affect QoS per se by dealing with latency, or jitter, or bandwidth allocation, but it is the foundation for the other tools. Other Cisco tools that will affect QoS characteristics include the drop policy (affects loss), scheduling between queues (affects every QoS characteristic), and maximum queue length (affects loss and delay).

QoS Related Packet Fields

The IP header, LAN trunking headers, ATM cell header, and Frame Relay header all have at least one field that can be marked for QoS purposes. The book spends most of its time on IP Precedence and DSCP. This is because IP packet headers are retained during routing; layer 2 headers are removed when routing is done.

RFC 791 - defines the IP packet header, including a one byte field called Type of Service (ToS)- see section 3.1 in the RFC. ToS was further subdivided and the 3 higher order bits are known as the IP Precedence field. As a historical side note, most of the precedence names were taken straight from military message coding.

Differentiated Services - when DiffServ came along, it redesignated the ToS field and it became known as the DiffServ field. IPP was replaced by a 6 bit field called the DSCP or Differentiated Services Code Point. RFC 3168 defined the lower two bits of the DiffServ field as being used for QoS Explicit Congestion Notification (ECN),

Per-Hop Behaviors (PHBs) - RFC 2475 defines these as "differential treatment an individual packet receives, as implemented by queue service disciplines and/or queue management disciplines." The RFC explicitly states it is defining the behaviors and not the implementation mechanics, since the latter rapidly evolve with technology. Class Selector (CS) per-hop behaviors are used for backwards compatibility with IP precedence marking.

RFC 2598 - defines Expedited Forwarding class (DSCP decimal value 46). EF packets get queuing priority but should also be policed to prevent them from choking out other traffic. It also helps if you've properly estimated your bandwidth usage by EF traffic, but that is another story.

RFC 2597 - defines the Assured Forwarding PHB, with 4 classes inside it for queuing, and 3 levels of drop probability inside each queue. Thus, AF has 12 DSCP values it may set. The names of the values are formatted as AFxy where x is one of the 4 queues and y is one of the 3 drop probability settings. Higher x values correspond to better priority queuing treatment. Ex: AF13 is the lowest setting combination and AF41 is the highest.

Ethernet LAN Class of Service

Ethernet supports a 3 bit QoS field in 802.1Q or ISL trunking headers. 802.1Q defines the 3 most significant bits of the Tag Control field as the QoS field; it calls these bits the user priority bits. In the ISL header, the 3 least significant bits of the 1 byte User field are defined as QoS bits. They are known as the Class of Service (CoS0 field. Most people call Layer 2 QoS settings "CoS" bits, regardless of the actual trunking method in use.

Marking WAN Traffic

Both Frame Relay and ATM have a single bit used for QoS, but these are intended to identify only the drop probability of a cell or frame. Frame Relay calls this Discard Eligibility (DE) and ATM calls this bit Cell Loss Priority (CLP).

If you are using Multiprotocol Label Switching (MPLS) then you can use the MPLS Experimental (EXP) field, 3 bits intended for QoS marking. It is common to see DSCP or IP Precedence markings remapped into the EXP field at the boundary of an MPLS network.



Where Classification and Marking is done

Non-IP header fields will only exist in certain parts of the network, so you can end up doing classification and marking at multiple places. The rules on where to mark traffic are as follows:

• Classification of traffic: on ingress only (provided the interface supports the particular header field, i.e. EXP, CoS, etc)
• Marking: on egress only, again provided the header is supported 

Summary of Fields for Marking Traffic

Field                                       Location                                       Length
IP Precedence                         IP Header                                      3 bits
IP DSCP                                 IP Header                                      6 bits
DS Field                                 IP Header                                       1 byte
ToS Byte                                IP Header                                       1 byte
CoS                                       ISL & 802.1Q Header                    3 bits
Discard Eligible (DE)              Frame header                                  1 bit
Cell Loss Priority                    ATM cell header                             1 bit
MPLS Experimental               MPLS Header                                 3 bits

Notes on various RFCs (re: Ch. 5)

VRRP

RFC 3768 - VRRP creates a virtual router, managed by an elected master router which forwards packets to ensure load balancing among gateways. The assigned multicast address is 224.0.0.18.
Cisco - VRRP priority values are 1-254, higher being preferred; preemption occurs by default. VRRP object tracking can be used to modify values dynamically. The default authentication for VRRP is plaintext; MD5 strings or key chains can also be used. Note: per Cisco MD5 key chains are supposed to be rotating; I can find no config commands to do this for VRRP though. The punks in programming need to get on the stick!


NTP (v3)

RFC 1305 - discusses truechimers and falsetickers, convergence functions to eliminate the effects of falsetickers. It specifies the following five modes-

• Symmetric Active: a host sends messages regardless of peer reachability or stratum (it will synch and be synched by the peer)
• Symmetric Passive: normally created by receipt of message from a symmetric active peer; only persists while peer is reachable and operating at a stratum <= that of the host receiving the message. This state always lasts at least until one reply is sent to the peer.
• Client: host sends periodic messages regardless of peer reachability or stratum. Think a LAN workstation.
• Server: normally created when receiving a client request message; exists only to reply to that message and the association is then dissolved. So the server will synchronize, but won't synch with, a client.
• Broadcast: a time server that will synch devices on a LAN but won't synchronize with them

NTP Configuration for Cisco Nexus
Cisco IOS 12.1 NTP Configuration Commands (side note: Nexus doesn't yet have NTP authentication commands)

Syslog

RFC 5424 - describes the standard format for syslog messages
PCAP- the Wireshark Book website has an example file available (syslog.pcap) for download
Cisco - All IOS syslogs have the following attributes: timestamp (optional), facility (where it came from), severity, message name, message text

SNMPv3 Beginner's reference

RFC 3410 - Describes the origin and evolution of SNMP. Leaving aside clients and management servers, SNMP is a framework consisting of a management protocol and the Management Information Base (MIB). By decoupling the protocol and the MIB, SNMP has been able to expand through several versions.SNMPv3 is based on RFCs 1902-1908 and adds security and administration capabilities.
RFC 3416 - this is the nitty gritty for network engineers: SNMP operations you will see (GETREQUEST, GETBULKREQUEST, etc). You want to know section 4 of the RFC pretty well.
RFC 3414 -  describes how that new authentication model (user-based security) works in SNMPv3
PCAP - don't rely on the Wireshark book downloads here! Their pcaps are only SNMP v1. Try PCAPR which has examples of all SNMP versions available.

This concludes today's blog, netizens. Move along, nothing to see here.

Ch 5 Notes and other tidbits

 I'm going to reference exam topics by number in all future posts. It's quicker. If you don't know what I'm referencing, grab a copy of the CCIE Blueprint from here- https://learningnetwork.cisco.com/docs/DOC-4374

Today's posting only covers the main topical protocols of the chapter. I intend to follow up tomorrow with a second posting regarding the related RFCs mentioned (for SNMP, syslog, NTP, etc).

Book Notes

Ch. 5, IP Services, covers the protocols ARP, Proxy ARP, RARP, BOOTP and DHCP. These are not directly related to one exam topic; instead they are knowledge you might need to understand several other topics. Those include 9.10, 9.30, and 9.40. There may be others, but I think these are the likely culprits for test questions.

ARP and proxy ARP are used by a host to learn another host's MAC address. RARP, BOOTP and DHCP are about a host getting an IP address (and related info, such as DHCP options). Related RFCs you'll want to skim, if not read entirely, are:

• ARP- RFC 826
• Proxy ARP - RFC 1027
• RARP - RFC 903
• BOOTP - RFC 951
• DHCP - RFC 2131

Also mentioned in the chapter are HSRP, VRRP, GLBP, CDP, NTP, syslog, and the SNMP versions (1, 2, 2c, and 3). Relevant RFCs are:

• VRRP - RFC 3768
• NTP - RFC 1305
• Syslog - RFC 5424
• SNMP beginning reference - RFC 3410
• SNMP version 3 - RFC RFCs 2578–2580, 3410–3415
• SNMP ver 2c - RFC 1901

I'm omitting RFCs for earlier SNMP versions since it's not in use. However, it may behoove you to understand how the specification has changed over time, specifically what new features were added in which release. That seems to be a common test question(s).


RFC and other resource notes

ARP Notes
RFC 826- "The world is a jungle in general, and the networking game contributes many animals."
      ARP is used only for resolution in the same broadcast domain

http://docwiki.cisco.com/wiki/Internetworking_Basics 
      The section "Mapping Addresses" details ARP

Wireshark PCAPs
       Grab the packet captures from http://wiresharkbook.com/ and check out a real ARP packet to understand its format

RARP Notes
RFC 903
    RARP requires 1+ servers to maintain a mapping of MAC to IP and respond to client requests. The packet format is the same as ARP, but two new OPCODES are used- 3 and 4, request reverse and reply reverse
PCAP- http://www.pcapr.net/ has a RARP sample. Registration is required for the site

BOOTP Notes
RFC 951- BOOTP consists of 2 phases: address assignment and a file transfer (generally TFTP). Port numbers used are 68 (client) and 67 (server).
PCAP- http://www.pcapr.net/ has a BOOTP sample PCAP you can download (registration required)

DHCP Notes
RFC 2131
      DHCP is an extension of BOOTP. It follows the format DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK (for a normal, working process)

PCAP
     The Wireshark Book pcap file dhcp-boot.pcap shows an example of DHCP. 

Current Status

So- currently I'm reading through CCIE Routing and Switching Certification Guide, 4th edition. This blog will document my progress, notes, and study methodology. As a side note, I'm using techniques from the excellent book, How To Read A Book, to analyze the book in question, as well as synthesize data from different sources.

My approach is to take an exam topic, summarize high points from the book, read all supplemental materials recommended in the book, summarize those, and then round out the topic with any additional research/reading I feel I need for mastering the information. I'm also utilizing memory schema from the book Learn To Remember to aid in retaining the voluminous data I'm covering. Not that I find it boring. :-)