No Queues are formed with Custome Queue (CQ)

[turbo_engine26]

Hello Nice People,

I am posting this QoS topic in this area since CCIE R&S is involving QoS in its exams.

Please see attached configuration and topology files.

I've configured classification and marking on Alex router's FE0/0 interface (input) in order to classify and mark Netmeeting traffic as DSCP EF. Then, i configured custom queueing on Alex's serial 1/0 interface. Also, i configured CQ on Cairo and Suez routers' serial 1/1 and FE 0/0 respectively to take advantage of the end-to-end QoS queueing design.

I am using two host PCs both running Windows XP, an IP traffic generator (very cool) and MS Netmeeting. I configured the traffic gen. on VBOX 2 to be the IP traffic sender and VBOX 1 to be the IP traffic answering (or receiving). Also, i opened both Netmeetings.

Now, to test it right, i started to generate 3 concurrent connections (TCP,UDP,ICMP). one connection is sending at 200 Kbps, one is sending at 100 Kbps and the thirds is sending at 50 Kbps.

However, the issue here is, that i don't see any queues formed for the first 2 connections. I clocked all serial connections at 64 Kbps and because 200 Kbps and 100 Kbps connection is bigger than the clock rate, they should be queued. The third connection is just 50 Kbps so it will drain fast on the serial link.

then i placed a call in Netmeeting from VBOX 2 to VBOX1 but a delay occured. In the config, i gave the netmeeting traffic 10 Kbps which is good for a voice call. I don't know maybe the delay is from my Labtop processor (GNS3 + VBOX + Traffic gen) not from the network itself. In short, i discovered that you can't test voice quality in a virtual environment because if a delay occured, you don't know exactly the source of the delay, is it my host PC or m guest PC or my network or etc....?

So forget about the Netmeeting thing now ... My concern now is why queues are not formed in the routers for these 2 connections?

Last thing.. Appreciate if someone got an idea on how to better test voice quality or QoS in general. This is because if i just only type a punch of IOS commands without feeling their effect, i won't understand them in depth and troubleshooting would be hard. Specially the QoS.

Regards,

AM

[maayre · Accepted solution]

The IP SLA feature set is often the most convenient way to emulate traffic flows, you can do TCP/UDP/ICMP/voice (pageant IOS images are good too but I've never really bothered because IP SLA is in most images and no IOS change is required)

http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsvoipj.html#wp1074072

On the CQ queue question your issue is probably with matching, I think your ACLs are not matching traffic. Otherwise you would see an increase like this;

    access-list 101 permit icmp any any

    !

    queue-list 5 protocol ip 1 list 101

    queue-list 5 default 2

    queue-list 5 queue 1 byte-count 10000

    queue-list 5 queue 2 byte-count 5000

    !

    interface Ethernet0/0

     ip address 192.168.12.1 255.255.255.0

     custom-queue-list 5

    R1#show queueing int e0/0

    Interface Ethernet0/0 queueing strategy: custom

    Output queue utilization (queue/count)

            0/178 1/27094 2/56568 3/0 4/0 5/0 6/0 7/0 8/0

    R2#ping 192.168.12.1 re 1

    !

    Success rate is 100 percent (1/1), round-trip min/avg/max = 4/4/4 ms

    R1#show queueing int e0/0

    Interface Ethernet0/0 queueing strategy: custom

    Output queue utilization (queue/count)

            0/179 1/27095 2/56568 3/0 4/0 5/0 6/0 7/0 8/0

You could try making it more basic and testing with ICMP packets to start off with as I have in my example

PS Not sure if you already knew this but 10K is only enough if you are using G.729 codec, did you confirm it is not G7.11 because that's around 80K with overhead?

[turbo_engine26]

First, on which router is your configuration should be applied? ... I think the "custom-queue-list 5" should be applied on a serial interface (output Q) not ethernet.

Second, why do i need to create an explicit ACL for ICMP? .. Simply, all non-voip traffic that are not matched by the DSCP ACL, will be placed in Q 2 (Default).

Third, my concern is with the "show queue serial 1/0" command to show the number of queues that are formed not the number of packet counts.

Fourth, i agree with you about the G.729 and you're right. Netmeeting doesn't use G.729. It uses G.711 and G.723.1 as i read in many articles so i will try to increase the byte count rate and test it again.

Regards,

AM

[maayre]

Hi again,

1) I didn't really mention it but I was demonstrating on a different topology, there isn't really any difference between ethernet & serial in the example we're discussing. So I'm not saying it needs to be on a different interface, just showing a working example from my lab;

    Router#show queueing int serial 2/0

    Interface Serial2/0 queueing strategy: custom

    Output queue utilization (queue/count)

            0/0 1/0 2/0 3/0 4/0 5/0 6/0 7/0 8/0

            9/0 10/0 11/0 12/0 13/0 14/0 15/0 16/0

2) You don't need an ICMP matching ACL unless you are trying to classify ICMP into a queue. I was more making the point that if you make it simple, ie just classifying ICMP into a queue and build up from there as a way of breaking it down into managable components.

3) "show queue" and "show queueing" are different commands. I think this is the cause of your problem. As you can see in my response for point one the same output is shown.

HTH,

Matt

[turbo_engine26]

 
1) I didn't really mention it but I was demonstrating on a different topology

In that case, i would ask you to discuss my problem using my topology to just avoid confusion.

there isn't really any difference between ethernet & serial in the example we're discussing.

Honestly, i can't agree with you in this since the output queue is always used by queuing tools in routers. Perhaps input queue can be used on switches but not routers as most of Cisco press books suggests. As a good QoS design calls for classifying/marking on ingress and apply queuing on egress, then how come there is no difference?

2) You don't need an ICMP matching ACL unless you are trying to classify ICMP into a queue. I was more making the point that if you make it simple, ie just classifying ICMP into a queue and build up from there as a way of breaking it down into managable components.

Got that! ... you're trying to narrowing down the troubleshooting efforts to something explicit. However, as mentioned, the problem is not with packet counts in the queue because in my current configuration (without your explicit ICMP ACL) i can see those counts which means the configuration actually works. I just want to see the actual enqueued packets that are formed in the Q's but anyways, this issue is solved by generating 10 concurrent connections this time (not 3) just to create some K.A.O.S. now i can see the queues. Previously, simply no queues were formed because the packets were drained quickly from the queues due to the 3 only connections. This is one of the important points on how to test QoS, is to create crowd and simulate the crowded converged networks.

3) "show queue" and "show queueing" are different commands. I think this is the cause of your problem. As you can see in my response for point one the same output is shown.

Where? lol ... I don't see the output that i need in your response. Well, take a look at the output that i need below:

Alex#show queue serial 1/0

Output queue for Serial0/0 is 26/60

Packet 1, linktype: ip, length: 1404, flags: 0x88   source: 192.168.3.100, destination: 192.168.1.100, id: 0xF560, ttl: 127,   TOS: 0 prot: 6, source port 2831, destination port 1668     data: 0x0B0F 0x0684 0x79EB 0x0D2A 0x05B4 0x0FF5 0x5010           0x4510 0x5BF8 0x0000 0x6076 0xEEFD 0xFBB6 0xCC72

Packet 2, linktype: ip, length: 724, flags: 0x88   source: 192.168.3.100, destination: 192.168.1.100, id: 0xF561, ttl: 127,   TOS: 0 prot: 6, source port 80, destination port 1667     data: 0x0050 0x0683 0x79C1 0x0930 0x05B3 0xE88E 0x5010           0x41C5 0x276E 0x0000 0xDA9B 0x48F7 0x7F64 0x7313

Packet 3, linktype: ip, length: 724, flags: 0x88   source: 192.168.3.100, destination: 192.168.1.100, id: 0xF562, ttl: 127,   TOS: 0 prot: 6, source port 80, destination port 1666     data: 0x0050 0x0682 0x79BC 0xE875 0x05B3 0xE2C6 0x5010           0x441A 0xA5A2 0x0000 0x8071 0x4239 0x5906 0xD18C

Regards,

AM

[maayre]

Hi again,

I think a lot of the confusion here was me missing what you were actually having a problem with in the first place.

1) What I was trying to say is it doesn't matter if you use CQ on  a serial or ethernet interface, it doesn't change how the CQ feature  works.

I didn't actually say anything about QoS end-to-end  design as you mentioned (classify/mark ingress, queue egress) but since  you brought it up, my question to you is why does it matter what the  underlying interface is? The features you're talking about operate  independently of this. This only case where this isn't true is you are  using L2 parameters in your QoS (COS,DE,CLP,High priority DLCI/VC).

Bottom line I think we are talking about different things and not actually disagreeing.

2-3) Exactly, sorry I could have explained at greater  length in the first instance. Actually I see now that your question was  in fact about viewing packets in the queue and not matching packets into  queues.

The "show queue" command you are using is only for  when you are using WFQ/WRED and I thought you were trying to use it on  the CQ interface (which doesn't work / isnt supported)? Your config  shows Se1/0 as a CQ interface? Looking at the output you pasted you ran  the comand for Se1/0 but got a result for Se0/0?

"show queue" command reference

http://www.cisco.com/en/US/docs/ios/12_3/qos/command/reference/qos_s3g.html#wp1127393

I think you can see the CQ depth using show interface though;

Router#show int se2/0

Serial2/0 is up, line protocol is up

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1694

  Queueing strategy: custom-list 5

  Output queues: (queue #: size/max/drops)

     0: 20/20/1694 1: 0/20/0 2: 0/20/0 3: 0/20/0 4: 0/20/0     <<< queue zero is maxed and dropping

     5: 0/20/0 6: 0/20/0 7: 0/20/0 8: 0/20/0 9: 0/20/0                    note: done on random topology

     10: 0/20/0 11: 0/20/0 12: 0/20/0 13: 0/20/0 14: 0/20/0

     15: 0/20/0 16: 0/20/0

I think that the  only time you can actually see packets in the queue is using WRED/WFQ on  a major interface, I don't think you can get that kind of detail using  the various MQC features.

Regards,

Matt Ayre

[turbo_engine26]

Thanks Matt .. Appreciate your efforts and valuable responses.

No, actually, the "show queue" command is supported by CQ, PQ as well as WFQ. Btw, WRED is beyond of our discussion because it is a congestion avoidance tool not queueing. 

I didn't actually say anything about QoS end-to-end  design as you mentioned (classify/mark ingress, queue egress) but since  you brought it up, my question to you is why does it matter what the  underlying interface is? The features you're talking about operate  independently of this. This only case where this isn't true is you are  using L2 parameters in your QoS (COS,DE,CLP,High priority DLCI/VC).

I didn't say anything about QoS end-to-end design either . The prove is that i only mentioned Alex router and didn't mention the other routers involved in QoS .. All i said is that the placement of the queueing policy is very important in order to take effect Like ACL, it is very important to know on which interface you're applying your policy, otherwise, it won't take effect, yeah? ...

1) What I was trying to say is it doesn't matter if you use CQ on  a serial or ethernet interface, it doesn't change how the CQ feature  works. 

Yeah, that's right .... You are talking very generally. However, in my post, i talk specifically about a working configuration . Of course, you can drive a car in highways or in a beach. it doesn't affect how your car operates but my goal is to drive on highways. The same apply, the CQ feature will indeed work regardless of which interface but will it take effect as per my needs?... In the CCIE lab, the CQ will work on any interface but i will lose points if i don't apply on the right interface, right?

Thanks again ... I am going to give an IP SLA a shot as you adviced.

Regards,

AM

[maayre]

Love your analogy with the car and the highway!!

Regarding CCIE lab they would usually ask you to perform a configuration on a specific device and interface. CCIE is not really as much about design, more so it is usually configuring a specific feature in a specific place while meeting a few requirements.

With CQ the hardest part is being able to do the math to get from what the question gives you to what byte counts to use so if you've got that down I think you should be in the clear.

That's my two cents anyway.

Regards,

Matt

[turbo_engine26]

Thanks again Matt

Very true! CCIE is not a design exam (CCDE is), that's why i dumped the "End-to-End QoS design" book.

CQ's math is nothing compared to traffic shaping and policing's math.

Btw, IP SLA is cool and i recently noticed that it is included in the "Optimizing the network" section in the blueprint.

I'd like to thank you again for your knowlege sharing and efforts.

Regards,

AM

[maayre]

Glad it helped and good luck with the lab!

PS - while we're on the topic I think this is by far the best book on QoS I've read and I strongly recommend it!

http://www.ciscopress.com/bookstore/product.asp?isbn=1587201240

Regards,

Matt Ayre