For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Ken_B_50116's avatar
Ken_B_50116
Icon for Cirrostratus rankCirrostratus
Jun 18, 2014

Explain the requirements to configure LTM for an inline routed configuration

I do not understand all of requirements to configure LTM 11.4.1 HF1 (active/standby) to use an inline routed setup. This page (http://packetpushers.net/stateless-routing-f5-ltm) provides some good in...
application delivery
design
LTM
mimlo_61970's avatar
mimlo_61970
Icon for Cumulonimbus rankCumulonimbus
Jun 19, 2014

Just an FYI, this becomes significantly easier to do with SNAT. If you don't have a requirement to preserve the original IP I would strongly suggest you look into using SNAT. x-forwarded-for headers have almost always met my requirements.

 

Anyway, assuming you can't SNAT...

 

A. I have done 1 armed deployments, but using SNAT. It could probably be done in a 'routed' mode, but I have always had at least 2 interfaces(1 for virtual server ip, one for backend servers)

 

B. No, I have a deployment that uses an upstream router to route a /24 to the floating self IP, making the virtual servers in a completely different subnet than the self ip is. I must admit this is an old v9 system though, I've moved away from this model on newer deployments(using a dedicated interface/vlan/subnet for virtual server ips), but I assume it still works.

 

C. I think what you may be after here is if SNAT is used or not. If there is no SNAT defined, it will preserve the source IP of the request when sent to the back-end server, making it appear to be 'routed' If there is a SNAT, then the source IP becomes that of the floating self ip(or of a defined snat pool)

 

D. No idea. Lean on your account team SE a little :)