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.
You can verify if a session has been offloaded with CLI command: > show session id <id_num>
> show session id 421199Session 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.
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.
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:
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).
"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?
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.