Kevin Dorrell, CCIE #20765

01 May 2008

Custom Queueing

Filed under: Queueing : Custom Queue — dorreke @ 15:15

NMC Lab 18.10 has prompted me to have another look at Custom Queueing.  I have always been a bit vague and empirical about how you set the byte-count to determine the bandwidth weighting of each queue, so I thought I would try and take the bull by the horns.

Reading “CCIE Practical Studies Vol II” by Karl Solie and Leah Lynch, I come across something that seems to be not as I understood it.  On page 425, it says:

Each queue is emptied, to its byte or packet limit, and then the next queue is serviced.  […] After a queue’s packet or byte size limitation is met, any new packets destined for that queue are dropped.

Again, on page 426 it says:

With CQ, when a queue is full, the last packet in the queue is transmitted before the next queue is serviced.  If a queue fills up while waiting for service, and new packets for the queue are dropped.

This is not how I had understood it.  I don’t know which is right, the way it is explained in the book or the way I had understood it.  The book seems to imply that the byte count and the packet limit are both tail-drop limits, beyond which packets are discarded.  Instead, I had always understood that the queue limit (in packets) was a tail-drop limit, whereas the byte-count determined the number of bytes that would be serviced before going on to the next queue in the round-robin, even if the queue was not yet empty.

Consider the command queue-list 1 queue 2 byte-count 3000 limit 20.  I thought that this means that each time the queue is served up to 3000 bytes would be taken off the front of the queue and transmitted, and then the scheduler would move on to queue 3, even if queue 2 was not empty yet.  If the queue ever gets full at 20 packets, then the next packet would be tail-dropped.

Suppose we are sending packets of exactly 1500 bytes.  By my understanding, the scheduler would transmit two packets each round-robin.  The queue could hold up to 20 packets, i.e. 30000 bytes.  If there are 10 packets in the queue, the scheduler would transmit 2, leaving 8 in the queue until the round-robin comes round again.

So:

  • The book says that the byte-count and packet-limit are both about tail drop, and the scheduler empties the whole queue.
  • I think that the byte-limit is about the scheduling from the head of the queue, while the packet-limit is about tail-drop from the back of the queue.

Who is right?

30 Mar 2008

13.12 Router QoS

Filed under: QoS — dorreke @ 11:27

Notes to self:

  • When making a policy-map, there is no need to include a class-default clause unless the default requires a policy.  The class-default is transmitted by default.
  • When doing single threshold policing, the default actions are confirm=transmit, exceed =drop.  There is no need to specify thos explicitly.  In that case, the command is simply police <cir-bps> <burst-bytes>
  • I wonder if it would have been acceptable to specify the access list only on the top level policer.  After all, the lower level policers are applied only within classes that are already contingent on the access-list.

24 Mar 2008

QoS study week

Filed under: Frame Relay, QoS — dorreke @ 12:33

This week, I want to concentrate some effort on understanding QoS, particularly shaping and policing.  I am fed up with losing 2 to 8 points every time I do a mock lab because I have not got a firm grasp of the subject.  Sometimes I muddle through.  I know the commands, and usually I can match up the parameters in the requirements with the parameters of some command or other, but I am not confident.

I read the chapter in the Wendell Odom book this morning.  It all seemed to make sense, but it left me wondering about two points:

  1. If you are traffic-shaping, and you have a frame in the queue that is longer than BC+BE, and the bucket overflows at BC+BE, how do you ever get enough tokens in the bucket to transmit it?
  2. If CB policing replenishes the bucket(s) with a prorata number of tokens according to how long ago was the last frame transmitted, if there is a long silence so the last frame transmitted was a very long time ago, then is the bucket replenished with an enormous number of tokens.  Doesn’t that make the traffic very very bursty?
  3. On page 566, he states “FRTS cannot classify traffic in order to shape a subset of traffic on a particular VC.”  But you can specify a service-policy within a map-class.  And in the corresponding policy map, you can specify policing under the class-default.  So what happens if you try and specify other classes in the policy map?

No doubt these things will become clearer as I read more.

23 Mar 2008

FRTS : Frame-Relay Traffic-Shaping

Filed under: Frame Relay, QoS, WAN — dorreke @ 20:10

Cisco Documentation

Cisco Tech Notes

Books and Course Notes

  • CCIE R&S Exam Certification Guide, Wendel Odom, 2nd edition, pages 565 – 570.
  • CCIE Practical Studies Volume I, Karl Solie, pages 363-369
  • Cisco : “Implementing Cisco QoS”, version 2.1, module 7 “Understanding Traffic Policing and Shaping”, esp. Lesson 4 “Configuring Class-Based Shaping on Frame Relay Interfaces”

Practical examples 

  • DOiT Labs 6, 8, 18, 20
  • CCIE Practical Studies Volume I, Karl Solie, Lab 14 on pages 382 – 391

 

10 Mar 2008

Goodstuff about Catayst QoS

Filed under: QoS — dorreke @ 15:18

Since Catalyst QoS is one of my weak points, here is a reading list:

24 Feb 2008

Catalyst QoS

Filed under: QoS — dorreke @ 11:10

I’m going to have to get a grip on this QoS stuff.  About three years ago I went on the official Cisco QoS course, but I never got a chance to use it in anger.  I have also been to quite a few Networkers presentations about it, and they all made sense at the time.  but the information did not stick.  In any case, a lot of it has changed, and the 4500, 3560, 3550, 2960, 2950 all use subtly different paradigms.

I’m doing NMC Lab 8.13, and I’m thrashing between the config line and the documentation, but I hope I’m learning something in the process.  I’m feeling the lack of any 3560s.  I have the proper 3550s for CAT1 and CAT2 (albeit with 12.1=), but my CAT3 and CAT4 are 2950s with a 2610 router on a stick behind each one in case there are any layer-3 tasks.  So far, there have not been any, but there has been plenty of QoS and special features.

So far, I tripped over a couple of configuration gotchas.  The first is “let’s put the service policy on the interface first and I’ll define it later”.

CAT2#conf t 
Enter configuration commands, one per line.  End with CNTL/Z. 
CAT2(config)#int f0/1 
CAT2(config-if)#service-policy input set-af11 
policy map set-af11 not configured 
CAT2(config-if)#end 
CAT2# 
Feb 24 09:57:47.247: %SYS-5-CONFIG_I: Configured from console by console

No, that isn’t just a warning.  It hasn’t remembered it:

CAT2#show run int f0/1 
Building configuration... Current configuration : 150 bytes 
! 
interface FastEthernet0/1 
 description R1-F0/0 
 switchport trunk encapsulation isl 
 switchport trunk allowed vlan 12,16 
 switchport mode trunk 
end CAT2#

 You must define the policy-map first.

The second gotcha was to do with monitoring the DSCP on the QoS:

CAT2#show run int f0/1 
Building configuration... Current configuration : 211 bytes 
! 
interface FastEthernet0/1 
 description R1-F0/0 
 switchport trunk encapsulation isl 
 switchport trunk allowed vlan 12,16 
 switchport mode trunk 
 mls qos monitor dscp 0 10 11 
 service-policy input Set-AF11 
end

Woops, no I didn’t mean 0, 10, and 11.  I meant 12.  OK, I have 8 slots in the stats, so I’ll just add it in:

CAT2#conf t 
Enter configuration commands, one per line.  End with CNTL/Z. 
CAT2(config)#interface FastEthernet0/1 
CAT2(config-if)#mls qos monitor dscp 0 10 11 12 
QoS: Following DSCPs are monitored already: 0 10 11 
CAT2(config-if)#end 
CAT2# 
Feb 24 10:05:05.824: %SYS-5-CONFIG_I: Configured from console by console

That was just a warning, wasn’t it?

CAT2#show run int f0/1 
Building configuration... Current configuration : 211 bytes 
! 
interface FastEthernet0/1 
 description R1-F0/0 
 switchport trunk encapsulation isl 
 switchport trunk allowed vlan 12,16 
 switchport mode trunk 
 mls qos monitor dscp 0 10 11 
 service-policy input Set-AF11 
end

No, clearly it wasn’t just a warning.  However, you can add the DSCP into the existing monitor list provided you don’t mention any of the existing entries:

CAT2#conf t 
Enter configuration commands, one per line.  End with CNTL/Z. 
CAT2(config)#int f0/1 
CAT2(config-if)#mls qos monitor dscp 12 
CAT2(config-if)#end 
CAT2# 
Feb 24 10:03:53.589: %SYS-5-CONFIG_I: Configured from console by console

Let’s have a look:

CAT2#show run int f0/1 
Building configuration... Current configuration : 214 bytes 
! 
interface FastEthernet0/1 
 description R1-F0/0 
 switchport trunk encapsulation isl 
 switchport trunk allowed vlan 12,16 
 switchport mode trunk 
 mls qos monitor dscp 0 10 11 12 
 service-policy input Set-AF11 
end

That’s better!

Here is another gotcha.  It seems you cannot set DSCP (on the input service-policy of a 3550) on the class-default.  You can only do that in the classes you have actually defined.  For example, I started with this policy map, applied input from the R6 connection on CAT1:

CAT1#show policy-map Set-AF11 
 Policy Map Set-AF11 
   class  class-default 
   set ip dscp 10

But that didn’t work.  It’s lucky I tested it by monitoring the DSCP on the the R1 connection on CAT2, with show mls qos int Fa0/1 statistics, and doing lots of pings from R6 to R1.  Otherwise I might not have noticed that the service policy was not marking the packets.  What I needed was:

CAT1#show class-map 
 Class Map match-any class-default (id 0) 
   Match any 
 Class Map match-all All-IP (id 1) 
   Match access-group name All-IP CAT1#show policy-map Set-AF11 
 Policy Map Set-AF11 
  class  All-IP 
   set ip dscp 10 
  class  class-default

 Now I can see the markings on R6’s packets at the R1 port.

One thing I did think of was to put mls qos trust dscp on each side of each trunk link.  In my case, that meant only CAT1-F0/13, CAT1-F0/23, CAT2-F0/13, CAT2-F0/23 since it was irrelevant for the CAT3 and CAT4 2950s.  Just to make sure it was necessary, I remove the command from those interfaces and tried pinging from R6 to R1 again.  Sure enough, the AF11 marking had been stripped.  Strangely, the SHOWiT does not do that, so I have asked the question on the DISCUSSiT forum.

Create a free website or blog at WordPress.com.