5
VLAN-Datenverkehr zwischen zwei Routern läuft asymetrisch, obwohl der Routerbandbreitentest gleiche Geschwindigkeit in beide Richtungen liefert
Hallo!
Wir binden eine Außenstelle aufgrund spezieller örtlicher Verhältnisse über fünf hintereinander geschaltete Richtfunkstrecken an unsere Zentrale an. An den beiden Endpunkten sitzen jeweils Mikrotik Cloud Core-Router. Wenn man den Mikrotik Bandbreitentest nutzt, wird angezeigt, dass die Mikrotik-Router in beide Richtungen volle Bandbreite (ca. 100 Mbit/s) liefern. Wenn man aber zwischen einem PC/Server in der Zentrale und einem PC in der Außenstelle Dateien transferiert, so bekommen wir die 100 Mbit/s nur auf der Richtung Außenstelle zu Zentrale. Von der Zentrale zur Außenstelle werden nur ca. 22-25 Mbit/s erreicht. Hat jemand eine Idee, woran es liegen kann, dass der Mikrotik-Speedtest die volle Geschwindigkeit in beide Richtungen anzeigt, der Windows-Dateitransfer in eine Richtung aber nur ca. 1/4 der Bandbreite nutzt/nutzen kann?
Zwischen den Mikrotik-Cloud-Core-Routern wird der Datenverkehr per VLAN weitergereicht (Ja, Layer-2-Anbindung, die Außenstelle hat keinen eigenen Adressraum). Eine MPLS-Fehlkonfiguration (unterschiedliche Wege) müsste daher ausschließbar sein.
Wir binden eine Außenstelle aufgrund spezieller örtlicher Verhältnisse über fünf hintereinander geschaltete Richtfunkstrecken an unsere Zentrale an. An den beiden Endpunkten sitzen jeweils Mikrotik Cloud Core-Router. Wenn man den Mikrotik Bandbreitentest nutzt, wird angezeigt, dass die Mikrotik-Router in beide Richtungen volle Bandbreite (ca. 100 Mbit/s) liefern. Wenn man aber zwischen einem PC/Server in der Zentrale und einem PC in der Außenstelle Dateien transferiert, so bekommen wir die 100 Mbit/s nur auf der Richtung Außenstelle zu Zentrale. Von der Zentrale zur Außenstelle werden nur ca. 22-25 Mbit/s erreicht. Hat jemand eine Idee, woran es liegen kann, dass der Mikrotik-Speedtest die volle Geschwindigkeit in beide Richtungen anzeigt, der Windows-Dateitransfer in eine Richtung aber nur ca. 1/4 der Bandbreite nutzt/nutzen kann?
Zwischen den Mikrotik-Cloud-Core-Routern wird der Datenverkehr per VLAN weitergereicht (Ja, Layer-2-Anbindung, die Außenstelle hat keinen eigenen Adressraum). Eine MPLS-Fehlkonfiguration (unterschiedliche Wege) müsste daher ausschließbar sein.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 314446
Url: https://administrator.de/contentid/314446
Ausgedruckt am: 22.11.2024 um 10:11 Uhr
5 Kommentare
Neuester Kommentar
Eine Layer 2 Anbindung über die Funkstrecke ist tödlich und ein vollkommen falsches Design. Gerade in deinem speziellen Falle mit 5 ! kaskadierten RiFu Strecken. Eigentlich ein totales NoGo und man kann sich nur wundern wer solch ein Design verbrochen hat.
Letztlich dürfte das die Ursache des problems sein. Ziel sollte es sein unter jeden Umständen überflüssigen Traffic von der RiFu Strecke fernzuhalten um die Performance für die Nutzdaten auf hohem Niveau zu halten.
Genau das ist bei einer L2 Kopplung nicht der Fall !
Die RiFu Strecke wird jetzt von den beiden angeschlossenen LANs mit sämtlichem Broad- und Multicast Traffic belastet aus diesen Segmenten, den Durchsatz einschränkt. Ein NoGo.
Hier ist in jedem Fall ein geroutetes Szenario Pflicht. Und zwar auf den beiden LAN Routern, so das die Funkstrecke in ihrer Gesamtheit als separates IP Segment zu sehen ist:
(LAN 1)---Router---(Funkstrecken mit 5 Hops)---Router---(LAN2)
Das garantiert optimale Performance !
Hast du uns hier vom Design was unterschlagen ? Gibt es noch eine Backup Strecke über MPLS ?
Sollte das der Fall sein bist du mit dem Layer 2 Design erst recht völlig falsch, denn das würde ja ein Routing erzwingen.
Was MPLS da jetzt in dem Zusammenhang für eine Rolle spielt bleibt vollkommen unklar. Das eine hat mit dem anderen rein gar nichts zu tun !
Aus Funksicht bzw. globaler Design Sicht ist das ein völliges Fehldesign und zeigt eher das derjenige der das verbrochen hat recht wenig von Netzwerken bzw. Funknetzen versteht.
Kann man nur hoffen das du das nicht selber warst... ?!
Langfristig wirst du das umstellen müssen von dem falschen Bridging auf Routing. Alles andere ist dillettantische Frickelei die weitere Probleme bereiten wird.
Letztlich dürfte das die Ursache des problems sein. Ziel sollte es sein unter jeden Umständen überflüssigen Traffic von der RiFu Strecke fernzuhalten um die Performance für die Nutzdaten auf hohem Niveau zu halten.
Genau das ist bei einer L2 Kopplung nicht der Fall !
Die RiFu Strecke wird jetzt von den beiden angeschlossenen LANs mit sämtlichem Broad- und Multicast Traffic belastet aus diesen Segmenten, den Durchsatz einschränkt. Ein NoGo.
Hier ist in jedem Fall ein geroutetes Szenario Pflicht. Und zwar auf den beiden LAN Routern, so das die Funkstrecke in ihrer Gesamtheit als separates IP Segment zu sehen ist:
(LAN 1)---Router---(Funkstrecken mit 5 Hops)---Router---(LAN2)
Das garantiert optimale Performance !
Eine MPLS-Fehlkonfiguration (unterschiedliche Wege) müsste daher ausschließbar sein.
Was soll das heissen ??Hast du uns hier vom Design was unterschlagen ? Gibt es noch eine Backup Strecke über MPLS ?
Sollte das der Fall sein bist du mit dem Layer 2 Design erst recht völlig falsch, denn das würde ja ein Routing erzwingen.
Was MPLS da jetzt in dem Zusammenhang für eine Rolle spielt bleibt vollkommen unklar. Das eine hat mit dem anderen rein gar nichts zu tun !
Aus Funksicht bzw. globaler Design Sicht ist das ein völliges Fehldesign und zeigt eher das derjenige der das verbrochen hat recht wenig von Netzwerken bzw. Funknetzen versteht.
Kann man nur hoffen das du das nicht selber warst... ?!
Langfristig wirst du das umstellen müssen von dem falschen Bridging auf Routing. Alles andere ist dillettantische Frickelei die weitere Probleme bereiten wird.
Die Verbindung läuft über einen lokalen Anbieter, der eine Richtfunkinfrastruktur vor Ort hat. Er hat einen layer-2-Tunnel für uns erzeugt. Im Hintergrund hat er das ganze wohl über MPLS realisiert. Um eine MPLS-Fehlkonfiguration auszuschließen, wurde dann auf VLAN umgebaut (also ohne automatisches Backup-Routing). Aber die Probleme bestehen weiterhin, daher meine Anfrage. Jetzt glaubt natürlich jeder, dass jeweils der andere Schuld ist... Wir vertragen uns noch gut, aber so langsam gehen uns die Ideen aus, daher meine Anfrage,
Es wurde auf Layer2 anstatt Layer3 gesetzt, da die Außenstelle nur temporär (einige Monate) benötigt wird und man sich die Umkonfigurationsarbeiten sparen wollte...
Es wurde auf Layer2 anstatt Layer3 gesetzt, da die Außenstelle nur temporär (einige Monate) benötigt wird und man sich die Umkonfigurationsarbeiten sparen wollte...
OK, dann kann man das verschmerzen. Du darfst aber nicht außer Acht lassen das die Broad- und Multicast Last beider LAN Segmente die Strecke beeinflussen.
So oder so ist es ja vollkommen egal wie der lokale Provider die Funkstrecke löst, für dich ist das ja nix weiter als ein transparenter Draht, quasi wie ein simples Patchkabel.
Die generelle Frage die sich hier stellt ob ihr im Vertrag eine garantierte bandbreite habt. Wenn der lokale Anbiter das mit MPLS und VPLS macht ist es möglich das das grundlegende Netz mit mehreren Usern geshared wird ! Denn er wird solchen technischen Aufwand nicht nur für euch treiben.
Du solltest die Durchsatzmessung auch niemals mit Dateikopieren machen. Schon gar nicht mit SMB/CIFS, denn das ist sehr ineffizient da es sehr kleine Pakete nutzt und Leitungen nicht auslasten kann.
Besser du machst das nochmal mit NetIO:
http://www.ars.de/ars/ars.nsf/docs/netio
bzw.
http://www.nwlab.net/art/netio/netio.html
Damit bekommst du eine bessere und verlässlichere Aussage des Durchsatzes ohne störenden Protokolloverhead und vor allen Dingen spezifiziert nach Paketgröße !
Das wäre hilfreich.
So oder so ist es ja vollkommen egal wie der lokale Provider die Funkstrecke löst, für dich ist das ja nix weiter als ein transparenter Draht, quasi wie ein simples Patchkabel.
Die generelle Frage die sich hier stellt ob ihr im Vertrag eine garantierte bandbreite habt. Wenn der lokale Anbiter das mit MPLS und VPLS macht ist es möglich das das grundlegende Netz mit mehreren Usern geshared wird ! Denn er wird solchen technischen Aufwand nicht nur für euch treiben.
Du solltest die Durchsatzmessung auch niemals mit Dateikopieren machen. Schon gar nicht mit SMB/CIFS, denn das ist sehr ineffizient da es sehr kleine Pakete nutzt und Leitungen nicht auslasten kann.
Besser du machst das nochmal mit NetIO:
http://www.ars.de/ars/ars.nsf/docs/netio
bzw.
http://www.nwlab.net/art/netio/netio.html
Damit bekommst du eine bessere und verlässlichere Aussage des Durchsatzes ohne störenden Protokolloverhead und vor allen Dingen spezifiziert nach Paketgröße !
Das wäre hilfreich.
Danke für den Tip!
Mit NetIO bekomem ich folgende Ergebnisse (Messung Zentrale zu Außenstelle):
TCP
=> Zentrale zu Außenstelle ist nur 1/4 der Bandbreite Außenstelle zu Zentrale.
UDP
=> Bei UDP nimmt die Bandbreite beim Versenden Zentrale zu Außenstelle ab, je größer die Pakete werden? Das ist seltsam, oder?
=> Was geben die Prozentwerte bei den UDP-Ergebnissen an?
Mit NetIO bekomem ich folgende Ergebnisse (Messung Zentrale zu Außenstelle):
TCP
Packet size 1k bytes: 2675.96 KByte/s Tx, 8217.60 KByte/s Rx.
Packet size 2k bytes: 2392.55 KByte/s Tx, 8597.43 KByte/s Rx.
Packet size 4k bytes: 2512.17 KByte/s Tx, 10.82 MByte/s Rx.
Packet size 8k bytes: 2567.24 KByte/s Tx, 10.30 MByte/s Rx.
Packet size 16k bytes: 2708.43 KByte/s Tx, 10.73 MByte/s Rx.
Packet size 32k bytes: 2808.60 KByte/s Tx, 10.98 MByte/s Rx.
Done.=> Zentrale zu Außenstelle ist nur 1/4 der Bandbreite Außenstelle zu Zentrale.
UDP
Packet size 1k bytes: 11.50 MByte/s (89%) Tx, 9501.91 KByte/s (16%) Rx.
Packet size 2k bytes: 10022.77 KByte/s (50%) Tx, 10.48 MByte/s (6%) Rx.
Packet size 4k bytes: 3405.66 KByte/s (91%) Tx, 9.96 MByte/s (12%) Rx.
Packet size 8k bytes: 1073.22 KByte/s (98%) Tx, 11.13 MByte/s (2%) Rx.
Packet size 16k bytes: 451.11 KByte/s (99%) Tx, 10.56 MByte/s (6%) Rx.
Packet size 32k bytes: 394.91 KByte/s (99%) Tx, 10.80 MByte/s (5%) Rx.
Done.=> Bei UDP nimmt die Bandbreite beim Versenden Zentrale zu Außenstelle ab, je größer die Pakete werden? Das ist seltsam, oder?
=> Was geben die Prozentwerte bei den UDP-Ergebnissen an?
Problem ist ja hier scheinbar der Sendezweig wie du ja auch selber siehst !
Die RX Daten sind ja einwandfrei. 80-90 Mbit/s sind ein sehr ralistischer Wert.
Bei den TX Daten fällt auch auf das die erheblich schwanken (UDP) und kaum mehr als 20Mbit/s im besten Falle rausgehen. Worst Case ist hier 4Mbit/s
Die Schwankungen lassen auf ein Sharing schliessen, deshalb die Frage der commiteten Bandbreite.
Sinnvoll wäre jetzt nochmal der Rückweg gewesen also Außenstelle zur Zentrale.
Was die Prozentzahlen anbetrifft kann man das so interpretieren das TCP ja eine gesicherte Verbindung realisiert. Hier kann es also nicht zu Paket Losses kommen. Nicht so bei UDP.
Vermutlich geben die Prozentzahlen die Anzahl der Paket Losses aus, denn die Werte werden besser je besser der Durchsatz ist.
Ist jetzt mal hergeleitet da eine genaue Beschreibung dazu fehlt und auch der .doc File im Paket nix dazu sagt. Der Quellcode könnte das verraten.
Die RX Daten sind ja einwandfrei. 80-90 Mbit/s sind ein sehr ralistischer Wert.
Bei den TX Daten fällt auch auf das die erheblich schwanken (UDP) und kaum mehr als 20Mbit/s im besten Falle rausgehen. Worst Case ist hier 4Mbit/s
Die Schwankungen lassen auf ein Sharing schliessen, deshalb die Frage der commiteten Bandbreite.
Sinnvoll wäre jetzt nochmal der Rückweg gewesen also Außenstelle zur Zentrale.
Was die Prozentzahlen anbetrifft kann man das so interpretieren das TCP ja eine gesicherte Verbindung realisiert. Hier kann es also nicht zu Paket Losses kommen. Nicht so bei UDP.
Vermutlich geben die Prozentzahlen die Anzahl der Paket Losses aus, denn die Werte werden besser je besser der Durchsatz ist.
Ist jetzt mal hergeleitet da eine genaue Beschreibung dazu fehlt und auch der .doc File im Paket nix dazu sagt. Der Quellcode könnte das verraten.
