November 2008 Archives

NetScaler 9 is officially here. Well, actually, it's officially announced. It won't be officially available to download from mycitrix.com until November 27^th. Yes, I know that's Thanksgiving. However, Citrix is a global company, and what better way to prove it than to post the NetScaler 9 code on a major US holiday? And, there is a chance that it might show up a day or two before the 27^th.

NetScaler 9 is a pretty big release. Looking at the detailed feature tracker, it contains over 350 new features and feature enhancements. I'm not going to go through all of them in this post, because that's what release notes are for. However, I do want to highlight some of the major new features that folks seem to be most excited about, and point you to some additional resources on this site that go into a bit more detail on some of them.

I like to think that NetScaler acts as the bridge between the network and the applications that run on it, making each of them work better with the other. NetScaler 9 furthers this.  A lot of the new capabilities and features making NetScaler more application-saavy than it already is. This is not to say that there aren't any hardcore networking enhancements in NetScaler 9, because there are a lot of them. These include everything from end-to-end support for IPv6 to enhancements to our GSLB functionality to the ability to tunnel IP within IP.

But in the end our networks are there to run applications, and it's the new AppExpert features in NetScaler 9 that seem to be generating the most interest.

AppExpert Templates make a given application the "first class citizen" within NetScaler. They do this by encapsulating everything about a NetScaler configuration that is specific to a given application, including:

All of this is presented in a way that puts the application front and center, and configuration and policy changes can be made from there as well. So, while today understanding the entire NetScaler configuration for Microsoft SharePoint (for example) involves moving around between the various NetScaler GUI tabs, with AppExpert Templates everything is centralized in one place.

AppExpert Templates can be imported and exported as well, so they make it pretty easy to move app-specific configurations between different systems. More broadly, several folks have told us that this, and the general look and feel of AppExpert Templates, will help with knowledge transfer within their organizations. You can see an example of the Microsoft SharePoint template being imported and then applied here.

If you go here when NetScaler 9 becomes available in a couple of weeks, you'll be able to download AppExpert Templates we've already built. And, as you'll quickly notice, AppExpert Templates aren't static. The underlying infrastructure makes it really easy for you tweak a template to your own specific needs, or to improve the template by adding to it. Hopefully, you'll all post any improvements and modifications you make back to the community site so that others can benefit. And definitely look for additional AppExpert Templates to be made available by us, but Citrix partners, and hopefully by other NetScaler users.  

With AppExpert rate controls, we've integrated the concept of data rate into the core NetScaler policy infrastructure.  This allows building policies that are only triggered when a defined data rate is exceeded.  And since it's integrated with the core policy infrastructure, it can be used with the various NetScaler functional modules (e.g., content switching, responder), so you're not limited to just dropping traffic as an action.

There's a number of ways folks have told us they're going to use AppExpert rate controls. Of course straight-up rate limiting (e.g., DNS rate-limiting, limiting traffic originating from a single subnet) is one example. Ensuring a given resource (e.g., anything from a VServer to a specific URL) isn't overwhelmed by requests is another. Two specific examples are:

1. One customer allows some of its partners to scrape its website so the partners can republish content on their own sites. However, the customer wants to ensure that overly aggressive scraping by the partners doesn't overwhelm the website and degrade the site's performance. AppExpert rate controls can be used to limit how much scraping each partner can do. This same approach could be used to ensure that websites that publish APIs -- so that partners can do mashups, for example -- aren't overwhelmed by any particular partner's use of the API.
2. Another example is a customer that was having problems with a couple of users FTPing a few too many large files at the same time. By using AppExpert rate controls to build an expression around bandwidth consumed per sourceIP, they can drop any additional FTP requests coming from a sourceIP (aka a user) that already has too much FTP activity. A more generalized use could also do something along the lines of limiting the amount of concurrent file downloading for a given SharePoint site, to ensure that downloads don't drown out other SharePoint (or other application) activity.

AppExpert service callouts make NetScaler policies extensible, and will allow you to integrate logic or functionality available in other systems and applications into NetScaler policies. Specifically, using an AppExpert service callout, a policy can send (over HTTP or HTTPS) any part of an incoming request to an external service. The result returned by the external service is then used like any other policy evaluation result.

As an example, one beta customer has an application that identifies and tracks IP addresses that are scraping its site's content. No, this is not the same customer that is interested in AppExpert rate controls. In earlier case, scraping is encouraged, they just needed to control it. In this case, the scraping of content amounts to theft, and the customer want to prevent as much of it as possible. Unfortunately, the IP addresses doing scraping change constantly (hence the reason they had to build an app), so statically defining them within the policy itself isn't practical. However, a service callout can query the application in real-time, and NetScaler then uses the response to either pass or drop the request.

Other use cases customers have mentioned include:

• Passing content to an external transformation engine
• Integration with UDDI or other directory services
• Geo-targeting or other token-based switching decisions, where the logic for the content switch is available in an external application  

NetScaler 9 has the first availability of the XML technology we acquired from QuickTree last year. New XML protections in the NetScaler Application Firewall module will now be able to inspect and protect XML as well as HTML traffic. In addition to protecting XML-based applications from attack, this can also be used to ensure that incoming XML traffic conforms to various standards (e.g., XML syntax, schema, WSDL validation). With XML, sometimes "bad" traffic isn't malicious but is just a mistake. Either way, the XML capabilities in the app firewall will catch it.

We've had the ability to rewrite payloads within the TCP header or payload since NetScaler 8.0. However, in NetScaler 9.0 we've added a URL transformation 'mini-module' to our generalized rewrite functionality specifically for rewriting HREFs. While this function is often thought of in the context of either SSL VPN or application firewall, it has uses beyond these as well. For example, onboarding apps acquired through M&A activity, simplifying change management or "Akamai-zing" graphics content.

Again, NetScaler 9.0 is big release. There is a lot more than the app-centric things mentioned above. There is a pretty comprehensive What's New in NetScaler 9 writeup here for those of you that want a more comprehensive overview.