How Does the Device Manage Offloaded Session?

by panagent on ‎03-16-2012 11:02 AM - edited on ‎03-22-2017 09:22 AM by (10,679 Views)

Overview

When traffic of a session is processed by Dataplane software, session stats and timers will be updated every packet.

 

Most of our high-end platforms have a FPGA chip to entirely offlad a session (CTS and STC flows) and bypass the cores completely. 

 

Verification

You can verify if a session has been offloaded with CLI command: > show session id <id_num>

For example:

> show session id 421199
Session          421199
        c2s flow:
                source:      172.24.12.116 [Untrust-L3]
                dst:         192.168.41.21
                proto:       6
                sport:       43871           dport:      22
                state:       ACTIVE          type:       FLOW
                src user:    unknown
                dst user:    unknown
                offload:     Yes
 
        s2c flow:
                source:      192.168.41.21 [Trust-L3]
                dst:         172.24.12.116
                proto:       6
                sport:       22              dport:      43871
                state:       ACTIVE          type:       FLOW
                src user:    unknown
                dst user:    unknown
                offload:     Yes
 
        start time                    : Tue Jan 29 23:32:33 2013
        timeout                       : 3600 sec
        time to live                  : 3181 sec

 

 

Session statistics and timers are maintained in software.

So, It is necessary for offload chip to send regular updates to sofware.

These updates cannot be sent every packet due to performance concern.

 

Details

Depending on platform model, different rules apply:

 

3050 - 50xx series

Offload chip is sending a per-flow stat message to Dataplane software after 16 packets received on one flow

(CTS or STC).

Sotware will update session statitics and refresh timer accordingly.

 

On 3050 and 50xx, you can have scenario where low traffic session has been aged-out due to TTL expiration, if 16 packets condition has not been met before the end of this timer.

 

70xx series

7000 is doing the updates a little bit differently.

It will send the per-flow stat to Dataplane software when one of the two conditions happen:

  • One flow has accumulated 64 packets of stat
  • A scan timer has expired for this particular flow

Sotware will update session statitics and refresh timer accordingly.

 

Workaround

To avoid this, several workarounds exist:

 

  • Turn off hardware offload temporarily using with the CLI command: 

    > configure
    set session offload no 

     or permanently with:

    > configure
    # set deviceconfig setting session offload yes 
    # commit

     Note: This approach can have a noticeable impact on the CPU.

  • Create a custom application and adjust the timeout value for the custom application to accommodate the worst case scenario. We accept a maximum timeout value of 604800 seconds (1 week).

  • Tune the tcp keepalive timer and interval on the application servers.

 

Comments
by a.cadarso
on ‎06-26-2012 10:43 AM

"For sessions that will be offloaded there must be a minimum of 16 packets scanned before a message is sent to the CPU to reset the timeout for the session. "


Can you please explain this point, I don't understand its meaning.


I assume it is indicating that sessions will be offloaded in the future ...... but :

ONE -- If the CPU doesn't scan 16 Packets then the session will timeout. Which timeout?

TWO -- If the CPU scan 16 packets then a message is sent to the CPU to reset the timeout. Who sends the timeout message?


Additionally, if the session is offloaded. what happen with that timeout?

by mgarg
on ‎12-17-2016 02:31 PM

Every time a packet is matched with the session in the fastpath the timer for the session is reset. This is for the sessions that are not offloaded. So if even a single packet is not seen by the firewall in either direction matching that session for its lifetime, the session will be marked as discarded

 

For sessions that are offloaded the session lifetime timer is not reset after every single packet. The offloaded session must see about 16 tcp packets in either direction before the cpu resets the session lifetime. Similarly for udp it is 8 packets before the session is reset.

 

 

Ask Questions Get Answers Join the Live Community