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 information, but is short on details.

 

From what I can understand, I need at the least the following items:

 

1) A self IP on each LTM (active unit and standby unit). 2) A floating IP on the LTM cluster. 3) An LTM virtual server. 4) The Routed-Forwarding iApp installed and configured according to sol7595. This should enable traffic to return back to the servers. 5) Servers in the associated LTM pool should use the floating IP (2 above) as their gateway. (ie: The servers must have a route to the floating IP address)

 

The questions I have are:

 

A) Must this use more than one physical interface? If yes, then other than the VLAN configured on the virtual server, where do I configure this to use a second interface? B) Does the LTM virtual server (3 above) need to be in the same IP subnet and VLAN as the floating IP? C) What setting or configuration indicates that the LTM is going to route traffic from the virtual server to the servers in the pool? D) Is there an official F5 document that details this for people who otherwise have no clue?

 

1 Reply

  • 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 :)