Project

General

Profile

Actions

Bug #1302

closed

MPLS - stats.log

Added by Peter Manev over 9 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
-
Affected Versions:
Effort:
Difficulty:
Label:

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

Actions #1

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.

Actions #2

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
Actions #3

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?

Actions #4

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.

Actions #5

Updated by Andreas Herz about 8 years ago

  • Assignee set to OISF Dev
  • Target version set to TBD
Actions #6

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

Actions #7

Updated by Victor Julien over 6 years ago

  • Target version deleted (TBD)
Actions

Also available in: Atom PDF