Forum Discussion

Ross_Vandegrift's avatar
Ross_Vandegrift
Icon for Nimbostratus rankNimbostratus
Jul 09, 2009

Wildcard forwarding VIP connections, Immediate Idle Timeout

Hi everyone,

 

 

In my LTM implementation, an HA pair of BIG-IP boxes act as the default gateway for clients that are load balanced behind it. As such, we need to provide IP service to the individual reals behind the BIG-IP.

 

 

To accomplish this I created a virtual server with VIP 0.0.0.0/0 that matches any port/protocol, type is Forwarding(IP), and the Protocol Profile is fastL4. This nicely replicates packet forwarding behavior of a normal router. With one exception: connections to/from individual nodes consume entries in the connection table. Since DNS is a major application of our installation, oubound DNS queries (which typically exchange a few packets and then evaporate) sit around for the default 300 seconds of idle time. This is around 500k sessions in my installation.

 

 

I noticed that if I create a new FastL4 profile I can change the Idle Timeout to "Immediate". This sounds like what I want - actual packet-by-packet (instead of flow-based) forwarding for non-VIP traffic.

 

 

However, the documentation says that Immediate timeout "Specifies that the system deletes idle connections immediately." But I can't find out what the definition of an idle connection is.

 

 

If a node sends a DNS request to a slow host and it takes two seconds to answer, was the connection idle for those two seconds? If so, do I risk burning CPU in connection table management? Also, in this scenario, if the BIG-IP does reap the connection and then the response comes in, is the response still forwarded? At that point it would have no session to match.

 

 

Thanks,

 

Ross
config
design

4 Replies

Sort By
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Jul 09, 2009
    Hi Ross,

     

     

    You can create a separate 0.0.0.0:53/0.0.0.0 Forwarding IP, with a custom FastL4 VS and then apply a very short idle timeout just for the DNS. You could enable the VS only on the VLAN that your hosts will originate traffic from.

     

     

    If you want to test your other scenarions, you could use the 'b conn all show all' output while making requests.

     

     

    Aaron
  • epaalx's avatar
    epaalx
    Icon for Cirrus rankCirrus
    Jun 27, 2011
    > apply a very short idle timeout just for the DNS

     

    Can you please explain why you recommend "short" instead of "immediate" (ie. 0) timeout? Is it to maintain TMM's built-in persistance for UDP datagrams?

     

    R's, Alex

     

  • L4L7_53191's avatar
    L4L7_53191
    Icon for Nimbostratus rankNimbostratus
    Jun 27, 2011
    Pretty much, yes. It's a happy medium - you still get a table of client->vip->pool_member but the entries will clear out quickly. A zero timeout requires more configuration that may not be worth it.

     

     

    -- Matt
  • epaalx's avatar
    epaalx
    Icon for Cirrus rankCirrus
    Jun 27, 2011
    > A zero timeout requires more configuration that may not be worth it.

     

    Apologies for opening a new can of works, but can you elaborate on what you mean "more configuration"?

     

    In the context of TCP, I understand that we'd need loose initiation to allow any non-handshake packets being forwarded, however, in the context of UDP, what's the "more"?

     

     

    Does immediate mean a Connection Table entry is created and erased (during processing of the datagram/packet) or that an entry is not created at all? Either way, wouldn't it make sense that reset on timeout is ignored?