Hi All, Following our discussion on connection tracking: single table vs multi table I prepared a short comparison: -------------
Terms to make the discussion clear: Rule – IF-THEN clause composed of the form: if (packet classification) then (action) Flow – a set of rules chained together. Connection – an established connection between ORIGIN and REPLY. Session – composed of two connections. Single table method (ST): multiple software rules which compose a chain are ‘compiled’ into a single hardware rule. Multiple table method (MT) : each rule from software layer is transferred to the hardware ‘as is’ * Packets which belong to a connection run inside a flow. ST - Cons: When several millions connections are active: 1. Compilation is costly in term of CPU utilization. When dealing with Millions of rules then even a small CPU utilization grows very fast not to be a not small cost 2. When having several flow tables chained together then a modification of one table in the middle immediately leads to re-compilation or to flash of all the rules for all the flows ☹ This effectively means: (1) a CPU spike. (2) latency: clearing a single ‘mega rule’ might take up to few seconds (3) latency: a port down/route change can take few seconds. it is worth mentioning that the typical required SLA is sub second. 3. It is not clear how to compile flow which forks into two (or more) ends. for example: packets go from within container to both external port and sampling where only some of the packets are sampled, or having a mirror port with packets sent there according to some classification. 4. Software needs to ‘remember’ the compiled version of a flow per connection. ST - Pros: 1. Fallbacks from hardware to software is easier to deal with 2. each connection leads to a single hardware rule/entry. MT – Cons: 1. Not clear how to correctly fall from hardware flow into software flow. 2. Multiple calls to connection-tracking within a single flow require multiple hardware entries. MT – Pros: 1. Easier to implement. Merely a reflection of what we already have. 2. Cheap in terms of CPU utilization.
