Friday, May 24, 2013

MTU Vs MSS - Part Two

Previously I published a blog post called MTU Vs MSS - Part One. At the time the plan was to follow it up with Part Two a short time later, however, here it comes over a year late :) I do apologise for that.

What prompted me to get back to writing Part Two was an e-mail from a reader who asked how I came to the conclusion that using the "ip tcp adjust-mss" command affects a SYN packet's MSS regardless of whether it is applied to the inbound or outbound interface. The reader also asked if I have any links to documentation that describes this. The way in which I came to the conclusion was by labbing it up. Unfortunately though I do not have any documentation that backs me up.

This blog post will demonstrate the lab I used to come to the above conclusion.

Here is the topology that I used. I have marked each link with a letter to mark the points at which the proceeding packet captures were done. (Note that PC1 and PC2 are GNS3 routers with their icons changed).


No MSS Change

Before making any changes to the MSS, I'll first initiate a telnet session from PC1 to PC2.

Packet Capture from PC1's F0/0 interface ("A"):


Packet Capture from R2's F0/1 interface ("B"):





Looking at the above captures we can see that the PC1 sent an MSS of 536 in its SYN packet, and PC2 responded with an MSS of 536 in its SYN/ACK packet.


R2 F0/0 MSS Change

Now that we've done our benchmark test, let's see what happens when we set an MSS of 500 on R2's F0/0 interface.

R2(config)#int f0/0
R2(config-if)#ip tcp adjust-mss 500

Now let's repeat the telnet test:

Packet Capture from PC1's F0/0 interface ("A"):


Packet Capture from R2's F0/1 interface ("B"):




Here we can see that when the packet leaves PC1, it is sending its SYN packet with an MSS of 536, but when the packet leaves R2, the MSS has changed to 500.


R2 F0/1 MSS Change

Now I'll remove the "ip tcp adjust-mss" command from R2's F0/0 interface and will apply it to R2's F0/1, this time using an MSS of 510.

R2(config)#int f0/1
R2(config-if)#ip tcp adjust-mss 510

Now let's repeat the telnet test:

Packet Capture from PC1's F0/0 interface ("A"):




Packet Capture from R2's F0/1 interface ("B"):




Here we can see the results are the same as the ones seen when the "ip tcp adjust-mss" command was put on R2's F0/0 interface.


MSS on Both Interfaces

As you might expect, if you set the  "ip tcp adjust-mss" command on both of the router's interfaces, it will use the lower of the two.


As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Saturday, May 18, 2013

Understanding MQC Series

Series Index

I am in the process of writing a series of blog posts which will cover:
  • Modular QoS CLI (MQC)
  • Weighted Fair Queue (WFQ)
  • Class-Based Weighed Fair Queuing (CBWFQ)
  • Low Latency Queuing (LLQ)
To assist readers in keeping track of these posts, I will update this page each time a new entry is published.

Series Entries

Here are the links to the posts which have been published to date:

Understanding MQC, Part 1: The Basics
Understanding MQC, Part 2: Basic Configuration
Understanding MQC, Part 3: Output Analysis

Other Reading

Before you jump in to the above posts though, you may want to have a read of these first:

Shape Average Vs Shape Peak - Part 1
Shape Average Vs Shape Peak - Part 2
Shape Average Vs Shape Peak - Part 3

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Understanding MQC, Part 3: Output Analysis

In my previous blog post I implemented a basic QoS configuration. In this post I will demonstrate how the "bandwidth" and "priority" commands treat their respective classes, as well as how to interpret the "show policy-map interface" command output.

Parent Shaper 

Below is the output seen when the "show policy-map interface" command is issued. The Parent Policy's class-default Class Map (at the top of the output seen below) represents all of the Child Class Maps' counters put together.

For example, if 5 packets are dropped from the "MATCH-Voice" Class Map and 10 packets are dropped from the "MATCH-BulkData" Class Map, 15 drops will be shown under the Parent Policy. 

Router#sh policy-map int gi 0/1
 GigabitEthernet0/1

  Service-policy output: PARENT-EGRESS-Shaper

    Class-map: class-default (match-any)
      1 packets, 68 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 2/158
      shape (average) cir 1024000, bc 4096, be 4096
      target shape rate 1024000

      Service-policy : CHILD-EGRESS-BandwidthAllocation

        queue stats for all priority classes:
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0

        Class-map: MATCH-BulkData (match-any)
          0 packets, 0 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match:  dscp af33 (30)
            0 packets, 0 bytes
            30 second rate 0 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0
          bandwidth 300 kbps

        Class-map: MATCH-Voice (match-any)
          0 packets, 0 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match:  dscp ef (46)
            0 packets, 0 bytes
            30 second rate 0 bps
          Priority: 150 kbps, burst bytes 3750, b/w exceed drops: 0
         

        Class-map: class-default (match-any)
          1 packets, 68 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match: any
         
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 1/98


Offered & Dropped Rate 

 The "Offered Rate" and "Dropped Rate" figures are important figures to take note of. It gives you an average of how many bits per second each class has Class has sent and dropped respectively for an interval (the default interval is 5 minutes, however, I have changed it to 30 seconds using the load-interval 30 command). 

As demonstrated below, if a Class or multiple Classes do not use their allocated bandwidth, their "Offered Rate" will be less than their allocated bandwidth. This unused bandwidth can then be used by other Classes who require it. Due to this there will be times where you will see a Class' "Offered Rate" being higher than their allocated bandwidth.

Note: It is important to keep in mind that the "Offered" and "Dropped" rates are an average. This means that if you're using a 5 minute interval and there is a traffic one minute traffic spike, it is very likely that you won't see it in the "Offered" and "Dropped" rate figures.

Bandwidth command

This demonstration shows how the router treats the "Bulk Data" traffic when there is no load coming from any other sources.

iperf test:

[1912] local 192.168.10.101 port 1265 connected with 192.168.20.101 port 5001
[ ID] Interval       Transfer     Bandwidth
[1912]  0.0- 1.0 sec   128 KBytes  1.05 Mbits/sec
[1912]  1.0- 2.0 sec   120 KBytes   983 Kbits/sec
[1912]  2.0- 3.0 sec   128 KBytes  1.05 Mbits/sec
[1912]  3.0- 4.0 sec   120 KBytes   983 Kbits/sec
[1912]  4.0- 5.0 sec   120 KBytes   983 Kbits/sec
[1912]  5.0- 6.0 sec   120 KBytes   983 Kbits/sec
[1912]  6.0- 7.0 sec   120 KBytes   983 Kbits/sec
[1912]  7.0- 8.0 sec   120 KBytes   983 Kbits/sec
[1912]  8.0- 9.0 sec   120 KBytes   983 Kbits/sec
[1912]  9.0-10.0 sec   120 KBytes   983 Kbits/sec
[1912] 10.0-11.0 sec   120 KBytes   983 Kbits/sec
[1912] 11.0-12.0 sec   120 KBytes   983 Kbits/sec
[1912] 12.0-13.0 sec   120 KBytes   983 Kbits/sec
[1912] 13.0-14.0 sec   120 KBytes   983 Kbits/sec
[1912] 14.0-15.0 sec   120 KBytes   983 Kbits/sec
[1912]  0.0-15.2 sec  1.78 MBytes   984 Kbits/sec


Policy Map output:

Router(config-if)#do sh policy-map int gi 0/1
 GigabitEthernet0/1

  Service-policy output: PARENT-EGRESS-Shaper

    Class-map: class-default (match-any)
      1494 packets, 1970729 bytes
      30 second offered rate 118000 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 1533/1980890
      shape (average) cir 1024000, bc 4096, be 4096
      target shape rate 1024000

      Service-policy : CHILD-EGRESS-BandwidthAllocation

        queue stats for all priority classes:
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0

        Class-map: MATCH-BulkData (match-any)
          1372 packets, 1941896 bytes
          30 second offered rate 114000 bps, drop rate 0 bps
          Match:  dscp af33 (30)
            1372 packets, 1941896 bytes
            30 second rate 114000 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 1372/1941896
          bandwidth 300 kbps

        Class-map: MATCH-Voice (match-any)
          0 packets, 0 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match:  dscp ef (46)
            0 packets, 0 bytes
            30 second rate 0 bps
          Priority: 150 kbps, burst bytes 3750, b/w exceed drops: 0
         

        Class-map: class-default (match-any)
          122 packets, 28833 bytes
          30 second offered rate 4000 bps, drop rate 0 bps
          Match: any
         
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 122/28787
 

Analysis

Looking at the iperf test, we can see that average speed achieved as 984kb/sec. This may seem strange seeing as though we specifically assigned 300kb to this class. However, as mentioned above, MQC Classes are allowed to use other Classes' bandwidth if it is not being used.

Looking at the MATCH-BulkData section of the router output, we can confirm that the packets are being matched and prioritised correctly.

Priority command

This demonstration shows how the router treats the "Voice" traffic when there is no load coming from any other sources.

iperf test:

[1912] local 192.168.10.101 port 1266 connected with 192.168.20.101 port 5002
[ ID] Interval       Transfer     Bandwidth
[1912]  0.0- 1.0 sec   184 KBytes  1.51 Mbits/sec
[1912]  1.0- 2.0 sec  0.00 Bytes  0.00 bits/sec
[1912]  2.0- 3.0 sec   768 KBytes  6.29 Mbits/sec
[1912]  3.0- 4.0 sec   136 KBytes  1.11 Mbits/sec
[1912]  4.0- 5.0 sec  72.0 KBytes   590 Kbits/sec
[1912]  5.0- 6.0 sec   144 KBytes  1.18 Mbits/sec
[1912]  6.0- 7.0 sec   112 KBytes   918 Kbits/sec
[1912]  7.0- 8.0 sec  80.0 KBytes   655 Kbits/sec
[1912]  8.0- 9.0 sec   160 KBytes  1.31 Mbits/sec
[1912]  9.0-10.0 sec  72.0 KBytes   590 Kbits/sec
[1912] 10.0-11.0 sec  8.00 KBytes  65.5 Kbits/sec
[1912] 11.0-12.0 sec  0.00 Bytes  0.00 bits/sec
[1912] 12.0-13.0 sec  8.00 KBytes  65.5 Kbits/sec
[1912] 13.0-14.0 sec  8.00 KBytes  65.5 Kbits/sec
[1912] 14.0-15.0 sec  16.0 KBytes   131 Kbits/sec
[1912] 15.0-16.0 sec  0.00 Bytes  0.00 bits/sec
[1912]  0.0-16.9 sec  1.73 MBytes   862 Kbits/sec


Policy Map output:

Router(config-if)#do sh policy-map int gi 0/1
 GigabitEthernet0/1

  Service-policy output: PARENT-EGRESS-Shaper

    Class-map: class-default (match-any)
      1555 packets, 2131519 bytes
      30 second offered rate 61000 bps, drop rate 6000 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/138/0
      (pkts output/bytes output) 1418/1927733
      shape (average) cir 1024000, bc 4096, be 4096
      target shape rate 1024000

      Service-policy : CHILD-EGRESS-BandwidthAllocation

        queue stats for all priority classes:
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 1298/1899284

        Class-map: MATCH-BulkData (match-any)
          0 packets, 0 bytes
          30 second offered rate 0 bps, drop rate 0 bps
          Match:  dscp af33 (30)
            0 packets, 0 bytes
            30 second rate 0 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0
          bandwidth 300 kbps

        Class-map: MATCH-Voice (match-any)
          1436 packets, 2103396 bytes
          30 second offered rate 57000 bps, drop rate 4000 bps
          Match:  dscp ef (46)
            1436 packets, 2103396 bytes
            30 second rate 57000 bps
          Priority: 150 kbps, burst bytes 3750, b/w exceed drops: 138
         

        Class-map: class-default (match-any)
          119 packets, 28123 bytes
          30 second offered rate 4000 bps, drop rate 0 bps
          Match: any
         
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 119/28351

 

Analysis

Looking at the iperf test, we can see that average speed achieved as 862kb/sec. Like the "bandwidth" command, the "priority" command also allows the use of extra bandwidth should it be available.

Looking at both the iperf test and the MATCH-Voice outputs we can see that multiple packets were dropped. The reason why we see drops when performing the Voice test but not the Bulk Data test is due to the "priority" and "bandwidth" commands. While the "bandwidth" command allows packets to be queued and sent when there is bandwidth available, the "priority" command (which uses Low Latency Queuing (LLQ)) sends the data straight away or it drops it. This is because, despite its name, LLQ does not queue packets. The reason for this is simple. When using a time-sensitive application, queuing packets would introduce too much delay which would result in packets arriving too late to be used. The queuing would then cause subsequent packets to be queued too and therefore they would be delayed as well, meaning that the router will always be trying to catch up. Instead, by dropping packets instead of delaying them, subsequent packets will be able to be delivered on time.

Another interesting thing to note here is that as per the MATCH-Voice output above, 138 packets were dropped. If you look at the router's interface counters, you will see that the drops also appear there too:

Interface output: 

Router(config-if)#do sh int gi0/1 | i drops
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops:
138
  Output queue: 0/1000/138 (size/max total/drops)


Multiple Streams

When there are multiple streams of data (Voice traffic, Bulk Data traffic and Unclassified traffic) being sent simultaneously, the policy output looks like this:

Router(config-if)#do sh policy-map int gi 0/1
 GigabitEthernet0/1

  Service-policy output: PARENT-EGRESS-Shaper

    Class-map: class-default (match-any)
      6630 packets, 9284598 bytes
      30 second offered rate 932000 bps, drop rate 39000 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 51/239/0
      (pkts output/bytes output) 6413/8931702
      shape (average) cir 1024000, bc 4096, be 4096
      target shape rate 1024000

      Service-policy : CHILD-EGRESS-BandwidthAllocation

        queue stats for all priority classes:
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 963/1395762

        Class-map: MATCH-BulkData (match-any)
          1839 packets, 2606098 bytes
          30 second offered rate 281000 bps, drop rate 0 bps
          Match:  dscp af33 (30)
            1839 packets, 2606098 bytes
            30 second rate 281000 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 17/0/0
          (pkts output/bytes output) 1839/2606098
          bandwidth 300 kbps

        Class-map: MATCH-Voice (match-any)
          1202 packets, 1754308 bytes
          30 second offered rate 121000 bps, drop rate 38000 bps
          Match:  dscp ef (46)
            1202 packets, 1754308 bytes
            30 second rate 121000 bps
          Priority: 150 kbps, burst bytes 3750, b/w exceed drops: 239
         

        Class-map: class-default (match-any)
          3589 packets, 4924192 bytes
          30 second offered rate 530000 bps, drop rate 0 bps
          Match: any
         
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 32/0/0
          (pkts output/bytes output) 3589/4924428


Analysis

When situations like this occur, you will find that each Class will have an "offered" rate which is very close to the the Class' allocated bandwidth amount. If one or more of the Classes drops below their allocated bandwidth amount you will see their "offered rate" drop, however, you will also see one or more of the other classes' "offered rate" rate increase. This is because, as demonstrated previously, Classes can consume more than their allocated bandwidth should it be available.


Unallocated Bandwidth

All bandwidth which has not been allocated to a Class is given to the Child Policy's "class-default".

Also, as mentioned in my previous post, anything which does not match a manually configured Class (which in this example are the MATCH-BulkData and MATCH-Voice classes) will automatically be sent to the "Class-Default" class. In other words, unless traffic and bandwidth is specifically assigned to a Class, it will be assigned to the Class-Default class.

To verify this, let's take another look at the "show policy-map int gi 0/1" output under the "Multiple Streams" above -

We can see that MATCH-BulkData and MATCH-Voice have an offered rate of 281000 bits (274kb) and 121000 bits (118kb) respectively which is just below their allocated bandwidths of 300kb and 150kb respectively. As we're using a 1mb shaper, this means that we should have about 574kb left over. Looking at the class-default class we can see that it has an offered rate of 530000 bits (517kb) - which is very close to the 574kb we were looking for.

Sharing Unused Bandwidth

In the above sections I've talked about and demonstrated the fact that Classes can use more bandwidth than they're allocated if there is additional unused bandwidth available.What I have not explained yet though is how the router decides which classes to give the additional bandwidth to should more than one need it.

It is actually very simple - The router uses each Classes' original bandwidth configuration as a weight. The more bandwidth the Class has been configured with, the more "weight" it has, and therefore it will be allocated a larger amount of the unused bandwdith.

For example, above we used the MATCH-BulkData and MATCH-Voice classes, giving them 300kb and 150kb respectively. This means that MATCH-BulkData has twice the amount of "weight" that MATCH-Voice has, and therefore should be allocated twice has much unused bandwidth. Let's run a test and see if that is true:

Router(config-if)#do sh policy-map int gi 0/1
 GigabitEthernet0/1

  Service-policy output: PARENT-EGRESS-Shaper

    Class-map: class-default (match-any)
      6347 packets, 8861862 bytes
      30 second offered rate 920000 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 33/0/0
      (pkts output/bytes output) 6348/8862106
      shape (average) cir 1024000, bc 4096, be 4096
      target shape rate 1024000

      Service-policy : CHILD-EGRESS-BandwidthAllocation

        Class-map: MATCH-BulkData (match-any)
          4136 packets, 5867664 bytes
          30 second offered rate 610000 bps, drop rate 0 bps
          Match:  dscp af33 (30)
            4136 packets, 5867664 bytes
            30 second rate 610000 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 17/0/0
          (pkts output/bytes output) 4136/5867664
          bandwidth 300 kbps

        Class-map: MATCH-Voice (match-any)
          2084 packets, 2955204 bytes
          30 second offered rate 307000 bps, drop rate 0 bps
          Match:  dscp ef (46)
            2084 packets, 2955204 bytes
            30 second rate 307000 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 14/0/0
          (pkts output/bytes output) 2084/2955204
          bandwidth 150 kbps

        Class-map: class-default (match-any)
          127 packets, 38994 bytes
          30 second offered rate 6000 bps, drop rate 0 bps
          Match: any
         
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 127/39178


As we can see above, MATCH-BulkData has an Offered Rate of 610000 bits (310000 additional bits taken from the unused "Class-Default" class). We can also see that  MATCH-Voice has an Offered Rate of 307000 bits (157000 additional bits taken from the unused "Class-Default" class). This confirms that MATCH-BulkData was allocated very close to double the amount of bits which MATCH-Voice was given.

Note: You may have noticed that I changed MATCH-Voice to a "bandwidth 150" in the last output above. The reason for this is because as shown above, using the "priority" command with iperf results in quite a lot of packet loss, therefore it would affect the "Offered Rate" shown.

Below is another test which demonstrates the splitting of unused bandwidth. MATCH-BulkData again uses the "bandwidth 300" statement but this time MATCH-Voice has used the "bandwidth 100" command. This therefore means that MATCH-BulkData should be allocated three times as much unused bandwidth as compared to MATCH-Voice:

BO1-RTR-2951(config-pmap-c)#do sh policy-map int gi 0/1
 GigabitEthernet0/1

  Service-policy output: PARENT-EGRESS-Shaper

    Class-map: class-default (match-any)
      6267 packets, 8720258 bytes
      30 second offered rate 897000 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 35/0/0
      (pkts output/bytes output) 6288/8725874
      shape (average) cir 1024000, bc 4096, be 4096
      target shape rate 1024000

      Service-policy : CHILD-EGRESS-BandwidthAllocation

        Class-map: MATCH-BulkData (match-any)
          4580 packets, 6497848 bytes
          30 second offered rate 669000 bps, drop rate 0 bps
          Match:  dscp af33 (30)
            4580 packets, 6497848 bytes
            30 second rate 669000 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 17/0/0
          (pkts output/bytes output) 4580/6497848
          bandwidth 300 kbps

        Class-map: MATCH-Voice (match-any)
          1544 packets, 2188764 bytes
          30 second offered rate 226000 bps, drop rate 0 bps
          Match:  dscp ef (46)
            1544 packets, 2188764 bytes
            30 second rate 226000 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 16/0/0
          (pkts output/bytes output) 1544/2188764
          bandwidth 100 kbps

        Class-map: class-default (match-any)
          143 packets, 33646 bytes
          30 second offered rate 4000 bps, drop rate 0 bps
          Match: any
         
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 143/33908


As we can see above, MATCH-BulkData has an Offered Rate of 669000 bits and MATCH-Voice has an Offered Rate of 226000 bits. This confirms that MATCH-BulkData was allocated very close to three times the amount of bits which MATCH-Voice was given.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Understanding MQC, Part 2: Basic Configuration

In my previous post I mentioned the six steps which are required in order to implement a QoS solution. In this post I'll use those steps to create an example implementation. Before I do though, I'll first cover the "bandwidth" and "priority" commands.

Priority & Bandwidth Commands

In Step 3 of the process you must assign a a portion of bandwidth to the Class Map. The two main options used here are "priority"and "bandwidth". Details on these two options can be found here.

In short though, the "priority" command is used for time sensitive applications where packets need to be sent ASAP, for example, VoIP calls. To ensure that these packets are sent as soon as possible, the router uses a special queuing process called Low Latency Queuing (LLQ) whereby all priority packets are sent immediately, even if there are other packets which on the router first.

The "bandwidth" command is used for non-time sensitive traffic, such as large file backups.

Basic Configuration

Now that we've covered the basics, let's jump in to a Basic Configuration example using the Six Steps outlined in my previous post.

I'll be using iperf to generate traffic in my lab network. The two traffic flows I will prioritise are:

Interface Shape: 1mb

Bulk Data Traffic:
Source IP:  192.168.10.101
Destination IP: 192.168.20.101
Destination Port: 5001
DSCP Marking: AF33
Bandwidth: 300kb

Voice Traffic:

Source IP:  192.168.10.101
Destination IP: 192.168.20.101
Destination Port: 5002
DSCP Marking: EF
Priority: 150kb

Step 1 - Classify Class Map

Note: I'll be using ACLs to match the desired traffic, however, protocols can also be matched through the use of NBAR.

The "classify" ACLs look like this:

ip access-list extended BULK_DATA
permit tcp host 192.168.10.101 host 192.168.20.101 eq 5001
 

!
ip access-list extended VOICE
permit tcp host 192.168.10.101 host 192.168.20.101 eq 5002


Now we need to create the "classify" Class Maps and tie them to the above ACLs:

class-map match-any  MARK-BulkData
match access-group name BULK_DATA
!

class-map match-any  MARK-Voice
match access-group name VOICE


Step 2 - Inbound Policy Map

Next, we have to tie the above "classify" Class Maps to a Policy Map and assign the DSCP values to each of the Classes:

policy-map INGRESS-Mark-DSCP
  class MARK-BulkData
    set dscp af33 

!
  class MARK-Voice
    set dscp ef
 

Now we apply the Policy Map in the inbound direction on the router's LAN facing interface:

interface gi0/2.10
  desc LAN Port - Ingress Packet Marking 
  service-policy input INGRESS-Mark-DSCP

Step 3 - Prioritisation Class Map

Note: These Class Map names do not need to match the ones used in Step 1.

Here we match the DSCP values which were configured in Step 2:

class-map match-any MATCH-BulkData
  match dscp af33

class-map match-any MATCH-Voice
  match dscp ef

 

Step 4 - Bandwidth Allocation Policy Map (Child)

Now we allocate the bandwidth to each of the above Class Maps using another Policy Map.

Recall that this Policy Map will not be applied to an interface and will instead be applied underneath another Policy Map. That is why this Policy Map is known as a "Child" Policy Map:

policy-map CHILD-EGRESS-BandwidthAllocation
  class MATCH-BulkData
    bandwidth 300
!
  class MATCH-Voice
    priority 150


Step 5 & 6 - Shaper Policy Map (Parent)

Here we create the Parent Policy Map as well as apply the 1mb shaper. We then attach the Child Policy Map to it.

policy-map  PARENT-EGRESS-Shaper
  class class-default
    shape average 1024000
    service-policy CHILD-EGRESS-BandwidthAllocation
 

Now we apply the Parent Policy Mapoutbound on the router's WAN facing interface:

interface gi 0/1
  service-policy output PARENT-EGRESS-Shaper


Class-Default

Before I end this post I thought I should quickly mentioned the "Class-Default" class. Anything which does not match a manually configured Class (which in this example are the MATCH-BulkData and MATCH-Voice classes) will automatically be sent to the "Class-Default" class. The same goes for unallocated bandwidth. Both of these scenarios are discussed in my next post.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.
 

Understanding MQC, Part 1: The Basics

Over the course of my next few blog posts I will be covering Modular QoS CLI (MQC), Weighted Fair Queue (WFQ), Class-Based Weighed Fair Queuing (CBWFQ) and Low Latency Queuing (LLQ).

Configuring MQC is not an easy job for those who have never done it before, but thankfully once you understand the basics it's not very difficult to delve deeper. So let's get started!
 

Most Important Rule of QoS

I need to stress the most important rule of QoS - That is, QoS is not implemented if there is no congestion on the link. This is because if there is no congestion on the link, then packets are being sent as soon as they're being received, therefore there is no need for QoS to kick in.

It is a simple rule to understand but it is easily forgotten.

DSCP

DSCP values are used to determine how traffic types should be handled. There is the priority value called Expedite Forwarding (EF) which is used to mark traffic which is latency sensitive, such as Voice. Then there is the Assured Forwarding (AF) values which define varying amounts of prioritisation and drop probability. (This Wikipedia table is well worth a look). Finally there is the Class Selector (CS) values.

Class Maps & Policy Maps

MQC's configuration is all about Class Maps and Policy Maps. To sum each of them up:
  • Class Maps - There are two types of Class Maps - one is used to classify (also known as mark) traffic, while the other is used to assign a portion of bandwidth to the marked traffic. They are applied inbound and outbound respectively through the use of Policy Maps.
  • Policy Maps - Policy Maps contain multiple Class Maps. As mentioned above, they are applied to interfaces in the outbound and inbound directions. They are also used to shape an interface's speed as agreed with your carrier. 
The above is expanded on below.

Diagram



 Step by Step

Let's take a look at the steps which must be taken in order to achieve a QoS setup:
  1. The "classify" Class Maps are written to match traffic types/groups. For example, all Backup traffic would be matched in one Class Map while all Voice traffic would be matched in another.
  2. These Class Maps are then put in to a Policy Map. From here the Class Maps are given appropriate markings. For example, mark the Voice Class Map as EF and the backup Class Map as AF33. This Policy Map is then placed inbound on the router's LAN facing interface (Fa0/0 in the image above).
  3. The "prioritisation" Class Maps are then written to match the DSCP values marked in Step 2.
  4. The above mentioned Class Maps are then put in to a Policy Map which assigns each one an appropriate amounts of bandwidth. For example, for all packets which match the Voice Class Map, give them 150kb of bandwidth to share. (Note that unlike the inbound Policy Map mentioned above, this Policy Map is not applied to any of the router's interfaces).
  5. A third Policy Map is created. This one is used to shape the interface's speed to the rate which has been agreed with your carrier. This Policy Map is applied outbound on the router's WAN facing interface (Fa0/1 in the image above).
  6. Finally, the Policy Map mentioned in Step 4 is configured as a "child" policy of the Policy Map mentioned in Step 5.
You might be wondering why outbound traffic requires two Policy Maps. As mentioned in Step 5, the first one is used to shape the interface's speed. The reason why this needs to be done is due to the "Most Important Rule of QoS" mentioned above.

For example, if you purchased a 2mb Ethernet service from your carrier and had it terminated on your router's gigabit interface, your router will believe that it has a gigabit connection to the carrier. This therefore means that your router will never use the QoS policies as it will never think there is any congestion. However, by implementing a shaper you can tell the router "although the carrier connection is terminated on a gigabit port, we can only use 2mb/sec". The router then disregards the fact that it is using a gigabit interface and instead  treats it as a 2mb interface, therefore enforcing the QoS policies in times of congestion.

Now that the basics are covered my next blog post covers basic configurations.

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.

Thursday, May 9, 2013

New Website Launch - Ultimate Cisco Lab

In my "Connecting Your PC to Your Virtual GNS3 Routers" post I provided basic instructions explaining how you can connect your PC to your GNS3 topology, allowing you to connect to the virtual routers as if they were real physical routers.

Next, in my "Virtual Equipment + Physical Equipment = Big Lab" post I expanded on the above idea and explained how you can connect physical and virtual machines to your GNS3 routers, as well as physical network gear too.

However, after having re-read the above two posts I felt that they may not be clear enough for those who are not familiar with GNS3 and/or virtualisation. With this in mind I decided to create a brand new website that would explain every single step of the process in great detail. A few months have past since then but it is now with great pleasure I would like to announce that it has finally been completed! Please follow the link below to get started.

Ultimate Cisco Lab

As always, if you have any questions or have a topic that you would like me to discuss, please feel free to post a comment at the bottom of this blog entry, e-mail at myciscolabsblog@gmail.com, or drop me a message on Twitter (@OzNetNerd).

Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.