Bug #2100
closed
Added by Igor Novgorodov over 7 years ago.
Updated about 6 years ago.
Description
Same configuration as in https://redmine.openinfosecfoundation.org/issues/2099
Network topology is simple:
[host1 eno50] <-> [eno50 host2(suricata) eno49] <-> [eno50 host3]
host1# ip addr add 192.168.99.1/24 dev eno50
host3# ip addr add 192.168.99.2/24 dev eno50
host3# ping 192.168.99.1 -c 1000 -q -f
PING 192.168.99.1 (192.168.99.1) 56(84) bytes of data.
--- 192.168.99.1 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 19977ms
rtt min/avg/max/mdev = 23.308/26.272/39.973/0.457 ms, pipe 3, ipg/ewma 19.997/26.274 ms
When using NFQUEUE and routing through Suricata the latency is fine (sub-millisecond)
- Assignee set to OISF Dev
- Target version set to TBD
Testing with latest git confirms that problem still persists, latency is still about 20ms.
Are you testing with tpacket_v3 ? If yes can you test without it (so with v2) ?
Yep, it was TPACKET_V3.
I've read somewhere that V3 is experimental, but didn't pay much attention to that.
With TPACKET_V2 it's fine - 0.2ms, thanks!
It is not really experimental regarding to IPS. It will never work correctly: tpacket_v3 is using a block concept that contains a group of packets and deliver block by block so this induce a latency..
Eric should we add a big fat warning or even outright refuse to work in IPS mode with AFPv3?
Yes, the CRIT log message during startup would be very nice and some mention in the docs, so others would not guess the cause of latency.
Sadly, but V2's performance is much worse. I was able to achieve the 0% drop on V2 only with 35% lower PPS than with V3.
I think it is a good idea to avoid this kind of issue. I'm cooking something to go with the IPS fix.
- Assignee changed from OISF Dev to Eric Leblond
- Target version changed from TBD to 4.1rc2
- Status changed from New to Closed
Also available in: Atom
PDF