Datenfluss visualisiert

Wenn ein ISP über seine Außenanbindungen Traffic schaufelt, dann ist es oft Glückssache, welches Leitung wieviel Daten abbekommt. Natürlich wird man gezielt versuchen einige Teilnetze nur auf einigen bestimmten Upstreams zu announcieren, damit genau dort der Traffic auch rein kommt. Aber das Finetuning ist sehr schwer. Man müßte ziemlich genau wissen, welcher Datenstrom zu welcher Zeit auf welchem Weg durchläuft, um die Änderung planen zu können.

Details bitte

Kürzlich hatte ich über Netflow geschrieben. Dort wurden die Datenströme nach Quell- und Ziel-AS summiert. jetzt will ich es detaillierter haben.

Weiterhin benötigt werden nun:

  • Der Router, der die Daten einsammelt.
  • Das Peer-ASN mit dem der Router direkt redet.
  • Der Netzblock, der im globalen Routing auftauchen wird.
  • Und der Schönheit wegen, der lokale Dienst, der den Traffic abbekommt oder initiiert.

Um nicht sämtliche IP Adressen als relevant ansehen zu müssen, definiere ich mir einen neuen Flow pro Richtung:

flow record in
 match routing source as 4-octet
 match routing source as peer 4-octet
 match routing destination as 4-octet
 match ipv4 destination address
 match ipv6 destination address
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last
 collect counter bytes long
 collect counter packets long
flow record out
 match routing source as 4-octet
 match routing destination as 4-octet
 match routing destination as peer 4-octet
 match ipv4 source address
 match ipv6 source address
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last
 collect counter bytes long
 collect counter packets long

Zusätzlich zu den Quell- und Ziel-ASNs nehme ich nun auch noch das Peer-ASN und die Quell- oder Ziel-IP dazu.

So beschränke ich mich auf die IP-Adressen im lokalen Netz (oder halt Transit) und aggregiere auf dem Router schon über die unbekannten externen IPs. Es wäre denkbar, auch IP-Prefixe statt der Adresse zu nehmen, aber ich habe Routing-Objekte, die kleiner sind als einige Prefixe. Also bleibt es bei den Adressen.

IPv4 und IPv6 sind zusammengefaßt, eine von beiden Werten wird schon relevant sein.

Als erste Überraschung präsentiert mir die Ausgabe Peer-ASN an Routern, die gar keine direkte Verbindung zu diesem AS haben!

Es stellt sich heraus, daß das Peer-AS ein abgeleiteter Wert ist, der durch ein Blick in die Routing-Tabelle ermittelt wird. Es zeigt also immer auf das Peer-AS, das der Router genommen hätte, wenn er das Paket jetzt in diese Richtung routen müßte.

Logischerweise ist also das Source-Peer-ASN i.d.R. falsch. Aber auch das Destination-Peer-ASN kann falsch sein, wenn es mehrere gleichberechtigte Wege gibt. Es ist durchaus möglich, das Pakete zum Peer 1 zu schicken und Peer 2 im Netflow zu hinterlegen.

Also stelle ich erstmal auf incoming und outgoing Interface um. Unglücklicherweise kann der Netflow-Collector überhaupt nicht damit umgehen, nur ein Interface zu bekommen. In der Annahme es gäbe beide Interfaces im Flow werden einfach die nächsten zwei Byte nach dem ersten Interface als das fehlende Interface angesehen. Alle anderen Felder werden danach mit einem Offset von zwei völlig fehlerhaft geparst. Also bekommt der Collector seinen Willen und das fehlende Interface (aber nur collected).

flow record in
 match routing source as 4-octet
 match routing destination as 4-octet
 match interface input
 match ipv4 destination address
 match ipv6 destination address
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last
 collect counter bytes long
 collect counter packets long
 collect interface output
flow record out
 match routing source as 4-octet
 match routing destination as 4-octet
 match ipv4 source address
 match ipv6 source address
 match interface output
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last
 collect counter bytes long
 collect counter packets long
 collect interface input

Achja, die Router-IP. Der nfcapd hat mehrere Module, die man getrennt aktivieren muß. Das Modul 13 schreibt die IP-Adresse des Netflow-Sensors (des Routers) mit.

Damit sind die Werte erst einmal erfaßt.

Mach mal bunt

Da mich aktuell nur IPv4 interessiert genügt es für die Auswertung sich darauf zu konzentrieren:

nfdump -r ... -q -N -A srcip4/26,srcas,inif,router,outif,dstas,dstip4/26 -O bps

Dieses Kommando aggregiert auf Basis von /26er Netzen, für die ich händisch im Auswertescript hinterlegt habe, welches Routing-Object und welcher Zweck gemeint sind.

Das Script schreibt die aggregierten Daten alle fünf Minuten in ein Logfile. Es ersetzt dabei die Interfaces pro Router mit den Peer-AS-Werten anhand einer manuellen Zuordnungstabelle.

Das Script versucht des weiteren, Flows von Transit-Traffic korrekt zuzuordnen. Wenn Quell- und Ziel-ASN ungleich Null sind, habe ich Transit.

Sind auf einem Router Quell- und Ziel-Interface einem Peer zugeordnet ist es einfach, wenn nicht muß man den eingehenden Flow einem Ausgehenden zuordnen, der die gleichen Quell- und Ziel-ASNs aufweist. Dabei kann es passieren, daß der Traffic aufspaltet. In dem Fall entnehme ich das Minimum an übereinstimmenden Traffic und ordne den Rest solange weiter zu, bis der Resttraffic unter der Nachweisgrenze verschwindet.

Im Ergebnis entstehen Einträge der Form:

DHCP 91.137.60.0/22 rudo5 8220 other 94
2906 8220 rudo5 178.19.237.0/24 NAT 86
other 196714 rudo7 178.19.228.0/22 NAT 85
2906 8220 rudo8 rudo6 196714 196714 83

Der Flow ist von links nach rechts zu lesen und die letzte Zahl ist der Traffic in Mbps.

Aus diesen Angaben generiert sich mit Javascript ein SVG.

SVG deswegen, weil es interaktiv ist:

  • Man kann die Daten in fünf-Minuten-Schritten auswählen.
  • Fährt man mit der Maus über eine Kurve, so wird diese hervorgehoben und der Eintrag erscheint als Tooltip.
  • Fährt man mit der Maus über ein Rechteck (Router, Peer, Netz, ...) werden alle durchlaufenden Kurven hervorgehoben und man bekommt die Summenbandbreite als Tooltip.
2018-09-24-163642_1280x1024_scrot

Grün ist eingehender Traffic, blau ausgehender und rot ist Transit. Die Dicke der Linie und die Größe der Rechtecke geht linear mit dem Traffic. Router und Peers haben die Größe der maximalen Kapazität. so sieht man den Auslastungsstand.

Mit dieser Darstellung kann ich nachträglich mir anschauen, was zu bestimmten Stoßzeiten im Netz los war. Ich sehe, welche Routing-Objekte evtl. besser über einen anderen Upstream announciert werden könnten. Auf diese Weise kann ich sehr fein abstimmen, wieviel Traffic auf welcher Leitung herein kommt und muß erst wesentlich später neue Bandbreite zukaufen.

Das Aggregationsschema führt allerdings auch in die Irre. Es ist nicht unterscheidbar, ob es 5000 Flows mit 1 Mbps gab oder 10 Flows mit 500 Mbps: Angezeigt werden 5 Gbps. Das fiel auch erst spät auf, als ein Scan über alle IP Adressen trotz nur wenig Mbps sich zu einem gewaltigen Strom aufplusterte. Aber damit muß man aktuell leben.

Post a comment

Verwandter Inhalt