I'm currently self studding for my CCNP ONT certification Exam.
I read the official certification guide for this exam from Cisco Press. But, some point are still confuse for me :
1- Why WRED is most deploy on cores devices then all devices in Enterprise Network ? (The author saied :"Because WRED is usually applied to network core router....") And which implementation of congestion management system I should deploy on none core device, because thoses can also experience congestion in some point of the day and tail drop should be avoid also on thoses (distribution and access devices) devices also if I understand correctly ?
2- I understand WRED is an evolution of RED. Is still exist some reason to choose to use RED over WRED ? If WRED is available in device, is the RED is also available ? In my book in the example it say to activate WRED the command is RANDOM-DETECT, what about to activate RED ?
3- I do not understand why RED created or do not TCP global synchronisation.... (in my understand the author is contradict himself... maybe due to gate language)
When RED is not configured, output buffers fill during periods of congestion. When the buffers are full, tail drop will occur by default, and all additional packets are dropped.
RED reduces the chances of tail drop by randomly dropping packets when the output interface begins to show signs of congestion.
By dropping some packets early rather than waiting until the buffer is full, the transmission line can be used fully at all times.
In addition, RED statistically drops more packets from large users than small. Therefore, traffic sources that generate the most traffic are more likely to be slowed down than traffic sources that generate little traffic.
Weighted RED (WRED) on the other hand generally drops packets selectively based on IP precedence. Packets with a higher IP precedence are less likely to be dropped than packets with a lower precedence. WRED ensures that higher priority traffic is delivered with a higher probability than lower priority traffic.
When configuring RED you generally configure the same commands as WRED, however you configure the queue weight to me the same. Therefore a specific queue is not serviced more freqeuently than other.
Remember different platforms have different capabilities which determine the number of egress queue available for mapping your COS values.
Another thing to consider is why tail-drop is a bad thing. Tail-drop does not hurt UDP (or RTP) streams any worse than RED. However, TCP streams suffering tail-drop will cause a significant loss of efficiency due to TCP windowing. Because TCP cuts the window in half when it detects a lost packet and then slowly increase it, if a large number of streams all lose packets at the same time, all of those streams will be cut back at the same time causing the saturated line to no longer be fully utilized. This causes a 'sawtooth' effect that reduces the effective (average) bandwidth.
I understand what you explain to me : "TCP global synchronisation", but why RED cause "TCP Global synchronisation" and WRED do not ?
Also, I want activated RED on router interface which command should I use ? random-detect look like to activate WRED.
LKast thing, I also read RED and WRED are most often deploy in the core router ? Why exactly, which congestion management feature I should use in others network router if those 2 are most often used only in the core router ?
WRED provides you with more granularity when determining what traffic or application is treated as either low, medium or high priority, whereas RED does not.
For example you have SAN replication across your WAN, your primary corcern would be to ensure that drops are minimised where possible in order to reduce the overall effect of TCP synchronisation. Hence you would use WRED and ensure that the queue assocaited with the application is weighted more favourably.
WRED is extremely useful on any output interface where there is a high probability of congestion. This is particularly the case when broadcast domains are extended throughout the network using VLAN Trunking.
Thus, WRED is primarily deployed within the Core rather than the edge. Edge devices can assign IP precedence values to packets as they enter the network, and WRED can uses these precedence values to determine how it treats different types of traffic.
However, when you configure WRED to ignore IP precedence when making drop decisions non-weighted RED behavior is achieved.
Although the recommendation stipulates that WRED is usually deployed within the Core, this does include your Core routers also.
Your Core routers will ordinarily be the bottle neck within you network for all your traffic, particular in a hub-and-spoke branch network.
To clarify, there are three flavors of WRED, in additional to vanilla RED (and Distributed WRED, which is like WRED with sprinkles :)
'random-detect' turns on RED
'random-detect flow' turns on flow-based WRED
'random-detect dscp' turns on DSCP-based WRED
'random-detect prec' turns on IP precedence-based WRED
RED is truely random. Bandwidth intensive traffic flows will have more packets dropped, but only due to probability.
Flow-based WRED attempts to classify the traffic flows. It will reduce the probability of packet drops in low bandwidth traffic flows and in non-TCP based traffic flows (which do not use TCP's Windowing bandwidth reduction scheme).
DSCP-based and IP Precedence-based WRED are similiar, but have an important distinction. Both use the ToS field to determine drop probability. However, IP Precedence-based WRED on uses the first 3 bits, the IP Precedence bits, actually, and gives higher drop probability to lower priority packets; i.e. higher drop probability to CS1 (which would include AF11, AF12, and AF13) than CS3.
DSCP-based uses the 6-bit DSCP field, but ignores the first 3, which make up the IP Precendence field. Drop probability is based on the second number of the AF setting. Therefore, AFX1 will be dropped before AFX2, and AFX3 would never be dropped. This allows for a seperation between priority and drop preference. This makes sense: There may be critical traffic flows that would suffer if packet loss occurred, but can tolerate delay easily.
thanks a lot for your help !
In reading the author say if now parameter is provide to random detect command WRED will be IP Precedence based. I never see anything talking about "flow" parameter, thanks a lot for provide and the the explication.
When you talking about the drop preference like I tell you on the other post (different conversation) what I'm understand when I read what you had wrote had what I read my in books or on Cisco Web site :( http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a00800949f2.shtml (on the middle of the page)) are in contradiction....
I know you will probably have more advantage to deploy WRED than RED. But my question was if I check running configuration of a production router how can I reconnized it is RED or WRED is running ? I probably find the answer with a collegue today at the office on this Cisco page :http://www.cisco.com/en/US/docs/ios/12_1/qos/configuration/guide/qcdwred.html section : Changing WRED Parameters
my understanding if WRED is supported on the router the command "random-detect" will enable WRED rather that RED. If for some reason I still want to used RED rather than WRED I must configured WRED the drop each queue with same setting in comparison of others queues.
Your explication about why we most deploy WRED/RED on the core rather than edge is also in conflict with my reading... On BCMSN certification guide I reed we must make sure core building block should never become the bottleneck of the network, and everething should be made this possible. (not doing security policy in the core, do not mark the trafic in the core....)
Whould like to understand if I done all possibles things to avoid my core be the bottleneck how the core is still the bottleneck ?
If I only deploy WRED/RED in the core should I use some other congestion mecanism at the edge or in distribution switches ?
I find this in the same book "Congestion is a rare event within campus networks; if it happens, it is usually instantaneous and
does not sustain. However, critical and real-time applications (such as Telephony) still need the
protection and service guarantees for those rare moments. QoS features such as policing, queuing,
and congestion avoidance (WRED) must be enabled on all campus network devices where
In the last sentence the author answer to my question I tried to find the section where he's tell something different I was'nt able to find it....