SecureXL

[Ratnesh_Singh]

Hi Team,

I have doubt related to SecureXL .If we have already connection table in firewall kernel,then what is the need of  maintaining secureXL connection table? 

[Danny]

The SecureXL connections table 'fwaccel conns' shows all connections handled by SecureXL while the connections kernel table also shows those not handled by SecureXL. Also check sk104468.

[G_W_Albrecht]

Look here: sk98348: Best Practices - Security Gateway Performance

[Timothy_Hall]

When a packet arrives at the firewall, it always hits the SecureXL Implementation Module (sim) kernel driver running on an SND/IRQ core first.  In R80.20+ if the packet's attributes match a connection in the SecureXL state table (fwaccel conns - in other words SecureXL is handling that connection), SecureXL commences direct processing on that packet.  If the packet does not match a connection in the SecureXL state table because it is the first packet of a new connection, or it is part of an existing unaccelerated connection that is not being handled by SecureXL, the packet is sent up to a Firewall Worker/Instance which is maintaining its own state table (fw tab -t connections).  There is a notification mechanism to sync certain operations between the two separate tables.

[Bob_Zimmerman]

It's probably worth noting the SecureXL table is simpler, so it's faster to check. That's ultimately the reason for maintaining the tables separately.

[PhoneBoy]

One of the original design goals of SecureXL was to provide acceleration for connections in hardware independent from the main CPU of the system.
This necessitates a separate connection table for the accelerator device itself.
There are no hardware accelerator cards that we sell currently, though they have been sold in the past.