That's not so easy to check QoS is running properly just on Steelhead.
For each optimized connection you can see in "Report / current connections" which QoS class is matching
But this does not work for passthrough connections
So this is really painfull to check if QoS works properly. We have many Interactive of RealTime traffic in passthrough as it can't be optimized, but we can't check if it fails in the right QoS class.
If you have Cascade, you can debug with it, if not, you will have to take tcp dump on the steelhead and then analyse it.
There is a Feature Request here since many years, we are asking to also have the QoS Class displayed even for non optimized connections, but Riverbed seems to be deaf on this.
I guess there's the real question: how can I analyse it with a TCP dump if I cannot use a match criteria of the application recognition when this match criteria used by a steelhead is not supported by TCP dump.
This in effect makes me work on an assumption that my TCPdump match criteria is equal to the steelhead in built match criteria (namely the application recognition). This assumption is not precise enough for me to be confident. So what's left? Pairing up a conversation pair with application recognition so you know you're not getting any noise? Then you validate the interpretation of the flow correctly?
Call me old fashioned but how can I be confident in inbuilt application recognition if I cannot validate it's working properly? Reiverbed sort it out. This is not a new request.
Isn't this kind of application recognition the main driver for the price of the product? If it is not interpreting the QoS class correctly, and uses the same categorisation method for optimization then what else is being missed!?!??!?
By default, the QOS rules apply to both optimized and pass through traffic. I have read the posts above but to be clear, the Steelhead platform's main purpose is to optimize or not optimize. As I read earlier posts, our SteelCentral product is designed for a more granular approach to what you are asking.(The reason is that not 100% of RB customer have steelheads. Some of them have only SteelCentral and so on).
It would be like comparing the router with firewall capabilities to an actual firewall. Yes it is nice to have everything on 1 product, but it's better for the router to do what it is supposed to do, which is route traffic and let the firewall do what it is designed for which is to block/allow traffic (among other things).
I see what you are saying with the cost, but offloading some of the processes used in reporting is a smart way to not try to kill the original device . For instance, if the steelcentral product dies, you still still have optimization which by far trumps anything relating to reporting functionality.What you could do is ask for an eval license for steelcentral to see if its something that you would like. Never hurts to try!
TCPdump is always the tell-all because it tells what is going on at the packet level through the wire if you do not want to use the Steelcentral product or have concerns of the current architecture of steelhead reporting. (Mitchell had a good idea also).
Reach out to me directly if you have any other concerns. I am always happy to help!
if you can push somewhere, just to have visibility of which class is matching for PassThroug connection, same as optimized that would help us a lot for debugging QoS.
I already asked this to all product managers I met at Riverbed, they all told me : yes that's a nice idea and then never heard anything about it.
That is a great point. What you could do is as your Riverbed SE for a feature request on a custom RIOS build. I know some customers want a little extra to a feature that already exists and I think that would fit this mold here. Normally the custom builds are for bug fixes, but it certainly wouldn't hurt to ask since it is not already incorporated into the normal download.
If you don't want to invest on a new platform such as Steelcentral, it would be a fair ask.
We also asked for it to our SE......
We don't want a custom build as this can be useful for all customers. We are currently running with a custom build because of a bug fix, but for a new feature I prefer to get it in the standard build.
I'm also using Cascade (Steelcentral something now), I can check the QoS from there , but there is a delay , you have to wait flow export, then run a report, so you cannot debut real time.
For debugging, you just need to know if your QoS is matching properly or not, we need to have it in the connections same as the optimized one.
And it is very important because many Pass through are interactive or Real time traffic on which you must be sure the right class is matching.