[Oisf-users] Shared state in multi-tenancy?

Victor Julien lists at inliniac.net
Wed Mar 29 12:52:46 UTC 2017


On 29-03-17 00:43, Alan Amesbury wrote:
> Is state tracking shared between tenants in a multi-tenancy configuration?  For example, if a TCP SYN is seen on VLAN1 and later seen on VLAN2, do both tenancy instances track state individually or is it shared?  I'm curious because this may have implications in situations where traffic is hitting two distinct tenancy instances.  For example, given this horrendous ASCII art:
> 
> 
> 	10.0.0.1 ----VLAN_101---- router_A =====trunk===== router_B 
>                                      |
>                                      |
>         10.1.0.9 ----VLAN_102--------/
> 
> 
> Host 10.0.0.1 on VLAN 101 talks to 10.1.0.9, on VLAN2.  For reasons known only to the network engineers, both VLANs terminate at router B.  If Suricata is being fed by equipment tapping the trunked segment between routers A and B, it will see each packet twice but on distinct VLANs.  For the purposes of multi-tenancy, using VLANs 101 and 102 as selectors, will Suricata track state individually per tenant, or does it track state for both connections in a table shared across tenants?  I'm guessing it's per tenant (probably by 6-tuple of src/dest addrs/ports + proto + vlan), but I have some coworkers that think it might be shared across tenants.

Assuming you didn't disable vlan tracking by the flow engine, the
traffic on both vlans will be treated separately. So no state sharing
between the tenants.

> Another thing that came up was whether Suricata actually tracks state in the first place.  Some people thought one possible performance optimization would be to ignore the SYN+ACK during TCP session setup, but I think that would have some--er, adverse implications.

Yeah, Suricata tracks the TCP session, including the setup and shutdown
sequences. We need to, for example for proper TCP window handling. W/o
the SYN/SYN-ACK we don't know if window scaling is in use.

There is still quite a bit we could (and should) do wrt reducing startup
cost of TCP session tracking. We do too much work on the initial SYN
currently.

> Again, I've tried reading code and looking at docs, but don't see this touched on anywhere in detail.  Thanks in advance for any insights you might have!

Flow tracking is in flow*.[ch] and TCP tracking in stream-tcp*.[ch].
Especially the TCP code is quite involved.

Hope this helps!

-- 
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------




More information about the Oisf-users mailing list