12 Replies Latest reply: Feb 16, 2017 7:53 AM by Guillaume 74 RSS

How do I determine what traffic is being classified by a QoS class?

Nik Sheridan

Hi forum!

 

We use the in built traffic definitions on out steel heads to make classification easier.

I know I can see a graph of the class usage in reports, but by blazes, how on earth does one find out the traffic being categorised?!?!?!?

We got a sneaky suspicion the built in definitions might not be right!

This one has almost blown our socks off here!!!

  • Re: How do I determine what traffic is being classified by a QoS class?
    Guillaume 74

    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

    QoS_cnx.jpg

     

     

    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.

    • Re: How do I determine what traffic is being classified by a QoS class?
      Nik Sheridan

      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!?!??!?

       

      OMG

  • Re: How do I determine what traffic is being classified by a QoS class?
    Mitchell Kotler

    I know this solution may not be what you're looking for or will not scale but you can create a custom Application that matches your pass-through traffic. Next, create a QoS rule using that customer App and tie that to a QoS classification that you also create.

  • Re: How do I determine what traffic is being classified by a QoS class?
    Dustin Burke (Riverbed TAC - Senior EE)

    Good morning,


    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!


    Dustin