cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1382
Views
9
Helpful
6
Replies

Should I use WRED on the edge of network?

geredmpsc
Level 1
Level 1

Hi folks,

I have a lot of remote branchs with a WAN ISP MPLS link to my HQ and my question is:

Since the core routers are not possession of mine, I can only change the configuration on the edge.

And the slowest path is this 1mbps link between the router on the edge and the ISP core.

Should I configure WRED on the edge of network, despite Cisco suggests to use it only on core routers?

1 Accepted Solution

Accepted Solutions

Joseph W. Doherty
Hall of Fame
Hall of Fame

Disclaimer

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.

Liability Disclaimer

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.

Posting

I would recommend against using WRED, on the edge, for random early detect drops.  It can be useful for multi-tier drops, through.

For edge (to cloud), FQ tends to work well, optionally with special classes/weights for special traffic.

If traffic flows hub-to-spoke, shaping on the hub to match spoke bandwidths often permits more granular QoS then provided by SP.  If any-to-any traffic, you'll need to rely on QoS provided by SP (although you might still need to special queue hub's traffic to cloud).

View solution in original post

6 Replies 6

Joseph W. Doherty
Hall of Fame
Hall of Fame

Disclaimer

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.

Liability Disclaimer

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.

Posting

I would recommend against using WRED, on the edge, for random early detect drops.  It can be useful for multi-tier drops, through.

For edge (to cloud), FQ tends to work well, optionally with special classes/weights for special traffic.

If traffic flows hub-to-spoke, shaping on the hub to match spoke bandwidths often permits more granular QoS then provided by SP.  If any-to-any traffic, you'll need to rely on QoS provided by SP (although you might still need to special queue hub's traffic to cloud).

Thank you JosephDoherty.

I will be marking your response as correct.

Regards.

Could Joseph or someone else please explain why it's not a good idea to use WRED?

We use it as part of our standard CBWFQ policy-map on interfaces facing the carriers.

Disclaimer

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.

Liability Disclaimer

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.

Posting

Why not would be "it depends" kind of answer.  Or conversely, why do you use it?  Do you know, whatever your goals are for using it, are they actually being obtained?

Generally I recommend against it because most don't understand how to use it optimally, and don't configure it beyond its defaults.  When used non-optimally, it will drop packets without obtaining its designed benefits.

For example, you note it's part of your standard for your carrier facing policy-maps.  Do you distinguish using WRED against rate-adaptive traffic, such as TCP, and non rate-adaptive traffic as many UDP?  Do you distinguish between dropping TCP ACK packets vs other TCP ACK packets?  Do you distinguish between few flows and many flows being subject to it?  Do you distinguish between RTT in buffer allowances?  Do you understand it may drop packets when the queue is empty yet not drop packets when the queue is very full?  Do you realize it, for example, will put TCP flows into congestion avoidance, but you might desire them to go into slow start, etc?

If you do understand it, by all means, go ahead and use it.

hi Joseph,

Thank you for the reply, and you pointed out some very interesting things that we weren't aware of.

Is there a document or link you could forward to me, so that we can do more research on?

Most Cisco CCO doc's, including the SRND Medianet QoS design guide, only touch on how to configure WRED, and when WRED would drop packets (Mean queue depth > Min/Max threshold), but not the things you mentioned in detail.

In your experience, is it fair to say performance is actually better without WRED, for most of the common use cases? (I know it's impossible to use one formula for all cases)

To answer your question, most of our app's are TCP based, so we don't have class-map's/queues that are dedicated for TCP, or UDP. (of course VoIP bearer gets its own priority/LLQ queue)

Although a few class-map's may have certain tcp ports as the matching ACL creteria, so in a sense, that particular queue would only contain TCP packets.

We don't have flow-based RED for the same reason (not much UDP traffic), but if you have a different recommendation we'd love to know how you handle it. (flow-based is not an available option in MQC...do you just enable it under the interface?)

You asked about TCP ACK packets...obviously we wouldn't want to drop any TCP syn/syn-ack/ack packets, but do you provision special queues just for them?

We have a queue to protect the call-signals.

No idea about RTT in buffer allowances - if you have a link to good info, please share.

I've always wondered why we'd see drops when the interface utilization is low.

We've just assumed there were micro-bursts that we couldn't catch in real time, or sampled NetFlow records.

So, no I don't understand why WRED may drop packets when the queue is empty yet not drop packets when the queue is very full.

Do you mind explaining it, or pointing me to a resource where I can study up on this particular behavior?

TIA

Disclaimer

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.

Liability Disclaimer

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.

Posting

Sorry, don't know of any one link about WRED issues.  However, if you search for RED across the Internet, you'll find lots of papers about it, and all the improved variants.  The latter, of course, trying to "resolve" issues with earlier variants.

Laugh - whether performance is better or worse with WRED active, especially with default values, is another "it depends".  In the "real world", non-optimal WRED drops are usually low enough that there's not a hugely noticeable difference, but personally, I don't like to needlessly drop packets.

Also personally, about the only thing I often only use WRED for is counting packets with different markings as they egress a class.  When I do use it for intentional dropping, then I'm likely configured tiered drop levels (i.e. WTD rather than WRED).

If the platform supports it, I find per (FQ) flow, tail dropping, more effective.

When I mentioned ACL packets, I wasn't thinking just of the TCP 3-way handshake, but of normal TCP ACKs.

Regarding RTT buffer allowances, read up on BDP (and then think about implications for network devices).

WRED can drop packets when a queue is empty and conversely not drop when queue is "full"; because it drops on moving weighted average queue size, not what's actually in the queue.  (Of course, this is another parameter you can "tune".)

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco