Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Users might experience few discrepancies in Search results. We are working on this on our side. We apologize for the inconvenience it may have caused.
New Member

Queuing on an un-congested link

I have enabled QoS on my 10Mb link, classifying voice bearer and signaling traffic.  The link typically does not get congested and has not been congested since this configuration has been put in place.  My question is why do I see packets being thrown into the queue?

I have copied the output of "show policy-map int" as welll as the section of the config that is pertinent. There is a reason for the two custom entries below.

Thanks in advance.


  Service-policy output: Tag_Policy

    Class-map: TagVoice (match-any)
      719472004 packets, 40496640283 bytes
      5 minute offered rate 2026000 bps, drop rate 0 bps
      Match: protocol custom-05
        682415448 packets, 38116877131 bytes
        5 minute rate 1849000 bps
      Match:  dscp ef
        37056564 packets, 2379763292 bytes
        5 minute rate 164000 bps
      QoS Set
        dscp ef
          Packets marked 719472059
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 25 (%)
        Bandwidth 11250 (kbps) Burst 281250 (Bytes)
        (pkts matched/bytes matched) 23928977/1346290667
        (total drops/bytes drops) 0/0

class-map match-any TagCallProc
match protocol custom-06
match  dscp af41
class-map match-any TagVoice
match protocol custom-05
match  dscp ef
policy-map Tag_Policy
class TagVoice
  set dscp ef
  priority percent 25
class TagCallProc
  set dscp af41
  bandwidth percent 15
class class-default


Re: Queuing on an un-congested link

When talking about phone calls, a queue is only used when the line is busy (i.e. congested).  However, network interfaces don't work like that.  Every packet is placed into a queue.  Even if there is no QoS configured, the router still uses a queue.  If for no other reason than because the route processor handles packets alot faster than the port speed.  So rather than waiting for the relatively slow (and 10 mbps is slow for the processor) to accept the bits, the route processor places the bits into a queue and the port processor reads the bits off of that queue as fast as it can.

Packets queuing is completely normal.  What you want to watch for is dropped packets, which implies that the queue was too full.

New Member

Re: Queuing on an un-congested link

Thanks for the reponse.  I was beginning to think I was in the wrong place.

Your reply was also suggested by a co-worker, but it doesn't sound right to me.  I am aware that all packets are thrown into the FIFO queue before being sent out an interface.  However, all of my investigation indicates that packets should only be placed in the designated software queues when there is congestion and only packets that are placed into the software queues should be listed in the output. This is when decisions are made regarding which packets get priority.  Also, if your assessment is right, why are there more packets marked as EF than there are packets in the EF queue? I agree that drops are what really needs to be watched.

I appreciate the response.

CreatePlease to create content