8
Traffic Auswertung Provider
Hallo,
welche Programme kommen in der Regel bei Providern für eine Traffic Auswertung zum Einsatz?
Wie sieht so eine typische Umgebung aus? Es gibt einen Kollektor der den IP Datenstrom von den Routern einsammelt und diesen wegschreibt? In Textfiles oder in eine Datenbank? Liefert ein Kollektor normalerweise eine Datenbank mit, oder wird auf eine seperate zugegriffen?
Wie werden die gesammelten Daten z.B. für Kunden grafisch aufbereitet? Wird das auch von einem Kollektor vorgenommen?
Gruß
welche Programme kommen in der Regel bei Providern für eine Traffic Auswertung zum Einsatz?
Wie sieht so eine typische Umgebung aus? Es gibt einen Kollektor der den IP Datenstrom von den Routern einsammelt und diesen wegschreibt? In Textfiles oder in eine Datenbank? Liefert ein Kollektor normalerweise eine Datenbank mit, oder wird auf eine seperate zugegriffen?
Wie werden die gesammelten Daten z.B. für Kunden grafisch aufbereitet? Wird das auch von einem Kollektor vorgenommen?
Gruß
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 304655
Url: https://administrator.de/forum/traffic-auswertung-provider-304655.html
Ausgedruckt am: 09.03.2025 um 15:03 Uhr
8 Kommentare
Neuester Kommentar
In der Regel sind das Programme die NetFlow oder sFlow Daten auswerten über eine SQL Datenbank wie pmacct, netflowtools usw.
Die verbreitesten sind
http://www.networkuptime.com/tools/netflow/
http://www.pmacct.net
usw. usw.
Cacti und MRTG werden auch vielfach verwendet.
Netzwerk Management Server mit Raspberry Pi
Wie sowas in Real Life aussieht kannst du bei z.B. AMSIX sehen:
https://ams-ix.net/technical/statistics/sflow-stats
und
https://ams-ix.net/technical/specifications-descriptions/sflow-at-ams-ix
Die verbreitesten sind
http://www.networkuptime.com/tools/netflow/
http://www.pmacct.net
usw. usw.
Cacti und MRTG werden auch vielfach verwendet.
Netzwerk Management Server mit Raspberry Pi
Wie sowas in Real Life aussieht kannst du bei z.B. AMSIX sehen:
https://ams-ix.net/technical/statistics/sflow-stats
und
https://ams-ix.net/technical/specifications-descriptions/sflow-at-ams-ix
Zitat von @aqui:
In der Regel sind das Programme die NetFlow oder sFlow Daten auswerten über eine SQL Datenbank wie pmacct, netflowtools usw.
Ok, das heißt man kann zB mit pmacct die flows einsammeln und in eine DB schreiben... Wie kann man nun eine grafische Auswertung von den Daten die in der DB liegen machen? Die grafische Auswertung wie bei AMS-IX trifft meine Vorstellung recht gut.In der Regel sind das Programme die NetFlow oder sFlow Daten auswerten über eine SQL Datenbank wie pmacct, netflowtools usw.
das heißt man kann zB mit pmacct die flows einsammeln und in eine DB schreiben...
Exakt !Wie kann man nun eine grafische Auswertung von den Daten die in der DB liegen machen?
MRTG bzw. die RRD Tools ist da der Klassiker. Es gibt auch noch sowas wie Munin usw.http://oss.oetiker.ch/rrdtool/
http://oss.oetiker.ch/mrtg/
http://munin-monitoring.org
Für den kleinen Bereich mit sFlow gibt es auch ein paar freie Tools von Inmon:
http://www.inmon.com/products/sFlowTrend.php
http://www.inmon.com/technology/sflowTools.php
Netzwerk Management Server mit Raspberry Pi
Zum Flow-Accounting sei gesagt, dass es einen entscheidenden Nachteil hat:
Es benötigt enorme Ressourcen auf der regulären CPU (zumindest bei Cisco) und wenn es die nicht bekommt, kommen keine Verbindungen mehr zustande.
Sollte z.B. eine IP per SYN-Flood attackiert werden ist es sehr wahrscheinlich, dass trotz der geringen Bandbreite euer gesamtes Netz nicht mehr erreichbar ist, weil der Router mit seinem Accounting nicht hinterher kommt. Und evtl. leiden auch weitere Dienste wie BGP darunter, dass die CPU längere Zeit komplett ausgelastet wird.
Wenn es dir wirklich nur um reine Bandbreiten-Graphen geht: Frage die per MRTG via SNMP vom Router ab und lasse den Flow-Kram sein
Der hat zwar den Mehrwert dass du damit auch rausfindest welche IP über welchen Port wie viel Traffic verursacht, das allerdings wie gesagt zum Preis, dass du hin und wieder Packetloss bekommst, wenn die CPU des Routers nicht hinterher kommt.
Es benötigt enorme Ressourcen auf der regulären CPU (zumindest bei Cisco) und wenn es die nicht bekommt, kommen keine Verbindungen mehr zustande.
Sollte z.B. eine IP per SYN-Flood attackiert werden ist es sehr wahrscheinlich, dass trotz der geringen Bandbreite euer gesamtes Netz nicht mehr erreichbar ist, weil der Router mit seinem Accounting nicht hinterher kommt. Und evtl. leiden auch weitere Dienste wie BGP darunter, dass die CPU längere Zeit komplett ausgelastet wird.
Wenn es dir wirklich nur um reine Bandbreiten-Graphen geht: Frage die per MRTG via SNMP vom Router ab und lasse den Flow-Kram sein
Der hat zwar den Mehrwert dass du damit auch rausfindest welche IP über welchen Port wie viel Traffic verursacht, das allerdings wie gesagt zum Preis, dass du hin und wieder Packetloss bekommst, wenn die CPU des Routers nicht hinterher kommt.
Zitat von @LordGurke:
Zum Flow-Accounting sei gesagt, dass es einen entscheidenden Nachteil hat:
Es benötigt enorme Ressourcen auf der regulären CPU (zumindest bei Cisco) und wenn es die nicht bekommt, kommen keine Verbindungen mehr zustande.
Sollte z.B. eine IP per SYN-Flood attackiert werden ist es sehr wahrscheinlich, dass trotz der geringen Bandbreite euer gesamtes Netz nicht mehr erreichbar ist, weil der Router mit seinem Accounting nicht hinterher kommt.
Das kann ich mir irgendwie nicht vorstellen. Dass IPs von Kunden bei großen Providern geflutet werden kommt schon hin und wieder vor... Das würde ja dann bedeuten, dass jedes Mal das Provider Netz welches über den betroffenen Router läuft komplett ausfällt?Zum Flow-Accounting sei gesagt, dass es einen entscheidenden Nachteil hat:
Es benötigt enorme Ressourcen auf der regulären CPU (zumindest bei Cisco) und wenn es die nicht bekommt, kommen keine Verbindungen mehr zustande.
Sollte z.B. eine IP per SYN-Flood attackiert werden ist es sehr wahrscheinlich, dass trotz der geringen Bandbreite euer gesamtes Netz nicht mehr erreichbar ist, weil der Router mit seinem Accounting nicht hinterher kommt.
Es benötigt enorme Ressourcen auf der regulären CPU
Andere wie Brocade, Extreme etc. machen es direkt in Hardware (Port ASIC). AMSIX benutzt z.B. ausschliesslich Brocade HW. Da muss man eher ein Augenmerk auf den Flow Collector haben.Syn Flood Attacken kann man recht schnell mit entsprechenden Flow Analyzern erkennen und dann per SDN (OpenFlow) Massnahmen ergreifen z.B. was die CIXe auch z.T. schon so machen.
Das erfordert aber entsprechende HW die OpenFlow Hybrid Modes usw. supporten.
Bei einfachem quantitativem Überblick reichen aber die SNMP Counter, keine Frage.
Wie kommt man denn an solche Infomationen? Sowas steht vermutlich weniger im Datenblatt der Hardware, oder?
Richtig.
An sowas kommt man meist nur über Systempartner oder die Distribution oder den Hersteller selber. Die haben Datenblätter mit dedizierter HW Information aus der sowas ersichtlich ist.
Oft wird sowas auch in gut gemachten Ausschreibungen gefordert wo Hersteller dann die Hosen runterlassen müssen wenn sie sich da bewerben.
Endkunden ohne solche Infos merken das oft schmerzlicher wenn nach dem 3ten Port mit sFlow dann der Switch kollabiert. Das sind dann die Buhmänner die es kosmetisch im Datenblatt stehen haben aber nicht wie sie es umsetzen....
An sowas kommt man meist nur über Systempartner oder die Distribution oder den Hersteller selber. Die haben Datenblätter mit dedizierter HW Information aus der sowas ersichtlich ist.
Oft wird sowas auch in gut gemachten Ausschreibungen gefordert wo Hersteller dann die Hosen runterlassen müssen wenn sie sich da bewerben.
Endkunden ohne solche Infos merken das oft schmerzlicher wenn nach dem 3ten Port mit sFlow dann der Switch kollabiert. Das sind dann die Buhmänner die es kosmetisch im Datenblatt stehen haben aber nicht wie sie es umsetzen....
