iRule design considerations for ISA to BigIP migration.

So on the way home from work, I was thinking about the above and it dawned on me that this might not be as hard as I first thought.

 

 

I suppose the variable elements, such as public URI and the translated application URI could live in a DGL. Using the above example - something along the lines of (pseudo code)

 

 

class myuris {

 

"/abc /xyz"

 

"/123 /789"

 

}

 

 

Then there could be an iRule on the VS which could do something along these lines (pseudo code):

 

 

rule myrule {

 

when HTTP_REQUEST

 

match HTTP URI from DGL myuris on the left

 

replace HTTP URI from DGL myuris on the right

 

}

 

 

This would mean that the iRule itself is fairly static and that the DGL is the only element that needs to be updated. I think there may be a further issue in that some URIs are /def* which maps to /uvw* so it's a case of replace the /def with /uvw but ensure that * is appended.

 

 

So the next question would be, what's the order of operation in terms of iRule vs ASM? Say I rewrite /abc to /xyz, then in my HTTP Class for ASM, would I be matching against /abc or /xyz.

 

 

I suppose I'll have to lab the above up, but first I need to work out the actual iRule syntax.

 

 

Still open to suggestions if this can be achieved any other way, but this is my (pseudo) attempt at a possible solution.

 

 

Cheers,

 

Packeteer.

 

 

 

Hi Packeteer,

 

 

That all sound do-able. It's similar to a government implementation I worked on a while back. I would check with an F5 SE though to get detailed feedback. You'd be able to share more exact details on the scenario and get more exact recommendations.

 

 

If you have a lot of standalone ASM units I would try to minimize the number of policies you create. In current versions, you'll need to manually synchronize policy changes across the units. That's not so bad, but you will have to check each unit individually for policy building and/or learning suggestions. If you can get away with using jus tone ASM policy, I would actually recommend using a single HTTP class with no filters and no pool. You could then use an iRule to select the pool based on the URL.

 

 

If you rewrite the URI in an iRule in HTTP_REQUEST, this will be done before the HTTP class URI evaluation is done. But again, I wouldn't suggest using HTTP classes to filter the traffic as this would require multiple ASM policies.

 

 

Lastly, I'd try posting in the main iRule thread rather than this General Discussion forum. You'll get more eyes on your post that way.

 

 

http://devcentral.f5.com/Forums/tabid/53/afv/topicsview/aff/5/Default.aspx

 

 

Aaron

Hi Aaron,

 

 

Thanks for taking the time to reply.

 

 

I suppose key considerations will be:

 

 

1. Minimise the number of ASM policies. I don't think we can limit it to one as there may be different application backends to tailor for - unless a decision is made to provide a very "light" policy which isn't app specific. I think the iRule may have become a little more complicated as I have seen evidence that we have a combination of the following:

 

 

http://URL/someuri is replaced with http://URL/somecompletelydifferenturi

 

and

 

http://URL/anotheruri is prepended with http://URL/prepend/anotheruri

 

 

A coder may look at this and think that's easy. I have an idea on how it might work but not sure if it's a valid one or not. My thought would be that the prepend is treated the same as the replace, and given the example from my second post to this topic, the "right" URI string in the DGL will simply replace the "left" string in the DGL, rather than trying to make a decision on whether it's a rewrite or a replace. But then I think you could make a decision on whether it's a rewrite or a prepend and execute the appropriate section of the iRule. The thing that leads me away from that idea though is the actual decision requirement to begin with, as it starts to complicate things imho.

 

 

2. The iRule and associated DGL (probably just the latter) need to be easy to update. Unfortunately the state of the environment is that the devices are under the administrative control of people who don't really know too much about application delivery and are more often thought of as 'data entry' types. Sometimes we might find a diamond or two in the rough but getting consistent access to these resources is difficult at best. Given your comments though regarding making the LB decision within the iRule, rather than a pool on an HTTP class, would require updates to the iRule which I'm tempted to avoid if possible.

 

 

3. Whilst I'd love to engage an F5 SE, I'm not quite sure how to go about it in the UK. To date we've always dealt with a third-party supplier. Given our size, it's not very easy to get funding approved to bring in the third-party and I'm told the project hasn't allocated any budget to do so. Doh! Also in recent times it's become a little harder to obtain some pro-bono consultancy as some of their long-serving consultants have moved on. We're not a small F5 shop to be honest. We have 40+ devices, most of which are at least 6400's and a fair few 8400's so I wonder how we could engage F5 directly?

 

 

Thanks for the heads up on the main iRule thread. I wanted to avoid to "main" line for now as I wasn't trying to write code (something I feel I need to start learning how to do and quickly) but rather just get an idea on how an iRule developer might tackle this migration.

 

 

Sorry for the long post but I appreciate your time.

 

 

Cheers,

 

Packeteer.

I've had my first attempt at writing the iRule for this and this is what I've come up with so far. Not sure if it's CMP compliant but it's parsing on 6400 running 10.2.0 HF2.

 

 

class uri_prepend_dgl {
   "/prependabc" { "/prependxyz" }
}
class uri_replace_dgl {
   {
      "/123" { "/789" }
      "/abc" { "/xyz" }
   }
}

 

 

 when HTTP_REQUEST {
   log local0. "Original URI is: [HTTP::uri]"
   set external_uri [HTTP::uri]
   log local0. "External URI is: $external_uri"

   if { [class match [HTTP::uri] equals "uri_replace_dgl"] } {
      log "We're in the replace if statement"
      set internal_uri [class search -value uri_replace_dgl eq [string tolower [HTTP::uri]]]
      log local0. "Internal URI is: $internal_uri"
      set HTTP::uri $internal_uri
   } elseif { [class match [HTTP::uri] starts_with "uri_prepend_dgl"] } { 
      log local0. "We're in the prepend if statement"
      set prepend_uri [class search -value uri_prepend_dgl starts_with [string tolower [HTTP::uri]]]
      log local0. "Prepend URI is: $prepend_uri"
      HTTP::uri "$prepend_uri[HTTP::uri]"
      log local0. "Internal URI is: $prepend_uri[HTTP::uri]"
      return
   } else {
      log local0. "We're in the do nothing part of the iRule"
      log local0. "Passed URI is: [HTTP::uri]"
   }
}

 

 

There's lots of logging so I can see what's happening in the ltm log whilst I run my curl commands.

 

 

It's sort of doing what I expect, however the prepend section isn't quite right. I can't work out how to preserve anything after the interesting part of the URI. For example, if I sent the URI "/prependabc" then the resulting URI is "/prependabc/prependxyz". However if the URI I send is "/prependabc123" my expectation is to get "/prependxyz/prependabc123" however this isn't the case. I can see why, but I can't work out in iRule lingo how to add the logic I'm after. I could just have a seperate statement for each prepend, however I'd like to recycle a function with a DGL rather than statically code this for each and every prepend.

 

 

I'll keep trying to work it out and then post for help in the main iRule thread.

Hi Packeteer,

 

 

Can you clarify the issue you're having? Based on the class and iRule definitions, if the requested URI is /prependabc the the URI should be rewritten to /prependabc/prependxyz.

 

 

Are you running into an issue with query strings? If so, can you post a more accurate anonymized example of the original URI, corresponding datagroup entry and what you want it to end up as?

 

 

Thanks, Aaron