Great presentation @Peter_Elmer which certainly clarified a few things. A few questions if you don't mind:
1) You said that Multi-Queue is enabled by default if using kernel 3.10, is this done only for interfaces faster than 1Gbps? Can we assume that the prior limit of no more than five interfaces using Multi-Queue at the same time has been lifted under the new 3.10 kernel?
2) Other than Multi-Queue being enabled by default, are there any benefits to using the 3.10 kernel on a gateway that are specifically SecureXL and CoreXL related in the realm of performance. I am well aware of the other benefits of the new 3.10 kernel such as support for new hardware and new/updated Linux commands, my question specifically is that if still using the 2.6.18 kernel will it NOT permit some of these new acceleration technologies to be used?
3) When you say "most SecureXL functions have been moved to the firewall worker" in R80.20+ I assume you are talking about the formation of connection rate acceleration templates and processing path determination? (SXL/PXL/F2F) I think that SecureXL itself was performing these functions in R80.10 and earlier. It looks like actual forwarding of a connection's subsequent packets is still done by SecureXL itself (if possible to be fully accelerated) once these two things are completed by the Firewall Worker, right?
4) You said in R80.20+ the first packet of a new connection (that doesn't match an existing connection in the "connections" table) is always sent to a Firewall Worker via the Dynamic Dispatcher, which didn't always happen in R80.10 and earlier if a connection template was matched and the connection was eligible to be fully accelerated. What path are these initial new-connection packets assigned to as shown in fwaccel stats -s? My first guess is F2V, second guess F2F.
5) I assume once the path determination is made by the Firewall Worker core for the first packet of a new connection and that connection is offloaded into SecureXL that it cannot be "undone", which is why running an fwaccel off on an R80.20+ gateway only disables acceleration for new connections and not existing ones too as it did in R80.10 and earlier, correct?
6) Please explain the function of the F2V path, some have speculated that it is Accelerated VPN handling, but it appears to be "Forward to Virtual Machine" which is I assume is a reference to the INSPECT engine on a Firewall Worker.
7) There have been references to SecureXL and the Firewall Workers communicating asynchronously in R80.20+ vs. synchronously in R80.10 and earlier. Is this a reference to how connection notifications are being passed between the two? Can you elaborate more on this? I'm assuming "asynchronously" means that connection notifications can go both ways, where perhaps it was only one-way (SecureXL to Firewall Workers) in R80.10 and earlier?
😎 What is Augmented SSL inspection? Is it purely software or is it taking advantage of something specific in the hardware of the 6000 series whose datasheets it is touted in? Is it just the SNI inspection software feature?
9) Will the 3.10 kernel still be using FIFO ring buffers for handling of packets coming up off the NIC cards just like 2.6.18? Any chance that something like CoDel or other active queuing strategy will be supported?
10) USFW is touted as a way to get around a 2GB kernel limit by moving the firewall workers out of the kernel and into fwk processes. What is this 2GB limit exactly? The amount of third-party code that can be added to the kernel? How much kernel memory can be addressed by kernel modules due to 32-bit limitations?
11) I'm still trying to figure out how the Processing Paths in R80.10 (SXL/PXL/F2F/QXL) match up to the Paths in R80.20+ SecureXL (SXL/F2F/F2V/CPASXL/PSLXL/QoS/Corrected) *and* what CPU type each path's traffic is being handled by (SND/IRQ core or Firewall Worker core as I call them in my "Max Power" book). Rather than asking such an open-ended question, I will take my best guess and try to answer it myself, please clarify any areas where I am incorrect:
R80.10 and earlier:
- SND/IRQ Core: SXL/Accelerated path packet handling, Accept Template (Connection Rate Acceleration) initial formation, NAT template formation (if enabled), Throughput Acceleration Path Determination (SXL/PXL/F2F), Dynamic Dispatcher, Multi-Queue, SoftIRQ processing
- Firewall Worker Core: PXL path packet handling, F2F path packet handling, Priority Queues (if enabled), Rule base evaluations, QXL Path packet handling, virtual reassembly of IP fragments
R80.20 and later:
- SND/IRQ Core: SXL/Accelerated path packet handling, Dynamic Dispatcher, Multi-Queue, SoftIRQ processing, PSLXL path packet handling, SoftIRQ processing, virtual reassembly of IP fragments
- Firewall Worker Core: Accept Template (Connection Rate Acceleration) initial formation, NAT template formation (if enabled), Throughput Acceleration Path Determination (SXL/PXL/F2F), F2F Path packet handling, Priority Queues (if enabled), Rule base evaluations, CPASXL Path packet handling, F2V (Forward to Virtual Machine) Path packet handling, QoS Inbound/Outbound Path packet handling, Corrected Path handling (when more than one SecureXL instance is present such as in the case of a Falcon card, and moving a packet to the "correct" instance for handling)
How did I do?
Thanks! This list of questions got longer and longer the more I thought about it, but I need to stop now. 🙂
Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
