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:

  1. Identify the origin country of each incoming HTTPS request
  2. If the request does not originate from within the US, track the number of requests being issued from that source.
  3. If a single source makes more than 500  requests per minute, perform the following:
    1. Log the IP, country of origin, and the page requested that put them over the limit.
    2. Delay all requests from that source by 1 second for the next minute
    3. 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.

#Colin