Bug #1302
closedMPLS - stats.log
Description
Using the latest git (info below, running suri with pf-ring) I am seeing something strange.
The decoder.mpls gets only incremented on the first and last thread in stats.log.
decoder.mpls | RxPFReth31 | 15123587 decoder.mpls | RxPFReth32 | 0 decoder.mpls | RxPFReth33 | 0 decoder.mpls | RxPFReth34 | 0 decoder.mpls | RxPFReth35 | 0 decoder.mpls | RxPFReth36 | 0 decoder.mpls | RxPFReth37 | 0 decoder.mpls | RxPFReth38 | 0 decoder.mpls | RxPFReth39 | 0 decoder.mpls | RxPFReth310 | 0 decoder.mpls | RxPFReth311 | 0 decoder.mpls | RxPFReth312 | 0 decoder.mpls | RxPFReth313 | 0 decoder.mpls | RxPFReth314 | 0 decoder.mpls | RxPFReth315 | 0 decoder.mpls | RxPFReth316 | 2664128
I will do some more tests and update accordingly.
Additional info:
This is Suricata version 2.1dev (rev 8c09648) Features: PCAP_SET_BUFF LIBPCAP_VERSION_MAJOR=1 PF_RING AF_PACKET HAVE_PACKET_FANOUT LIBCAP_NG LIBNET1.1 HAVE_HTP_URI_NORMALIZE_HOOK HAVE_NSS HAVE_LIBJANSSON SIMD support: SSE_4_2 SSE_4_1 SSE_3 Atomic intrisics: 1 2 4 8 16 byte(s) 64-bits, Little-endian architecture GCC version 4.6.3, C version 199901 compiled with -fstack-protector compiled with _FORTIFY_SOURCE=2 L1 cache line size (CLS)=64 compiled with LibHTP v0.5.15, linked against LibHTP v0.5.15 Suricata Configuration: AF_PACKET support: yes PF_RING support: yes NFQueue support: no NFLOG support: no IPFW support: no DAG enabled: no Napatech enabled: no Unix socket enabled: yes Detection enabled: yes libnss support: yes libnspr support: yes libjansson support: yes Prelude support: no PCRE jit: no LUA support: no libluajit: no libgeoip: yes Non-bundled htp: no Old barnyard2 support: no CUDA enabled: no Suricatasc install: yes Unit tests enabled: no Debug output enabled: no Debug validation enabled: no Profiling enabled: no Profiling locks enabled: no Coccinelle / spatch: yes Generic build parameters: Installation prefix (--prefix): /usr/local Configuration directory (--sysconfdir): /usr/local/etc/suricata/ Log directory (--localstatedir) : /usr/local/var/log/suricata/ Host: x86_64-unknown-linux-gnu GCC binary: gcc GCC Protect enabled: no GCC march native enabled: yes GCC Profile enabled: no
Updated by Jason Ish over 9 years ago
Using PF_RING? I wonder if PF_RING isn't load balancing the MPLS traffic very well. The problem with MPLS is that the same label need not be used in both directions.
Updated by Peter Manev over 9 years ago
It seems not to be related to pf_ring only. This is with afpacket:
grep mpls stats.log |tail -16 decoder.mpls | AFPacketeth31 | 49360201 decoder.mpls | AFPacketeth32 | 0 decoder.mpls | AFPacketeth33 | 0 decoder.mpls | AFPacketeth34 | 0 decoder.mpls | AFPacketeth35 | 0 decoder.mpls | AFPacketeth36 | 0 decoder.mpls | AFPacketeth37 | 0 decoder.mpls | AFPacketeth38 | 0 decoder.mpls | AFPacketeth39 | 0 decoder.mpls | AFPacketeth310 | 0 decoder.mpls | AFPacketeth311 | 0 decoder.mpls | AFPacketeth312 | 0 decoder.mpls | AFPacketeth313 | 0 decoder.mpls | AFPacketeth314 | 0 decoder.mpls | AFPacketeth315 | 0 decoder.mpls | AFPacketeth316 | 0
Updated by Jason Ish over 9 years ago
Are you able to determine if the stats are correct are wrong? Is it possible, that all MPLS packets are being sent to the same thread by the load balancing implementation?
Updated by Peter Manev over 9 years ago
It does not look this is the case. I mean this is repeatedly the output (though diff numbers of packets of course) but it is always the same threads in pf_ring and the same first thread in afpaket - which is strange.
I recall there was a similar issue(bug) some time ago with the stats.log and decoder.vlan ( https://redmine.openinfosecfoundation.org/issues/954 )
Not sure if it is related though.
Updated by Andreas Herz about 8 years ago
- Assignee set to OISF Dev
- Target version set to TBD
Updated by Peter Manev about 8 years ago
- Status changed from New to Closed
This is not necessarily a Suricata bug.
I was discussing with Eric and it seems the NIC and/or kernel dont do load balancing on MPLS labels - so it all goes to the first thread by default,like that bellow in the cases I have seen/tested:
decoder.mpls | Total | 20392799
decoder.mpls | AFPacketeth21 | 10021642
decoder.mpls | AFPacketeth22 | 0
decoder.mpls | AFPacketeth23 | 0
decoder.mpls | AFPacketeth24 | 0
decoder.mpls | AFPacketeth25 | 0
decoder.mpls | AFPacketeth26 | 0
decoder.mpls | AFPacketeth27 | 0
decoder.mpls | AFPacketeth28 | 0
decoder.mpls | AFPacketeth29 | 0
decoder.mpls | AFPacketeth210 | 0
decoder.mpls | AFPacketeth211 | 0
decoder.mpls | AFPacketeth212 | 0
decoder.mpls | AFPacketeth213 | 0
decoder.mpls | AFPacketeth214 | 0
decoder.mpls | AFPacketeth215 | 0
decoder.mpls | AFPacketeth216 | 0
decoder.mpls | AFPacketeth41 | 10371157
decoder.mpls | AFPacketeth42 | 0
decoder.mpls | AFPacketeth43 | 0
decoder.mpls | AFPacketeth44 | 0
decoder.mpls | AFPacketeth45 | 0
decoder.mpls | AFPacketeth46 | 0