[CoS] - Scheduler - No delay buffers are configured with the rate, priority and the RED profile
[ Edited ]
Good day all,
Considering the below configured scheduler, how will the interface delay buffers be distributed among queues? and why am I seeing tail-drops in the "never filled" CT queue3? As far as I understand the tail drops occurs when the queue is full and the rate of receiving packets is higher than the rate of sending them. The whole interface congests, but the best effort queue only exceeds its transmit-rate, but this is not the case on queue three, it never reaches half the configured transmit rate even when the interface congests and yet it counts tail-dropped packets.
drop-profile-map loss-priority any protocol any drop-profile CT;
CoS transmit queue Bandwidth Buffer Priority Limit
% bps % usec
0 BE r r r 0 low none
1 AF 10 100000000 r 0 high none
2 EF 15 150000000 r 0 medium-high none
3 CT 1 10000000 r 0 high exact
Queue: 3, Forwarding classes: CT
Packets : 248989131 12 pps
Bytes : 57070571069 18304 bps
Packets : 244703142 12 pps
Bytes : 55003278937 18304 bps
Tail-dropped packets : 31095 0 pps
RL-dropped packets : 0 0 pps
RL-dropped bytes : 0 0 bps
RED-dropped packets : 4254894 0 pps
Low : 4174091 0 pps
Medium-low : 0 0 pps
Medium-high : 0 0 pps
High : 80803 0 pps
RED-dropped bytes : 2051789386 0 bps
Low : 2011756013 0 bps
Medium-low : 0 0 bps
Medium-high : 0 0 bps
High : 40033373 0 bps
Greetings, Assuming that your steady traffic is not reaching the configured bandwidth as you mentioned something that you can consider is microburst.
What is microburst you might be wondering?
Microbursts are traffic patterns where traffic arrives in small bursts. While almost all network traffic is bursty to some extent, storage traffic usually has large bursts when transferring data. Applications in financial trading environments or in Web2.0 environments with Memcached servers can have very small burst sizes. Such microbursts usually last only a few microseconds and are hard to detect using standard network management tools that sample data rates over a few minutes
How to detect microbursts?
If you have a monitoring tool this could be very handy or you can configure JunOS telemetries to give you some assistance
Detecting Microbursts Using Junos Telemetry QMON Sensor
Re: [CoS] - Scheduler - No delay buffers are configured with the rate, priority and the RED profile
From the experience, it's best practice to have both transmit-rate and burst-size configured on your scheduler.
Your understanding is completely right, however only reason to explain tail drop is 0 us assigned to the queue. For deeper reason, we need to go into the PFE (Different PFE has different queueing mecahnisms) and check what is being programed there.
One small test you can do is, try to ping the interface directly connected interface and see if you are able to ping all the way till max MTU.
Also "show interface queue" command should have following fields.
Queue-depth bytes : Average : 0 Current : 0 Peak : 0 Maximum : 33280 <<
If this value is somehow smalled then your MTU, some traffic will get dropped no-matter the fillness of the queue