Understanding qos configuration

pesanchez2002 · ‎02-03-2009

Hi, I have configuration,annex, type hub and spoke, the router 2 is the central equipment.

I would like to help to interpret the configuration.

If we are making two simultaneous calls, we have still available bandwidth = 64 - (25+8) = 3k?.

If we do not have traffic associated with the classes, passing through the link of 64 k, but if i have http, this can fill all the bandwidth?.

Now If we are established two calls at that time, the called pass to occupy the bandwidth defined by the classes? Packet of http begin to make drop ?, is the same behavior if we receive packet "database" in addition to http is database?

Sometimes occurs to me, that i do ping to 1.4.1.2, from router 2, but i can't do to 1.4.1.1 from lan interface of router 1. Thing illogical. Now, this happens for the queues are occupied by traffic with the highest priority and router 1 makes drop of the packet of ping?

What behavior creates in the packet, the next command?

fair-queue

random-detect

in class_default

do you think,that i must correct something in this configuration ?

1) foro1.txt

Giuseppe Larosa · ‎02-04-2009

Hello Pedro,

you have applied a CBWFQ to a frame-relay DCLI on the point-to-point FR subinterface.

a LLQ queue (priority) command has been provisioned with 25 kbps.

Be aware that when BW usage of voip codecs are mentioned they don't include the header.

I see you have configured compression of RTP header and this is good.

And also FR fragmentation if size is more then 80 bytes to reduce jitter.

during the calls very few signalling traffic is used (the calls are already setup and bearer channels are on priority queue)

if you can place two calls they use the 25 Kbps of LLQ.

CBWFQ is elastic and the parameters provided with priority and bandwidth commands are the guaranteed rate during congestion.

So every class can go behind its assignment if the link is not congested including the default class

About ICMP: you can specify an higher waiting time the packet can actually be waiting in a queue to be transmitted and so you can get request timeout even if it is not been dropped.

if the queue is full tail drop will drop the packet but not before

class-default configuration tells to use a WFQ (fair-queue) queueing for default class and to use a WRED based congestion management algorithm: the queue is managed in a differentiated manner according to ip precedence of packets (two thresholds for each class) and the average queue depth is used to compare to the thresholds.

This is more smart then tail-drop and TCP traffic adapts well to selective discards by reducing the sliding window on the TCP session.

So WRED is good for TCP traffic with few losses make TCP to adapt to available bandwidth

Hope to help

Giuseppe

pesanchez2002 · ‎02-08-2009

"About ICMP: you can specify an higher waiting time the packet can actually be waiting in a queue to be transmitted and so you can get request timeout even if it is not been dropped.

if the queue is full tail drop will drop the packet but not before"

How i can see the packet icmp waiting in a queue, by command in the router?

Giuseppe Larosa · ‎02-09-2009

Hello Pedro,

in your case ICMP should be classified in the default class

A very useful command is

sh policy-map interface typex/y

this provides detailed statistics you cannot see the icmp packets but you go on class-default you can see the current average queue size of the queue and also if there have been drops made by WRED.

Hope to help

Giuseppe