About markbod

markbod · ‎11-06-2014

Hi Yad, The configuration you describe would be recommended for any services which you run with IP Transparency. When IP Transparency is enabled, your SteelApp will preserve the client source address when it connects to the server. The server will then use it's default gateway to respond. This default gateway must be the server side IP Address in your Traffic IP Group. The Keep-Together option ensures that the Front-End and Back-End VIPs are always raised on the same Traffic Manager. By default IP Transparency is disabled and SteelApp connects to the server using it's own IP Address. This is probably why your testing works as expected. If you were to enable IP Transparency on the pool, then you would require a Back-End VIP and for your servers to use this VIP as their default gateway. If you do not require IP Transparency then leave it disabled. If you do want to use it, then you might also want to check out the NAT / IP Forwarding options under System -> Networking. The servers will not be able to use SteelApp as a normal router unless you enable one or more of the options there. Cheers, Mark

markbod · ‎11-05-2014

Hi Joao, The stats which are used to generate the historical activity graphs are stored in the logs/statd folder. Inside you will find a folder for your stingray containing files named <date>.log. The file is tab separated. Each line will start with a "V" for Virtual Server, "P" for Pool, or "N" for Node. The next column will be the name of the object, and then three columns for connections, bits out, and bits in. Cheers, Mark

markbod · ‎11-04-2014

Hi Naveen, NTLM usually works just fine on SteelApp too. So this is unusual. I recommended trying with Generic Client First, because SteelApp will then default to doing connection load balancing and will not attempt to inspect the protocol. You will lose the ability to do Content Caching, Compression, and other HTTP optimizations, but I guess they're functions which are being carried out by the proxy servers anyway. The "generic" protocols in SteelApp are usually for Load Balancing protocols which aren't well known or don't have any out-of-the-box optimizations in SteelApp. But they can be used in place of the more intelligent options where necessary. A Generic Client First protocol is one in which the client sends data on the connection first, HTTP fits into that category. We also have Generic Server First for when the servers sends data first, eg SMTP, and Generic Streaming for protocols where client and server can talk at any time. Cheers, Mark

markbod · ‎11-04-2014

Hi Naveen, I think we'll need to look at a connection trace and/or tcpdump of the problem to figure out exactly what is going on here. That's almost certainly information you wouldn't want on a public forum like this one, so you might want to open a support ticket. NTLM authenticates the TCP connection between the client and the server. So SteelApp maintains a persistent connection whenever it detects NTLM is in use. If the persistent connection is dropped, then it can lead to the user being prompted to re-enter their password. Checking edition.cnn.com I see that the front page pulls in resources from over 20 different hosts. I don't know, but I wonder if SteelApp links the Host with the NTLM session in some way? I presume that you have the protocol set to HTTP on SteelApp currently? Does the problem go away if you change it to "Generic Client First"? Cheers, Mark

markbod · ‎11-03-2014

The SteelApp GLB (Global Load Balancer) performs global load balancing by manipulating DNS responses to clients. The load balancing algorithms available include round-robin, weighted, active/passive and load based. SteelApp also supports making the decision based on geographic proximity. An extension to DNS known as the Client Subnet Option (CSO) has been drafted by the IETF. The draft: draft-vandergaast-edns-client-subnet-02 is now at version 2.0 and is currently being used by Google and some other large DNS providers. The Client Subnet Option adds an additional DNS Extension record (EDNS0) into requests which are sent to authoritative name servers. This additional record allows recursive DNS servers to add in the originating client IP subnet into the request. The authoritative name server may then provide an optimized response. The SteelApp GLB does not natively understand EDNS0 records at present, but we can detect the presence of the CSO extension using a simple TrafficScript. The script can then modify the request in such a way that the GLB will use the CSO in its decision making process. Here's the TrafficScript: #=-To log resolver, use macro: %t %v %h %A:%p %n %B %b %T %{resolver}d # Set verbose to 1 to enable logging to event log, 0 to disable. $verbose = 0; # EDNS0 OPT Code 0x0 0x08, Len 0x0 0x07, IPv4 family 0x01, length 24bits 0x18, mask 0x0 $csoBytes = string.hexdecode("0008000700011800"); $resolver = "-"; $data = request.get( request.getLength() ); $end = string.skip( $data, string.length($data) - 11 ); if ( string.startswith($end, $csoBytes ) ) { $cs = string.skip($end,8); $client = string.bytesToInt(string.substring($cs,0,0)) . "." . string.bytesToInt(string.substring($cs,1,1)) . "." . string.bytesToInt(string.substring($cs,2,2)) . "."; $resolver = request.getRemoteIP(); $resolverOctets = string.split($resolver, "."); if ( $verbose ) log.info("DNS Request with CSO. Resolver: " . $resolver . ", Using Address: [" . $client . "]" . $resolverOctets[0]); request.setRemoteIP( $client . $resolverOctets[0]); connection.data.set("resolver", $resolver); } The script looks for the CSO data at the end of the incoming DNS request. If a record is found, then we use the address specified as the client IP when making our GLB decision. However the CSO only includes the first three octets of the clients address. The idea is for the resolver to give the name server enough information about the client to determine its region, without divulging the full IPv4 address. Unfortunately we need a full IP address for GLB, so the script uses the first octet of the resolvers IP as the last octet of the clients IP. Why not? If you prefer you could just hard code the last octet. An exercise for the reader. The rule stores the resolver address in connection memory so that you can log both the resolver and the address from the CSO by using the following request log log!format macro: %t %v %h %A:%p %n %B %b %T %{resolver}d Optionally, enabling $verbose will cause the script to write an event to the standard event log whenever it receives a request containing CSO information. This rule needs to be applied to your GLB DNS service as a request rule. Enjoy!

markbod · ‎11-03-2014

Hi Fahim, If you are pushing everything through a proxy, then you can remove the forward proxy "pool.use(pool, host, port) and replace with pool.use(proxypool). Then specify the proxy(ies) in the pool itself. You will also need to convert the standard HTTP requests into proxy ones. For example if your request is for "/bar.jsp" and you want to use the external host "http://www.foo.com:8080/bar.jsp" then you should set that in the path with http.setPath(). You might also want to set a proxy-connection header. EG http.setHeader("Proxy-Connection", "Keep-Alive"). The proxy will then do the rest. Cheers, Mark

markbod · ‎10-31-2014

Hi Dimitriy, Having a SteelApp in Amazon would allow you to load balance and optimize the application itself. The SteelApp would also run the Steelhead discovery agent and detect any Cloud SteelHeads you have deployed alongside the SteelApp. The SteelApp should then use the local Cloud SteelHead to optimize the traffic between Amazon and the SteelHead on the east coast. Cheers, Mark

markbod · ‎10-31-2014

Microsoft Direct Access is a VPN replacement technology which provides seamless connectivity for mobile users (remote employees) back into the corporate network. Unlike traditional VPNs, Direct Access is integrated directly into the Windows Operating System, and will attempt to establish a connection whenever an internet connection is available, and without the need for any user interaction. This document provides detailed instructions on deploying SteelApp Traffic Manager to load balance Microsoft Direct Access

markbod · ‎10-31-2014

Hi Gary, I've just checked and it would seem that there is not a Control API for creating new groups and/or altering a groups permissions. As you have discovered the User/Group functionality is currently limited to: listUsers listGroups addUser deleteUser changePassword I could open an enhancement request for you, but it would be better if you could open a support ticket and make the request yourself. This helps us to keep track of the number of users requesting each new enhancement. Cheers, Mark

markbod · ‎08-19-2014

HI Fahim, This has always been the case for monitors in SteelApp up to and including the current release (9.7). With SteelApp you can add multiple monitors to pools, and for that reason it must be the same monitor which fails/recovers the node. For example; you wouldn't want a ping monitor recovering a web server after it had been failed by a Full HTTP monitor. We do cover this in SteelApp training course material, but unfortunately (it seems) not in the user manual. I have raised a documentation bug to have the monitoring section expanded to include information about the node recovery process. I can only apologies for the inconvenience this has caused you. Cheers, Mark

markbod · ‎08-19-2014

Hi Fahim, Are you sure SteelApp shows the node has recovered? I suspect that it is the passive monitor which marked the node as down, and so it is the passive monitor which must recover it. The problem is that all traffic is being responded to by the TrafficScript rule and unless a request makes it back to the server it will never recover. I would recommend trying one of the following approaches (in no particular order): Allow requests from the local network to bypass the rule, then use event.emit() to launch an asynchronous script which makes a request to the index page of the site. Instead of responding in the request rule use "request.setMaxReplyTime(1)" to set a 1 second reply time on the pool. Then allow the request to the backend. The short reply time will timeout the node quickly and you can then either use a response rule to deliver your maintenance page or set an error file on the virtual server. Modify your rule to allow a percentage of the requests through to the back end. Use a small 1x1 blank gif on the maintenance page and exclude that from the maintenance page rule. Optionally set a short timeout on this request. If we went for the last option of using a blank.gif to bypass the rule, it might look like this: sub handleMaintenancePage( $pool, $page ) { if( pool.activeNodes( $pool ) < 1 ) { log.warn( "No active nodes for pool ". $pool ); if ( http.getPath() == "/blank.gif" ) { request.setMaxReplytime(1); break; } contents = resource.get( $page ); http.sendResponse( "200 OK", "text/html", $contents, "Pragma: no-cache\r\nCache-Control:no-cache\r\nExpires:0" ); } } If you are always delivering the same maintenance page for this VirtualServer, then you could set the resource as an error page under "Connection Management" for the Virtual Server, and then it will be used automatically. No TrafficScript required. Cheers, Mark

markbod · ‎04-10-2014

Hi Munim, The language is designed to have a look and feel of perl, but it is written from scratch specifically for the Traffic Manager. However we do use the PCRE standard for regular expressions, so it's very much like perl in that regard too. For more information, check out Owens post here: https://splash.riverbed.com/people/owen/blog/2012/07/03/trafficscript--why-create-a-new-language-08162010 Cheers, Mark

markbod · ‎04-10-2014

Hi Clinton, Your scipt is missing any code to get the username/password from the client. An example using HTTP Basic Authorization, would require something like this to be added before you run the auth.query(): $authHeader = http.getHeader("Authorization"); if ( string.startswith($authHeader, "Basic") ) { $decode = string.base64decode( string.skip($authHeader, 6) ); $userpass = string.split($decode, ":"); } else { http.sendResponse("401 Auth Required", "text/plain", "This resource is protected. Please log in", "WWW-Authenticate: Basic realm=\"Secure Area\""); } $user_name = $userpass[0]; $password = $userpass[1]; Cheers, Mark

markbod · ‎11-06-2013

When you import a rule into another then it's functions can be executed by the rule importing the code, but the imported rule itself is not executed directly. If you want to count the number of time a path is traversed vs total number of requests, then you could use counter.increment(), using one counter for all requests, and a second for the path you are interested in. the values of these counters can then be read using SOAP, SNMP or the ZCLI, and they can be graphed in "Current Activity". Cheers, Mark

markbod · ‎11-06-2013

Hi Shannon, If you suspect the connections are jumping between servers, then you could try adding a SSL Session Persistence class to the pool. Under Catalog -> Persistence create a new class using the "SSL Session ID Persistence" and then apply this to the pool. You probably also want to increase the timeout value of the virtual server under Connection Management -> Timeout Settings so that connections can be idle for longer. Cheers, Mark

markbod · ‎11-06-2013

Hi Shannon, Did you follow the steps covered in Stingray Traffic Manager Solution Guide: Microsoft Exchange 2013? Cheers, Mark

markbod · ‎11-05-2013

Hi David, Blocking countries is relatively simple using the geo.* functions in TrafficScript along with connection.close() or http.SendResponse(), but counting the countries first and writing them to file is a little more complicated. You can't write to files directly with TrafficScript, but you could create an alert and event under System -> Alerts which writes to a file and then call event.emit() within TrafficScript. However that's not very efficient, and you wouldn't want to call it on every request. So you would probably need some code which stored the data in memory using data.local.set(), and then fired off an event.emit() or even a log.info() once an hour. This example uses log.info() to write the stats to the standard event log once per hour. The stats are recorded using the per process memory store so you will get a count for each Stingray child process (ie one per cpu core in your machine), and you'll need to be running Stingray version 9.4. sub flushCodes() { $codes = data.local.get("CountryCount-Codes"); foreach ($cc in string.split($codes)) { $count = data.local.get("CountryCount-" . $cc ); $log .= $cc . ":" . $count . " "; } data.local.reset("CountryCount-"); data.local.set("CountryCount-lastFlush", sys.time() ); log.info("CountryLog " . $log); } $cc = geo.getCountryCode( request.getRemoteIP() ); if ( ! $cc ) { $cc = "UNKNOWN"; } $count = data.local.get("CountryCount-" . $cc); if ( ! $count ) { $codes = data.local.get("CountryCount-Codes"); if ( ! $codes ) { $codes = $cc; } else { $codes .= " " . $cc; } data.local.set("CountryCount-Codes", $codes); $count = 0; } data.local.set("CountryCount-" . $cc, ++$count); $flush = data.local.get("CountryCount-lastFlush"); if ( ! $flush ) { data.local.set("CountryCount-lastFlush", sys.time() ); } else { if ( sys.time() - $flush > 3600 ) { flushCodes(); } } Alternatively you could use the Request Logging feature of the Virtual Server, and record the country code from a TrafficScript variable. Then post-process the log to count the incidence of countries later. Cheers, Mark

markbod · ‎11-05-2013

Hi tpoise, Stingray will only return a "304 not modified" if you include a "If-Modified-Since" header with your request. [email protected]:~$ curl -i -H "If-Modified-Since: Mon, 18 Mar 2013 10:51:38 GMT" http://stingray1/ HTTP/1.1 304 Not Modified Date: Tue, 05 Nov 2013 00:12:14 GMT X-Cache-Info: cached However if you include the header, but the item is not already in Stingrays cache, then Stingray will need to forward the request to a node in the pool. The node may then respond with a 304 of its own. As the 304 does not include the actual content body, it is not cachable. How were you requesting the files when you saw only 200 responses? Try again and be sure to include an If-Modified-Since header. You will need to send at least one request through without the header to populate the cache first. In any case the 304 responses aren't really desirable either. What you actually want is for the browser not to request the content at all, and that can be achieved by setting a correct "Expires" header in the response. A browser will not re-request content while the content has a proper future expiry date. The below TrafficScript sets a Cache-Control and Expires header based on the Content-Type of the response, and will stop the browser making requests for that content until after it has expired. $ct = http.getResponseHeader("Content-Type"); if ( string.startswith($ct, "text/html") ) { $age = 10; } else if ( string.startswith($ct, "text/css") ) { $age = 172800; } else if ( string.startswith($ct, "text/javascript" ) ) { $age = 172800; } else if ( string.startswith($ct, "image") ) { $age = 172800; } else { $age = 60; } $expire = sys.time() + $age; http.setResponseHeader("Cache-Control", "max-age=" . $age ); http.setResponseHeader("Expires", sys.gmtime.format( "%a, %d %b %Y %T GMT", $expire)); In this example: html pages are cached for 10 seconds, images, javascript and CSS are cached for two days, and all other content is cached for 60 seconds. Cheers, Mark

markbod · ‎10-01-2013

Hi Jon, If the RSA server is returning a 500 then it's obviously not liking the request we're sending. Do you still get a 500 when you request "/console-selfservice", and are you rewriting the host name to match the node? I presume you only have one active node in the configuration, because other docs suggest that only one server can be written to at a time. You should have a pool with the primary in it, and a secondary pool with the backup. The secondary pool should be set as a failure pool of the primary. some other pointers which may help You don't need a rule to rewrite the cookie. Remove it. Instead go to Services -> Virtual Servers -> Your VServer -> Connection Settings -> Cookie Settings and set "cookie!domain" to "rewrite the domain to the host header in the request". You also don't need to worry about rewriting redirects. Still under Connection Settings look at "Location Header Settings" and for "location!rewrite" select "Rewrite the hostname to the requests host....." In order to ensure you are setting the correct hostname when you switch to the backup you can use pool.getActiveNodes() to determine if the primary pool has failed and start setting the hostname to the secondary when it does. You may be able to determine whether a request is a read or write and route to primary or secondary based on the request type, but that would require further investigation. If you still can't get this running, then you may want to contact your Riverbed account manager about getting assistance from PS. Cheers, Mark

markbod · ‎10-01-2013

Hi Kevin, There is a description of each OID in the MIB itself, eg: perPoolNodeResponseMean OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Mean response time (ms) in the last second for this node." ::= { perPoolNodeEntry 19 } nodeInet46IdleConns OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of idle HTTP connections to this node." ::= { nodeInet46Entry 19 } The nodeInet46IdleConns show the idle connections per node, and groups the nodes into v4 (...1.4) and v6 (...2.16) address classes. So an IPv4 web server (10.1.1.1:80) would be prefixed with a 1 for IPv4 and 4 for it's octet length... .1.3.6.1.4.1.7146.1.2.4.4.1.19.1.4.10.1.1.1.80 Cheers, Mark

markbod · ‎10-01-2013

Hi Jon, You don't mention it, but when you enabled the SSL decrypt on the Virtual Server, did you enable SSL encryption on the pool? If the "Service Unavailable" message is in Red, then it's likely the default error page from Stingray. If you are not re-encrypting on the pool then Stingray will be trying to talk HTTP to a HTTPS service resulting in service failure. Cheers, Mark

markbod · ‎09-27-2013

Hi Andrew, If you tell Stingray to restrict management to a single IP, then yes. Unfortunately this is set during initial configuration and can't be changed through the UI. The easiest way to change it would be to execute: /opt/zeus/zxtm/configure and chose option 2 to "perform the post-install configuration again". When asked if you want to restrict management to one IP, say (Y)es. Caution: Your STM will be restarted during this procedure. You can also set it using the REST API, but not until the next release of Stingray. Doing it in 9.3 and below may break cluster communication. An alternative work around would be to change the port the SSH daemon is listening on or disable it completely. You can find those settings under System -> Securty -> SSH Server Cheers, Mark

markbod · ‎09-27-2013

Hi Bruno, HTTP will require a two <CR><LF> at the end of the request, and HTTP/1.1 will require a Host header. Try changing your ping to: my $ping = "GET / HTTP/1.0\r\n\r\n"; OR my $ping = "GET / HTTP/1.1\r\nHost: www.foo.com\r\n\r\n"; Cheers, Mark

markbod · ‎09-16-2013

Hi Adrien, This is not a forum for technical support. I would suggest that you open a critical P1 ticket at the Riverbed Support site, https://support.riverbed.com or call the support line. Cheers, Mark

markbod · ‎09-09-2013

Hi Bruno, Try the below perl script. It doesn't require a TrafficScript rule, it simply connects to the address given by the stingray monitor process on the port specified in the $port variable. #!/bin/sh exec $ZEUSHOME/perl/miniperl -wx $0 ${1+"[email protected]"} if 0; #!/usr/bin/perl #line 7 BEGIN { unshift @INC, "/usr/bin/perl", "$ENV{ZEUSHOME}/zxtm/lib/perl", "$ENV{ZEUSHOME}/zxtmadmin/lib/perl"; } use strict; use Zeus::ZXTM::Monitor qw( ParseArguments MonitorWorked MonitorFailed Log ); use IO::Socket; my %args = ParseArguments(); my $port = 4567; my $retcode = 1; my $ping = "PING\r\n"; my $pong = "PONG"; my $socket = IO::Socket::INET->new(PeerAddr => $args{ipaddr}, PeerPort => $port, Proto => 'tcp'); die "$!" unless $socket; $socket->autoflush(); $socket->print( $ping ); my $resp = $socket->getline(); if ( defined($resp) && $resp =~ /$pong/ ) { $retcode = 0; } if ($retcode == 0) { Log("Monitor Passed, Host: $args{ipaddr}, PORT: $port, PONG: $resp"); MonitorWorked(); } else { if ( defined($resp) ) { MonitorFailed("PORT: $port, PONG Response: \"$resp\""); } else { MonitorFailed("PORT: $port, PONG - NO Response!"); } } exit $retcode; Ensure that you set $ping to the request string, and $pong to the response you expect. Cheers, Mark

markbod · ‎09-04-2013

Hi Gael. Keep it simple... Try this... if ( http.getPath() == "/" ) { http.redirect( "http://www.riverbed.com/mainApp/" ); } Change site will preserve the path, but the root folder is always "/" so it doesn't add any benefits. Cheers, Mark

markbod · ‎08-15-2013

Hi Eduardo, Your assertions about option 1 are correct. The only options you have when deploying a node using STM Auto-Scaler in Amazon are the imageid and the instance type. You can not set any other options with the built-in module. There is an open feature request for enhancing this module, so if you send me a private message with your account information I can add you as an interested party. With regards to the second option. If autoscale!external is set to yes, then STM takes no part in provisioning nodes or modifying the pool configuration. It essentially just allows you to create an empty pool. You need to manage the scaling of the nodes outside of STM, and have a workflow that updates the pool configuration when changes are made. The REST and SOAP APIs are the most obvious ways to update the pool configuration, but you could also write a script for the zcli if you wish. Cheers, Mark

markbod · ‎08-14-2013

Hi Machi Ma, It is not necessary for you to install the Stingray kernel modules manually. The Virtual Appliance ships with both the IP Transparancy and multhosted TIP modules installed. You just need to enable the feature on the pool, and the VA will load and use the module automatically. The service unavailable message is probably being show because the server is not routing the return traffic back through STM. When using IP Transparency the STM must be default gateway of the servers. Or at least be the default gateway for the server to reach client networks. If you are testing this with the client and server on the same network, then it almost certainly wont work. Cheers, Mark

markbod · ‎08-07-2013

Hi Sukie, Stingray supports synchronization of persistence data, so that if you are running active/active STM instances or should your cluster fail over, then any client-node persistence should be maintained. However the actual TCP connections will not be. The clients will need to reconnect. Stingray operates as a Layer 7 proxy, and does not synchronize TCP sessions. The overhead of doing this with a Layer 7 ADC is very high, and the probability of it actually working would be quite low due to timing and race conditions. Vendors which do have synchronization typically only recommend it for simple L2-L4 services, and not where full Layer 7 ADC functions are in use. Cheers, Mark

markbod · ‎08-07-2013

Hi Felix, See -> Re: Set header with Generic Streaming Protocol? Cheers, Mark

Re: Active Passive Keeptogether

Re: How to get the Historical Activity from the co...

Re: Baracuda proxy with NTLM authentication across...

Re: Baracuda proxy with NTLM authentication across...

glbcso.rts: Making use of the Client Subnet Option...

Re: Setting up a proxy for ZXTM

Re: What is the best way to optimize my infrastruc...

Riverbed SteelApp Deployment Guide for Direct Acce...

Re: ZCLI command to view and alter user group perm...

Re: pool.activenodes() is reliable?

Re: pool.activenodes() is reliable?

Re: Which language is inherited for TrafficScript ...

Re: User authentication - please help - traffic sc...

Re: Count Rule processing

Re: Request For Assistance.....

Re: Request For Assistance.....

Re: Can i write to a file from Traffic script

Re: Content Caching does not respond with HTTP 304...

Re: Re: Publish RSA self-service console via Sting...

Re: Is there a detailed definition of the various ...

Re: Publish RSA self-service console via Stingray ...

Re: Load-balancing SSH through stingray

Re: Health Check on a different port

Re: Stingray Crashed

Re: Health Check on a different port

Re: Re: Stingray - traffic script - HTTP redirecti...

Re: How to configure Stingray AutoScaling at Amazo...

Re: Kernel Modules for IP Transparency Module runn...

Re: Session synchronization

Re: Stingray IP Transparency Solaris