Forum Discussion

epaalx's avatar
epaalx
Icon for Cirrus rankCirrus
Nov 02, 2012

LTM as a router proposal

Hi F5'ers,

 

My organisation implements a number of LTM "instances" (physically, same LTM but with a number of Router Domains) used as packet forwarders, implemented by "ip forward" type VSs, allowing routed access to hosts "behind" the LTM.

 

Main issue with this configuration is that by default, LTM imposses session control (which a normal router won't) creating entries in LTM's Connection Table (and other resources, I guess) and I wish to eliminate these.

 

"SOL7595: Overview of IP forwarding virtual servers" (http://support.f5.com/kb/en-us/solutions/public/7000/500/sol7595.html) proposes:

 

profile fastL4 my_route_friendly_fastl4 {

 

defaults from fastL4

 

reset on timeout disable

 

idle timeout 300

 

loose initiation enable

 

loose close enable Optional (see below)

 

}

 

but this still maintains a Connection Table entry.

 

I propose:

 

profile fastL4 better_route_friendly_fastl4 {

 

defaults from fastL4

 

idle timeout immediate

 

loose initiation enable

 

}

 

allowing any traffic through the VS without creating Connection Table entry (or using other session-orientated resources).

 

Is this not better?

 

R's, Alex

 

 

4 Replies

  • Is this not better?i think it is okay but since there is no connection entry, you have to enable virtual server on both vlan (request and response). so, the return traffic can pass through properly.

     

     

    by the way, don't you also enable loose close?
  • > enable virtual server on both vlan (request and response)

     

    yes, of course, you're right.

     

    > enable loose close?

     

    since there's no Connection Table entry, there's (edit:) no connection to "close".

     

     

  • since there's no Connection Table entry, there's connection to "close".good point, thanks!
  • To clarify... F5 had advised me that above proposal is sub-optimal because "idle timeout immediate" will actually create and destroy Connection Table entry (for every packet) rather than (as I assumed) not create it in first place. F5's advice is to follow SOL7595.