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.
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.
Mit jQuery generiere ich aus den netflow Aggregaten SVG-Path Zeilen. Ca. 200 Zeilen strukturiertes Javascript.
ist das Tool, welches Du für die Visualisierung nutzt eine Eigenentwicklung oder gibt es da was "Fertiges"?
Viele Grüße,
Alex
3 Kommentare