I am testing tcp,voice & video over my network.What I found from WRED documentation is that WRED works fine with TCP traffic(bcauz of it's retransmission mechanism)but im a bit confused bcauz i have a mix of traffic,so my questions are:
1)Should WRED be configured on an interface which has TCP as well as UDP i.e. voip & video traffic passing through it?
2)Is WRED not suitable for an interface where we have voip & video traffic, or it doesn't support it at all?
I think that if we configure WRED is only suitable for interface that receices TCP traffic only & if there are UDP sources passing throough, it will only create problems!!
You can do one thing , if you are sure abt the traffic utilisation of your UDP and TCP traffic , then create two class maps and police UPD traffic and Use WRED on the class-map for TCP traffic .
If without using any class-maps and generally if you go for WRED in the interface , then surely your TCP applications would get a hit and UDP would make through and would keep on using a higher part of the bandwidh.
thanx for previous replies, that were of gr8 help indeed. in the light of above I beleive I should test on an interface with UDP & TCP both passing through & also WRED enabled on it,this testing i will do step by step with first tcp only traffic & then only udp & finally both of them. this will help me come to some conclusion whether WRED has any impact on UDP traffic.one thing i read in the link u fwd me was, it says its better to rely on PQ or LLQ for real-time traffic & it even doesn't recommend policing for that purpose.
anyway, my whole point is that using WRED, its may not be harmful for real-time traffic
but IP precedence may have to be defined for UDP connections so that new connections may not be denied.
You are right , WRED would not impact any Real time applications as all are UDP based .The reason for relying on the PQ or LLQ is that real time traffic need to be sent first rather than waiting in the queue for other traffic , so that the delay sensitive traffic is not affected by other traffic .
Pls clarify me on the last point of setting ip precedence for UDP connections to have a better understanding.
about ip precedence:i meant that with WRED working, just to ensure more priority to real-time applications, we can possibly alter IP Precedence accordingly,but now i would rather stick to default precedence parameters cauz all this is getting mixed up u know.
I will definately tell u some of my findings as i will be working on it whole day today.
one last thing can u send me some link regarding PQ & LLQ cauz i was actually not thinking of it before for voip & video, & was only sticking to CBWFQ.
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...