iRule catch all - to redirect if no pool selected
Hi I have multiple VS's setup (~150) that use an iRule to select the appropriate pool based on host header (no default pool assigned in VS config), this is working fine. I have been tasked with writing an iRule to serve up a sorry page when pool members == 0. This is also working fine. My issue is that my syslog server is getting pounded with TCL errors since I applied the sorry_page iRule TCL error: /Common/sorry_page_iRule - no such pool: (line 21) invoked from within "active_members [LB::server pool]" I added a Debug logging rule and found that the majority of the TCL errors are due to pool selection trying to select the Virtual Server IP Address as the pool. This of course triggers the TCL "no such pool" error because I do not name my pools with IP addresses. I would like to add a "catch all" in the sorry_page iRule that "if no pool selected or no such pool / redirect to ; Here are the two iRules I have applied to the multiple Virtual Servers - Pool_Selection_iRule: when HTTP_REQUEST { HTTP::host [string tolower [HTTP::host]] set PoolName "[HTTP::host]_pool" if { [catch { pool $PoolName}] } { } else { pool $PoolName } ` Sorry_Page_iRule: `when LB_FAILED { log -noname "[virtual name] DEBUG: Server Pool: $PoolName SELECTED" if { [active_members [LB::server pool]] == 0 } { log -noname "Sorry Page Activated / Server Pool: $PoolName selection failed on connection attempt from [IP::client_addr]" HTTP::respond 503 content { **a bunch of HTML code here** } Any help would be greatly appreciated.
Selective Access within Application via iRule
Greetings, iRule experts! I'm trying to block access to certain pages within application using data group but can't make it work. The problem is that blocked and accessible pages are located under the same /Application. Example, URI /Application/Administration/Index.aspx must be blocked, whereas URI /Application/PasswordReset/Index.aspx should be accessible. Another difficulty is that every page has multiple page objects (.js, .css, etc.). What would be best solution for this? Many thanks!
Another Challenge and FSEs to Watch
Every quarter or so the Sales Readiness team here at F5 are kind enough to invite me over to talk to the new crop of FSEs going through their new hire bootcamp and whip them into shape gently educate them on the finer points of iRules goodness. The way in which I get to do this is by creating a challenge for them to ponder and solve. The idea is, act like a customer, lay out a possible scenario that needs fixing, and give them some time to solve it. Mind you they're being put through their paces pretty hard during this time, so it's frankly impressive that they finish the challenge at all. Finish they do, though, and with some darn impressive results to boot. When dolling out the challenge this time, I didn't realize quite how hard I was making it until I went through to craft a solution myself. I suppose I get carried away sometimes, trying to make sure that things aren't too easy for them, trying to force them to not only learn the language itself but also the multiple resources such as DevCentral, internal mailing lists and their peers with years of experience, that they can leverage to get a better handle on what needs to be done. Even considering all that though, when I went through and wrote up my solution to this particular challenge, I realized I had gone too far, and likely shouldn't expect many of the new FSE hires to finish the challenge at all, let alone turn in solutions that were close to the mark. Boy was I wrong... Time and time again I'm impressed with the caliber of the engineers F5 puts out in the field, and this was no exception. These folks managed to put together some darn impressive challenge entries, a couple coming so close to the mark on functionality that I was honestly shocked. With a hill this steep to climb, getting within spitting distance of the top is more than I expected, and I was pleasantly surprised. I'll say a hearty well done and hat's off right here and now to each and every one of the challengers. That being said, there has to be a winner, and for that there has to be a challenge, so let's get down to it, shall we? Scenario: A client is moving to a full SSL deployment, and wants to have a smooth transition. They have identified some key requirements, some general, some application specific. Desired Solution: All non SSL requests originating from a country that does not host a branch office, route to pool “virus_scan”, otherwise route to “http_pool” All requests and responses to/from the client must be SSL encrypted All requests to /admin must have the admin_auth cookie All requests to /blog must have the blog_auth cookie Expire both admin_auth and blog_auth cookies from client browser if they are not secure Ensure all new versions of admin_auth & blog_auth cookies are secured Branch Offices: Seattle, London, Tokyo, Singapore, San Paulo, Mumbai Assumptions: HTTP(S) Protocol BIG-IP v11.1 or later Win/*Nix platform of your choice for dev/testing, along with associated tools (wireshark, iRule Editor, etc.) Only the iRule used must be shown, any internal configuration that must be completed can simply be documented and explained. So there's the challenge. As you can see, it's already pretty involved, with plenty of gotchas and order of operations traps to fall into. Go to code it yourself though, and you'll quickly realize a couple of pitfalls that are a bit deeper than I probably should have dug for folks new to iRules, and in some cases coding in general. These fine fellows, though, they put forth the effort and sweat required (and lack of sleep in some cases, I hear) and came out on top (Keep in mind that these examples are not production ready code snippets, they are great examples of a start down the path towards a solution): Third Place - Ron Ho Ron put forth a really solid effort that showed he had a strong grasp on the basic concepts needed to excel with iRules development. He used a clever switch statement, which I liked even if it was missing a port clause for accuracy to the challenge's intent, and he figured out the catch command which is awesome. A very solid entry to a very difficult challenge. #ColinDevCentral Top5 6/27/2011
As rare as the Hippocampus and as fleeting as the Pegasus, this special Monday edition of the Top5 is brought to you by "too much to get done on Friday"(tm). Think of it as a bonus edition though, not delayed, as this Top5 comes bearing wondrous gifts from around DevCentral. From iRules Challenges to MVP contributed Tech Tips to a special 20LoL and more, the community has borne deliciously geeky fruit of all manner the past weeks. So much so in fact that the bounty could not possibly be contained within this abbreviated format. Even still, I feel that the five I've chosen are worthy, and I hope you enjoy this week's Top 5: iRules Challenge #4 Results: Contemplating Context http://bit.ly/mjvwAx Every time I get the joy of participating in one of these FSE iRules Challenges I have a blast, but I'm also repeatedly blown away by the abilities of these new recruits. Not only are these people new to F5, but many have no scripting background whatsoever. If that weren't enough, while here in boot camp they're receiving a massive amount of information to process and imbibe every day. Given only their spare time to work on the iRule for the challenge, it's impressive that they even complete an iRule. Despite all of that, however, they somehow persevere and submit awesome entries, every time. This particular challenge was a doozy from the "What the heck did he just ask us to do?" stand point. A brief 20 minutes of questions goes by pretty fast when they're trying to formulate a plan and figure out what the heck they need to know. In spite of the intentionally confusing challenge some strong results cropped up, and I'm looking forward to the next challenge. Well played, one and all. BIG-IP and Merge File Configuration Changes http://bit.ly/iKWcVA Whenever a DevCentral MVP steps up to the plate, watch the fences for the outcome. Michael Yates continued the trend of awesome MVP contributions with his Tech Tip detailing how to make use of the a Merge File to make non disruptive changes to your BIG-IP's config. In a high throughput environment where downtime isn't an option, sometimes even largely simple changes can be a no-go if they cause even a brief hiccup in traffic while the config re-loads. With a merge file you can avoid that interruption, assuming the change itself doesn't cause one (I.E. things like removing a pool or pool member will always cause an interruption, even with a merge file). I get the feeling that this handy technique is something that many other users will be able to benefit from, in part thanks to the solid document Michael has put together to educate future BIG-IP experts. MVP indeed, well earned Michael and thanks for the contribution. BIG-IP APM-Customized Logon Page http://bit.ly/kEJrJe While APM offers some impressive power and inspection capabilities, let's be honest about the default login page: it's basic. Not bad basic, mind you, just simple and functional basic without a lot of bells and whistles that you don't need anyway. Why don't you need them? I'm glad you asked. You don't need our bells and whistles on your APM default login page because it is designed with the concept in mind that you will be adding your very own bells, whistles and any other doo-dads you see fit via customization. The login page is completely under your control. Whether you want to statically alter it, do away with it or like in Jason's fine example here, set up some automation around the way that it's customized via iRules fu, the choice is yours. In this example Jason is displaying how you can combine APM configuration options with a little iRules know how to get a powerful, dynamic result. Take a look for yourself for the details. F5 Friday: Performance, Throughput and DPS http://bit.ly/la6wsA Lori found a topic last week for her F5 Friday post that resonated so clearly with me that it would have been beyond the power of my will to refrain from adding it here today: DPS vs. Performance vs. Throughput. Now I admit that as a reformed WoW aficionado when I first saw DPS I was confused as to how it was applicable here, but the DPS of which Lori speaks is in fact Decisions Per Second. When dealing with metrics in an application world, how much do you really want to measure network throughput or the number of TCP transactions the network was able to set up and tear down in a given time period? These things are not directly applicable to the application, the way it behaves, what portion of the application's decision making chores have been offloaded to the network in one way or another, etc. What you really want to know, or likely should if you don't, is how many decisions per second are occurring and where. Just how much heavy lifting - application lifting that is - is your network really doing? If you aren't sure, maybe you should be. This is a great topic for discussion, though I warn that it may grow heated as you involve the different groups necessary to gauge this slippery concept. I'm not saying that throughput or TPS or whatever other metrics you're used to looking at are bad or shouldn't be reported, that would be asinine. I'm merely saying, thanks to Lori's unintentional prodding, that you should probably start looking at DPS as well to see where the real work is being done, and how to best tweak that. This one is worth a read for sure to get more depth. 20 Lines or Less #50: iRules Challenge Round-up http://bit.ly/mPqMbN Last on the page but first in my heart, I bring to you the (marginally) momentous 50th installment of the 20 Lines or Less series. This series has been running for 3+ years now, and I enjoy it every single time I get to take the time to write it. It's a pleasure sharing the awesome code snippets produced by the community, our engineers, the DC team and sometimes even by me. With over 150 examples of how iRules can provide serious power in under 21 lines of code, clearly no one could refute the benefit iRules bring to the table if they would but take a few minutes to browse through this series and see the proverbial rabbits being pulled out of hats by F5 users worldwide. For this 50th edition I shared my solutions to three of the iRules Challenges that have been issued so far. 50 down and I'm just getting started, so stay tuned for many more, and thanks for reading. That'll do it for this (last) week's DC Top5. As always thanks for playing and let me know if you've got any feedback, questions or contributions. Until then... #ColiniRules Challenge #4 Results: Contemplating Context
In a shocking turn of events, the gracious sales readiness team invited me back to yet again present an iRules Challenge to the inbound FSEs during their multi-week grooming process here at F5 Seattle, lovingly known as "boot camp". It's a joy for me to be a part of these boot camps not only because I get to geek out about iRules and dream up challenges to get people more involved with DevCentral and iRules, two of my main squeezes in the tech world. But also because it's killer to see the talent rolling through, chat with some of them about how and why they ended up here at F5, and get a constant stream of reassurance about just how wicked powerful our engineers out in the world are, not that I had any doubts. Why so fired up about the worldwide crew of Engineers? What's an FSE? To uphold tradition (and because I don't think I could write it better if I tried) I'll borrow from my first introduction of the iRules Challenge to depict what FSEs are, and why I'm such a fan of getting to work with them: FSEs are the engineering lifeblood of the sales force here at F5. They’re the ones out in the trenches dealing with customer requirements and issues, building real world solutions, and generally doing all the cool sh stuff that I get to talk about theoretically, but in the real world. I’ve got mad respect for those FSEs that take their jobs seriously and learn how to build full fledged F5 solutions that leverage our crazy broad product set and, you guessed it, our out of the box tools like iControl and iRules. Those that choose to flex those muscles garner a special place in my encrypted little heart. Lucky for me (and F5) this is an increasingly large number, but that’s a different conversation. As you can see, I'm a fan, and it's fun to get to help get them indoctrinated into the DevCentral and iRules cultures. Apparently I make some tasty Kool-Aid, and I'm more than happy to share. Speaking of which, on to the challenge! Desired Solution: If a user is making a request to one of a list of URIs (50+), and that request is bound for one of the 4 “secure servers” (4 servers, non-sequential IPs, in one pool) in the DMZ, the Client must originate from a particular subnet (10.10.10.0/28), or from an IP resolving to one of the partners in a given list of hosts (20+). Requirements: a) Identify the URI being requested b) Identify the IP address of the server the request is being sent to c) Identify the network and/or the PTR host the client is initiating the request from d) Drop any errant requests e) Log any “bad” requests, including: IP Address of Client, IP Address of Server, requested URI Each individual part of this isn't necessarily difficult, but the combination presents some unique challenges. First and foremost, intentionally, is the concept of context. Being a full proxy system is a wonderful, powerful thing, but it means that any engineers working in-depth with F5 devices need to keep the different proxy states in mind, and understand what information is available on each side of the connection. Combine that with the need to access information that might not be immediately available in your current state, lists of info to manage, multiple tiers of conditionals and one of my favorites: Session vs. Request based conditionals, and there are plenty of traps to fall into for an unsuspecting iRuler. That's was kind of the point, after all. As it turns out, however, this new batch of FSEs was largely up to the task right out of the gates, which was plenty impressive. 3.) First up is the second runner up, coming in at third place, David Parez Aznarez. David's iRule was well thought out and showed solid potential. It had a great logical flow and showed that he was adept at not only thinking through the problem, but also researching possible solutions on DevCentral, which I appropriate. In the end it was a bit more complex than necessary, but efficiency and coding elegance come with experience, so I have no doubts that David will be writing even more powerful iRules code in no time. 2.) Next in second place, the first runner up Anurak Chuetanapinyo! Anurak did a truly admirable job of keeping his code simple and efficient. He was at the opposite end of the spectrum from David, also with very solid logical flow and some good concepts such as RESOLV::lookup mixed in. In the end his simplification went slightly too far and earned him a respectable second place finish, due to a couple pieces of the challenge not being 100% in place, though he was close enough that a short chat later and he knew where he had left bits out, and I could see he was picking the concepts up mighty quick. He'll soon be an old hand at simple iRules like this, and be on to bigger, better coding tasks I'm sure. 1.) Last, but certainly not least, is our Winner, Vince Tognaci! Vince displayed a very solid understanding of not only contextual awareness and information availability, but also of connection vs. request based processing, two of the big "gotcha" concepts I was hoping to impart on these engineers with this challenge. That combined with his use of DevCentral scouring, solid coding concepts and practices and even some nice commenting earned him a well deserved first place finish. With a few minor tweaks this rule could solve all of the problems laid out and that, for someone with mere weeks as an F5 employee, is impressive indeed. Overall another outstanding showing from all of the engineers that were in the training course and had to endure the challenge. Thank you all very much for your hard work and the code submissions. It was a blast, as always, to participate and get to share a little of my passion for this technology with all of you, and I look forward to doing so more in the future. For those new hires out there that might be reading this, knowing you'll be in boot camp soon...get to reading, researching and learning the ins and outs of DevCentral & iRules. There's a Challenge heading your way, I'd bet on it. #ColinAnother batch of FSEs, another iRules Challenge
The Sales Readiness team is back at it, training another awesome crop of FSE type peoples here at F5 headquarters. And for the third time in a row, I get the esteemed honor/fun of building an iRules challenge to push them into learning iRules, the tools it takes to build them, how to research them, how to use DevCentral, etc. It's a super fun exercise for me, and I've gotten good feedback from the previous classes of FSEs as well, so hopefully it's a trend that'll continue. Continuing the tradition of my last two posts announcing iRules challenges, let me pause for a moment here to explain for those that might not have seen it before what FSEs are here at F5: FSEs are the engineering lifeblood of the sales force here at F5. They’re the ones out in the trenches dealing with customer requirements and issues, building real world solutions, and generally doing all the cool sh stuff that I get to talk about theoretically, but in the real world. I’ve got mad respect for those FSEs that take their jobs seriously and learn how to build full fledged F5 solutions that leverage our crazy broad product set and, you guessed it, our out of the box tools like iControl and iRules. Those that choose to flex those muscles garner a special place in my encrypted little heart. Lucky for me (and F5) this is an increasingly large number, but that’s a different conversation. So the setup for the challenge is basically the same. The class of FSEs is here in town, I wander over Monday morning and dish out a set of requirements. They get about 20 minutes to ask questions, get details, bounce ideas off me, call me names, throw rotten fruit (WHY DO YOU CARRY ROTTEN FRUIT?!), what have you. Then I'm on my way and back to the wild world of DC madness, leaving the 20 or so FSEs to fend for themselves. They delve into DevCentral's archives of iRules riches, ask peers, email me directly...whatever they can think of, they can use as a resource. The only stipulation is they can't have the rule (or any of the code therein) written for them directly. Suggestions from a peer are one thing, chunks of code are another. So here are the requirements for the challenge this time around: Requirements: Identify the origin country of each incoming HTTPS request If the request does not originate from within the US, track the number of requests being issued from that source. If a single source makes more than 500 requests per minute, perform the following: Log the IP, country of origin, and the page requested that put them over the limit. Delay all requests from that source by 1 second for the next minute For the duration of that minute, forward all requests from that particular source to a separate pool for further inspection (in addition to the default pool, not in place of it) So there it is, what do you think? Hard enough? Too hard? Can you solve it? Go ahead, take a stab at it and I'll let you know how close you get. I'm looking forward to the submissions (due tomorrow, folks, get on it!) as they're always hawesome to go through. Good luck challengees (hi, I'm Colin and I make up words), and I'll see you on Friday with some goodies for the winner. #ColinAn Issued Challenge…Again
It’s FSE iRules Challenge time again, folks, so strap on your geek-hats and follow along. First, before I get too deep into what the challenge actually was this time around, I want to steal a word or two from the last challenge’s announcement to describe what an FSE is. FSEs are the engineering lifeblood of the sales force here at F5. They’re the ones out in the trenches dealing with customer requirements and issues, building real world solutions, and generally doing all the cool sh stuff that I get to talk about theoretically, but in the real world. I’ve got mad respect for those FSEs that take their jobs seriously and learn how to build full fledged F5 solutions that leverage our crazy broad product set and, you guessed it, our out of the box tools like iControl and iRules. Those that choose to flex those muscles garner a special place in my encrypted little heart. Lucky for me (and F5) this is an increasingly large number, but that’s a different conversation. Now that you know who they are, let’s take a look at what they’ll be doing this time. Given the success of the last challenge and the killer feedback we got about how it helped those folks learn and investigate the awesomeness that is iRules, Clint reached out again for another challenge. Any time I get a chance to get more people involved in the iRule community, teach them how to write some of this wicked cool code, and get them tearing through DevCentral to research fixes to problems they might have, I’m game. As such I was more than happy to provide just that in iRules Challenge form. Here it is, the new iRule FSE challenge: Requirements: 1.Store a list of 50 unique “add strings” (a string of random text accompanied by a URL, intended to simulate a list of specials a site might want to advertise to incoming users) in a manner that makes them easy to update and retrieve. 2.Re-write all instances of “##InsertAddHere##” (case insensitive) with a randomly selected “add string” in the payload of every HTTP response that contains “##InsertAddHere##”. 3.Scrub all possibly harmful HTTP headers before reaching the client. Ensure that these headers are not blocked: "Host“, "Cache-Control“, "Connection“, "Content-Encoding“, "Content-Disposition“, "Content-Type“, "Content-Range“, "Content-Length“, "Date“, "ETag“, "Expires“, "Keep-Alive“, "Location“, "Pragma“, "Range“, "Set-Cookie“, "Transfer-Encoding“, "Vary“, "WWW-Authenticate“, "Age“, "Accept-Ranges“ 4. Ensure that all users attempting to access http://domain.com/users/login are only allowed to do so via HTTPS. The intent, much like last time, is to challenge these relatively new F5ers enough to make things interesting, but not soul crushing. Ideally they’ll reach out, research, and conquer. This isn’t intended to draw out the most intricate, challenging, mind-bending iRules known to man. It’s intended to force people (did I say force?) to get their feet wet and figure things out in a hurry. Hopefully it’ll do just that. Worth noting is my horrible spelling (due to this being written up while prepping for my day trip to Minneapolis for the User Group there) of “ad”. I meant “ad” as in advertisement, not “add” as in “addition”. Oh well, now that the challenge is issued there’s nothing that can be done but crack bad jokes about it, so have at it. The results are due a week from today, so don’t go posting your solutions just yet. Hopefully, though, this will get your brain churning on how to solve these things. There will be prizes given out to the most successful FSEs that complete the challenge, and if you want to play along I’ll mention the top 3 user contributed iRules as well when it comes judging time next Friday. A big thanks to everyone that’s participating. Now get to iRuling! #ColinWinner Winner, iRule Dinner
Last week I wrote about the iRules challenge issued to the FSEs again, and showed my intended solution. Go take a look at that post for a point of reference if you like, or just dive in. Today I want to give props where props are due, and show off the winner and two runners up of the FSE iRules Challenge. Big congrats to Harry Kleinbourg, Sudarshan Sivaperumal, and the winner, Karl Vogel. Excellent work, guys! There were many solid entries so the judging was surprisingly close, but these three engineers came the closest to the complete solution while keeping an eye towards efficiency and readability. Really an impressive feat for being so new to the technology. Okay, enough congratulating, on to the code! First we’ll give you the winning iRule, from Karl Vogel. Winner! Karl’s iRule made proper use of the class command, the getfield command and figured out the trick logging hurdle nicely, rather than getting caught in the intentionally laid trap of trying to log to the mgmt interface directly from the iRule, which is a no go. Another major blunder he avoided was setting the cookie in the request. This was a big one and I knew it would trip up a lot of people (and it did) but Karl handily avoided that pitfall and properly inserted the cookie in the response, as intended. He also showed some stylish HTTP::response formatting that caught my eye, and came very, very close to accomplishing the entire task in his iRule. Karl also made sure that the code was easy to read and maintain, and efficient. Extra points there for sure. There were a few places that could use improvement, and I’ve offered that feedback as well, but all in all, job very well done! A much deserved win after the time and effort invested, and the product produced. First Runner Up In second place we have Sudarshan Sivaperumal, whose iRule was so close to being perfect it was excruciating. Sudarshan was following almost the exact same thought process that I was and at first while reading through his iRule I thought he may have the exact solution I was looking for. He was using classes, logging correctly, responding to the client appropriately and his code was wonderfully compact and neat. The only thing that threw a wrench in the works here was the aforementioned cookie being set in the request and a little formatting around class requests. That being said, this was an extremely solid attempt and the base knowledge of how to solve the problems laid out is definitely there. With a little fine tuning and some more experience working with the products, Sudarshan is going to be an iRuling force to be reckoned with. Well played, sir, and keep at it. Second Runner Up Last but definitely not least, in third place we have Harry Kleinbourg, who put forth a very fine effort in this challenge. Harry showed some out of the box thinking by using the event disable command, had the cookie being inserted in the response, the logging problem was solved…it was a very promising looking rule. The big rub for Harry was that he confused the intent of the challenge and as such ended up re-writing the wrong part of the URL. Confusion will happen and I can’t hold that against him too harshly given how well written the code is in general. He’s got a bright future in the FSE world if he keeps up this kind of effort in researching and executing solutions to the problems that face those that he’s helping. Very strong effort indeed. Huge congratulations to our winner and finalists. You really deserve a massive amount of props for churning out such solid solutions with so little exposure to the technology. I’m duly impressed, as were others that I’ve shared the challenge and results with. Keep pushing the ball, digging through DevCentral and learning the ins and outs of this outstanding tech. Now that it is all said and done, this iRules challenge has been amazingly fun, educational and rewarding, at least for me. I hope those involved all got something out of it as well, and I’m looking forward to doing it again as long as I didn’t mess it up too badly this time. A big thank you to everyone that participated and again to Clint for getting me involved. #Colin
