The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
How to configure for 20 Mbps? Depends on what's your traffic and what you're trying to accomplish. Same question when trying to formulate a drop policy on any interface.
What do 24 and 40 mean? The 24 is number of packets in queue when WRED will begin to drop, i.e. no drops up to 23. The 40 is the number of packets in queue when WRED will drop at the maximum percentage rate, which your posting doesn't note so defaults to 10%. Starting with packet 41 all packets will be dropped. (NB: if you want to know the drop rate for each packet number from 8 though 23, you solve the linear equation where drops are zero at 7 and 10% at 24, or graph it out.)
These numbers have nothing to do with link speed, they reflect queue depth (actually average queue depth). However, since link speed will indicate how long a packet will take to transmit, you can calculate how long it would take to transmit 40 packets. I.e. This would provide your maximum queuing latency. (Again, though, WRED uses an average queue depth, so actual number of packets could be higher or lower than 40 even when packets are being queued or dropped. There's an additional parameter that can control how quickly the average value mirrors the instaneous value. Also remember, once 40 is exceeded all additional packets are dropped.)
WRED is designed for flow adaptive traffic such as TCP. Another reason why "what's your traffic" is relevant.
If working with TCP and you're trying to maximize throughput, you probably might want to insure dropping doesn't begin until the about half to full bandwidth delay product is exceeded. As you've only noted 20 Mbps, I don't know what your BDP is. How much of BDP to allocate for also depends on oversubscription ratio to your 20 Mbps, i.e. how quickly can traffic queue.
If all the foregoing appears complex, optimal tuning for WRED is complex. I often recommend it not be used if you don't understand the complexity. Instead, for 20 Mbps to MPLS, I would insure you're shaping for that rate (if not natural interface physical rate); configure queuing for your needs to manage possible egress (to MPLS cloud) congestion; configure traffic marking to work with a QoS model provided by the provider (although I recall Sprint didn't used to provide MPLS egress [from MPLS cloud] QoS).
BTW, queue depths configured for 40 is a fairly common default on Cisco devices, and 40 is often about BDP for 1500 byte packets for typical 10 Mbps LANs or 1.5 Mbps WANs. (Oh yea, BDP is in bytes and queue depths are in packets and packet sizes vary - more complexity.) So, 40 is probably too shallow for optimal single flow TCP performance across a 20 Mbps non-LAN. Conversely it might be too deep for multiple transactional flows too.
Also BTW, you could "trial-and-error" tune. Random drops should be under 1% and ideally there should be no tail drops. Adjust drop at numbers to achieve. Normally you don't want to mess with averaging value or the 10%. Hint: you often need to adjust distance between when dropping begins and when it goes to 100%; Cicso usually defaults at 2x start's value (20 40), but original author of RED recommended 3x.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...