Netzwerkverkehr mitlesen, wo

[snaxilian]

Weiß jemand hier eine Möglichkeit unter Linux (Xubuntu) die Uploadrate über einen längeren Zeitraum zu erfassen?

1. Kannst du sicher stellen, dass die Gegenseite, die die Daten empfängt, nie ausgelastet ist?
2. Ist die Gegenseite beim gleichen Provider sodass Peeringprobleme ausgeschlossen werden können?
3. Kannst du sicher stellen, dass das sendende System nicht der Flaschenhals ist?
4. Kannst du sicher stellen, dass nicht das verwendete Protokoll zur Datenübertragung das Problem ist?

Wenn du es fein granular haben willst:
telegraf > sammelt die Daten des $buntu Systems
influxdb > speichert die von telegraf gesammelten Daten in einer tsdb (time series data base)
grafana > nimmt die Daten aus influxdb und bereit diese grafisch auf

Wenn du $suchmaschine mit "telegraf grafana network monitoring" fütterst sollte das ein oder andere Tutorial raus purzeln.

Wenn es minütliche Momentaufnahmen reichen würde ich auf traditionellere und kleinere Lösungen setzen wie z.B. Munin oder checkmk. Beides recht schnell aufgesetzt. Wenn ihr sowieso ne Fritzbox habt: checkmk hat da fertige Checks für Fritzboxen an Bord und speichert dir die Ergebnisse weg. Dürfte vermutlich schneller aufgesetzt sein als munin oder telegraf+influxdb+grafana.

 

[Tom_top]

Lt. Aussage des ITlers der die techn. Infrastruktur bei uns aufgebaut hat und das ganze Prozedere drumherum managt liegt es an unserem Anschluss, genauer am mangelnden Durchsatz beim Upload. Ich habe keinen Grund an seiner Aussage zu zweifeln.
ad 1.) Sicherstellen kann ich das nicht, aber ich bezweifle das stark.
ad 2.) Die Daten landen, soweit ich das weiß in der Amazon Cloud.
ad 3.) Da fehlt mir die Vorstellung was genau du meinst. Die Hardware, sprich der Rechner der die Daten versenden soll, wurde im Vorfeld basierend auf den Anforderungen zusammengestellt.
ad 4.) Hier muss ich passen, weil ich nicht was du meinst.

Wir drücken seit Monaten sehr große Datenmengen (ca 1-2 TB/Woche) durchs Netz, kontinuierlich und rund um die Uhr. Schon über diesen Zeitraum lässt sich ohne weitere Analysen feststellen ob der aktuelle Upload "schnell" oder "langsam" ist und wie er sich über die Zeit verändert. Gerade ist er wieder extrem langsam.
Ironischerweise wurde er noch langsamer nachdem ich am Freitag im Shop war und die aus der Ferne "Optimierungsmaßnahmen" durchgeführt haben.
Danke für die Schlagworte, ich lese mich mal ein.

 

[snaxilian]

Zum letzteren meine ich: Manche Übertragungsprotokolle haben einen größeren "Overhead" als andere, sodass effektiv weniger Nutzlast an eigentlichen Daten übertragen werden kann was im Ergebnis dann dazu führt, dass die Übertragungsrate vermeintlich geringer ist. Sollte in dem Fall aber irrelevant sein würde ich vermuten.

Amazon Cloud

Ach ja und die haben natürlich nur einen Standort. Ach ne doch nicht. Du redest von technischen Problemen und kommst mit dem Informationsgehalt eines leeren Schuhkartons. AWS Frankfurt? Shanghai? Antarktis? Südafrika? Irland? USA East? USA West? Das macht einen absolut relevanten Unterschied.
Wie gesagt was du brauchst ist eine Monitoring Lösung mit der du im besten Fall den Durchsatz entweder am PC oder besser am Router auslesen kannst.
Hier hat das schon einmal jemand quick and dirty mit einem Raspi nachgebaut aber das kann prinzipiell auf jedem Linux laufen. Ist halt 0 auf Sicherheit bedacht und für den privaten Gebrauch gedacht. Wenn ihr aber einen IT-Menschen für die Infrastruktur habt dann hoffe ich inständig, dass du zusammen mit ihm an dem Problem arbeitest und nicht dran vorbei...

 

[conf_t]

Zum letzteren meine ich: Manche Übertragungsprotokolle haben einen größeren "Overhead" als andere, sodass

Zwar richtig, der Punkt ist aber praktisch bei heutigen Bandbreiten irrelevant geworden.
Ein Ethernetframe mit 1500 bytes Payload hat einen 18 bytes Ethernet Header plus ggf. 4 bytes für VLANs. Also belegt 1518-1522 bytes auf der Leitung.
Die Payload von IP ist dann aufgrund der 20 bytes Headers noch mal 20 bytes weniger, also 1480.
Die Payload des Transportprotokolls, UDP bzw. TCP liegt dann noch mal 8 bytes (UDP) bzw. 20 bytes (TCP) darunter.

Wirklichen Einfluss haben die Transportprotokolle nicht. Ob ein Ethernetframe nun 1460 bytes TCP Payload hat oder 1472 bytes UDP payload ist nicht wirklich relevant. Der Overhead für Ethernet und IP fällt so oder so an. Da ist eine RAS / VPN Einwahl schon entscheidender, die geht dann runter auf eine Payload unterhalb der 1400 bytes.

Das gibt es relevantere Bremsen, wie zu kleines TCP-Receiver Window, fehlendes oder nicht genutzten TCP-SACK, TCP-Window-Scalling (gerade bei SQL und Oracle Datenbanken). dauerhaft zu kleine Datenpakete (tritt auch gerne bei Datenbanken - habe mal unverschlüsselte SQL DB gesnifft, die jedes Zeichen eines Befehls in einem eigenen Paket übertragen hat, man war das schnell und effizient - nicht) usw. die auf Protokollebene bremsen, aber nicht wie du es erklärst wegen der Payload, sondern wegen Administratoren, die unfähig sind die richtigen Einstellungen zu setzen oder wegen Programmieren denen egal ist wie im Netzwerk die Kommunikationsregeln sind. Gepaart mit einer Latenz größer 10 ms ist das für viele Anwendungen das Todesurteil.

 

[snaxilian]

Dann haben wir aneinander vorbei geredet^^ Ich meinte mit Protokolle das ganze Layer 7 Geraffel, also ineffiziente Anwendungen wie dein SQL Beispiel.

 

[conf_t]

Ah, ok, das sind dann aber keine Übertragungsprotokolle, sondern Anwendungsprotokolle. Dann passt das schon eher, wobei die meisten dort auch recht effizient genutzt (selbst smb ab v2 - erst recht ab v3) werden können, die Frage ist immer, kann es auch die Anwendung? Vergleiche mal im Wireshark das Laden einer Datei von einer Dateifreigabe in Excel und das Kopieren selbiger im Explorer. In beiden Fällen wird SMB genutzt, ein oftmals gemessener Faktor war 5-8 mal so langsam per Excel, als per Explorer - was nicht an der Berechnung der Excel lag.
Und die schlechteste Anwendung, die nicht mit SMB umgehen kann ist Wireshark selbst. Niemals per Dateifreigabe eine PCAP öffnen.

 

[Tom_top]

Kleines Update zu unserem Uploadproblem: Ockham hat sich mal wieder rasiert
Man hat sich des Problems seitens unseres IT-Kooperationspartners angekommen, das ganze via Feenglas ... ne keine Ahnung wie beobachtet, wir bekommen nun tages- bzw. wochenweise schöne Graphiken mit den entsprechenden Uploadraten und das ernüchternde Zwischenfazit: der Provider kann nicht liefern was auf dem Papier steht. Nicht mal annäherungsweise. Und als Argument kommt dann auch noch: "sorry, Homeoffice und so belastet unsere Leitungen stärker als sonst".

 

[Raijin]

der Provider kann nicht liefern was auf dem Papier steht. Nicht mal annäherungsweise.

Man bedenke, dass Provider penibelst darauf achten, dass überall nur "bis zu xxx Mbit/s" steht. Die Leitungen werden ganz bewusst überbucht. Wenn der Provider in der Straße zB nur 1 Gbit/s Uplink insgesamt hat, kann er theoretisch nur 10 Kunden 100 Mbit/s bieten. Tatsächlich verkauft er aber zB 20x 100 Mbit/s. Das ist nicht so verwerflich wie es im ersten Moment klingt, sondern ein Erfahrungswert. Im Schnitt sind beispielsweise zu jedem Zeitpunkt nur max 10 Kunden online und belasten den Uplink und wenn die 10 offline gehen, kommen die anderen 10 mit Last. Unterm Strich reicht der Uplink also aus.

Nu ist es aber leider so, dass hier ein schickes Stellrad für Profit ist. Reicht die Leitung, die in der Theorie nur für 10 Kunden ausreicht, in der Praxis für 20 Kunden aus, kann man ja den Kunden übervorteilen und die Leitung insgesamt 30x verkaufen, wird schon gut gehen. Im Vertrag schreibt man dann "bis zu" und weiß genau, dass man den Sweet Spot bereits überschritten hat und somit eben auch der Kunde merkt, dass der Uplink überlastet ist.


Als Kunde kann man dagegen leider nur wenig tun. Die einzige Handhabe, die man hat, ist die vertraglich zugesicherte Mindestbandbreite einzufordern, die falls nicht explizit angegeben beim "bis zu" des nächstniedrigeren Tarif liegt. Wenn man zB 50 Mbit/s gebucht hat und es einen Tarif mit 25 Mbit/s gibt, darf der 50er Anschluss nicht unter 25 Mbit/s sinken, weil man sonst Preisnachlass fordern darf, was effektiv heißt, dass man in den günstigeren Tarif wechselt. Kommen aus dem 50er Anschluss aber 30 Mbit/s raus, hat man keine Handhabe, wenn in den AGB nicht explizit ein anderer Wert steht.

 

[conf_t]

Eine weitere, aber dann teurere Alternative nutzen wir im Konzern: Leased-Lines - dedizierte Leitungen, die man mietet. Zumindest bis in den Provider Backbone hat man dann auch die zugesicherte Bandbreite. Man hat kein "bis zu xxx" sondern bei 100 Mbit/s, hat man 100 Mbit/s. Je nach Vertrag sind schon nur noch 10% weniger oder noch weniger eine ggf. pönalebewährte Vertragsverletzung..... Das sind aber oftmals Individualverträge - nichts von der Stange für das 08/15-Geschäft. Wenn wir das wollen legt unser Provider auch nach Hinterupflingen wo es nicht mal DSL-light gibt, für uns eine LWL mit 10 Gigabit aus dem Rahmenvertrag (aber wir bezahlen auch eine Menge Geld). Erschließung dauert dann auch mal 1-2 Jahre.