The WAF enforcer rule is automatically added first by default, but it can be rearranged - just grab the handles and put it in the request / response stack where appropriate..   See the attached picture showing how to move the rules ( I am moving the WAF Enforcer requet rule in the example screenshot):   Moving TrafficScript Rules ... View more

Q: Azure load balancer will take care of traffic distribution to these hosts. Is this a good method? A: This is as good a method as any other. Some customers use multiple public IP addresses and Use RoundRobin DNS. An advantage of the Azure LB is that you can scale the vTM Cluster size behind the AzureLB pretty seamlessly. Just make sure you are health checking your application from the Azure LB.   Q: Will the connection table on the devices in cluster will be synced across? A: Important distinction here - with vTM with an HTTP vServer there is no "connection table" as each HTTP request is atomic, and the protocol supports retry. Load balancers that DO offer state sync always tell you to NEVER turn it on for HTTP, as it more often than not kills your ADC. Net:Net answer, don't worry about "connection table" sync for HTTP.   Q: Also if we apply policies like rate limiting and bot detection, Will the decision making be done based on the traffic pattern/hits coming in from both devices in cluster? A: Here is the real question, and the answer is, it depends on how you set it up. In more detail:   1) Bandwidth Classes can be applied per connection, per vTM or per Cluster, as seen in the screenshot below:     2) Rate Classes are deployed using TrafficScript and give you ultimate control over how they are applied. If you want to leverage them between cluster members, you would need to use a data.set() function in TrafficScript to store a key/value pair that can be leveraged between vTMs (ie: if you wanted to record an IP address as having triggered a condition that means you want to rate limit them, for example, so that other vTMs could apply the same restrictions.   3) Service Protection Classes (or SPCs, which is what I think you were actually referring to in your question) are actually applied a little differently for individual settings.     a) Network Access Restrictions are  configuration element, thus the IP white/black lists are synchronised across the cluster whenever changes are made.     b) Concurrent connection limits are applied per vTM process (and vTM typically has several running per vTM instance, one per CPU core) by default. Concurrent limits are handled this way as they need to be FAST more than anything. Within the SPC Concurrent Connections  setup, you have the option to modify this default behaviour to apply per vTM Instance rather than per vTM Process on an instance.     c) SPC Connection Rates are applied per Client IP address and are applied on a per vTM basis. Typically in an active/active scenario, some form of persistance ensures all requests from a particular client are glued to a specific vTM, so the enforcement of rates don't typically need to be tracked across vTMs in a cluster. For more granular control, we use specific rate classes that can be synchronised using TrafficScript functions, as mentioned earlier.     d) SPC HTTP Specific restrictions are essentially a protocol level enforcement, so no tracking between vTMs is needed, as the config is enforced no matter which vTM instance you are talking to     e) SPC Service Protection Rules are where you get full flexibility. It is a TrafficScript that is run as part of the SPC that gives you total control, and you can set/get data to set up business logic across the cluster to do pretty much whatever you want.. I hope this helps you understand how this all works. Let us know if this fits the bill or if you need more info...   ... View more

Jochen,      Apologies for the late reply - I went back to the Engineering team for guidance, and with all the Brocade acquisition stuff, it fell off my radar. As an aside, I have raised an internal bug to have the actual setting strings logged in the message as well to make it easier to decode for administrators... Which Setting? The "HTTP Specific Settings" section has 6 attributes it can check.  Each generates a corresponding report message in the log.  The correspondences are:        http!check_rfc2396  -->  "URL broke RFC 2396"        http!max_body_length  -->  "rejected because of body data size"        http!max_header_length  -->  "rejected because of header size"        http!max_request_length  -->  "rejected because of request size"        http!max_url_length  -->  "rejected because of URL size"        http!reject_binary  -->  "contained binary data" (This is the current text in version 9.9; ) So the "rejected because of request size" message is from a violation of the "http!max_request_length" setting. Which Request? The "debug" setting in the Service Protection Class gives more information for some violations (such as http!max_header_length exceeded), but not for violations of http!max_request_length. But we can handle these requests using TrafficScript.  The documentation for "http.getRequest()" (on the TS help page https://localhost:9090/apps/zxtm/help.fcgi?section=TrafficScript%20Reference#http.getRequest) is an example of exactly this: # Check that the request is not too big # for our servers $request = http.getRequest(); if( string.len( $request ) > 2048 ) {    http.sendResponse( "413 Request too large",                       "text/plain",                       "Request too large", "" ); } So: 1. Put that in a rule, edit it to log whatever you want. 2. Set the "http!max_request_length" setting to 0 in the Service Protection class. 3. Set the Service Protection class to call the rule (section: "Service Protection Rule"). ... View more

Gaurav, Apologies for the delay in responding... This is a probably too big  a question than we can normally take in the forums, If you reply to my direct message (I just sent it now) , we will work to get you linked up with your local Presales Engineer that can help with the high level architecture... Cheers. Aidan. ... View more

Dhinesh, The documentation covers the elements you need pretty well. Manuals are available from here: SteelApp Traffic Manager I would start with the "Cloud Services Getting Started Guide" and the "Stingray Traffic Manager User Manual". Specifically, Chapter 8 in the "Cloud Services Getting Started Guide" covers how Traffic IP's work on EC2 (using Elastic IPs), but should be read after reading and understanding how Traffic IPs work on a regular STM first. Hope this helps. A. ... View more

Wagner, Are you asking if you can transport a Stingray STM license from Linux to Solaris? It will depend on what version of STM you licensed. Best bet is if you contact your SteelApp sales team, alternatively, if you want to contact me out of band (I will message you my Riverbed email address directly in just a minute) you can send me the details of your serial/license and I can look it up in the system and figure out what is possible. Cheers. Aidan ... View more

Stuart,      There is no direct way to make a system call to execute something from TrafficScript equivalent to system() or exec functions in other languages.. There are some ways in which functionality like this can be emulated but with a few caveats: 1) "Non blocking ONE-WAY" execution (ie: one where the output of the executed event cannot be processes) in a "fire and forget" fashion. This is useful for a custom alert program that something happened. Using the TrafficScript function event.emit() you can trigger a customised event that can then have an action associated with it under system > alerting to trigger an executable script uploaded to the STM "Extra Files" section (under Catalogs > Extrafiles) 2) "A Blocking Interactive" execution (ie: one where the output of the executed event can be processed). This is useful if the output of the execution needs to be processed: Using the http.request.*() TrafficScript functions, an interactive http request can be issued to a remote HTTP server that executes the needed code (maybe as a GCI-BIN for example) and returns the appropriate data/value that the TrafficScript can then parse appropriately. Be aware that the http.request.*() functions cannot be used in completion rules. Using the java.run() TrafficScript function to execute a custom Java Applet on the STM. Be aware that java.run() can only be used with TCP-based protocols and cannot be used in completion rules. Does this help? Cheers. Aidan. ... View more

Just updating this thread for the sake of completeness.  We have been working with Chris in the background through the Riverbed TAC to provide a solution to this problem. If anyone else is hitting this issue, I ask you to please create a support case with the Riverbed TAC (remembering to set the appropriate priority on the case to reflect the impact on your business). ... View more

Sameh,      the TS client functions are bolted implicitly to the VS for a very large number of reasons (ie: you can't access http headers if it isn't an HTTP vserver as the traffic has not been put through the HTTP parser) That being said, your use case of having a TS trigger an HTTP GET event (ie using http.request.get() ) from a UDP vserver is totally valid and possible.  I have used it in the past on a DNS UDP vserver to query a web service to determine what DNS record to return to a client... In fact I just tested it again to be sure and I was able to trigger an http.request.get() on a DNS vserver with every DNS query that hit it... ... View more