npath and persistence

The Universal Inspection Engine (UIE) can be used to create persistence records for just about anything. A common use-case for UIE is to pull JSESSIONID strings out of HTTP headers or cookies and create persistence records from them. There's a write up here:

 

 

http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=48

 

 

This iRule, for example:

 

 

http://devcentral.f5.com/wiki/default.aspx/iRules/FixSelectPoolBasedOnSenderCompID.html

 

 

...uses UIE to create persistence for the FIX protocol. There is also some information in the Config guide (check the bottom of this page: https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/LTM_config_guide_943/ltm_persist_profiles.html1193560).

 

 

In short, you're going to want to identify something in the traffic that can be used to identify and distinguish sessions, use UIE to pull this string out and then persist on it.

 

 

 

To clarify: are you running true npath? If so, persistence may be difficult for you as the BigIP isn't privy to the entire flow. From the sounds of your original post it's not clear if you're running in-line or not. Hopefully, you're in-line. If this is the case, you've got a bunch of options, as the post above indicates.

 

 

-Matt

Yeah this will be running true nPath (outbound node traffic does not touch the BigIP) and the virtual servers are configured as type: Performance (Layer 4). Will UIE still work with this?

I don't think it will, but someone please correct me if I am wrong. The challenge with this design is that the BigIP only sees a portion of the full traffic flows, so your persistence options are dramatically limited.

 

-Matt

I don't see why you couldn't use UIE to persist based on some element of each request, since every request should come to the LTM. You shouldn't need to do anything with responses, so the fact that those are bypassing the LTM shouldn't matter. Maybe I'm missing something too, but...

 

 

Denny