07-21-2009 03:11 PM
QoS is currently enforced based on the pre-existing DSCP marking, even if the Steelhead has been configured to re-mark the DSCP value. That means you must make sure your VoIP packets are marked beforehand, at an upstream device before they reach the Steelhead, if the traffic is to receive the correct QoS.
We are thinking of changing this in the future as part of a major release, but that is how it currently works today.
Josh
07-15-2009 04:53 AM
Hi,
The DSCP marking of the packets at the WAN edge is to allow QOS through the global WAN cloud and remote WAN\LANs in other regions.
Just wanted to be 100% sure the Steelhead QOS marks packets before applying the QOS rules. Otherwise using DSCP recognition in the QOS Rules would not work.
Have not found any documentation relating to how a packet is processed (order of different processes, QOS marking, inpath rules, HSTCP\MXTCP, QOS enforcement) from LAN to WAN interface.
Have you seen any?? Most of the documentation tells you how to configure and available options. Not a general flowchart from start to finish.
Fabs.
07-15-2009 01:55 AM
Hi
Not sure I understand you correct:
You mark incoming packets on the steelhead with DSCP Values and use these Values on the same Steelhead for QoS Descissions?
If so, that's not neccessary.
The DSCP Stuff in the QOS Rules are useful, if you receive packets with already set DSCP Values (i.e. the DSCP Value is the only thing to differentiate).
If you don't have that situation, you don't need to tag, just do the QoS Stuff and you're done
Andre
Jabber: andre@dieball.net
07-09-2009 06:32 PM
RIOS 5.5.1a
In relation to data flowing from LAN to WAN Interface. Does the QOS Marking process happen before the QOS Classification\Enforcement process?
I have configured a remote steelhead with a QOS configuration that would mark outbound packets with specific DSCP values and QOS rules that look for these DSCP values to classify into QOS classes.
This allows VoIP pre-marked packets to flow into the correct class and a cleaner configuration rather than having separate QOS Marking and QOS rules that classify the same traffic types.
Solved! Go to Solution.
© Copyright 2012 Riverbed Technology. All rights reserved Riverbed.com | Contact Us | Technical Support | Terms & Conditions | Privacy Policy