- Bronze, 100 points or more
Hi every body.
I was reading about how qos help in congested network. Let say we have a network . Three hosts and a router is connected to ethernet. The link between hosts and router is not congested. Thee is no congestion elsewhere in the network. a host sends a packet to router. This router though configured with qos configurations receives the packet. Since there is no congestion, router will not prioritizing the traffic. Will received packet still get placed in some queue? or to put simply is there any queue associated with outgoing interface on router when no qos is configured on a router?
thanks have a good day.
you have found a good link by a well known author ( Pepelnjak is also author of books and writes in many places including his own blog iosinternals and on nanog forums)
>> The hardware queue shared between the CPU and the interface chipset cannot be reordered, as the CPU has no control over the operation of the interface hardware that might pick up a packet at any time. Once a packet enters the hardware queue, its position in the queue cannot be changed.
This is a clear description of my doubts: once the packet is in the HW queue is too late to provide any QoS differentiation.
For this reason the HW queue should get packets from the output of the SW queues also when congestion is not present it provides a way to give priority to small VoIP packets for example.
The HW queue size is minimized to only a few packets when SW Queues are enabled, this is reported also on some of those books that say that when the link is not full the SW queues are bypassed.
but if the HW queue is 4 packets "congestion" = 4 packets in the HQ queue or tx ring as it is called!
About your questions:
it is difficult to describe router internals:
packets are placed in a shared memory waiting to be transmitted the interface HW takes them from this memory and move them to the tx ring.
Actually in modern routers interrupts to main cpu are minimized by using the mechanism described above ( a packet memory)
The mentioned descriptors are internal tags added to the packet to allow low level and efficient moving of packets from packet memory to interfaces.
To be more practical: in my tests I usually had many traffic flows belonging to different traffic classes. To demonstrate good behavior of schedulers like CBWFQ or MDDR the offered traffic had a total volume slightly more then outgoing interface speed (101% to 103%) but only one traffic class was over its limit. The expected result is that only packets of that exceeding class are dropped.
However, even using a load variable in time with the appropriate instruments results are in line with the idea that SW queues are not bypassed.
Have a nice weekend you too.
I' m more busy in this period so I'm less present in the forums
Hope to help
" Will received packet still get placed in some queue? or to put simply is there any queue associated with outgoing interface on router when no qos is configured on a router?"
Yes, there is always a queue associated with every L3 interface on a router. This is the interface hold-queue in the outbound direction. For interfaces <= ~ 2 Mbps, the queueing defaults to fair-queue; over 2 Mbps, it's fifo.
The interface hold-queue, like the queues associated with a QoS policy, is a software queue.
As for the packet flow:
- CEF switched traffic: During the tx_interrupt, packets are placed on the tx_ring or the so-called 'hardware queue'. This is basically the buffers present on the PLIM. The tx_ring is a FIFO structure and it's size various according to HW / media.
- Process switched traffic: Process switched traffic, like traffic originated form the router itself, *always* go through the 'software' queues(irrespective of whether there is congestion or not), before being placed on the tx_ring.
- An interface getting 'congested' basically means, the tx_ring is overrun. When this happens, there is backpressure from the tx_ring so that CEF switched packets are queued in the software queued (intf hold-queue or QoS queues). Hence, any software queueing is invoked by this 'backpressure' mechanism. This mechanism itself varies depending on the hardware, it can either be the tx_ring getting overrun (this is the case for most lower-end platforms) or can be an internal shaper / ASIC that provides this mechanism (like in the case of SIP / SPA).
I think the SW queues are created and used before congestion happens otherwise how we could provide better QOS to some traffic classes?
My opinion is based on many tests I did of CBWFQ on C7500 and MDRR schedulers on 12000 routers using traffic generator instruments like SMARTBITS or Agilent router tester. The first instrument has the limit to be not able to change the traffic load during the test, but Agilent router tester can do this.
This is my opinion and this can be true only of these high end routers, however a show policy-map interface shows packets for each traffic class on an interface where CBWFQ is applied outbound also if the link is not congested.
In real networks congestion happens without any advice what about the packets already in the FIFO HW queue ?
I agree that the HW queue is still there but minimized in size (expressed as a number of packets) and that may be a sort of threshold mechanism might be used to bypass the SW queues when average load is low. But I don't know how this could handle the sudden change to congestion state, when the thr threshold is reached we start to send packets to SW queues instead of sending them directly to the HW queue.
Hope to help
You have hardware Queue and a software queue. The Hardware Queue is always FIFO where the software Queue is a queuing mechanism configurable by the user.
In your case, No Queing is configured, The hardware queue recieves tha packet and When a queue packet is full, Cisco IOS software has no place to put extra packet. The packet will be tail droped.