What? You want more?

I am always pretty amazed when people email me, and say that they have bought and enjoyed the books I have written. I am also always surprised when they ask me to write more.

Writing books takes quite a while, somewhere between three and six months each. It's a long process, and has to be juggled between regular employment, my own studies and family life. But it is a rewarding process.

One very common request is for a book on QoS and Multicast, and this was planned, and started many moons ago, but it stalled as I concentrated on getting my own CCIE.

But the voices should not be ignored.

So far I have had requests via email (Ionut and Marino), LinkedIn (Noore) and Twitter (Mark) all asking if I intend to write a book on QoS, and it was part of my original plan, in fact, here is the intended releases, which actually includes Services, and the IGPs:

BGP, MPLS, and VPNs and NAT have already been released, and the CCNA book (now called CCNA and Beyond) will be released at the end of the month. The personal folder is just a few tax documents, it's not my memoirs of anything like that. The UNetLab Cookbook stalled as the guys keep changing it, and the new version is so much different to how it was when I started writing that book.

So the next volume in the series would have been/will be Multicast and QoS. The biggest issue, and perhaps the reason why I stopped writing it was that I could not make a proper Multicast server.

I think I have fixed this issue, as I found, whilst doing my CCIE Security studies, that SUSE Studio is a great way to create custom VMs, and get them in Qemu, which is ideal for UNetLab. So, that is a manageable hurdle.

The next issue is time management. Can I write another book at the same time as studying for my CCIE Security, and maintain a happy work/home life balance? Not sure the wife wants me to write another book at the moment, I think we could do with some "us" time.

So, what to do??
Well, I guess that's where you lot come in.

There is a poll on the menu to the right. I reckon 100 "yes's" should cover it. Leave a comment below. I'll probably ditch Kindle, or keep the Kindle price the same as the printed price. Kindle sales are not as good as printed, and I am actually quite happy about this. I much prefer printed textbooks.

The price would be about the same as the other books, but the platform would move to UNetLab. I havn't touched GNS3 since finishing VPNs and NAT.

The other question is would you support a Kickstarter project for this? If so, for how much and what would you want in return? I have seen other people doing Kickstarters for books, and I'd quite like to turn this into a full-time thing, but at present this is not feasible. Maybe a Kickstart project would be the way forward. I could do things like your name in the book, and so on.

If there is enough people who would like me to write it, then I will do it.

I won't give any timelines for it, but I would keep people updated via the website.

Let me know your thoughts via the poll and feedback below.

GNS3 vs. IOU poll - who won?

I have been running a poll on the site to determine whether people would prefer the next volume (Multicast and QoS) to be designed for IOU or, like the previous three volumes, for GNS3.

At the start, IOU steamed ahead, but then GNS3 started to catch up.

The poll has now closed. We had 67 people take part. The end result?

IOU won by a large margin.

If it had won by any more, then the pie chart would look like Pacman.

So the book will be designed for...
UNetLab.

Here's why.

1. On the basis that if people are using IOU, then they will have probably heard of UNetLab.
2. If people have IOU images in IOU, they can be used in UNetLab.
3. UNetLab offers support for more systems then IOU, therefore we can have a Linux VM and PROPERLY test multicast AND QoS.

The thing about Multicast (and QoS) that it is hard, in a closed environment such as IOU, or even when you are restricted to just using routers and switches, is that you have to take output as an indication of whether something is working or not. If you could actually see a multicast stream, i.e. a video file playing on VLC, then it's easier to see cause and effect.

UNetLab will allow for a nicer book, we'll be able to see video being multicasted, and also implement QoS restrictions on this as well, rather than just seeing an ICMP response. 

It'll be fun, as networking should be.

QoS & The MQC - Part 2: Classification with Class Maps and NBAR

In the previous post we looked briefly at the MQC, and set up a basic QoS mechanism to classify a ping packet. In this post we will look closer at Class Maps, the match commands and classification using NBAR (Network Based Application Recognition).

Packets are classified using the match command, and we have already seen that the list of things we can match is pretty huge, we can match on layer 2 (MAC addresses), layer 3 (IP, Access-lists, or applications), or even match that grey-area between layers, MPLS. If we choose to match by protocol then IOS will use Network Based Application Recognition (NBAR), and lastly we can match absolutely everything, using the any command.

We can have multiple match statements within a class-map, and here we pick up on something from the previous post:

R1(config)#class-map ?
  WORD       class-map name
  match-all  Logical-AND all matching statements under this classmap
  match-any  Logical-OR all matching statements under this classmap
  type       Configure CPL Class Map

We have the ability to match-all and match-any (a logical AND, or a logical OR), for example, we can match http traffic coming from a machine with a source mac-address:

class-map match-all example1
  match protocol http
  match source-address mac 0000.0000.0000

Or we can match traffic that matches either of these two conditions (either http, or coming from the same mac address:

class-map match-any example2
  match protocol http
  match source-address mac 0000.0000.0000

We can also match another class-map when we use the match-all or match-any option.

class-map match-any example3
  match class-map example1
  match dscp af12

With example3 we will match http and a source mac address of 0000.0000.0000 OR if the dscp value is af12. If we omit the match-any or match-all keyword then the default behaviour will be match-all.

We can match up to four CoS and IPP or eight DSCP values in a single command (match cos, match precedence or match dscp respectively).

NBAR

NBAR is pretty cool, we have already used it in this post as whenever we use the match protocol command, this actually employs NBAR. What NBAR actually does is classify packets that would otherwise be hard to classify, such as where an application uses dynamic port numbers. NBAR can look into the packet using deep packet inspection and can match on things like host name, URL or MIME type.

Using this topology we have an HTTP server and a client set up:

From the client we can do a curl request to the http server and see a couple of pages, the default index.html page:

And a couple of pages that we will try and control using NBAR:

On R1 we configure the following:

class-map match-all CLS-DENY-FAIL-HTML
 match protocol http url "/fail.html"
!
policy-map POL-DENY-FAIL-HTML
 class CLS-DENY-FAIL-HTML
   drop
!
interface FastEthernet0/1
 ip address 10.250.1.1 255.255.255.0
 duplex auto
 speed auto
 service-policy input POL-DENY-FAIL-HTML

And if we now test from the client machine we can see that (eventually) the curl requests times out:

But the request to pass.html still works:

With our router configuration placement is key. The same class-map and policy map set on R2 on the same interface in the outgoing direction does not work, and this is because our http server is listening on port 80 (http), but requests from the client will come from an ephemeral port, and therefore will not be matched to the http protocol.

We can make this example a bit more interesting and change the QoS values for the pass and fail pages. We will now set the pass.html page to be classified as CS5, and the fail.html page to be classifed as CS1:

class-map match-all CLS-CS1-FAIL-HTML
 match protocol http url "/fail.html"
class-map match-all CLS-CS5-PASS-HTML
 match protocol http url "/pass.html"
!
policy-map POL-CHANGE-CS-HTML
 class CLS-CS5-PASS-HTML
  set dscp cs5
 class CLS-CS1-FAIL-HTML
  set dscp cs1
!
interface FastEthernet0/1
 ip address 10.250.1.1 255.255.255.0
 duplex auto
 speed auto
 service-policy input POL-CHANGE-CS-HTML

We can now look at the link between R1 and the http server and see that our requests are forwarded to the http server with different DSCP values:

Now if we do another wireshark capture either between the two routers, or between R2 and the client machine we can see that the DSCP value is returned as default - which makes sense because the service-policy is set as "input" on R1 rather than output. We can make sure that the return traffic gets the same DSCP values by specifying the same service-policy on R1 in an output direction, and this way the DSCP value is retained throughout the network.

Wireshark is a great way to confirm that our values are being set as we want them to be! Sadly as I am running a 3600 series router in GNS3 and not a 7200 embedded packet capture is not available. But this would be another way (and something we will cover later on) that would enable us to confirm the DSCP values through traffic capturing.

QoS & The MQC - Part 1: Quick QoS

QoS is a pretty big area on the CCIE exam topic list, it's certainly the largest single topic, IPv4 has 9 different areas, but these are broken down into protocols, so can be considered separate, whereas QoS is all one major topic, and has six sub-topics (but OK, you could argue that these are as separate as EIGRP and OSPF are in IPv4...), anyway, it's a big topic.

QoS isn't something I have done anything with so far, either on this blog or in the workplace, so it's all new to me, as are some other topics I'll need to cover. But let's get started.

QoS is covered by part 8 on the exam list, and 8.10 lists the following:

8.10 Implement Modular QoS CLI (MQC) 
   (a) Network-Based Application Recognition (NBAR) 
   (b) Class-based weighted fair queuing (CBWFQ), modified deficit round robin (MDRR), and low latency queuing (LLQ) 
   (c) Classification 
   (d) Policing 
   (e) Shaping 
   (f) Marking 
   (g) Weighted random early detection (WRED) and random early detection (RED) 
   (h) Compression 

So lets start at the beginning with the MQC

QoS and the MQC

QoS has been around on Cisco devices for ages, there were many different tools, with different commands and configurations, then life was made easier and everything was bundled into the Modular QoS CLI (MQC).  MQC is a method of catgorizing classification, marking, policing and shaping into logical groups. MQC based tools all begin with "Class-Based" - or CB for short - such as Class-Based Weighted Fair Queuing (CBWFQ).

MQC has three components, a class-map (classifies packets into classes), the PHB (Per-Hop Behaviour - or the actions to take) and the policy-map (which is configured on an interface). The interface calls a service-policy which references our policy-map, which in turn calls our class-map:

class-map myclassmap1
  #set match commands
policy-map mypolicymap1
  class myclassmap1
    #actions to take
interface serial 0/0
  service-policy output mypolicymap1

Policy maps can reference multiple class maps, and with that let's take a look at class maps.

MQC Class Maps

Let's start with the class-map command:

R1(config)#class-map ?
  WORD       class-map name
  match-all  Logical-AND all matching statements under this classmap
  match-any  Logical-OR all matching statements under this classmap
  type       Configure CPL Class Map

R1(config)#class-map

We can either specify a class-map name or using one of the match- commands specify whether we are going to use ANDing or ORing. Type gives us the following options:

R1(config)#class-map type ?
  access-control   access-control specific class-map
  control          Configure a control policy class-map
  inspect          Configure Firewall Class Map
  logging          Class map for control-plane packet logging
  multicast-flows  multicast class-maps
  port-filter      Class map for port filter
  queue-threshold  Class map for queue threshold
  stack            class-map for protocol header stack specification
  urlfilter        Config Class map for local URL filtering
  waas             Configure a WAAS Class Map

For the moment we will just look at the first option and give our class-map a name:

R1(config)#class-map MYFIRSTCLASS
R1(config-cmap)#?
Class-map configuration commands:
  description  Class-Map description
  exit         Exit from class-map configuration mode
  match        classification criteria
  no           Negate or set default values of a command

So lets give it a description and start matching some packets. Doing "match ?" shows what you can match:

R1(config-cmap)#match ?
  access-group         Access group
  any                  Any packets
  application          Application to match
  class-map            Class map
  cos                  IEEE 802.1Q/ISL class of service/user priority values
  destination-address  Destination address
  discard-class        Discard behavior identifier
  dscp                 Match DSCP in IPv4 and IPv6 packets
  fr-de                Match on Frame-relay DE bit
  fr-dlci              Match on fr-dlci
  input-interface      Select an input interface to match
  ip                   IP specific values
  metadata             Metadata to match
  mpls                 Multi Protocol Label Switching specific values
  not                  Negate this match result
  packet               Layer 3 Packet length
  precedence           Match Precedence in IPv4 and IPv6 packets
  protocol             Protocol
  qos-group            Qos-group
  source-address       Source address
  vlan                 VLANs to match

We'll start by matching a protocol. If you do "match protocol ?" you will find loads and loads of options (too many to list here), so for the moment lets match icmp:

R1(config)#class-map MYFIRSTCLASS
R1(config-cmap)#description My First Class-Map
R1(config-cmap)#match protocol icmp

Now we need a Policy map so that we can use our class map.

MQC Policy Maps

In order to use our class-map we need a policy map.

R1(config)#policy-map MYFIRSTPOLICY
R1(config-pmap)#?
Policy-map configuration commands:
  class        policy criteria
  description  Policy-Map description
  exit         Exit from policy-map configuration mode
  no           Negate or set default values of a command

R1(config-pmap)#description My First Policy Map
R1(config-pmap)#class MYFIRSTCLASS
R1(config-pmap-c)#?
Policy-map class configuration commands:
  bandwidth        Bandwidth
  compression      Activate Compression
  drop             Drop all packets
  exit             Exit from QoS class action configuration mode
  fair-queue       Enable Flow-based Fair Queuing in this Class
  log              Log IPv4 and ARP packets
  measure          Measure
  netflow-sampler  NetFlow action
  no               Negate or set default values of a command
  police           Police
  priority         Strict Scheduling Priority for this Class
  queue-limit      Queue Max Threshold for Tail Drop
  random-detect    Enable Random Early Detection as drop policy
  service-policy   Configure QoS Service Policy
  set              Set QoS values
  shape            Traffic Shaping
  

So there is a lot we can do with our class-map. We can compress packets, drop them, enable fair-queuing, sample them using netflow, police them and drop depending on how well our network is performing, along with all the other options.

For the moment I want to drop ICMP traffic. To see this in action I have set up two routers, joined by their FastEthernet interfaces using the IP addresses 10.250.1.1 and 10.250.1.2.

R1#ping 10.250.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.250.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/25 ms
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#policy-map MYFIRSTPOLICY
R1(config-pmap)#class MYFIRSTCLASS
R1(config-pmap-c)#drop
R1(config-pmap-c)#exit
R1(config-pmap)#exit
R1(config)#exit
R1#

Now we need to "attach" this policy map to our interface

R1(config)#int f0/0
R1(config-if)#service-policy output MYFIRSTPOLICY
R1(config-if)#exit
R1(config)#exit
R1#

And we can see the before and after effects from the other router:

R2#ping 10.250.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.250.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/11/15 ms
R2#ping 10.250.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.250.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R2#

So there we have a very basic example. Just dropping traffic isn't really the best usage of QoS - after all it's about improving quality rather than just dropping traffic (unless we are dropping marked traffic in order to improve other traffic - but that's for later). Let's see what we can do to our ping packets instead, and for that we need to know a bit about DSCP classes and values.

DSCP

If we fire up Wireshark and look at a ping packet we can see that in the IPv4 details we have a Differentiated Services Field, and the value is set to 0x00:

But what does this value mean and what's DSCP anyway?

Within an IP header are different byte fields. Originally this included a 1-byte field called the type of Service (ToS) byte - and this was used to mark a packet for QoS. The ToS byte included the IP Precedence field (IPP) and this was numbered from 0 to 7 (as it used the high-order 3 bits):

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

Differentiated Services (DiffServ) then came along and needed three more bits, the ToS byte got renamed to the Differentiated Service (DS) field, and IPP was replaced witha 6-bit field called the Differentiated Services Code Point (DSCP) field. The low-order 2 bits of which is ised for Explicit Congestion Notification (ECN), which you can also see in the Wireshark output above.

There is a lot of commonality between IPP and and DSCP, they are numbered from CS0 (meaning Class Selector) to CS7 and the binary values match those of IPP:

DSCP Class Selector Name	Binary
Default/CS0	000000
CS1	001000
CS2	010000
CS3	011000
CS4	100000
CS5	101000
CS6	110000
CS7	111000

Now if we set our DSCP value to CS4

R1(config)#policy-map MYFIRSTPOLICY
R1(config-pmap)#class MYFIRSTCLASS
R1(config-pmap-c)#set dscp ?
  <0-63>     Differentiated services codepoint value
  af11       Match packets with AF11 dscp (001010)
  af12       Match packets with AF12 dscp (001100)
  af13       Match packets with AF13 dscp (001110)
  af21       Match packets with AF21 dscp (010010)
  af22       Match packets with AF22 dscp (010100)
  af23       Match packets with AF23 dscp (010110)
  af31       Match packets with AF31 dscp (011010)
  af32       Match packets with AF32 dscp (011100)
  af33       Match packets with AF33 dscp (011110)
  af41       Match packets with AF41 dscp (100010)
  af42       Match packets with AF42 dscp (100100)
  af43       Match packets with AF43 dscp (100110)
  cos        Set packet DSCP from L2 COS
  cs1        Match packets with CS1(precedence 1) dscp (001000)
  cs2        Match packets with CS2(precedence 2) dscp (010000)
  cs3        Match packets with CS3(precedence 3) dscp (011000)
  cs4        Match packets with CS4(precedence 4) dscp (100000)
  cs5        Match packets with CS5(precedence 5) dscp (101000)
  cs6        Match packets with CS6(precedence 6) dscp (110000)
  cs7        Match packets with CS7(precedence 7) dscp (111000)
  default    Match packets with default dscp (000000)
  ef         Match packets with EF dscp (101110)
  qos-group  Set packet dscp from QoS Group.

R1(config-pmap-c)#set dscp cs4
R1(config-pmap-c)#exit
R1(config-pmap)#exit
R1(config)#int f0/0
R1(config-if)#serv
R1(config-if)#service-policy out
R1(config-if)#service-policy output MYFIRSTPOLICY
R1(config-if)#

We can then see this in Wireshark:

We have some other options we could have chosen - those beginning with AF, we could have set the DSCP manually (<0-63>) or set ef or qos-group. The AF values are for Assured Forwarding, and ef is for Expedited Forwarding.

Assured Forwarding

Assured Forwarding defines four classes for queuing, and each of these has three levels of "drop probability", allowing for 12 different values or levels. The first number (1-4) is the queue that the packet is in, and the second number (1-3) is its drop probability.

Queue Class	Low Drop Probability	Medium drop Probability	High drop Probability
	Name / Decimal / Binary	Name / Decimal / Binary	Name / Decimal / Binary
1	AF11 / 10 / 001010	AF12 / 12 / 001100	AF13 / 14 / 001110
2	AF21 / 18 / 010010	AF22 / 20 / 010100	AF23 / 22 / 010110
3	AF31 / 26 / 011010	AF32 / 28 / 011100	AF33 / 30 / 011110
4	AF41 / 34 / 100010	AF42 / 36 / 100100	AF43 / 38 / 100110

Expedited Forwarding

Expedited Forwarding (EF) queues packets to that they are scheduled quicker, EF packets are also policed so that they do not starve other queues. The DSCP value in decimal is 46, and the binary value is 101110.

I think this is a good point to end at. So we can let things sink in a bit before moving on to a deeper delve into classification using class-maps.