Flexible Netflow mit Voraggregation im Router

Was bei einem ISP so rein und raus geht, ist für die Planung wichtig und für Traffic-Engineering essentiell. Um diese Informationen abzugreifen, hat der Netzwerk-Gott Netflow erfunden. Normalerweise ist Netflow zu detailliert, um es auf höheren Bandbreiten einsetzen zu können, also muß man schon am Router aggregieren.

Beschränkung aufs Relevante

Von Interesse ist, mit welchen Autonomen Systemen der ISP Daten austauscht. Genau dafür gibt es ein vordefiniertes Profil:

#show flow record netflow ipv4 as      
flow record netflow ipv4 as:
  Description:        AS aggregation schemes
  No. of users:       0
  Total field space:  29 bytes
  Fields:
    match routing source as
    match routing destination as
    match interface input
    match interface output
    match flow direction
    collect counter bytes
    collect counter packets
    collect timestamp sys-uptime first
    collect timestamp sys-uptime last

Der entsprechende Eintrag ist gar nicht von der IP Version abhängig und paßt genauso auch auf IPv6. Er definiert einen Flow primär anhand des Quell- und Ziel-ASN. Für alle Pakete, die in allen match-Feldern übereinstimmen, werden die collect-Felder gesammelt. Ob summiert, das Minimum oder das Maximum genommen wird, ist vom jeweiligen Feld abhängig.

Den aufgesammelten Datenwust kann man sich lokal anschauen oder exportieren:

flow exporter server8
 destination 192.0.2.8
 source Loopback0
 transport udp 9995
flow monitor asn
 exporter server8
 record netflow ipv4 as
interface TenGigabitEthernet0/1/0
 ip flow monitor asn input
 ip flow monitor asn output
 ipv6 flow monitor as input
 ipv6 flow monitor asn output

Soweit so einfach.

Auf dem betreffenden Server läuft dann ein Netflow-Collector, der die Daten einsammelt und alle fünf Minuten in eine extra Datei auf der Platte ablegt. Auf dieser Datei führe ich nun meine Aggregation aus.

~# nfdump -r /var/spool/netflow/2018/09/27/12/nfcapd.201809271200 -A srcas -O bps | head
Date first seen          Duration  Src AS   Packets    Bytes      bps    Bpp Flows
2018-09-27 11:58:23.111   400.103   15169    38.9 M   47.7 G  953.1 M   1225 25304
2018-09-27 11:58:22.973   401.026       0   157.9 M   45.9 G  915.4 M    290 714869
2018-09-27 11:58:24.009   399.987    2906    23.3 M   34.4 G  688.4 M   1474  1223
2018-09-27 11:58:23.215   400.643   16509    26.0 M   33.7 G  673.7 M   1297 34785
2018-09-27 11:58:23.167   399.702   16097    18.3 M   27.0 G  541.3 M   1477  2560
2018-09-27 11:58:23.143   399.853    3356    16.9 M   25.2 G  503.6 M   1486  3869
2018-09-27 11:58:23.411   396.579    6185    15.3 M   22.7 G  458.5 M   1488  3624
2018-09-27 11:58:29.698   393.297   22822    10.8 M   16.0 G  324.6 M   1482   734
2018-09-27 11:58:23.095   400.807   32934    11.7 M   14.6 G  292.4 M   1251 11138

Sehr schön. Das AS0 ist Traffic, der von lokal kommt (ausgehend also). Dann plotte ich das mal auf:

2018-09-13-151512_447x228_scrot

WTF? Das ist definitiv nicht korrekt.

Fehlersuche

Bei der Auswertung sind ja viele einzelne Flows nochmal nachaggregiert worden. Wenn man die sich einzeln anschaut, dann gibt es keinen einzigen Flow, der mehr als 4,3 GByte an Daten enthält. Und von diesen gibt es eine ganze Menge. Alle mit der identischen Datenmenge.

Was ist passiert?

#show flow exporter templates
  Client: Flow Monitor asn
  Exporter Format: NetFlow Version 9
  Template ID    : 0
  Source ID      : 0
  Record Size    : 29
  Template layout
  _____________________________________________________________________
  |                 Field                   |  Type | Offset |  Size  |
  ---------------------------------------------------------------------
  | timestamp sys-uptime first              |    22 |     0  |     4  |
  | timestamp sys-uptime last               |    21 |     4  |     4  |
  | counter bytes                           |     1 |     8  |     4  |
  | counter packets                         |     2 |    12  |     4  |
  | interface input snmp                    |    10 |    16  |     4  |
  | interface output snmp                   |    14 |    20  |     4  |
  | flow direction                          |    61 |    24  |     1  |
  | routing destination as                  |    17 |    25  |     2  |
  | routing source as                       |    16 |    27  |     2  |
  ---------------------------------------------------------------------

Der Byte-Zähler hat eine Größe von 4 Byte, also 32bit, was genau bis 4294967295 enthalten kann. Anders gesagt: Mehr als 4,3 GByte kann man nicht pro Flow exportieren. Und diese Grenze wird immer wieder gerissen.

Normalerweise ist es kein Problem, einen Flow auf 4GB zu beschränken, da die typische Flow-Definition auch IPs und Portnummern enthält. Mit ausgelasteten 100Mbps braucht man für diese Datenmenge fast sechs Minuten, also mehr als das Meßintervall.

Hier jedoch wird schon auf Routerseite stark voraggregiert, die IP Adressen oder gar die Portnummern spielen keinerlei Rolle mehr. Deswegen werden deutlich weniger Flows erzeugt und exportiert. Andererseits werden die Zähler nun aber deutlich größer.

Ebenfalls auffällig ist, daß auch für die AS-Nummern nur 2 Byte zur Verfügung stehen. Und tatsächlich sind im Export alle 4-Byte ASNs durch 23456 ersetzt, so wie es RFC 4893 vorschreibt. Für die Auswertung ist das natürlich witzlos.

Also definiere ich mir einen maßgeschneiderten Record:

flow record asn
 match routing source as 4-octet
 match routing destination as 4-octet
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last
 collect counter bytes long
 collect counter packets long

Und siehe an, das schaut viel besser aus. Wie im obigen Bild zu sehen ist, habe ich die Änderung am ersten Router gegen 17 Uhr vorgenommen. Die Spitzen sind danach deutlich angestiegen.

Aber warum überhaupt die seltsamen Spitzen? Alle halbe Stunde steigt der Traffic stark an, um dann wieder abzufallen? Sehr unwahrscheinlich.

Es sieht so aus, als ob die Flow-Records schlicht nicht gleichmäßig ankommen, sondern schubweise.

#show flow monitor asn
Flow Monitor asn:
  Description:       User defined
  Flow Record:       asn
  Flow Exporter:     server8
  Cache:
    Type:                 normal (Platform cache)
    Status:               allocated
    Size:                 200000 entries
    Inactive Timeout:     15 secs
    Active Timeout:       1800 secs
    Trans end aging:   off

Der Timeout für aktive Flows, also die, auf denen weiter Daten rein kommen, ist 1800 Sekunden, 30 Minuten, eine halbe Stunde!

Selbstverständlich sind bei der aggressiven Aggregation alle Flows dauerhaft aktiv. Sie werden also still aufsummiert und die Zwischensummen alle halbe Stunde exportiert. Im Ergebnis sieht man die Spitzen, da fast alle Flows zu der Zeit beginnen, als Netflow auf dem Interface aktiviert wurde.

Da alle fünf Minuten ein Snapshot beim Collector weggeschrieben wird, sollte man etwas häufiger Zwischensummen exportieren.

flow monitor asn
 exporter server8
 cache timeout active 100
 cache timeout update 150
 record asn

Und schon flutscht es.

2018-09-24-164028_497x248_scrot

Post a comment

Related content