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 lastDer 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:
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: offDer 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.
