Fehlerbehebung bei niedrigem Durchsatz von Metro Ethernet TCP

14

Die Einrichtung

Wir haben einige Mietleitungen gemietet, die sich als Layer-2-Netzwerk präsentieren, dh Sie haben eine große Leitung im Rechenzentrum und die entfernten Standorte haben kleinere Leitungen. Innerhalb des Layer 2-Netzwerks können Sie tun, was Sie möchten. Wahrscheinlich verwenden sie 802.1ad, um jedem Kunden sein eigenes Netzwerk innerhalb seines Netzwerks zuzuweisen. AFAICS die meisten Standorte sind über einfaches VDSL verbunden.

Wir haben beschlossen, an jedem Standort einen Router einzurichten und jedem Standort ein eigenes VLAN zuzuweisen. In der Firewall am DC sind somit so viele VLANs definiert, wie Standorte vorhanden sind. Jeder Standort verwendet daher seinen On-Adressbereich in seinem eigenen VLAN.

Netzwerkdiagramm:

netzwerkdiagramm

Das Problem

Jetzt stehen wir vor Durchsatzproblemen:

  • Das Ausführen einer FTP-Übertragung von der Site zum DC funktioniert einwandfrei mit einer Geschwindigkeit von ca. 10 MBit / s (Leitungsgeschwindigkeit).
  • Das Ausführen einer FTP-Übertragung von DC zu Site funktioniert bei 6 MBit / s oder weniger nicht einwandfrei.

Es spielt keine Rolle, welche Seite die Übertragung initiiert. Die einzig beständige Sache ist, dass eine Richtung nicht gut funktioniert. Schade, dass dies die Richtung zum Standort ist, da dies die Bandbreite ist, die wir am meisten benötigen, da wir Terminalserver-Clients verwenden möchten.

Ungefähr 10 Sekunden nach dem Transfer sinkt der Durchsatz. Wir sehen DUP ACKs beim Schnüffeln. Was führt mich vielleicht zu einer Ratenbegrenzung am Ende des Anbieters? (Derzeit haben sie keine Ahnung, und ich möchte sicherstellen, dass wir keine Schuld haben, bevor ich eskaliere.)

HINWEIS Die entfernten Standorte sind irgendwie auf 10 MB beschränkt. Das Setzen des Switch-to-Metro-Ports auf 10 MB hilft auch nicht. In der Tat ist es dann das Schlimmste (max. 30 KB / s). Die Einstellung auf 100 MB funktioniert einwandfrei, führt jedoch bereits zu dem beschriebenen Problem. Gleiches gilt für 1G.

Die Aufzeichnungen des Problems können hier heruntergeladen werden:

* http://178.63.11.6/dc-to-remote_dc-side.pcapng
* http://178.63.11.6/dc-to-remote_remote-side.pcapng

Diagnose

Im Bild sehen Sie das Wireshark IO-Diagramm mit einigen Fehlerdetails:

  • links: FTP-Transfer von DC zur Site
  • rechts: FTP-Transfer von Site zu DC

Acks duplizieren

Falls die andere Seite die Übertragung einleitet (dh von dc anstatt von remote), bleibt das Problem unverändert.

Bitte gönnen Sie mir, was Ihrer Meinung nach das Problem sein könnte.

UPDATE # 1 (oben integriert)

UPDATE # 2 ( AKTUALISIERT )

Dies muss eine Sache zur Überlastungskontrolle sein.

Beachten Sie, dass wir von DC zu Remote 10G-> 1G-> 100M-> 10M-> 1G-Verbindungen haben. <- funktioniert nicht

In der anderen Richtung haben wir also das Gegenteil: 1G -> 10M -> 100M -> 1G -> 10G. <- ganz gut

Das erste "1G-> 10M" ist das "unsichtbare" 10M am Remote-Standort, bei dem die Geschwindigkeit des Uplink-Ports auf 1G festgelegt ist, obwohl nur 10M dahinter stehen (verkauft werden).

Die 100 Mbit / s am DC sind jedoch echte 100 Mbit / s, die Schnittstelle ist auf der physischen Ebene mit 100 Mbit / s konfiguriert.

Ich habe jetzt iperf benutzt:

  • TCP- Tests funktionieren nur in einer Richtung (Client = DC, Server = Remote)
./iperf -c 192.168.x -i2 -t 60 -r
-------------------------------------------------- ----------
Server überwacht TCP-Port 5001
TCP-Fenstergröße: 85,3 KByte (Standard)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Client, der eine Verbindung zu 192.168.x, TCP-Port 5001 herstellt
TCP-Fenstergröße: 16,0 KByte (Standard)
-------------------------------------------------- ----------
[3] Lokaler 10.x-Port 38195, verbunden mit 192.168.x-Port 5001
[3] 0,0 - 2,0 Sek. 1,44 MByte 6,03 MBit / Sek
[3] 2,0 - 4,0 Sek. 2,23 MByte 9,37 Mbits / Sek
[3] 4,0 - 6,0 Sek. 2,28 MByte 9,57 MBit / Sek
[3] 6,0 - 8,0 Sek. 1,88 MByte, 7,90 MBits / Sek
[3] 8,0-10,0 Sek. 1,00 MByte 4,19 MBits / Sek
[3] 10,0-12,0 Sek. 1,30 MByte 5,47 Mbits / Sek
[3] 12,0-14,0 Sek. 688 KBytes 2,82 Mbits / Sek
[3] 14,0-16,0 Sek. 840 KB 3,44 Mbits / Sek
[3] 16,0-18,0 Sek. 1,03 MByte 4,33 MBits / Sek
[3] 18,0 - 20,0 Sek. 1,01 MB 4,23 MBit / Sek
[3] 20,0-22,0 Sek. 1,03 MByte 4,33 Mbits / Sek
[3] 22,0-24,0 Sek. 1,18 MByte 4,95 Mbits / Sek
[3] 24,0-26,0 Sek. 904 KByte 3,70 Mbits / Sek
[3] 26,0-28,0 Sek. 840 KB 3,44 Mbits / Sek
[3] 28,0-30,0 Sek. 936 KByte 3,83 Mbits / Sek
[3] 30,0-32,0 Sek. 1,09 MB 4,59 MBit / Sek
[3] 32,0-34,0 Sek. 960 KB 3,93 Mbits / Sek
[3] 34,0-36,0 Sek. 752 KByte 3,08 Mbits / Sek
[3] 36,0-38,0 Sek. 1,09 MB 4,59 MBit / Sek
[3] 38,0-40,0 Sek. 1,09 MByte 4,59 Mbits / Sek
[3] 40,0-42,0 Sek. 840 KB 3,44 Mbits / Sek
[3] 42,0-44,0 Sek. 1,27 MByte 5,34 Mbits / Sek
[3] 44,0-46,0 Sek. 1,16 MByte 4,85 Mbits / Sek
[3] 46,0-48,0 Sek. 840 KB 3,44 Mbits / Sek
[3] 48,0-50,0 Sek. 960 KB 3,93 Mbits / Sek
[3] 50,0-52,0 Sek. 1,28 MByte 5,37 Mbits / Sek
[3] 52,0-54,0 Sek. 1,09 MB 4,59 MBit / Sek
[3] 54,0-56,0 Sek. 992 KB 4,06 Mbits / Sek
[3] 56,0-58,0 Sek. 1,00 MB 4,19 MBit / Sek
[3] 58,0-60,0 Sek. 1,09 MB 4,59 MBit / Sek
[3] 0,0-60,2 Sek. 33,9 MByte 4,73 Mbits / Sek
[5] Lokaler 10.x-Port 5001, verbunden mit 192.168.x-Port 10965
[5] 0,0 bis 2,0 s, 1,85 MByte, 7,75 MBits / s
[5] 2,0 - 4,0 Sek. 1,90 MByte, 7,98 MBits / Sek
[5] 4,0 - 6,0 Sek. 1,89 MByte, 7,93 MBits / Sek
[5] 6,0-8,0 s 1,92 MByte 8,07 MBit / s
[5] 8,0-10,0 Sek. 1,91 MByte 8,02 MBit / Sek
[5] 10,0-12,0 Sek. 1,83 MByte 7,69 Mbits / Sek
[5] 12.0-14.0 Sek. 1.86 MBytes 7.78 Mbits / Sek
[5] 14,0-16,0 Sek. 1,79 MByte 7,52 Mbits / Sek
[5] 16,0-18,0 Sek. 1,79 MByte 7,52 Mbits / Sek
[5] 18,0 - 20,0 Sek. 1,89 MByte, 7,91 Mbits / Sek
[5] 20,0-22,0 Sek. 1,91 MByte 8,00 Mbits / Sek
[5] 22,0-24,0 Sek. 1,88 MByte 7,91 Mbits / Sek
[5] 24,0-26,0 Sek. 1,95 MByte 8,16 Mbits / Sek
[5] 26,0-28,0 Sek. 1,90 MByte 7,99 Mbits / Sek
[5] 28,0 - 30,0 Sek. 1,87 MByte, 7,84 MBit / Sek
[5] 30,0-32,0 Sek. 1,85 MByte, 7,77 Mbits / Sek
[5] 32,0-34,0 Sek. 1,55 MByte 6,49 Mbits / Sek
[5] 34,0-36,0 Sek. 1,92 MByte 8,07 Mbits / Sek
[5] 36,0-38,0 Sek. 1,90 MByte 7,99 Mbits / Sek
[5] 38,0-40,0 Sek. 1,84 MByte 7,73 Mbits / Sek
[5] 40,0-42,0 Sek. 1,66 MByte 6,95 Mbits / Sek
[5] 42,0-44,0 Sek. 1,92 MByte 8,07 Mbits / Sek
[5] 44,0-46,0 Sek. 1,91 MByte 7,99 Mbits / Sek
[5] 46,0-48,0 Sek. 1,90 MByte 7,98 Mbits / Sek
[5] 48,0-50,0 Sek. 1,84 MByte, 7,70 Mbits / Sek
[5] 50,0-52,0 Sek. 1,93 MByte 8,09 Mbits / Sek
[5] 52,0-54,0 Sek. 1,80 MByte 7,54 Mbits / Sek
[5] 54,0-56,0 Sek. 1,83 MByte 7,67 Mbits / Sek
[5] 56,0-58,0 Sek. 1,88 MByte 7,86 Mbits / Sek
[5] 58,0-60,0 Sek. 1,85 MByte, 7,78 Mbits / Sek
[5] 0,0-60,3 Sek. 56,0 MByte 7,79 Mbits / Sek
  • Hier sind UDP- Tests von zwei Hosts im selben VLAN unter Verwendung der Metro Connection, 200 = remote, 201 = DC

Wir sehen, dass der Paketverlust mit zunehmender Bandbreite zunimmt (wenn wir uns 10 Mbit / s nähern, haben wir 0,93%, beginnen kritisch zu sein ... und würden auch erklären, warum TCP Probleme mit der Leistung hat).

++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Server lauscht auf UDP-Port 5001
Empfangen von 1470-Byte-Datagrammen
UDP-Puffergröße: 64,0 KByte (Standard)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Client, der eine Verbindung zu 192.168.191.200, UDP-Port 5001 herstellt
Senden von 1470-Byte-Datagrammen
UDP-Puffergröße: 64,0 KByte (Standard)
-------------------------------------------------- ----------
[4] Lokaler 192.168.191.201-Port 61759, verbunden mit 192.168.191.200-Port 5001
[ID] Intervallübertragungsbandbreite
[4] 0,0 - 1,0 Sek. 128 KByte 1,05 Mbits / Sek
[4] 1,0 - 2,0 Sek. 128 KByte 1,05 Mbits / Sek
[4] 2,0 - 3,0 Sek. 129 KByte 1,06 Mbits / Sek
[4] 3,0 - 4,0 Sek. 128 KByte 1,05 Mbits / Sek
[4] 4,0 - 5,0 Sek. 128 KByte 1,05 Mbits / Sek
[4] 5,0 - 6,0 Sek. 128 KByte 1,05 Mbits / Sek
[4] 6,0 - 7,0 Sek. 128 KByte 1,05 Mbits / Sek
[4] 7,0 - 8,0 Sek. 128 KByte 1,05 Mbits / Sek
[4] 8,0-9,0 Sek. 128 KByte 1,05 Mbits / Sek
[4] 9,0-10,0 Sek. 129 KByte 1,06 Mbits / Sek
[4] 10,0-11,0 Sek. 128 KByte 1,05 Mbits / Sek
[4] 11,0-12,0 Sek. 128 KByte 1,05 Mbits / Sek
[4] 12,0-13,0 Sek. 128 KByte 1,05 Mbits / Sek
[4] 13,0-14,0 Sek. 128 KByte 1,05 Mbits / Sek
[4] 14,0-15,0 Sek. 128 KByte 1,05 Mbits / Sek
[4] 15,0-16,0 Sek. 128 KByte 1,05 Mbits / Sek
[4] 16,0-17,0 Sek. 128 KByte 1,05 Mbits / Sek
[4] 17,0-18,0 Sek. 128 KByte 1,05 Mbits / Sek
[4] 18,0-19,0 ​​Sek. 131 KByte 1,07 Mbits / Sek
[4] 19,0-20,0 Sek. 128 KByte 1,05 Mbits / Sek
[4] 0,0-20,0 s 2,50 MByte 1,05 MBit / s
[4] 1785 Datagramme gesendet
[4] Serverbericht:
[4] 0,0 bis 20,0 s, 2,50 MByte, 1,05 MBit / s, 0,257 ms, 0/1785 (0%)
[3] Lokaler 192.168.191.201-Port 5001, verbunden mit 192.168.191.200-Port 50749
[3] 0,0 - 1,0 Sek. 128 KByte, 1,05 Mbit / s, 0,285 ms, 0/89 (0%)
[3] 1,0 - 2,0 Sek. 128 KByte, 1,05 Mbit / s, 0,313 ms, 0/89 (0%)
[3] 2,0 - 3,0 s, 128 KByte, 1,05 MBit / s, 0,278 ms, 0/89 (0%)
[3] 3,0 - 4,0 Sek. 128 KByte, 1,05 Mbit / s, 0,241 ms, 0/89 (0%)
[3] 4,0 - 5,0 Sek. 128 KByte, 1,05 Mbit / s, 0,266 ms, 0/89 (0%)
[3] 5,0 - 6,0 Sek. 128 KByte, 1,05 Mbit / s, 0,293 ms, 0/89 (0%)
[3] 6,0 - 7,0 Sek. 128 KByte, 1,05 Mbit / s, 0,314 ms, 0/89 (0%)
[3] 7,0 - 8,0 Sekunden, 128 KByte, 1,05 Mbit / s, 0,280 ms, 0/89 (0%)
[3] 8,0-9,0 Sek. 128 KByte 1,05 MBit / Sek. 0,242 ms 0/89 (0%)
[3] 9,0-10,0 Sek. 129 KBytes 1,06 Mbit / s 0,250 ms 0/90 (0%)
[3] 10,0-11,0 Sek. 128 KBytes 1,05 Mbit / s 0,275 ms 0/89 (0%)
[3] 11,0-12,0 Sek. 128 KByte 1,05 MBit / Sek. 0,299 ms 0/89 (0%)
[3] 12,0-13,0 Sek. 128 KByte 1,05 Mbit / s 0,327 ms 0/89 (0%)
[3] 13,0-14,0 Sek. 128 KByte 1,05 Mbit / s 0,290 ms 0/89 (0%)
[3] 14,0-15,0 Sek. 128 KByte 1,05 Mbit / s 0,251 ms 0/89 (0%)
[3] 15,0-16,0 Sek. 128 KByte 1,05 MBit / Sek. 0,275 ms 0/89 (0%)
[3] 16,0-17,0 Sek. 128 KByte 1,05 MBit / Sek. 0,303 ms 0/89 (0%)
[3] 17,0-18,0 Sek. 128 KByte 1,05 Mbit / s 0,333 ms 0/89 (0%)
[3] 18,0 - 19,0 Sek. 128 KByte, 1,05 Mbit / s, 0,294 ms, 0/89 (0%)
[3] 19,0 - 20,0 Sek. 131 KByte, 1,07 Mbit / s, 0,281 ms, 0/91 (0%)
[3] 0,0-20,0 s 2,50 MByte 1,05 MBit / s 0,305 ms 0/1785 (0%)

++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 5m
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Server lauscht auf UDP-Port 5001
Empfangen von 1470-Byte-Datagrammen
UDP-Puffergröße: 64,0 KByte (Standard)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Client, der eine Verbindung zu 192.168.191.200, UDP-Port 5001 herstellt
Senden von 1470-Byte-Datagrammen
UDP-Puffergröße: 64,0 KByte (Standard)
-------------------------------------------------- ----------
[4] Lokaler 192.168.191.201-Port 61760, verbunden mit 192.168.191.200-Port 5001
[ID] Intervallübertragungsbandbreite
[4] 0,0 - 1,0 Sek. 610 KBytes 5,00 Mbits / Sek
[4] 1,0 - 2,0 Sek. 609 KByte 4,99 Mbits / Sek
[4] 2,0 - 3,0 Sek. 610 KByte 5,00 Mbits / Sek
[4] 3,0 - 4,0 Sek. 609 KByte 4,99 Mbits / Sek
[4] 4,0 - 5,0 Sek. 610 KBytes 5,00 Mbits / Sek
[4] 5,0 - 6,0 Sek. 609 KByte 4,99 Mbit / s
[4] 6,0 - 7,0 Sek. 610 KBytes 5,00 Mbits / Sek
[4] 7,0 - 8,0 Sek. 609 KByte 4,99 Mbits / Sek
[4] 8,0-9,0 Sek. 610 KByte 5,00 Mbits / Sek
[4] 9,0-10,0 Sek. 619 KByte 5,07 Mbits / Sek
[4] 10,0-11,0 Sek. 610 KBytes 5,00 Mbits / Sek
[4] 11,0-12,0 Sek. 609 KByte 4,99 Mbits / Sek
[4] 12,0-13,0 Sek. 609 KByte 4,99 Mbits / Sek
[4] 13,0-14,0 Sek. 610 KByte 5,00 Mbits / Sek
[4] 14,0-15,0 Sek. 609 KByte 4,99 Mbits / Sek
[4] 15,0-16,0 Sek. 610 KBytes 5,00 Mbits / Sek
[4] 16,0-17,0 Sek. 609 KByte 4,99 Mbits / Sek
[4] 17,0-18,0 Sek. 610 KByte 5,00 Mbits / Sek
[4] 18,0 - 19,0 Sek. 619 KByte, 5,07 Mbits / Sek
[4] 19,0 - 20,0 Sek. 609 KByte 4,99 Mbits / Sek
[4] 0,0-20,0 Sek. 11,9 MByte 5,00 MBit / Sek
[4] 8504 Datagramme gesendet
[4] Serverbericht:
[4] 0,0-20,0 Sek. 11,9 MByte, 4,99 Mbit / s, 0,000 ms, 12/8503 (0,14%)
[4] 0,0-20,0 Sek. 1 Datagramme nicht in der richtigen Reihenfolge empfangen
[3] Lokaler 192.168.191.201-Port 5001, verbunden mit 192.168.191.200-Port 50750
[3] 0,0 - 1,0 s, 606 KByte, 4,96 Mbit / s, 2,238 ms, 1/423 (0,24%)
[3] 1,0 - 2,0 Sek. 610 KBytes 5,00 MBit / Sek. 2,739 ms 0/425 (0%)
[3] 2,0 - 3,0 s, 609 KByte, 4,99 Mbit / s, 3,089 ms, 1/425 (0,24%)
[3] 3,0 - 4,0 s, 609 KByte, 4,99 Mbit / s, 3,605 ms, 0/424 (0%)
[3] 4,0 - 5,0 Sek. 607 KByte, 4,97 Mbit / s, 1,954 ms, 0/423 (0%)
[3] 5,0 - 6,0 Sek. 612 KBytes 5,01 MBit / Sek. 2,666 ms 0/426 (0%)
[3] 6,0 - 7,0 Sek. 607 KByte, 4,97 Mbit / s, 2,602 ms, 0/423 (0%)
[3] 7,0 - 8,0 Sek. 612 KBytes 5,01 MBit / Sek. 2,960 ms 0/426 (0%)
[3] 8,0-9,0 Sek. 609 KBytes 4,99 Mbit / s 2,512 ms 0/424 (0%)
[3] 9,0-10,0 Sek. 619 KBytes 5,07 Mbit / s 2,133 ms 0/431 (0%)
[3] 10,0-11,0 Sek. 609 KBytes 4,99 Mbit / s 3,605 ms 1/425 (0,24%)
[3] 11,0-12,0 Sek. 609 KBytes 4,99 Mbit / s 2,509 ms 0/424 (0%)
[3] 12,0-13,0 Sek. 610 KBytes 5,00 MBit / Sek. 3,570 ms 0/425 (0%)
[3] 13,0-14,0 Sek. 609 KBytes 4,99 Mbit / s 3,077 ms 1/425 (0,24%)
[3] 14,0-15,0 Sek. 609 KBytes 4,99 Mbit / s 2,679 ms 0/424 (0%)
[3] 15,0-16,0 Sek. 609 KBytes 4,99 Mbit / s 1,887 ms 0/424 (0%)
[3] 16,0-17,0 Sek. 610 KBytes 5,00 MBit / Sek. 2,651 ms 0/425 (0%)
[3] 17,0-18,0 Sek. 609 KBytes 4,99 Mbit / s 3,390 ms 0/424 (0%)
[3] 18,0 - 19,0 Sek. 617 KByte, 5,06 Mbit / s, 2,601 ms, 0/430 (0%)
[3] 19,0-20,0 Sek. 612 KBytes 5,01 MBit / Sek. 3,525 ms 0/426 (0%)
[3] 0,0-20,0 Sek. 11,9 MByte 4,99 Mbit / s 3,156 ms 3/8503 (0,035%)
[3] 0,0-20,0 Sek. 1 Datagramme nicht in der richtigen Reihenfolge empfangen

++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 9m
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Server lauscht auf UDP-Port 5001
Empfangen von 1470-Byte-Datagrammen
UDP-Puffergröße: 64,0 KByte (Standard)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Client, der eine Verbindung zu 192.168.191.200, UDP-Port 5001 herstellt
Senden von 1470-Byte-Datagrammen
UDP-Puffergröße: 64,0 KByte (Standard)
-------------------------------------------------- ----------
[4] Lokaler 192.168.191.201-Port 61761, verbunden mit 192.168.191.200-Port 5001
[ID] Intervallübertragungsbandbreite
[4] 0,0 - 1,0 Sek. 1,07 MByte 9,00 MBit / Sek
[4] 1,0 - 2,0 s, 1,07 MByte, 8,98 Mbit / s
[4] 2,0 - 3,0 Sek. 1,07 MByte 9,00 MBit / Sek
[4] 3,0 - 4,0 s, 1,07 MByte, 8,98 Mbit / s
[4] 4,0 - 5,0 Sek. 1,07 MByte 9,00 MBit / Sek
[4] 5,0 - 6,0 s, 1,07 MByte, 8,98 MBits / s
[4] 6,0 bis 7,0 s, 1,07 MByte, 8,98 MBits / s
[4] 7,0-8,0 s 1,07 MByte 9,00 MBit / s
[4] 8,0-9,0 Sek. 1,07 MByte 8,98 MBits / Sek
[4] 9,0-10,0 Sek. 1,09 MByte 9,14 Mbits / Sek
[4] 10,0-11,0 Sek. 1,07 MByte 9,00 MBit / Sek
[4] 11,0-12,0 Sek. 1,07 MByte 8,98 Mbits / Sek
[4] 12,0-13,0 Sek. 1,07 MByte 8,98 Mbits / Sek
[4] 13,0-14,0 Sek. 1,07 MByte 9,00 MBit / Sek
[4] 14,0-15,0 Sek. 1,07 MByte 8,98 Mbits / Sek
[4] 15,0-16,0 Sek. 1,07 MByte 9,00 Mbits / Sek
[4] 16,0-17,0 Sek. 1,07 MByte 8,98 Mbits / Sek
[4] 17,0-18,0 Sek. 1,07 MByte 8,98 Mbits / Sek
[4] 18,0 - 19,0 Sek. 1,09 MByte 9,14 Mbits / Sek
[4] 19,0-20,0 Sek. 1,07 MByte 9,00 MBit / Sek
[4] 0,0-20,0 Sek. 21,5 MByte 9,00 MBit / Sek
[4] 15315 Datagramme gesendet
[4] Serverbericht:
[4] 0,0-20,0 Sek. 21,3 MByte 8,94 Mbits / Sek. 0,104 ms 96/15314 (0,63%) !!!!!!!!!!
[4] 0,0-20,0 Sek. 1 Datagramme nicht in der richtigen Reihenfolge empfangen
[3] Lokaler 192.168.191.201-Port 5001, verbunden mit 192.168.191.200-Port 50751
[3] 0,0 - 1,0 s, 1,06 MByte, 8,89 MBits / s, 2,405 ms, 0/756 (0%)
[3] 1,0 - 2,0 s, 1,07 MByte, 9,00 Mbit / s, 2,308 ms, 0/765 (0%)
[3] 2,0 - 3,0 s, 1,07 MByte, 9,00 Mbit / s, 2,305 ms, 0/765 (0%)
[3] 3,0 - 4,0 s, 1,07 MByte, 8,97 Mbit / s, 2,290 ms, 1/764 (0,13%)
[3] 4,0 bis 5,0 s, 1,07 MByte, 8,98 MBit / s, 2,271 ms, 1/765 (0,13%)
[3] 5,0 - 6,0 s, 1,07 MByte, 8,98 Mbit / s, 2,313 ms, 0/764 (0%)
[3] 6,0 bis 7,0 Sekunden, 1,07 MByte, 9,00 MBits / Sekunde, 2,191 ms, 0/765 (0%)
[3] 7,0 - 8,0 s, 1,07 MByte, 8,95 MBits / s, 2,314 ms, 3/764 (0,39%)
[3] 8,0 - 9,0 s, 1,07 MByte, 8,98 Mbit / s, 2,232 ms, 1/765 (0,13%)
[3] 9,0-10,0 Sek. 1,09 MByte 9,13 MBits / Sek. 2,257 ms 0/776 (0%)
[3] 10,0-11,0 Sek. 1,07 MByte 8,98 MBits / Sek. 2,365 ms 0/764 (0%)
[3] 11,0-12,0 Sek. 1,07 MByte 8,98 MBits / Sek. 2,301 ms 1/765 (0,13%)
[3] 12,0-13,0 Sek. 1,07 MByte 8,98 MBit / Sek. 2,277 ms 0/764 (0%)
[3] 13,0-14,0 Sek. 1,07 MByte 9,00 MBit / Sek. 2,323 ms 0/765 (0%)
[3] 14,0-15,0 Sek. 1,07 MByte 9,00 MBit / Sek. 2,176 ms 0/765 (0%)
[3] 15,0-16,0 Sek. 1,07 MByte 8,96 Mbit / s 2,273 ms 2/764 (0,26%)
[3] 16,0-17,0 Sek. 1,07 MByte 8,98 MBits / Sek. 2,313 ms 0/764 (0%)
[3] 17,0-18,0 Sek. 1,07 MByte 8,98 MBits / Sek. 2,247 ms 1/765 (0,13%)
[3] 18,0 - 19,0 Sek. 1,09 MByte 9,11 MBit / Sek. 2,276 ms 1/776 (0,13%)
[3] 19,0 - 20,0 s, 1,07 MByte, 8,97 Mbit / s, 2,394 ms, 1/764 (0,13%)
[3] 0,0-20,0 Sekunden, 21,5 MByte, 8,99 Mbit / s, 2,659 ms, 11/15314 (0,072%)
[3] 0,0-20,0 Sek. 1 Datagramme nicht in der richtigen Reihenfolge empfangen

++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 9850k
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Server lauscht auf UDP-Port 5001
Empfangen von 1470-Byte-Datagrammen
UDP-Puffergröße: 64,0 KByte (Standard)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Client, der eine Verbindung zu 192.168.191.200, UDP-Port 5001 herstellt
Senden von 1470-Byte-Datagrammen
UDP-Puffergröße: 64,0 KByte (Standard)
-------------------------------------------------- ----------
[4] Lokaler 192.168.191.201-Port 61762, verbunden mit 192.168.191.200-Port 5001
[ID] Intervallübertragungsbandbreite
[4] 0,0 bis 1,0 s, 1,17 MByte, 9,84 MBit / s
[4] 1,0 - 2,0 s, 1,17 MByte, 9,84 Mbit / s
[4] 2,0 bis 3,0 s, 1,17 MByte, 9,84 MBits / s
[4] 3,0 - 4,0 s, 1,17 MByte, 9,84 Mbit / s
[4] 4,0 - 5,0 Sek. 1,17 MByte 9,84 MBit / Sek
[4] 5,0 bis 6,0 s, 1,17 MByte, 9,83 MBits / s
[4] 6,0 bis 7,0 s, 1,17 MByte, 9,84 MBits / s
[4] 7,0 bis 8,0 s, 1,17 MByte, 9,84 MBits / s
[4] 8,0-9,0 Sek. 1,17 MByte 9,84 MBits / Sek
[4] 9,0-10,0 Sek. 1,19 MByte 10,0 MBit / Sek
[4] 10,0-11,0 Sek. 1,17 MByte 9,84 Mbits / Sek
[4] 11,0-12,0 Sek. 1,17 MByte 9,84 Mbits / Sek
[4] 12,0-13,0 Sek. 1,17 MByte 9,83 Mbits / Sek
[4] 13,0-14,0 Sek. 1,17 MByte 9,85 Mbits / Sek
[4] 14,0-15,0 Sek. 1,17 MByte 9,83 Mbits / Sek
[4] 15,0-16,0 Sek. 1,17 MByte 9,85 Mbits / Sek
[4] 16,0-17,0 Sek. 1,17 MByte 9,83 Mbits / Sek
[4] 17,0-18,0 Sek. 1,17 MByte 9,84 Mbits / Sek
[4] 18,0-19,0 ​​Sek. 1,19 MByte 10,0 MBit / Sek
[4] 19,0-20,0 Sek. 1,17 MByte 9,84 MBit / Sek
[4] 0,0-20,0 Sek. 23,5 MByte 9,85 Mbits / Sek
[4] 16765 Datagramme gesendet
[4] Serverbericht:
[4] 0,0-20,0 Sek. 23,3 MByte 9,74 MBit / Sek. 3,421 ms 156/16764 (0,93%) !!!!!!!!!!
[4] 0,0-20,0 Sek. 1 Datagramme nicht in der richtigen Reihenfolge empfangen
[3] Lokaler 192.168.191.201-Port 5001, verbunden mit 192.168.191.200-Port 50752
[3] 0,0 - 1,0 s, 1,16 MByte, 9,74 Mbit / s, 2,131 ms, 0/828 (0%)
[3] 1,0 - 2,0 s, 1,17 MByte, 9,84 Mbit / s, 2,140 ms, 0/837 (0%)
[3] 2,0 - 3,0 s, 1,17 MByte, 9,83 Mbit / s, 2,099 ms, 1/837 (0,12%)
[3] 3,0 - 4,0 s, 1,17 MByte, 9,84 mbit / s, 2,113 ms, 0/837 (0%)
[3] 4,0 - 5,0 s, 1,17 MByte, 9,84 mbit / s, 2,105 ms, 0/837 (0%)
[3] 5,0 - 6,0 s, 1,17 MByte, 9,83 MBits / s, 2,058 ms, 1/837 (0,12%)
[3] 6,0 - 7,0 s, 1,17 MByte, 9,82 MBits / s, 2,165 ms, 1/836 (0,12%)
[3] 7,0 - 8,0 Sekunden, 1,17 MByte, 9,84 MBits / Sekunde, 2,156 ms, 0/837 (0%)
[3] 8,0-9,0 s, 1,17 MByte, 9,82 Mbit / s, 2,135 ms, 2/837 (0,24%)
[3] 9,0-10,0 Sek. 1,19 MByte 9,97 MBit / Sek. 2,152 ms 2/850 (0,24%)
[3] 10,0-11,0 Sek. 1,17 MByte 9,83 MBit / Sek. 2,153 ms 1/837 (0,12%)
[3] 11,0-12,0 Sek. 1,17 MByte 9,84 MBit / Sek. 2,127 ms 0/837 (0%)
[3] 12,0-13,0 Sek. 1,17 MB 9,83 MBit / Sek. 2,136 ms 1/837 (0,12%)
[3] 13,0-14,0 Sek. 1,17 MByte, 9,82 MBit / Sek. 2,087 ms 2/837 (0,24%)
[3] 14,0-15,0 Sek. 1,17 MByte 9,83 MBit / Sek. 2,061 ms 1/837 (0,12%)
[3] 15,0-16,0 Sek. 1,17 MByte, 9,84 Mbit / s, 2,045 ms, 0/837 (0%)
[3] 16,0-17,0 Sek. 1,17 MByte 9,82 MBit / Sek. 2,203 ms 1/836 (0,12%)
[3] 17,0-18,0 Sek. 1,17 MByte 9,84 MBit / Sek. 2,165 ms 0/837 (0%)
[3] 18,0 - 19,0 Sekunden, 1,17 MByte, 9,83 MBits / Sekunde, 2,154 ms, 1/837 (0,12%)
[3] 19,0 - 20,0 Sek. 1,19 MByte, 9,98 Mbit / s, 2,209 ms, 0/849 (0%)
[3] 0,0-20,0 Sekunden, 23,5 MByte, 9,84 MBit / s, 2,548 ms, 13/16764 (0,078%)
[3] 0,0-20,0 Sek. 1 Datagramme nicht in der richtigen Reihenfolge empfangen

Die eigentliche Frage bleibt:

Der Zwischenkreis ist nicht überbelegt, da er 100 Mbit / s beträgt und nicht mehr als 100 Mbit / s senden kann. Die entfernten Standorte haben jedoch eine Geschwindigkeit von 10 Mbit / s.

  • Laufen die Puffer auf der Remote-Seite über und werfen Pakete ab?
  • Tut der Traffic Shaper des Providers etwas mit dem Verkehr? (Würde der Verkehr von einem anderen Knoten durch den Traffic Shaper des Internetdienstanbieters beeinflusst oder nur der Verkehr, der in den Knoten eindringt (von außen)?) ...... Sie sehen, was ich meine?

Warum kann TCP das nicht alleine bewältigen?

Update Nr. 3 Ich habe jetzt das folgende Szenario verwendet:

Laptop ------- ... LAN ... --- DC switch --- Metro-Eth --- Laptop (directly connected)
NIC@10Mbps                       100Mbps                  NIC@10Mbps

Hier ist der Paketverlust in der DC-> Remote-Richtung: (iperf 9 Mbps UDP-Test)

[  3] local 192.168.191.200 port 5001 connected with 192.168.191.201 port 55236
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0- 1.0 sec   912 KBytes  7.47 Mbits/sec   2.713 ms    0/  635 (0%)
[  3]  1.0- 2.0 sec  1001 KBytes  8.20 Mbits/sec   2.168 ms    0/  697 (0%)
[  3]  2.0- 3.0 sec  1001 KBytes  8.20 Mbits/sec   2.478 ms    0/  697 (0%)
[  3]  3.0- 4.0 sec   999 KBytes  8.18 Mbits/sec   0.933 ms    0/  696 (0%)
[  3]  4.0- 5.0 sec  1001 KBytes  8.20 Mbits/sec   2.620 ms    0/  697 (0%)
[  3]  5.0- 6.0 sec  1001 KBytes  8.20 Mbits/sec   2.721 ms    0/  697 (0%)
[  3]  6.0- 7.0 sec  1001 KBytes  8.20 Mbits/sec   2.089 ms    0/  697 (0%)
[  3]  7.0- 8.0 sec   999 KBytes  8.18 Mbits/sec   2.641 ms    0/  696 (0%)
[  3]  8.0- 9.0 sec  1002 KBytes  8.21 Mbits/sec   0.896 ms    0/  698 (0%)
[  3]  9.0-10.0 sec  1015 KBytes  8.31 Mbits/sec   2.557 ms    0/  707 (0%)
[  3] 10.0-11.0 sec   999 KBytes  8.18 Mbits/sec   2.822 ms    1/  697 (0.14%)
[  3] 11.0-12.0 sec   999 KBytes  8.18 Mbits/sec   1.551 ms    1/  697 (0.14%)
[  3] 12.0-13.0 sec   998 KBytes  8.17 Mbits/sec   2.504 ms    2/  697 (0.29%)
[  3] 13.0-14.0 sec   995 KBytes  8.15 Mbits/sec   2.038 ms    3/  696 (0.43%)
[  3] 14.0-15.0 sec   991 KBytes  8.11 Mbits/sec   2.539 ms    7/  697 (1%)
[  3] 15.0-16.0 sec   992 KBytes  8.13 Mbits/sec   2.759 ms    6/  697 (0.86%)
[  3] 16.0-17.0 sec   998 KBytes  8.17 Mbits/sec   2.229 ms    2/  697 (0.29%)
[  3] 17.0-18.0 sec   993 KBytes  8.14 Mbits/sec   2.723 ms    4/  696 (0.57%)
[  3] 18.0-19.0 sec   998 KBytes  8.17 Mbits/sec   2.038 ms    2/  697 (0.29%)
[  3] 19.0-20.0 sec  1012 KBytes  8.29 Mbits/sec   2.575 ms    3/  708 (0.42%)
[  3]  0.0-20.0 sec  19.5 MBytes  8.15 Mbits/sec   2.775 ms   31/13917 (0.22%)
[  3]  0.0-20.0 sec  1 datagrams received out-of-order

Die andere Richtung ist in Ordnung. Wenn Sie jedoch einen TCP-Test ausführen, ist die Remote-> DC-Richtung nicht viel besser als die DC-> Remote-Richtung (ca. 5 Mbit / s) .......

Ich bin nicht sicher, ob wir den Grund dafür erreicht haben.

ethernet tcp troubleshooting packet-analysis metro-ethernet Marki
quelle
Keine wirkliche Antwort, aber meine Empfehlung wäre, eine JDSU zu besorgen und diese Schaltung zu testen. Wenn sie Sie überwachen, stellen Sie sicher, dass Sie den Überwacher, "Regler", Einstellungen ... erhalten. Wenn sie einen kleinen CBS haben, beschränken sie Ihren TCP-Verkehr auf eine wesentlich kleinere Fenstergröße. Sie können dies über einen Back-2-Back-Test testen. Ich habe viel Zeit damit verbracht, mit Anbietern auf L2-Stromkreisen hin und her zu gehen, um zu wissen, dass wenn wir einen neuen Stromkreistest erhalten, dieser nicht nur am CIR, sondern auch am CBS gründlich durchgeführt wird ...
matak 30.07.14
Auch nur eine kurze Randnotiz. Der TCP-Durchsatz eines Windows-Betriebssystems im Vergleich zu Linux ist unterschiedlich, da die TCP-Einstellungen unterschiedlich sind. dh Puffergröße, Algorithmus usw. Sie können die Einstellungen für Ihren Linux-Computer anzeigen, wenn Sie sysctlnicht sicher sind, ob Sie Windows verwenden oder nicht netsh. Wenn ich raten würde, was mit Ihrer Schaltung nicht stimmt, würde ich sagen, dass die CPE an der Spoke-Site mit einem größeren CBS als der Hub-Seite eingerichtet ist ... was normalerweise umgekehrt ist. Wieder wird die JDSU den Ball zurückwerfen oder Sie können sich wieder auf das Problem konzentrieren.
Matak
@matak Warum machen Sie keine zusätzliche Antwort auf Ihre Bemerkungen? Wo stelle ich mir dieses Gerät vor, wenn wir über den Former sprechen? Am DC befindet sich ein RJ45-Stecker ohne (sichtbaren) CPE. An den entfernten Standorten habe ich meist ein VDSL-Modem und eine Art MPLS-fähigen Router. Ich bin mir nicht sicher, ob sie MPLS verwenden. Und außerdem Welche Verkehrsrichtung formt der Shaper? Wir können Ingress @ Spoke (von der Site), Egress @ Spoke (in Richtung der Cloud des ISP), Ingress @ Hub (von DC), Egress @ Hub (in Richtung der Cloud des ISP) gestalten. Können Sie veranschaulichen, warum das Problem mit dem CBS ein Problem sein würde?
Marki

Antworten:

20

Verweis auf unseren Stack Exchange- Chat ...

Kurz gesagt , Sie müssen die Geschwindigkeitsinkongruenzen auf beiden Seiten Ihrer Metro-Ethernet-Verbindungen kontrollieren ... Ich habe Ihr Diagramm aus Gründen der Klarheit neu gezeichnet ... Anmerkung 1

Problemdiagramm

  • Der (grün dargestellte) Gleichstromübergang von 10GE zu 100M erfolgt sehr schnell. Dies ist ein 100-facher Geschwindigkeitsübergang. In der Regel müssen Sie eine Art von QOS (z. B. Shaping) implementieren, um einen so großen Übergang abzuschwächen. Unten in dieser Antwort finden Sie Hinweise darauf, dass der DC eine Formgebung benötigt (pro Standort) ...
  • Die entfernte Seite wechselt sehr schnell von 1GE zu 10M CIR. Auch dies ist ein 100-facher Geschwindigkeitswechsel. Shaping oder andere Problemumgehungen sind normalerweise erforderlich.
  • Es scheint auch einen Geschwindigkeitsunterschied zwischen der DC- UNI (100M) und der entfernten UNI (10M) zu geben. Dies selbst erfordert eine standortspezifische Lösung zur Bandbreitenverwaltung.

Zu Ihrer Information, wenn Ihr Provider MEF- konforme Dienste implementiert , gestaltet er diese nicht, sondern überwacht sie . TCP-Datenverkehr kann mit Shaping eine bessere Leistung erzielen .

Die Notwendigkeit für Ihre eigene QoS

Sie scheinen die Notwendigkeit von QOS in Frage zu stellen , daher zitiere ich aus dem MEF-Whitepaper "Understanding Carrier Ethernet Throughput" , Seite 9 ... zur Überprüfung hat der Kunde im MEF-Whitepaper in Abbildung 2 ein besseres Situation als Sie. .. sie haben eine CIR mit 50 Mbit / s gekauft, aber ihre UNI wird auf einer 1GE geliefert ... Ihre Remote-Site verfügt über eine CIR mit 10 Mbit / s auf einer 1GE-UNI.

The transition from legacy services such as T1, T3, Frame Relay and ATM
to Carrier Ethernet has created some unintended consequences. Not all customers have 
conforming equipment facing the network which properly limits/shapes the traffic outbound
to the network, with deleterious results.  For instance, on the 1 GigE interface of
Figure 2, if the customer’s equipment accidentally transmits long bursts of data at 
150 Mbits instead of the SLA’s Committed Information Rate of 50 Mbits, 67% of the data 
may be lost and network breakdown will likely result.

Antworten auf andere TCP-Fragen in einer Bearbeitung ...

Wir haben den Zwischenkreis nicht überzeichnet, da er 100 Mbit / s hat und nicht mehr als 100 Mbit / s senden kann ...

Ich bin anderer Meinung, Sie können Mikroburst senden bei 10GE da Ihr DC 10GE-Verbindungen hat, aber die U-Bahn-UNI 100 Mbit / s beträgt. Eine offene Frage ist, wie viel Puffer Sie auf Ihrem Enterasys LAN-Switch (Switch A) haben, wenn Sie von 10GE auf 100M wechseln.

Warum kann TCP das nicht alleine bewältigen?

TCP verlangsamt die Verarbeitung, wenn es einen Paketverlust feststellt. Bei schwerwiegenden Paketverlusten verlangsamt es die Verarbeitung (und bricht möglicherweise die Verbindung ab). TCP tut also, was es sollte. Als Netzwerkingenieur ist es Ihr Ziel, ein Netzwerk mit Bedingungen aufzubauen, die TCP glücklich machen.

Andere TCP-Fragen aus dem Chat

Marki sagte : Ich verstehe nicht, was wo und von wem gelöscht wird und warum und warum TCP nicht einfach mit der Tatsache umgeht, dass an einem Ende (echte) 100 MBit / s und am anderen Ende nur 10 MBit / s vorhanden sind.

In Bezug auf den Pufferbedarf von TCP und die Konsequenzen ohne Puffer :

Fakt Nummer 1: TCP muss für Geschwindigkeitsübergänge gepuffert werden, da es als Rückkopplungskontrollsystem konzipiert ist .

Mit einer Fahranalogie: Als gute Fahrer lassen wir immer ein paar Sekunden Abstand zwischen uns und dem Auto vor uns; In gewisser Weise entspricht dieser Abstand zwischen Autos in etwa einem Netzwerkpuffer. Wenn die Person vor uns auf die Bremse tritt, während ein Tier vor ihnen rennt, hindert uns der Abstand zwischen unseren Autos (hoffentlich) daran, auf ihr Auto zu treffen. Wir verlassen den Raum, weil es einige Zeit dauert, bis unsere Augen die Bremslichter sehen, unser Fuß reagiert und die Bremsen genügend Wärme abgeben. Unsere Augen geben uns ein visuelles Feedback-Kontrollsystem.

Wenn eine FTP-Sitzung mit 10GE gestoppt wird, kann der Datenverkehr (in Ihrem Fall) aufgrund der TCP-skalierten Fenstergröße bis zu 4 MB lang sein, bevor der Socket angehalten und auf eine TCP-ACK gewartet werden muss. Wenn der 10GE-Verkehrsstrom plötzlich auf ein "Fast Ethernet" trifft, muss TCP allmählich langsamer werden. Durch tiefe Puffer in Netzwerkgeräten kann TCP bei Geschwindigkeitsübergängen weitaus weniger Pakete verwerfen. Wenn Sie jedoch keine Puffer haben, können Sie möglicherweise 99% dieses 4-MB-TCP-Fensters löschen, wenn es von 10GE auf 100M gedrosselt wird. Stellen Sie sich diesen schweren Verlust von 99% als einen Absturz des TCP-Sockets vor. TCP reagiert vorhersehbar auf einen relativ allmählichen Paketverlust. TCP reagiert viel weniger vorhersehbar auf anhaltenden, schwerwiegenden Paketverlust Hinweis 3 .

Auf die Frage, warum Sie kein asymmetrisches Metro-Ethernet- CIR mit 100 M am DC und 10 M an der Fernbedienung verwenden sollten, sollten Sie sich eine rhetorische Frage stellen: "Wer puffert diesen 100-Mbit / s-Datenverkehr, wenn er die billige 10-Mbit / s-Ethernet- NID Ihrer Metro erreicht -ethernet provider hat dir das gegeben? "... (tipp: niemand puffert).

Wenn niemand die großen Geschwindigkeitsübergänge (siehe Anmerkung 2) puffert, sind diese Punkte potenzielle Orte, an denen der Verkehr zeitweise unterbrochen werden kann.

Was wird von wem fallen gelassen :

Der aus dem DC kommende Verkehr sinkt

Wenn der TCP-Verkehr das Rechenzentrum verlässt, kann er an drei Stellen gelöscht werden:

  • Bei D1: weil LAN-Switches selten tief genug gepuffert sind für einen 100: 1-Geschwindigkeitsübergang
  • Bei D2: Wenn die NID jemals die UNI- Verbindung mit einer höheren Geschwindigkeit als die CIR ausgehandelt hat ; Das ist derzeit nicht der Fall, daher erwarte ich dort keine Tropfen.
  • Bei D3: Aus all den Gründen, die ich gerade über asymmetrische Metro-Ethernet- CIRs beschrieben habe .

Wenn der TCP-Verkehr zum Rechenzentrum geht ...

Der ankommende Verkehr sinkt zum DC

  • Bei D4: weil du eine 1GE UNI hast und eine 10M CIR haben ; Dies ist der pathologische Fall von D2, den ich oben erwähnt habe.

So verringern Sie die Geschwindigkeitsinkongruenzen:

Eine beispielhafte EVPL- Lösung : EVPL mit Punkt-zu-Punkt-EVC-Lösung

  • In einer solchen Switched-Topologie ist ein EVPL mit Punkt-zu-Punkt-EVCs vom DC zu jeder Fernbedienung wahrscheinlich die beste Option (siehe Abbildung oben). Dies würde eine individuelle CIR anwenden auf jeden EVC . Hinweis: Alle anderen QoS-Richtlinien in dieser Antwort gelten ... dh große Geschwindigkeitsübergänge vermeiden Hinweis 2 Prüfen Sie nicht, ob Ihre Geräte diese Anforderungen erfüllen.
  • Alternativ können Sie auch Metrodienste kaufen, die symmetrische Raten zwischen DC und Remote haben. obwohl ich zugeben würde, dass dies möglicherweise nicht die praktischste Anleitung ist.
  • Die klassische Lösung für dieses Problem bei gerouteten Diensten besteht darin , Router zu kaufen, die das Shaping mit den erforderlichen Geschwindigkeiten unterstützen, und dann den U-Bahn-Verkehr auf die entsprechende CIR (pro Remote-Standort) zu konfigurieren . Zu Ihrer Information, die Gegenseite könnte mit einem einigermaßen kleinen Router davonkommen, da es sich nur um einen 1GE-Eingang und einen 10-Mbit / s-CIR handelt. Als wir vor Monaten über das Design dieses Dienstes sprachen, empfahl ich Routing, wenn Sie mit den Technologien vertraut sind ...

  • Wenn Sie kein zusätzliches Geld zum Ausgeben haben und Ihren Metro-Ethernet-Dienst nicht umgestalten können, können Sie die Geschwindigkeitsinkongruenzen schrittweise massieren. Ich habe das noch nie gemacht, aber im Prinzip könnten Sie versuchen, die Geschwindigkeitsübergänge von 10 zu 1 zu machen, anstatt von 100 zu 1 (was Sie derzeit sowohl an der DC als auch an der Fernbedienung haben):

    • Anstatt einen Router zu kaufen, um die Fernbedienung auf 10 MB auszurichten, können Sie versuchen, die Remote-UNI zu zwingen, eine automatische Aushandlung bei 100 MB anstelle von 1 GB durchzuführen. Für GigabitEthernet sind alle Pins eines Cat5e-Kabels erforderlich , sodass Sie es mit einem RJ45-Mod-Stecker, der lediglich die Pins 1, 2, 3 und 6 verbindet, effektiv auf 100 M zwingen können.
    • Verwenden Sie Enterasys, um die 10GE-Verbindung zu 1GE zu überwachen, anstatt einen Router zu kaufen, der die DC auf 100M ausrichtet, wenn Sie Datenverkehr auf die 100M-Verbindung senden

Analysieren Sie Ihre iperf Ergebnisse ...

Es gibt zwei wichtige Punkte, an die Sie sich erinnern sollten iperf(alle Informationen basieren auf iperfVersion 2):

  • iperfmisst die TCP- oder UDP-Nutzdatenbandbreite ; Mit anderen Worten, der Overhead von TCP-, UDP-, IP- und Ethernet-Headern wird ignoriert. Denken Sie daran, die iperfErgebnisse entsprechend zu ändern, da Sie über einen Ethernet-Dienst verfügen
  • Der iperfClient sendet während der Tests Daten an den Server .

Die folgende Ausgabe zeigt daher, dass der DC-Computer (im iperf -cModus) eine Verbindung zum iperfServer am Remotestandort (192.168.x) herstellt und Daten vom DC (100M UNI) zum Remotestandort (10M UNI) überträgt.

./iperf -c 192.168.x -i2 -t 60 -r
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.x, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 10.x port 38195 connected with 192.168.x port 5001
[  3]  0.0- 2.0 sec  1.44 MBytes  6.03 Mbits/sec
[  3]  2.0- 4.0 sec  2.23 MBytes  9.37 Mbits/sec
[  3]  4.0- 6.0 sec  2.28 MBytes  9.57 Mbits/sec
[  3]  6.0- 8.0 sec  1.88 MBytes  7.90 Mbits/sec
[  3]  8.0-10.0 sec  1.00 MBytes  4.19 Mbits/sec
[  3] 10.0-12.0 sec  1.30 MBytes  5.47 Mbits/sec
[  3] 12.0-14.0 sec    688 KBytes  2.82 Mbits/sec

Die Ausgabe oben zeigt deutlich Probleme in der Richtung von Gleichstrom nach Fern; Wir sollten damit rechnen, 9 Mbit / s oder mehr zu erreichen, wenn die Dinge gut funktionieren (dh Sie erwarten mindestens 90% der Kapazität - 10 Mbit / s am Remote-Standort). Betrachten wir nun den Verkehr in die entgegengesetzte Richtung (wenn iperfDaten vom Remote-Standort zum DC übertragen werden) ...

[  5] local 10.x port 5001 connected with 192.168.x port 10965
[  5]  0.0- 2.0 sec  1.85 MBytes  7.75 Mbits/sec
[  5]  2.0- 4.0 sec  1.90 MBytes  7.98 Mbits/sec
[  5]  4.0- 6.0 sec  1.89 MBytes  7.93 Mbits/sec
[  5]  6.0- 8.0 sec  1.92 MBytes  8.07 Mbits/sec
[  5]  8.0-10.0 sec  1.91 MBytes  8.02 Mbits/sec
[  5] 10.0-12.0 sec  1.83 MBytes  7.69 Mbits/sec
[  5] 12.0-14.0 sec  1.86 MBytes  7.78 Mbits/sec

Sie können ungefähr 80% der Kapazität Ihres Remote-CIR senden, aber das ist immer noch weniger als erwartet.

Abbildung der Nichtübereinstimmung der DC-Geschwindigkeit (10 Gbit / s -> 100 Mbit / s)

marki meinte : vergiss nicht, das problem zeigt sich nur wenn der flow 100mb-> 10mb ist, nicht umgekehrt.

Das Problem zeigt sich in beide Richtungen, aber die iperfSymptome scheinen in der DC -> Fernrichtung schlimmer zu sein. Siehe meine Analyse der iperfAusgabe oben.

Sehen wir uns dazu Ihren FTP-Server an, wenn Sie eine Datei von Ihrem DC-FTP-Server (130.1.6.4) zur Remote-Site (192.168.191.2) übertragen. Die Übertragung von der 100M-Metro-Ethernet-Seite wird an mehreren Punkten während der Übertragung begrenzt. Sie können dies sehen, wenn Sie sich den dc-to-remote_remote-side.pcapngpcap ansehen und danach filternexpert.message contains "segment not captured"

Bildbeschreibung hier eingeben

End Notes :

Anmerkung 1: Ich wähle CBS-Werte von 25 KB pro 1 Mbit / s MetroEthernet CIR. Dies ist ein allgemeines Verhältnis, das von Anbietern verwendet wird ... YMMV
Anmerkung 2 Meine persönliche Regel: "groß" ist ein Geschwindigkeitsübergang, der deutlich größer als ein 10: 1-Geschwindigkeitsübergang ist
Anmerkung 3Ich kann keine harten Zahlen für das geben, was für TCP zu viel Paketverlust ist und was nicht. Wenn der Verlust so groß ist, dass Ihre Anwendungen darunter leiden, ist er zu groß. Meine persönliche Regel: Wenn Sie ein verkabeltes Unternehmensnetzwerk vollständig unter meiner Kontrolle haben, ist jeder (unbeabsichtigte) Paketverlust zu groß. Es gibt jedoch einige Switch-Modelle, die beim Puffern Abstriche machen. Diese Switches können gelegentlich Pakete verwerfen. Es ist eine Entscheidung, ob Sie mit dem Problem leben müssen oder bessere Switches kaufen. Zu Ihrer Information: Es ist nicht immer offensichtlich, aber TCP erhöht regelmäßig die Übertragungsrate eines Sockets, um sicherzustellen, dass so viel Durchsatz wie möglich erzielt wird. Viele TCP-Implementierungen wissen, dass sie zu schnell arbeiten, wenn Paketverluste auftreten.

Mike Pennington
quelle
Beachten Sie, dass die PHY-Geschwindigkeit des DC (Metro-Ethernet-Port) bereits bei 100 MB liegt. Aber ich kann auch nicht mit 100M senden, weil die andere Seite maximal 10Mb groß ist ... Momentan ist mir noch unklar, wo genau die Formgebung stattfinden soll. Oh und meintest du "die iperf Symptome scheinen in der DC -> entfernten Richtung schlimmer zu sein "?
Marki
Ich habe die Antwort aktualisiert, ja "remote -> DC" war ein Tippfehler in der ursprünglichen Antwort.
Mike Pennington
Ich stimme Mike hier zu, je nachdem, wer Ihr Provider ist. Wenn Sie ihn fragen, wird er Ihnen die Leitungsrate an seinem Ende mitteilen. Passen Sie diese an Ihre physischen Schnittstellen an, die an Ihrer U-Bahn-E hängen. Was WHERE to QoS betrifft, würde ich an Ihren größten Einstiegspunkten, also Ihren 10-Gbit-Geräten, vorgehen, bevor sie zu den kleineren Upstream-Geräten wechseln. Ich verbringe zwar mehr Zeit mit Firewalling und Routing als mit Switching, aber hoffentlich kann Mike meine Behauptungen bestätigen!
AL
3
@MikePennington - Egress-Blocking aufgrund von Geschwindigkeitsfehlanpassungen ist etwas, auf das ich bei P2P-Mikrowellenverbindungen häufig stoße. Tolle Antwort, viele gute Informationen in Ihrem Beitrag. Vielen Dank!
Matak
1
Überprüfen Sie auch, ob eine Duplex-Nichtübereinstimmung vorliegt. Dies kann zu Geschwindigkeitsproblemen in einer Richtung führen.
cpt_fink
2

Während die Diskussion über dieses Problem sehr interessant war, hat der ISP inzwischen damit begonnen, die DSL-Modems an den verschiedenen Standorten durch eine andere Marke auszutauschen. Einige Paketfragmentierungsprobleme, sagen sie. Und hey, 9,5 Mbit / s in beide Richtungen ohne Probleme oder spezielle Einstellungen.

Marki
quelle