A new day, a new dawn, a new…version
Happy Friday folks! I’m happy to report in that so far this morning I’ve been reading up on the latest version of LTM (10.2.1) that just got released, while rocking out to some (probably too loud) tunes, of course. The new version is a dot release, so it’s largely improvements and fixes, but there’s some very groovy stuff in there. Here are a couple good ones: Application templates This release includes one new application template and one upgraded application template. An application template corresponds to a particular application, such as email access, and provides a fast, efficient way to configure the BIG-IP ® system to process the associated traffic. The new and upgraded application templates provided in this release are: App templates are going to be huge. This is just the first taste, trust me there is a lot more coming on this, and it’s something to keep your eye on. Right now they’re a quick way to get things configured for particular applications, but depending on how these unfold I could see it being a lot more, so we’ll see how that goes. NEBS support This release adds support for the new Network Equipment-Building System (NEBS) compliant version of the BIG-IP ® 11050 platform, and a NEBS-compliant version of our latest high performance blade (PB200) for the VIPRION ® platforms NEBS compliance is a pretty big deal to some folks, so it’s definitely good to get the top end platforms in line with these requirements. There were also a few fixes put in that are nice to see, and a couple iRules changes near and dear to my heart as well: TMM with iRules and CMP (ID 225747) Enhancements have been made to the Traffic Management Microkernel (TMM) with respect to iRules ™ and clustered multi-processing (CMP). Log messages for pool member status changes (ID 324272) Log messages for pool member status changes are no longer throttled, so that the system reports all pool member status changes. Data get and respond iRule commands on CMP systems and tmm (ID 324335) When using the ACCESS::session data get and ACCESS::respond combination in an iRule on systems with clustered multi-processing (CMP), the tmm service could have become unresponsive. This has been resolved. As you can see, these are all good things. I know it’s not as sexy as saying “HOLY COW LOOK AT ALL THE AMAZING NEW FEATURES!” but hey, even maintenance releases need some love. Go check out the release notes for complete info, and enjoy your Friday. #Colin
Some Days, A Reminder is all You Need.
My eldest son has been having car troubles. To be more direct, he needed a new car. We agreed to help him out financially, let him go do his shopping and comparing, and when he chose a car I took him to pick it up. He chose a used PT Cruiser to replace his worn-out Olds Achieva, and on the way home, tried to familiarize himself with the features of the new car. Anything that the Achieva didn’t have and the PT Cruiser did, he found to be odd to him. And I pondered that as I drove him to pick up the poor old Achieva and send it to its final resting place. We all do that. We get a shiny new toy, and then play with the features we were excited about when we chose it, or with the features that are somewhat familiar. In any complex system – cars or networking gear – we tend to lose some very cool bits in the conversion. But some of those bits – like the heads-up display in his new car – can be a boon that offers him information he didn’t have. In high-tech, there is plenty of that type of thing also. We’re all talking a ton about Cloud and the revival of SaaS in the down economy, and for me at least, WAN Optimization. These discussions leave us forgetting that there is a technological basis for these tools. But of course, these important topics are well below the radar when some of the cool stuff that comes out-of-the-box with F5 gear is being looked at (profiles for example, are high-level and very useful, so they draw admins eyes). This post is your friendly reminder that there are features on your F5 gear that could be garnering you a lot. I normally like to present a problem or issue, then talk about solutions. Sometimes those solutions include F5 gear, sometimes they do not. This time I’m going to just talk about some of the less obvious features of F5 gear that are there for you – all for free with the product – that you could be taking advantage of to automate your environment or improve your Application Delivery Architecture. If you’re not an F5 customer, well this is stuff that might change your mind, and if you are, you already have them in your building (or you can download them for free), so you should check the ones you are not familiar with out. I’m a geek. I started as a developer, learned networking, spent my time as IT management, and now am a Technical Marketing Manager. The items listed here have a relatively high “Geek Factor”, they’re not something you want to run out and tell a conference room full of business managers about… But what they can enable for your organization, what becomes easier/faster/better, that you might want to chat up the business leaders about. Note that some of these links require a free membership on F5 DevCentral. No worries though, that membership is not culled for prospects or anything, it is a community that F5 happens to host, not a sales engine that you’re getting duped into. Seriously. Ask the MVPs. Or any other member. It does give you access (through groups) to some of the brightest individuals involved in the topics below though. Related Articles and Blogs I linked all over above, no related articles and blogs links today…Like a Matrushka, WAN Optimization is Nested
WAN Optimization seeks to reduce the cost of transferring data over the WAN from one data center to another. This group of technologies has been around for a while, but with the advent of cloud computing, it is getting more attention than it has in the past. Whether you are transferring data to your backup/regional datacenter or out to a cloud provider, they can serve the same purpose – to speed both the general connection and specific protocols. As more and more enterprises consider moving some functionality out to the cloud, these devices have seen increased interest simply because the pool of organizations interested in them grows from those who keep multiple active data centers to all enterprises making use of the cloud. The best way to describe WAN Optimization is to compare it to a Russian Matrushka doll, with layers that contain each other and each adds something to the hole. You can skip a layer if you have the need (akin to leaving a doll out of the matrushka), but each layer offers independent benefits and going without them should be considered carefully. WAN OPT DEFINED According to Wikipedia, WAN Optimization consists of dedup, compression, caching, protocol spoofing, traffic shaping, equalizing, connection limits, and simple rate limits. I would argue that the last four are all variants of traffic shaping – you are trying to control how much traffic is flowing through the pipe and what kind, which is the heart of rate shaping. I would add encryption to this list. The difference of opinion here is one of which pigeon-hole does a technology belong in. I feel that since the product is sending your data out on a public line, it is reasonable to expect that it handle encryption. It is also far more beneficial for the device to process data and then encrypt it, send it, decrypt it, rehydrate and uncompress it, and only then pass it on than it is for things like dedup and compression to be done on an encrypted stream. But Wikipedia isn’t wrong, because encryption isn’t strictly necessary in the scientific sense and reduces the efficacy of the optimizations performed, I just feel that for the device to be useful, encryption must be an option, that way if you encrypt by another method, you can turn it off, but if you don’t have an alternate method you can turn it on. PROTOCOL ACCELERATION So coming in, you accelerate the protocol – what Wikipedia called protocol spoofing. Doing this first makes sense as the unencrypted stream will have the full set of back-n-forth commands that the protocol needs “spoofed”. Let us face it, CIFS sounds a lot like The Toddler with his “push this button” Optimus Prime toy. He says “I am Optimus Prime” about 20 times a minute, just as CIFS says “I am a server” over and over. Often this repetition is not necessary. Eventually I take the toy away from The Toddler and convince him to play with something less annoying. WAN Optimization is roughly the same, it takes the unnecessary bits out of protocol communication, leaving the important stuff. Implementing protocol acceleration correctly is definitely the geeky bits, but this has been going on for so long that it’s no longer rocket science. Most vendors support a variety of application protocols, check with yours to see what they cover and what’s on the roadmap. DEDUPLICATION Next it’s a good idea to do deduplication, simply because it must be done before compression – or deduplication will not be very fruitful. Dedup is another area that has been around a good long while, and the deduplication algorithms are utilized in a fairly wide selection of IT technologies, so they get a lot of exercise. At its simplest, this is a simple case of pulling out strings of matching bytes and replacing them with a placeholder, then telling the remote box what the placeholder is for “rehydration”. Of course there are a variety of ways to define “strings of bits” and “placeholder”, but that goes way beyond the scope of this simple blog. COMPRESSION Once you’ve optimized the protocol and removed as much as your flavor of deduplication will allow, we’re at a good point to apply compression. The remaining areas – caching and other TCP-based optimizations – can be handled on the compressed stream because only the compressed stream needs to be sent across the WAN. Compression is also a time-tested technology that applies standard compression techniques to the data being sent out – much the same as it can be applied to the data being saved in a file (though most file “compression” includes deduplication as a matter of course). ENCRYPTION At this point, you’ve got three layers of optimization applied, and we take a bit of a step back to encrypt, which does take some overhead. How much overhead depends upon how the data is encrypted, but in general it is not much. You are probably thinking “this data is useless in this form, it’s been modified, deduped, and compressed”, and there’s some validity in that argument, but let’s think of a determined Man-in-the-Middle attacker. Once they capture your stream, there are a finite number of compression algorithms for them to try to uncompress your data. Once it is uncompressed, a small amount of data analysis should show the pattern of deduplication because that technology is not a security function, and all of the dedup schemes I know of are pretty straight-forward in terms of examining the data and seeing patterns. That’s all the attacker needs to do – not something your average Joe would get through, but a resourceful hacker would not find it difficult at all. So encryption it is. This is a good place to apply it too, because the TCP optimizations should be working on the finished product – the sum of the other functions. As you know, encryption too is well-known and stable. TCP OPTIMIZATIONS AND RATE-SHAPING Next come an array of TCP optimizations that can be applied to limit the amount of overhead in your stream. What those optimizations are varies from product to product and even from one option within the product to another, but the important bit is that it lowers the overhead of TCP. Less overhead is your friend. And finally, rate shaping in its various forms. Rate shaping a connection – at this point let us call it a tunnel since we’re talking point-to-point – out of your datacenter has a two-sided benefit. It allows your tunnel to use as much bandwidth as you require to maintain performance, and allows you to set the maximum amount of bandwidth your tunnel can use so that you are not hogging the entire connection and stifling other valid users. TCP rate shaping is another area that has been around a very long time, and is both useful and viable on a connection that is not dedicated to your tunnel’s traffic. Of course if you have a separate connection for just communications between the two data centers it is less useful, but still leaves room for other traffic that is not run through the Optimization process. TIME FOR A SUMMARY As you can see, there is nothing terribly new or earth shattering in any of these items, though of course as time goes on developers have gotten better at writing them, new ideas have improved them, and they get more efficient, they are in general stable and effective. Taken as a whole, these techniques can have a huge impact on symmetric datacenter communications. Symmetric because some of the important bits – dedupe, compression, and encryption – require a box on the other end to reverse them. But check with your vendor for numbers, they definitely carry their weight, particularly if your connection is busy… Like it might be if it was pointing at the cloud. Our matrushka – bought in Red Square – goes from six inches in diameter down to less than an inch. Not as impressive as WAN Optimization’s layers, but still impressive. THIS BEING AN F5 BLOG, I SHOULD MENTION… Why yes, F5 does have a solution set to address this issue. F5’s solution to this complex problem is twofold – BIG-IP LTM version 10 and higher (essentially any version with iSessions support) for Compression, Encryption, Rate Shaping, and TCP Optimizations, BIG-IP WAN Optimization Module (WOM) for Protocol Acceleration and data De-duplication. I’ve seen actual results and test-based results for this and other vendor’s solutions, and if you’re looking at upgrading bandwidth to support dc-to-dc communication or dc-to-cloud communication, I would recommend including an eval of these products in your plan.DevCentral Top5 01/22/2010
Wow! What a whirlwind it's been the past few weeks. Between holidays and vacation and people traveling out of town, it's been an absolute zoo around here. Though I've been out the past week or so there has been an avalanche of content. I've hemmed and hawed and finally managed to slim my picks down to just five, though there are at least a dozen awesome things worth checking out on DevCentral in the past week or so. So don't be shy, get out there and poke around for yourself. For now, though, here are my top 5 picks for the week: v10.1 - The table Command - The Basics http://devcentral.f5.com/s/Default.aspx?tabid=63&articleType=ArticleView&articleId=2375 The new table command introduced in 10.1 is so hawesome and powerful it's hard for me to decide where to even begin describing the grandeur that is the table command. I've decided to begin at the beginning, and point you to the basics first. There are nine (yes, 9) tech tips published in the past week or so having to do with the new table command. They range from this intro doc to some pretty powerful, in depth, well explained examples. They are all penned by the creator of the command and go into amazing detail. This series has instantly become a contender for one of my favorite batches of content ever released on DevCentral, which is saying something. If you're looking for a way to store data, store data in a structured format, perform counting operations or about a bagillion other things dealing with data storage and manipulation in iRules, you must read about the table command. Huge thanks to spark for the work on the command and going above and beyond on the documentation. TMSH Scripting in v10.1 http://devcentral.f5.com/s/Default.aspx?tabid=63&articleType=ArticleView&articleId=2374 This week's Top5 has not one, but two awesome docs regarding scripting on your BIG-IP. While iRules are near and dear to my heart, TMSH is quickly catching my interest as well. The new shell along with the powerful new scripting capabilities are wicked cool and have the potential to do some pretty amazing things. TMSH crams a huge amount of utility into an easily approachable package. This great doc Jason wrote up gets you started in style with an excellent description of where to begin, then takes you quite a bit further giving you examples of just how to build your own script. The possibilities seem rather limitless so I'm excited to see what people start doing once they get the hang of it. Check this one out for sure, and if you like what you see I'd recommend taking a look at the TMSH wiki and maybe giving this week's podcast where we spoke with Mark Crosland in depth about TMSH a listen. ARX Config, Day One http://devcentral.f5.com/s/weblogs/dmacvittie/archive/2010/01/18/arx-config-day-one.aspx In the first installment of what I'm hoping proves to be a long, detailed series describing his experiences with his ARX, Don dishes out a great intro post about getting his ARX out of the box and working. He's honest and gives plenty of details about both what he loved and what he…didn't, which I appreciate. It sounds like he also plans to go into detail about any troubles he's having or things that he finds that stand out to him and the users should know about. With his vast experience in the storage world, getting to see an ARX through his eyes is just about the next best thing to getting to fiddle with one yourself. So if you have any interest in learning what it's like to set up and start using an ARX device, I recommend keeping a keen eye on this series. Having no ARX experience myself I'm quite interested to get his impressions, so I'll be one of the subscribed readers too. iRule Editor - Offline Editing http://devcentral.f5.com/s/Default.aspx?tabid=63&articleType=ArticleView&articleId=2385 Joe's amazing creation, the iRule Editor, just got better. He's released a couple new features for it recently but the one that caught my attention the most is something that people have been asking about for quite some time now: offline editing. The iRule Editor has previously been a 100% online tool. You'd fire it up, connect to your device and start editing away. But what if you're on a plane or just don't have a device to connect to? Well, you were out of luck. Even though you could save the iRules themselves to your on disk archive, the editor wouldn't allow you to edit them offline before. But now, you can. Keep in mind that you won't be able to use any syntax checking because that uses tmm on the BIG-IP to test compile the code, but you can edit to your heart's content along with all the handy features of the iRule Editor you've grown to love. Joe even took the time to go through a walkthrough of how this works and show you how to use the cool new feature in this video. This is a very cool improvement…thanks Joe! Following Google's Lead on Security? Don't Forget to Encrypt Cookies http://devcentral.f5.com/s/weblogs/macvittie/archive/2010/01/15/google-gmail-ssl-cookie-encryption.aspx Last but certainly not least is Lori's post talking about SSL and why it isn't the only thing you need to think about when working on securing an application. Yes, SSL is an excellent and pretty standard first step to securing an online application these days. I, just like Lori, completely agree that you should be using SSL encryption as a security measure if you're at all concerned about your users or their data. Something Lori mentions though is spot on, "it’s not a panacea, especially where cookies are involved". Just because something is being encrypted across the wire doesn't mean that you can necessarily assume that it's going to be 100% safe once it gets where it's going. Data being stored on a client system, such as cookies that carry auth information, are a prime target for many malicious attacks trying to pry at user info. Cooke Encryption can be a powerful agent in stopping this and stepping up your security one more level. Have a look for yourself for a more detailed description of how this works. There you have this week's DevCentral Top5. As always, feedback is welcomed and you can check out previous versions of the Top5 here - http://devcentral.f5.com/s/Default.aspx?tabid=101 #ColinTMSH Is here – Your guide to command line dominance
Well, tmsh has been around for a while now, but the scriptable version and support for it here on DevCentral are relatively new. In fact, I just got the links to the parts of DevCentral last night, so that’s very new. I wrote about tmsh when it first came out in version 10.0, but with version 10.1 we have added some key functionality to make it more useful in your daily admin work. And now, our team with the able assistance of our Technical Publications staff have created a tmsh wiki much like the iControl and iRules wikis, and forums to support tmsh (note: both require DevCentral logins). What is tmsh? Well the first link in this article will tell you a lot, but if you just want the synopsis, tmsh is the shell replacement for BIG-IP’s bigpipe command, only it does much more than bigpipe did. Worried that you don’t want to have to learn tmsh to manage your BIG-IP family products? No worries, bigpipe is still available at this time, but the power of tmsh combined with its scripting capabilities make us certain that you should check it out. bigpipe won’t be around forever, and you can get a lot out of tmsh. And that’s where the wiki and the forums come in. Pop by, registered members of DC can modify the wiki and post to the forums, so not only can you get a leg up getting started, but you can share your experience with others and take advantage of their knowledge. Colin and Jason have put together quite a few examples of how to use the features, they’re linked to the different tmsh commands in the wiki. Let us know what you think, offer up your own examples, help us expand the documentation, and have some fun. We’ll be around if you need anything. Until next time, Don.v.10 - Introduction to iSessions
Amongst the wave of new features that came out in Version 10 of TMOS is a nifty little feature called iSessions. This being the first release of iSessions, there is a lot of curiosity and not as much documentation as we’d like yet. So I’ll walk you through what is available, why you’d want to use it, and what benefits it offers in this blog post. As time goes on we will expand our coverage of iSessions to more fully discuss all of the options and challenges they present. The concept of iSessions in v.10 is pretty straight-forward… A secure tunnel between two BIG-IP systems to share in load-balancing and failover. The extension is that those BIG-IPs can be (and generally should be) geographically remote. Indeed, the whole point of iSessions is to make WAN communications faster, but we’ve got enough experience to know that some of you will find a use for them inside the datacenter. iSessions only require that the BIG-IPs be able to route between each other, not that they be geographically remote. Since optimization of traffic over an iSessions link is built in, you get both secure and accelerated WAN communications. The type of optimization is configurable, as are several other things about the tunnels. While this post isn’t intended to be a step-by-step How-To document, it will give you an overview of the steps necessary to get your BIG-IPs talking on the “back channel”, and offer some points of interest for you to be aware of. Much like some vendors have a remote office solution that is simply an optimizing proxy for their data center products, iSessions will forward requests to a remote BIG-IP. Unlike those solutions, if the connection the iSessions communicate over is down, the BIG-IP can be configured to handle the request locally if you have the servers in-place. For this blog post we will refer to the “Data Center BIG-IP” and the “Remote BIG-IP” note that the “Remote BIG-IP” could be configured in an alternate data center, and thus could be fulfilling both the role of the Data Center BIG-IP in some instances and that of the Remote BIG-IP in others. For simplicity’s sake, we will not explore that configuration here, simply note that it’s possible. For this blog post, the “Remote BIG-IP” is the device that the user’s requests will come in through, the “Data Center BIG-IP” is the one that will ultimately service requests. That should be all the background we need to cover, now on with the overview. The best way to think of iSessions (for me at least) is like a fibre optic cable. iSessions are turned on at both Remote and Data Center BIG-IPs, and that creates the sheath that holds the fibres. When connections are requested on the Remote BIG-IP, an individual fiber (connection) is created in the sheath (tunnel). Depending upon your settings, that connection could exist for a long time, servicing repeated requests from different clients, or it could exist only so long as the requesting connection is live. At its simplest, the iSessions configuration is easy. On the Remote BIG-IP, you configure a forwarding Virtual Server to forward requests to the Data Center BIG-IP. The Data Center BIG-IP has a Virtual Server configured for iSessions that either maps to a server or forwards to another Virtual Server on the same BIG-IP. Either way, the Data Center BIG-IP services the request, and sends the response along the same iSession connection, assuming the request is for the same target Virtual Server. Note that re-use has some drawbacks in every implementation out there, and you might want to consider their use carefully if you have very bursty traffic patterns. Also note that in this first implementation of iSessions, the longevity of a connection is 10 minutes and cannot be changed. Note that the iSession Forwarding Virtual Server is different than most Forwarding Virtual Servers – it is configured as a standard Virtual Server with address/port translation turned off and no Pool object associated with it. A destination is then set that is the Data Center BIG-IP’s address. The Virtual Server on the Remote BIG-IP requires a TCP profile to be selected for both the client and server side contexts, and a client SSL profile must be selected so that iSessions info can be decrypted when the other BIG-IP sends responses. This Virtual Server on the Remote BIG-IP also requires an iSession Profile to be selected so that tells the BIG-IP how to handle tunnel creation when communicating with the Data Center BIG-IP. The iSession profile specifically tells the BIG-IP about mappings to the Data Center BIG-IP, Session re-use, optimizations of the tunnel, and other general connection options like de-duplication (not currently available even if enabled… Check back for more info) and port transparency. Note that while the Endpoint Pool is slipped in at the bottom of the configuration screen, you need it set to a pool of one node that is the forwarding point for iSession Tunnels to the Data Center BIG-IP. The Data Center BIG-IP has the same iSession Profile, and your choices for tunnel-specific configurations are compared when a tunnel is initiated, and only those settings that are enabled on both sides are used for this tunnel. On the Data Center side, you must configure the iSession Profile such that it knows what to do with incoming connections – are they simply routed, or do they get sent to Virtual Servers for additional processing, etc. These options are at the bottom of the iSession Profile configuration. For Target Virtual type, your early implementations can probably use Match All, which will match to any Virtual that fits, and route the request on if none matches. Okay, that’s a ton of info. We’ll call that the quick overview. The salient points are: iSessions create an encrypted, optimized tunnel over the WAN between two BIG-IPs. Both BIG-IPs must be v.10 When configuring client and server profiles remember to think of traffic direction… Where the traffic comes in from the client (regardless of which BIG-IP you’re on) is the client side, where it flows back toward the client is the server side. iSessions are always encrypted but you have options for which and how much compression to use (and the ability to choose “adaptive” if you are uncertain which is best for you). Just because this blog post used “Remote BIG-IP” doesn’t mean it can’t also be in a data center, and in some instances it may even be the “Data Center BIG-IP” in highly distributed environments. Session re-use saves the overhead of renegotiating for each connection, but comes with a price of long-lived connections between the two BIG-IPs. That’s it for now. I’ll be posting soon about how and why this is important if you’re considering using a cloud provider. Check with your SE if you’re interested in more implementation-specific details. Don.
