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?
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.
- 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
- Seattle, London, Tokyo, Singapore, San Paulo, Mumbai
- 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.