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
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 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.