Chapter 14: Shaping, Policing and Link Fragmentation

The three tools mentioned in the chapter title are used for traffic shaping. Traffic shaping involves delaying packets when exiting a router to ensure the traffic rate doesn't exceed a configured bit rate. We'll be discussing both concepts and the Cisco tools for shaping- Frame Relay Traffic Shaping and Class-Based Shaping.

Traffic policers moderate packet rates for trafffic entering or exiting a router. Once the defined rate is exceeded, the policer either remarks packets or discards enough to reach the proscribed bit rate. Traffic shaping in Cisco routers uses a shaping queue, which is used to delay packets and help them match the configured rate.

Traffic shaping is used to solve 2 problems in a multi-access network: first it discards traffic to ensure conformance, preventing customers from sending more than the agreed upon rate. Secondly, egress blocking is partially resolved. Egress blocking occurs when a frame relay or ATM switch has to queue data on the VC. Shaping moves this queuing to the router and allows for manipulation with queuing tools.

Details of Cisco Shaping

Theory
The Cisco shaper process uses a base time interval, known as Tc. It uses that time interval to calculate the number of bits that can be sent, per second, to match the configured shaping rate. Bc, or comitted burst, is the amount of data that can be sent per Tc interval. Comitted information rate, or CIR, is the defined rate of a VC. Excess burst, or BE, is the amount of data beyond Bc that can be sent after a period of inactivity.

The excess burst concept is used to deal with bursty traffic. After a period in which less data than the CIR has been sent, more than Bc bits can be sent over the course of one or more Tc intervals. If configured, the shaper allows Be extra bits to be sent.

Details
The formula used to calculate Tc is easy:

Tc = Bc / shaping rate
 
The values available determine how the remaining portion is calculated. For example if both Tc and shaping rate are configured on the router, Bc will be calculated as shaping rate * Tc using a derivative of the formula.

However, both frame relay traffic shaping and class based traffic shaping may use default values in some cases.

A token bucket model is used to handle shaping. Let's review a couple of situations to better understand the token bucket. First, consider a situation where Be is not configured. A bucket the size of Bc is filled with tokens at the start of each Tc, giving the ability to send Bc amount of data.

 The shaper will perform two functions related to the bucket: fill it with tokens, and spend them to forward packets. If the bucket is refilled and tokens still remain from the prior fill-up, any amount greater than Bc is excess and will not be used. To send a packet there must be enough tokens in the bucket; a token is equal to a bit. Hence, 1000 tokens are needed to send a 1000 bit packet. If not enough bits are available, the shaper must wait until the next interval.

In a second model, the Be model is implemented by making the single token bucket bigger. This allows for more tokens than Bc to be available at the beginning of an interval once the bucket is refilled.

Frame Relay and Traffic Shaping
When shaping traffic over a frame relay network, you can configure it to adjust the shaping rate over time based on presence or absence of traffic congestion. Effectively, you can set a floor for traffic shaping. As congestion increases, the shaper lowers the shaping rate. The minimum by default is 50%, but it can also be configured. This floor is known as the minimum information rate (MIR) or mincir.

Cisco routers detect congestion and lower the shaping rate in response to one of two inputs:

• receiving a frame with the BECN bit set
• receiving a Cisco-proprietary Foresight congestion message

Upon receiving either of these, the shaper slows traffic shaping by 25%. CB Shaping does this by decreasing Bc and Be by 25%, but keeping the same Tc. Once 16 Tc increments pass without receipt of a BECN or Foresight message, the shaping rate is allowed to grow again. It will grow by 1/16th of the actual Bc or Be values until the maximum rate is reached.

Generic Traffic Shaping (GTS)
GTS is a form of traffic shaping available on most routers, but not usable with flow switching. GTS is configured at the interface or subinterface level. The basic GTS configuration shapes all traffic leaving the interface but you can implement a more advanced setup using an ACL to identify a subset of traffic which is to be shaped. The ACL should permit traffic to be shaped and implicitly deny all other traffic.

The command to enable GTS is traffic-shape rate shaped-rate [Bc] [Be] [buffer-limit]

The shaped rate is specified in bps, and the Bc and Be figures are in bits. Buffer-limit sets the maximum size of the queue buffer and is set in bps. Only the shaped-rate is required; Bc and Be values will default to 1/4 of the shaped-rate if not explicitly specified.

GTS can also be configured on frame relay interfaces. First you'll need to configure the traffic-shape rate command, as above, and add the following separate command: traffic-shape adaptive bit-rate. The bit-rate in this command is given in bps and it specifies the minimum bandwidth the router will use if it receives BECNs.

RSVP- Resource Reservation Protocol

RSVP is covered in the CCIE R&S Exam guide, but I have not heard of this protocol being used in production environments (although I'm sure it is in use). Given that it uses an Intergrated Services model where the protocol reserves bandwidth before a call is made, it's not as common as "per hop behavior" or DiffServ QoS treatment of traffic. The bandwidth reservation happens separately in both directions, so that one reservation is for source to destination traffic and a second one is for the opposite (destination to source).

While some devices might be capable of issuing RSVP reservation requests, the expected behavior is that a gateway device will issue the request for the end user device. The RSVP protocol uses PATH and RESV messages to request and reply to reservations, respectively. Upon receipt of a RESVCONF message, the gateway devices will allow the call (or other traffic) to proceed.

Configuring RSVP

After you decide on the amount of bandwidth to be reserved per call or per flow and the total amount of RSVP allocated bandwidth per interface, you'll need to configure each router that will run RSVP. Because you must take into consideration the interface bandwidth and configuration on each interface of each configured router, you can tell this will be a non-trivial task. It also doesn't scale well, which explains why RSVP and the Integrated Services model haven't been widely adopted.

Relevant Cisco commands are:

router(config-if)# ip rsvp bandwidth TOTAL-KBPS SINGLE-FLOW-KBPS
   By default, RSVP will reserve 75% of the interface bandwidth (unless you configure this command). Also, any single flow can reserve the entire amount of bandwidth unless you specify otherwise with this command.

router(config-if)# ip rsvp signaling dscp DSCP-VALUE
  This command sets the DSCP value for RSVP control messages.

More about 3560 QoS

When it comes time to talk about queue-sets on the 3560, I find a LOT more research is needed than I expected. Check out the following blog from INE.com to better understand how QoS configuration changed between the 3550 and 3560. It has an excellent section which explains how queue-sets are just a buffer space partitioning scheme for the switch.

http://blog.ine.com/2008/03/03/bridging-the-gap-between-3550-and-3560-qos-part-i/

That URL plus some research on the Cisco website for 3560 QoS configuration helped me understand how queue-sets work.

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.1_19_ea1/configuration/guide/swqos.html#wp1163863

The upshot is that by having two queue-sets available, you can provision two different QoS egress architectures on a single 3560. This will let you customize thresholds and buffer allocation for two groups of ports. However, an interesting side note is that DSCP and CoS mapping to queues remains global for all ports. This means the queue-sets are being utilized only to address different port speeds on the switch.

More on LAN Switching and Congestion Avoidance

The 3560 is the model I've got in my lab to test things on. It's helped me understand things like the method in use for congestion avoidance, weighted tail drop (WTD). Enabled with QoS, WTD will create 3 thresholds per queue for tail drop. The CoS value is used to help set the thresholds- you associate a CoS value(s) with the threshold for drops. In this case, usually CoS 6 and/or 7 is set to the last (highest) threshold, which performs tail drops once the queue reaches 100% full.

WTD is highly granular because it can be configured separately for each of the 6 queues on a 3560 (there are two ingress and four egress queues). The complexity is increased because you have to decide whether to trust CoS (or DSCP) values on received traffic, or to remark the traffic. Let's look at what to do if you trust markings received.

To assign specific CoS values to a threshold, use the command:
mls qos srr-queue input cos-map threshold THRESHOLD_ID cos1 . . . cos8
If you are trusting DSCP values, the command used to associate them with thresholds is:
mls qos srr-queue input dscp-map threshold THRESHOLD_ID dscp1 . . . dscp8
The command to associate tail drop percentages with thresholds is:
mls qos srr-queue input threshold QUEUE_ID THRESHOLD-PERCENTAGE1 THRESHOLD-PERCENTAGE2

Cisco 3560 Egress Queuing
The 3560 has 4 egress queues per interface. Just like with ingress queues, you can configure DSCP or COS mappings to each, set up weights, and configure WTD drop thresholds. If you configure a priority queue, it MUST be queue 1. A major difference is that while ingress commands were executed at the global level egress commands are run at the interface level.

On an odd note, the 3560 apparently is architected to slow down egress traffic. The book claims this allows implementation of subrate speed for Metro Ethernet as well as to prevent "some types of DoS attacks." I can find no information on the latter.

Slightly complicating queuing is the fact that 3560s assign an internal DSCP value to a frame. This is determined when the forwarding decision is made. Once the internal DSCP is assigned and an exit interface determined, two things occur:

1. Internal DSCP value is compared to a global DSCP-to-COS map to determine the COS value of the frame
2. The per-interface COS-to-queue map indicates which queue the frame will be placed in

 Let's next discuss the scheduler, which handles packets after they are queued. Confusion can arise because the 3560 has two different methods for scheduling that use the same acronym of SRR: they are shared round robin and shaped round robin. Both address the issue of queue starvation when a priority queue exists, but the shaped version rate-limits queues so that they will not exceed the configured bandwidth allowance.

The text offers two examples to understand how these schedulers work. In the first one, all queues hold some amount of frames. Both shaped and shared scheduling will service queues based on the weighting configured. The commands for weighting egress queues are:

srr-queue bandwidth share weight1 weight2 weight3 weight4
srr-queue bandwidth shape weight1 weight2 weight3 weight4

Per the IOS command reference for 12.2.25SEE, SRR shaping default weight is 25 for queue1 and zero for the other three. The other three also operate in shared mode by default. However, the queue setup is different for SRR sharing- each queue is assigned one quarter of the bandwidth. It's worth noting here that as per the IOS command reference, shaped queues with a zero weight configured will IGNORE the weighting assigned with the command srr-queue bandwidth shape and instead will use the values configured with the command srr-queue bandwidth share. So by default, when shaping queues you also are sharing them and will want to configure both commands to complete your QoS config on the 3560. *sigh* I hate extra typing!

Moving on, let's consider how the schedulers operate when not all queues contain traffic. If only one queue contained traffic and that queue had a weight of 25, then in shared scheduling this queue would utilize all the bandwidth for its traffic. However, if shaped scheduling were in use, the scheduler would delay sending packets even if no other queues had traffic to send, to limit the queue to 25% of bandwidth.

Let's now talk about having a priority queue (queue 1 is the only choice possible, remember). If all queues had traffic EXCEPT queue1, and then queue 1 has frames arrive, the scheduler will finish sending its current packet and service queue1 to the configured bandwidth limit (25% by default). Excess frames will be queued rather than discarded in this scenario.

Now let's imagine that queue1 has packets queued up like crazy and the other queues are empty. Here the scheduler behaviors will be different. In shared mode queue1 will be allowed to transmit at full line rate. In shaped mode, queue1 will be serviced to guarantee only its configured percentage of bandwidth (25 by default). The main takeaway from these examples is that shaped SRR will never allow the priority queue to exceed its configured bandwidth percentage, even if no other queues have traffic to send.

Next time we'll discuss egress queue-sets and more of the architecture used in sending out traffic from 3560s.

LAN switching: Congestion avoidance and management

The text discusses 3560 switch queues, specifically how this model has ingress and egress queues. There are two ingress queues, but only one of them can be configured as a priority queue, and these queues use a method called Weighted Tail Drop during periods of congestion.


Shared Round Robin (SRR) is used in the 3560 to schedule packets from the ingress queues to the backplane fabric. You can specify the guaranteed amount of traffic each queue will have (weighting), but neither queue is limited to only that amount. This way, if one queue is empty the second ingress queue can utilize all the bandwidth available for sending traffic.Finally, you should know that SRR weighting functions more like a percentage specification than as a bandwidth amount (e.g.- it is relative and not absolute).

Behaviors you'll want to keep in mind when you configure ingress queuing include:

1) COS mappings are used by default; COS 5 traffic gets its own queue. DSCP mapping is available.
2) You'll need to specify if the second ingress queue is a priority queue
3) Ensure the default WTD thresholds are appropriate for your traffic; at 100% full traffic is dropped by default
4) WTD can have up to three different thresholds where traffic is dropped in increasing increments

Priority Ingress Queuing
The relevant command is mls qos srr-queue input priority-queue QUEUE-ID bandwidth WEIGHT. In this syntax, the weight value is a percentage of link bandwidth. The next command used is mls qos srr-queue input buffers PERCENTAGE1 PERCENTAGE2. The default for the latter command has 90% of buffers allocated to queue 1 and 10% to queue 2, so you'll want to watch out for this if your priority queued traffic needs more buffers.

Unfortunately, when I tried to Google search the 3560 or 3750 buffer sizes I had no luck determining either how large the buffers are, or how best to check for buffer size problems! The best info available was to run a show interface command and check the input section for buffer overflow packets being reported. That's far from an exact science.

You'll also need to configure the SRR scheduler for both queues-  mls qos srr-queue input bandwidth WEIGHT1 WEIGHT2. Although the word bandwidth appears in this command, it's not an actual BW value but a weight number being specified. Confusing eh? Default values are 4 and 4 for weight1 and weight2, which divides scheduling evenly between queues. Although I've been Googling, I cannot locate solid info on what happens to the second queue once you configure a priority queue and its weight value. I'll test this in my lab tomorrow and update the blog.

EDIT: So the results are in! Configuring the bandwidth weight with mls qos srr-queue input priority-queue changes a weighting value, which is multiplied by the bandwidth value (set using the command mls qos srr-queue input bandwidth). To see these command options being changed, you'd check the output of the command sh mls qos input-queue. Sample output is below-

Rack1SW1(config)#mls qos srr-queue input priority-queue 2 bandwidth 30

Rack1SW1#sh mls qos input-queue
Queue     :       1       2
----------------------------------------------
buffers   :      90      10
bandwidth :       4       4
priority  :       0      30
threshold1:     100     100
threshold2:     100     100

Rack1SW1(config)#mls qos srr inp ban 2 6

Rack1SW1#sh mls qos input-queue
Queue     :       1       2
----------------------------------------------
buffers   :      90      10
bandwidth :       2       6
priority  :       0      30
threshold1:     100     100
threshold2:     100     100

Queuing Strategies and Tools continued

The Magic of WRED Weighting
WRED looks at IP precedence or DSCP values to prioritize packets when the time comes to discard. You configure this via a traffic profile, which has a minimum threshold, a maximum threshold, and a MPD value. These profiles provide granular control over discarding, for example IPP 0 traffic can be discarded at a lower threshold than other traffic.

As with many IOS features, WRED has default profile settings assigned to DSCP values. Here's a chart of them:

DSCP    Min. Threshold   Max Threshold  MPD
AFx1             33                    40                      10
AFx2             28                    40                      10
AFx3             24                    40                      10
EF                 37                    40                      10

Since WRED uses the queue depth as a trigger for dropping traffic, you have to configure it for each queue. There are limits on which queuing mechanisms support WRED, though. They are physical interfaces with FIFO queuing, ATM VCs, and non-LLQ classes in a CBWFQ policy map. N.B.- when you configure WRED on a physical interface, all other queuing mechanisms are disabled and you'll have only one FIFO queue!

random-detect is the command to enable WRED. The default is to check IPP, so if you want to use DSCP you'll have to use the syntax random-detect dscp-based. If you want to change the default WRED values, the syntax for IPP or DSCP commands is as follows-


random-detect precedence IPP_value min-threshold max-threshold [mark-probability-denominator]
random-detect dscp DSCP_value min-threshold max-threshold [mark-probability-denominator]

One last odd note from the CCIE study book pertains to changing the rolling average of queue depth. If you feel the need to adjust the calculation, you can use the command random-detect exponential-weighting-constant EXPONENT. Changing this exponent value from default will affect drops because WRED doesn't base its decisions on the current queue length; WRED uses the average queue length to decide whether to drop packets. It appears that in most cases you'd be looking to shorten the time between calculating the average queue lengths.

Modified Deficit Round Robin (MDRR)
This was implemented only in the Cisco 12000 series because they didn't support CBWFQ or LLQ. It's expected that you'd only need to know the concepts of how MDRR works, so my discussion will be brief. MDRR configures 7 queues (0-6) which are serviced in round robin method. One additional queue is a priority queue.

If there are no packets in the PQ, each queue gets serviced in turn (once/cycle). If there are packets in the PQ, it will service them in one of two ways depending on configuration. Strict priority mode always services the PQ but will starve other traffic. Usually alternate mode is used for this reason. Alternate mode services the PQ in between each regular queue (PQ, queue1, PQ, queue2, etc.). You may still get jitter with this method but no starvation will occur.

MDRR also has two concepts you'll want to know: quantum value and deficit. These relate to MDRR scheduling. The quantum value is a number (in bytes) of data that will be transmitted from each queue. The deficit concept comes into play when a router pulls a packet from a queue that exceeds the quantum value. Since more bytes were sent than the quantum value "allows," the router tracks the extra data sent and subtracts that number from the quantum value when it next services that queue. Over time, this guarantees that each queue will get its configured percentage of the bandwidth.

Queuing Strategies and Tools

As I'd mentioned at the beginning of my notes, queuing impacts for major characterisics of QoS. Those are bandwidth, delay, jitter, and packet loss. The default FIFO queue that IOS creates in memory to handle packets affects drop, delay, and jitter. This is because of its size: once full, tail drop of packets will happen. You can prevent this by lengthening the queue, but that has impact on delay and usually jitter. And of course, if traffic rates exceed the interface bandwidth, your chances of a drop are higher regardless of queue length.

The Cisco QoS Exam guide offers better insight into the queuing process than does the CCIE book. It displays a sample with two queues to better explain the process. Here's a diagram I created which is similar to the one in the book.

This diagram shows the major questions a chosen queuing method will answer. Note that while question 1 appears to be classification/marking, this is actually part of the queuing method's decision process. In other words, it is a queuing choice based on the markings which have already been applied by marking/classification. Don't get confused!

Each queue will normally be FIFO, unless you set class-default to use WFQ. This was mentioned before as an option. The interface subcommand is fair-queue.

After queuing occurs, queue scheduling will be done. This is the pattern, or algorithm, used to service queues. This can take several forms, such as always servicing a particular queue first, or a bandwidth cap may be observed, etc.


Weighted Random Early Detection (WRED)
This queuing mechanism monitors the usage of a queue and progressively drops traffic as it is more heavily utilized. This is done in hopes that TCP is the main protocol in use; if TCP is present, it will retransmit lost traffic and throughput will be better managed. If not, you will have a problem.

There are settings WRED uses you'll want to be familiar with. Among them are:

Average queue depth- this is compared to thresholds you set and then actions are taken (drop/remark traffic)
Mark probability denominator- used to specify how much traffic is being dropped; 1/X, where X is is the mark probability denominator. This calculation sets the max threshold drop percentage.

Low Latency Queuing (LLQ)

For delay sensitive traffic, LLQ is the best choice to ensure good performance. It works pretty much like CBWFQ  but adds the capability for some queues to be configured as low-latency. These are treated as strict priority queues, meaning LLQ always services packets in them first.

Confusion over terms can arise because even a single policy map with one low latency queue configured is known as LLQ. Also, the older Priority Queuing (PQ, no longer in use) is simliar to LLQ and sometimes a single LLQ may be called a ""priority queue." This is due to the IOS command used to configure a low latency queue-  priority.

LLQ queue adds a low latency queue, but prevents queue starvation which was a problem under the older PQ. LLQ will in fact police the low latency queue, making the configured bandwidth both a guaranteed minimum and a policed maximum. So while low latency is guaranteed, some packets might still be dropped to prevent starvation of other queues.

The priority  command is the only addition to queuing configuration commands in IOS for LLQ. It's used instead of the bandwidth command during class configuration. The full syntax is-

priority { bandwidth-kbps | percent  percentage } [ burst ]

An example LLQ configuration follows, taken from the text. It assumes all traffic is already marked as EF, etc.

policy map queue-on-dscp
     class dscp-ef
         priority 58
     class  dscp-af41
        bandwidth 22
     class dscp-af21
        bandwidth 20
        random-detect dscp-based
     class dscp-af23
         bandwidth 8
          random-detect dscp-based
    class class-default
          fair-queue
          random-detect dscp-based

interface Serial0/0
       bandwidth 128
       max-reserved-bandwidth 85
      service-policy output queue-on-dscp

More on Defining and Limiting Bandwidth for LLQ

The priority command for LLQ provides you two choices- define bandwidth as a set number or as a percentage of the total interface bandwidth (the latter is because there's no remaining percent option). Unlike the bandwidth command, you can use both choices within a single policy map. Madness, isn't it?

Of course, you've still got an upper limit set by IOS on total bandwidth usage: max reserved bandwidth times interface bandwidth. Both LLQ and non-LLQ classes can't exceed this magic number. Because both options for the priority command can be used in a single policy map, calculating this number can be confusing unless you pay careful attention. As the book states, you could have one LLQ using the priority option for bandwidth #, another LLQ with bandwidth %, and non-LLQ queues using one of the three bandwidth options.

Let's look at an example using a 256 kbps interface and 3 classes. The unreservable bandwidth is 25% of that, or 64 kbps. Let's say class 1 is configured with priority 32, class 2 with priority percent 25, and class 3 has bandwidth remaining percent 75. This means 32 kbps is used for class 1, 64 kbps for class 2, and 72 kbps for class 3.

As I mentioned before, the calculation for the command bandwidth remaining percent changes when priority queuing is in place. Normally, the command calculates bandwidth remaining as interface bandwidth minus reserved bandwidth (default value 25%). With LLQ in place, this calculation becomes interface bandwidth minus reserved bandwidth minus bandwidth allocated thru priority commands.

Also worth mentioning at this point is why you'd configure multiple queues with the priority command. The answer is policing of traffic. Although you may configure multiple LLQ queues, in reality all these packets will be dumped into one prioritized queue, which will then be serviced FIFO. However, the policing of traffic for each LLQ queue will still take place. Typically, this is used to separately police voice and videoconferencing traffic. Sometimes you'll want to rate limit separately like this.

Miscellaneous Notes
You'll want to configure a bandwidth command under the class class-default. Otherwise, IOS will divide any unallocated bandwidth equally among all classes; this can result in the class-default class having a very small amount of bandwidth.

Similarly, if a queue is empty, IOS will dynamically attempt to redistribute that bandwidth to other queues in proportion to their configured bandwidth commands. Finally, IOS will only use queuing when congestion occurs. Since applying a queuing policy causes IOS to shorten the hardware queue automatically (generally to 1 or 2 packets), "congestion" will occur frequently, ensuring that your QoS policy is enforced on almost all traffic!

Also of note is flow based classification. While only briefly referenced in the text (and in a table at that), flow based classification is for achieving finer granularity in applying QoS. Specifically, it's intended for User Based Rate Limiting.

Ch 13 QoS Congestion Management and Avoidance

Queuing, or congestion management, is used to manage frames before they exit a device. In routers this is known as output queuing because IP forwarding decisions are made prior to the queuing. Congestion avoidance is a term for managing traffic to decide if/when packets will be dropped during congestion periods. The most common congestion avoidance tool is Weighted Random Early Detection (WRED).

The concept of fancy queuing is defined as using congestion avoidance and management techniques. This is as opposed to simple queuing where you use FIFO. Hardware queuing always uses simple queuing (FIFO) and has the following characteristics:

• No CPU interrupt is required between packet transmissions from the queue
• It cannot be affected by IOS queuing tools (since this is the last step before transmission on the wire)
• The only controllable function from IOS is queue length
• IOS automatically shrinks hardware queues when other queuing tools are in use
• These shorter hardware queues mean traffic is more likely to end up in configurable software queues

 One example given in the text is using the tx-ring limit command to configure the number of packets allowed in the hardware transmit queue before buffering into software queues will begin. This is, of course, an interface level command. Interestingly enough, Cisco documents state that this command can be applied to each subinterface PVC, rather than being tied to the interface as a whole. This command is also generally only seen in use on older IOS, with slower speed links (<768K), where manual tuning of parameters is required.

IOS queuing tools maintain software-based queues that feed into the hardware queue, on a per-interface level. Queuing tools can also be used along side traffic shaping, which basically delays packet(s) to ensure that the traffic rate for a class doesn't exceed the defined rate. If you use shaping, it queues packets (by default into a FIFO queue). Also, depending on the shaping tool(s) used, you might be able to manipulate the delayed packets using a queuing tool. However, this won't be discussed until Chapter 14.

The book lists 5 major queuing tools in use with IOS: classification, drop policy, scheduling, maximum number of queues, and maximum queue length. Brief notes on each include:

Classification- checking packet headers to select a queue
Drop Policy- rules for dropping packets during congestion
Scheduling- logic for which packet to dequeue and send next
Max # Classes- how many classes of packets a queuing tool can utilize or is configured to use
Max Queue Length- upper limit of packets contained in a single queue


Queuing Tools: CBWFQ and LLQ
Class Based Weighted Fair Queuing (CBWFQ) reserves bandwidth for each individual queue and provides a way to implement WFQ for the class-default queue. Low Latency Queuing (LLQ) implements a Priority Queue (PQ) in addition to CBWFQ, but unlike the original PQ there can be no starvation of other queues. Both are configured via MQC with its wealth of classification options.

The largest implementation difference is whether you use the bandwidth command (CBWFQ) or the priority command (LLQ). Both support up to 64 queues or classes. Both implement a special queue known as the default (class-default) queue. If a packet fails to match any class-map specifications it is handled by the default queue.

CBWFQ Features and Configuration
CBWFQ implements a scheduler to guarantee a configured percentage of bandwidth to each queue. However, if some queues are empty, bandwidth will be allocated across other classes temporarily. CBWFQ implements that standard classification features. Its drop policy choices include either WRED or tail drop, configurable per queue.

As said, there can be up to 64 queues. Max queue length support varies according to the model of router used. Within each queue, CBWFQ uses FIFO scheduling, except for the class-default, which can use either FIFO or WFQ.


Command Reference
bandwidth { kbps | percent percentage }
             Class level subcommand; sets BW %
bandwidth { remaining percent percent }
              Class level subcommand; sets aside a % of remaining BW for the class
queue-limit queue-limit
             Class level subcommand; sets the maximum length for a queue in packets
fair-queue [ queue-limit queue-value ]
             Class level subcommand; enables QWFQ in the class (class-default only)
max-reserved-bandwidth percent
              Interface level subcommand; sets % of link BW for all classes except class-default. Defaults to 75%

An example config
This is an example config which would place VOIP traffic into one queue and everything else into class-default.

class-map match-all voip-rtp
   match ip rtp 16384 16383
policy-map queue-voip
   class voip-rtp
       bandwidth 64
   class class-default
       fair-queue
interface Serial0/0
   encapsulation frame-relay
   load-interval 30
   bandwidth 128
   service-policy output queue-voip

Define and Limit CBWFQ Bandwidth Usage 
When you apply a service policy to an interface, IOS checks the configured bandwidth (using the bandwidth command) against the bandwidth defined for the policy. The policy defines bandwidth needs using two subcommands- bandwidth and max-reserved-bandwidth. Nonreservable bandwidth is meant for use by overhead traffic.

When defining the bandwidth for CBWFQ, the policy-map uses the product of the bandwidth and max-reserved-bandwidth commands. So if the interface bandwidth is set to 512 kbps and the max reserved value is 75 percent, the policy-map has 384 kbps of bandwidth which can be allocated among the various queues (or bandwidth commands). If the policy-map allocates more total bandwidth than would be available using this calculation, IOS will reject the policy (you can't apply it). Go do some math and try again!

If you're thinking of just changing the max-reserved-bandwidth setting instead to a higher number, be aware that Cisco doesn't recommend you monkey with the defaults unless you know what you're doing. Another way to allocate bandwidth without specifying traffic size in kbps is to use bandwidth percent or bandwidth remaining percent. This makes it unlikely you will oversubscribe. The trade off is you still need to be certain how much bandwidth in kbps is allocated to priority queues such as voice and video.

There's a bit of subtlety to using the latter two commands though. Bandwidth percent sets reserved bandwidth for a class as a percentage of the total interface bandwidth. Again, IOS will check the total value set using these commands within a policy map to ensure it doesn't violate the value set using max-reserved-bandwidth (default 75%).

Bandwidth remaining percent defines bandwidth as a percentage of remaining bandwidth. However, the calculation changes when LLQ is used. Remaining bandwidth is another name for the product of bandwidth and max-reserved-bandwidth. Taking my earlier example of a 512 kbps link, remaining bandwidth would be 384 kbps. If the command bandwidth remaining percent 50 were issued on a router, 192 kbps would be set aside for that particular class.

All total, there are three different bandwidth related commands in place here: explicit, percentage, and remaining percent. IOS will only allow you to use one of the three methods in a single policy map. The following table is taken direct from the book:

Method                   BW Amt Rsvd               Sum BW Values Must Be <=
Explicit BW            As per command           Interface BW x Max-Rsv-BW
Percent                  % of interface BW       Max Reserved BW setting
Remaining %          % of reservable BW    100 %

Add'l Reading: QoS classification and marking

Some notes that perhaps didn't get clearly stated in my first posts about marking traffic with ACLs versus using the match command. If you use an extended ACL, you get all the options that format presents for matching traffic. This includes IP traffic (Source/Destination IP address, ToS, IP precedence), ICMP, IGMP, TCP, UDP, and of course DSCP.

Using the match command allows you to directly specify the IP Precedence and DSCP fields without using an extended ACL. However, other syntax options give you the flexibility to identify traffic based on source/destination MAC address, MPLS experimental bit, CoS, input interface, RTP UDP port numbers, QoS group, NBAR protocol types, NBAR Citrix applications, and hostname/URL strings.

IP Precedence and DSCP Values
I looked back at my notes and realized I have not yet transcribed these. This table is excerpted from the Cisco QoS Exam Certification Guide. The key to remembering these is of course the binary value arrangement. If you try and use the decimal, you're missing the structure of the design!

Note that under the original IP Precedence design, larger decimal numbers got better QoS treatment. This isn't the case with DSCP values (notably EF) due to the binary value assignments. Also, below you'll see CS values- the meaning of this is "Class Selector"which is the DiffServ name for the backwards-compatible values that match up to IP Precedence.

Field & Value (Decimal)                  Binary         Name                                    
Precedence 0                                   000            Routine
Precedence 1                                   001            Priority
Precedence 2                                   010            Immediate
Precedence 3                                   011            Flash
Precedence 4                                   100            Flash Override
Precedence 5                                   101            Critical
Precedence 6                                   110            Internetwork Control
Precedence 7                                   111            Network Control

DSCP 0                                           000000      Best Effort/default
DSCP 8                                           001000      CS1          
DSCP 16                                         010000      CS2
DSCP  24                                        011000      CS3
DSCP 32                                         100000      CS4
DSCP 40                                         101000      CS5
DSCP 48                                         110000      CS6
DSCP 56                                         111000      CS7
DSCP 10                                         001010      AF11
DSCP 12                                         001100      AF12
DSCP 14                                         001110      AF13
DSCP 18                                         010010     AF21
DSCP 20                                         010100     AF22
DSCP 22                                         010110     AF23
DSCP 26                                         011010     AF31
DSCP 28                                         011100     AF32
DSCP 30                                         011110     AF33
DSCP 34                                         100010     AF41
DSCP 36                                         100100     AF42
DSCP 38                                         100110     AF43
DSCP 46                                         101110     EF

Notes from the Cisco Enterprise QoS SRND
Cisco's text excellently defines QoS as being a combination of 3 items: delay (latency), jitter (variation in the amount of latency), and packet loss. One excellent way to get a real life insight into jitter is to grab a packet capture of RTP and examine it in Wireshark (www.pcapr.net has several). Under Telephony -> RTP -> Show All Streams you will get a window with various statistics on max and mean jitter.

Summing Up Classification and Marking, with Add'l References

The end of chapter summary just revisits commands, recommends further reading, and provides definitions. It also suggests you "fill in key tables from memory." After reviewing the original posting, I have concluded that while this chapter of the book provides a decent review, the book as a whole fails to provide a good overview of how marking (Ch 12), congestion avoidance (Ch 13), and shaping (Ch 14) all work together. So, I highly recommend all the additional reading discussed below.

I am omitting the recap of commands because I've already covered them in prior posts. However, I find their table on DiffServ RFCs useful so here it is-

RFC       Title                                                               Comments
2474      Definition of the DiffServ Field                         Contains details of the DSCP field in IP headers
2475      An Architecture for Differentiated Services      Core DiffServ concepts document
2597      Assured Forwarding PHB Group                     Defines 12 DSCP values and usage convention
3246      An Expedited Forwarding PHB                       Defines a DSCP value for use as a low-latency class
3260     New Terminology and Clarifications for DiffServ   Clarifies but doesn't supercede existing RFCs

The book also recommends you be able to write down definitions for the following terms:
IP Precedence, ToS byte, Differentiated Services, DS Field, Per Hop Behavior, Assured Forwarding, Expedited Forwarding, Class Selector, Class of Service, Differentiated Services Code Point, User Priority, Discard Eligible, Cell Loss Priority, MPLS Experimental Bit, class map, policy map, service policy, Modular QoS CLI, Class Based Marking, Network Based Application Recognition, QoS preclassification, AutoQoS.

Recommended further reading includes-

Cisco QoS Exam Certification Guide (2nd Edition), by Wendell Odom
End to End QoS Network Design, by Tim Szigeti
For real life QoS deployments, read the Enterprise QoS SRND Guide, posted at Cisco's website

My next post will summarize a few pertinent points from the Cisco QoS exam certification guide, as well as the QoS SRND Guide.

More on AutoQoS

AutoQoS VOIP on Routers
Meant for use on LAN ports. The command to enable AutoQoS on interfaces is auto qos voip [trust] at the interface or frame relay DLCI level. You'll also need to have the bandwidth command in place before enabling AutoQoS; changing it later won't affect the QoS setup so you'd need to rerun AutoQoS in that instance.

When you enable AutoQoS on a frame relay interface slower than 768kbps, it also enables compression and fragmentation. Regardless of the speed, a router will still perform the standard config for traffic shaping and apply the policy automatically.

On serial interfaces that aren't frame relay which are slower than 768kbps, AutoQoS changes the encapsulation to PPP and enables the features link fragmentation and interleaving (LFI). Interfaces that are faster will retain their original encapsulation.

When the trust keyword is used, the router groups traffic (via class maps) based on DSCP values. Those DSCP values are already present in packets and are assumed to be set by a trusted device(s). Without the trust keyword, the router creates class maps for voice and video traffic as well as call control ports. Those types are mapped into classes and any traffic not matching them is marked with DSCP value 0.

Verifying AutoQoS for VOIP 

show auto qos   displays QoS commands for an interface
show mls qos     shows queuing and mappings for CoS-DSCP and vice versa
show policy-map interface  displays how the policy maps are assigned to interfaces and details of each

AutoQoS for the Enterprise
Supported on Cisco routers; the main difference between this and AutoQoS VOIP is that Enterprise supports other applications and is meant to be used for WAN links. May be configured on Frame and ATM sub-interfaces if they are point to point links only. This has two steps- discovering traffic and a resulting QoS config.

Traffic discovery takes place on interfaces, so the command is run at the PVC, DLCI, or interface config level. CEF must be on, QoS should NOT be already in place on the interface, and you should have the bandwidth command specified. The command used to enable discovery is auto discovery qos [trust] and the trust keyword is used (as stated before) to accept existing QoS markings on traffic.

Activating traffic discovery enables NBAR (for that interface). Ten classes are created and traffic is classified into one of the ten. Default classification with the trust keyword is as follows (sample traffic is listed for each)-

Class                     DSCP/PHB Value             Traffic Examples
Routing                       CS 6                              EIGRP, OSPF
VOIP                          EF (DSCP 46)              RTP Voice Media
Interactive Video         AF 41                            RTP Video Media
Streaming Video          CS4                              RealAudio, Netshow
Control Signaling         CS3                              H323, SIP
Transactional              AF21                             SAP, Citrix, Telnet, SSH
Bulk                           AF11                             FTP, POP3, SMTP, Exchange
Scavenger                  CS1                               Peer to peer applications
Management               CS2                              SNMP, Syslog, DNS
Best Effort                  All others                       All other traffic

Disabling AutoQoS for an interface disables NBAR on there as well. The related command is no auto discovery qos. To validate that QoS is enabled, use the same commands as for AutoQoS VOIP. The only new command is show auto discovery qos, which displays NBAR statistics.

 

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.