Risoluzione dei problemi di throughput TCP Metro Ethernet basso

14

Il set up

Abbiamo noleggiato alcune linee affittate che si presentano come una rete di livello 2, vale a dire che hai un grosso tubo nel datacenter e i siti remoti hanno tubi più piccoli. All'interno della rete di livello 2 puoi fare quello che vuoi. Probabilmente usano 802.1ad per offrire ad ogni cliente la propria rete separata all'interno della propria rete. La maggior parte dei siti AFAICS sono collegati tramite VDSL semplice.

Abbiamo deciso di installare un router in ciascun sito e di assegnare a ciascun sito la propria VLAN. Il firewall nel DC ha quindi definito quante VLAN sono presenti quanti sono i siti. Ogni sito utilizza quindi il proprio intervallo di indirizzi attivo nella propria VLAN.

Diagramma di rete:

diagramma di rete

Il problema

Ora, siamo di fronte a problemi di throughput:

  • L'esecuzione di un trasferimento FTP dal sito al DC funziona bene a circa 10 Mb / s, ovvero la velocità della linea.
  • L'esecuzione di un trasferimento FTP da DC al sito non funziona correttamente a 6 Mb / se meno.

Non importa da quale parte inizia il trasferimento. L'unica cosa coerente è che una direzione non funziona bene. Peccato che sia la direzione verso il sito perché quella sarebbe la larghezza di banda di cui abbiamo più bisogno in quanto vorremmo usare i client terminal server.

Dopo circa 10 secondi dal trasferimento, il throughput diminuisce. Vediamo DUP ACK quando si annusa. Il che forse mi porta a limitare la tariffa alla fine del provider ?? (Attualmente, non hanno idea, e mi piace assicurarmi che non siamo in colpa prima di intensificare)

NOTA I siti remoti sono in qualche modo limitati a 10 Mb. Neanche l'impostazione dello switch-to-Metro-port su 10Mb. In effetti è il peggiore di allora (max. 30 KB / s). L'impostazione su 100 Mb funziona correttamente ma inizia già a produrre il problema descritto. Lo stesso per 1G.

Le catture del problema possono essere scaricate qui:

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

Diagnostica

Nell'immagine viene visualizzato il grafico IO di Wireshark con alcuni dettagli di errore:

  • a sinistra: trasferimento FTP da DC al sito
  • a destra: trasferimento FTP dal sito a DC

acks duplicati

Nel caso in cui l'altra parte avvii il trasferimento (ovvero put da dc, anziché get da remoto), il problema rimane invariato.

Per favore, concedimi quello che pensi possa essere il problema qui.

AGGIORNAMENTO N. 1 (integrato sopra)

AGGIORNAMENTO # 2 ( AGGIORNATO )

Questa deve essere una cosa di controllo della congestione.

Da DC a remoto abbiamo collegamenti 10G-> 1G-> 100M-> 10M-> 1G. <- non funziona

Nell'altra direzione abbiamo quindi l'inverso: 1G-> 10M-> 100M-> 1G-> 10G. <- bene

Il primo "1G-> 10M" è il 10M "invisibile" nel sito remoto, dove tutto, compresa la velocità della porta di uplink, è impostato su 1G, anche se ci sono solo 10M dietro (in vendita).

Tuttavia, i 100 Mbps sul DC sono reali 100 Mbps, l'interfaccia è configurata a 100 Mbps sul livello fisico.

Ora ho usato iperf:

  • I test TCP funzionano bene solo in una direzione (client = DC, server = remoto)
./iperf -c 192.168.x -i2 -t 60 -r
-------------------------------------------------- ----------
Server in ascolto sulla porta TCP 5001
Dimensione finestra TCP: 85,3 KByte (impostazione predefinita)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Client che si collega a 192.168.x, porta TCP 5001
Dimensione finestra TCP: 16,0 KByte (impostazione predefinita)
-------------------------------------------------- ----------
[3] porta locale 10.x 38195 collegata con la porta 500.1 192.168.x.
[3] 0,0- 2,0 sec 1,44 MByte 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 MByte 5,47 Mbits / sec
[3] 12,0-14,0 secondi 688 KByte 2,82 Mbits / sec
[3] 14,0-16,0 secondi 840 KByte 3,44 Mbits / sec
[3] 16,0-18,0 sec 1,03 MBytes 4,33 Mbits / sec
[3] 18,0-20,0 secondi 1,01 MByte 4,23 Mbits / sec
[3] 20,0-22,0 sec 1,03 MBytes 4,33 Mbits / sec
[3] 22,0-24,0 sec 1,18 MByte 4,95 Mbits / sec
[3] 24,0-26,0 secondi 904 KByte 3,70 Mbits / sec
[3] 26,0-28,0 secondi 840 KByte 3,44 Mbits / sec
[3] 28,0-30,0 secondi 936 KByte 3,83 Mbits / sec
[3] 30,0-32,0 sec 1,09 MBytes 4,59 Mbits / sec
[3] 32,0-34,0 secondi 960 KByte 3,93 Mbits / sec
[3] 34,0-36,0 secondi 752 KByte 3,08 Mbits / sec
[3] 36,0-38,0 sec 1,09 MBytes 4,59 Mbits / sec
[3] 38,0-40,0 sec 1,09 MBytes 4,59 Mbits / sec
[3] 40,0-42,0 sec 840 KByte 3,44 Mbits / sec
[3] 42,0-44,0 sec 1,27 MBytes 5,34 Mbits / sec
[3] 44,0-46,0 sec 1,16 MByte 4,85 Mbits / sec
[3] 46.0-48.0 sec 840 KBytes 3.44 Mbits / sec
[3] 48,0-50,0 secondi 960 KByte 3,93 Mbits / sec
[3] 50,0-52,0 sec 1,28 MBytes 5,37 Mbits / sec
[3] 52,0-54,0 sec 1,09 MBytes 4,59 Mbits / sec
[3] 54,0-56,0 sec 992 KBytes 4,06 Mbits / sec
[3] 56,0-58,0 sec 1,00 MByte 4,19 Mbits / sec
[3] 58.0-60.0 sec 1.09 MBytes 4.59 Mbits / sec
[3] 0,0-60,2 sec 33,9 MByte 4,73 Mbits / sec
[5] porta locale 10.x 5001 connessa con la porta 192.168.x 10965
[5] 0,0- 2,0 secondi 1,85 MByte 7,75 Mbits / sec
[5] 2,0- 4,0 sec 1,90 MByte 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 secondi 1,83 MByte 7,69 Mbits / sec
[5] 12,0-14,0 secondi 1,86 MByte 7,78 Mbits / sec
[5] 14,0-16,0 secondi 1,79 MByte 7,52 Mbits / sec
[5] 16,0-18,0 sec 1,79 MBytes 7,52 Mbits / sec
[5] 18,0-20,0 sec 1,89 MBytes 7,91 Mbits / sec
[5] 20,0-22,0 sec 1,91 MBytes 8,00 Mbits / sec
[5] 22,0-24,0 sec 1,88 MBytes 7,91 Mbits / sec
[5] 24,0-26,0 secondi 1,95 MByte 8,16 Mbits / sec
[5] 26,0-28,0 secondi 1,90 MByte 7,99 Mbits / sec
[5] 28,0-30,0 sec 1,87 MByte 7,84 Mbits / sec
[5] 30,0-32,0 sec 1,85 MByte 7,77 Mbits / sec
[5] 32,0-34,0 sec 1,55 MByte 6,49 Mbits / sec
[5] 34,0-36,0 sec 1,92 MBytes 8,07 Mbits / sec
[5] 36,0-38,0 secondi 1,90 MByte 7,99 Mbits / sec
[5] 38,0-40,0 sec 1,84 MByte 7,73 Mbits / sec
[5] 40,0-42,0 secondi 1,66 MByte 6,95 Mbits / sec
[5] 42,0-44,0 sec 1,92 MBytes 8,07 Mbits / sec
[5] 44,0-46,0 sec 1,91 MByte 7,99 Mbits / sec
[5] 46.0-48.0 sec 1.90 MBytes 7.98 Mbits / sec
[5] 48,0-50,0 sec 1,84 MByte 7,70 Mbits / sec
[5] 50,0-52,0 sec 1,93 MBytes 8,09 Mbits / sec
[5] 52,0-54,0 sec 1,80 MByte 7,54 Mbits / sec
[5] 54,0-56,0 sec 1,83 MByte 7,67 Mbits / sec
[5] 56,0-58,0 sec 1,88 MByte 7,86 Mbits / sec
[5] 58.0-60.0 sec 1.85 MBytes 7.78 Mbits / sec
[5] 0,0-60,3 sec 56,0 MByte 7,79 Mbits / sec
  • Per arrivare alla fine, ecco i test UDP di due host nella stessa VLAN che utilizzano ancora Metro Connection, 200 = remoto, 201 = DC

Vediamo che la perdita di pacchetti aumenta con l'incremento della larghezza di banda (quando ci avviciniamo a 10 Mbps abbiamo lo 0,93%, inizia a essere critico ... e spiegherebbe anche perché TCP ha problemi di prestazioni)

++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Server in ascolto sulla porta UDP 5001
Ricezione di datagrammi da 1470 byte
Dimensione buffer UDP: 64,0 KByte (impostazione predefinita)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Client connesso a 192.168.191.200, porta UDP 5001
Invio di datagrammi da 1470 byte
Dimensione buffer UDP: 64,0 KByte (impostazione predefinita)
-------------------------------------------------- ----------
[4] porta locale 192.168.191.201 61759 collegata alla porta 192168.191.200 5001
[ID] Larghezza di banda di trasferimento a intervalli
[4] 0,0- 1,0 sec 128 KByte 1,05 Mbits / sec
[4] 1,0-2,0 secondi 128 KByte 1,05 Mbits / sec
[4] 2,0- 3,0 sec 129 KByte 1,06 Mbits / sec
[4] 3,0- 4,0 sec 128 KByte 1,05 Mbits / sec
[4] 4.0- 5.0 sec 128 KBytes 1.05 Mbits / sec
[4] 5,0-6,0 secondi 128 KByte 1,05 Mbits / sec
[4] 6.0- 7.0 sec 128 KBytes 1.05 Mbits / sec
[4] 7.0- 8.0 sec 128 KBytes 1.05 Mbits / sec
[4] 8.0- 9.0 sec 128 KBytes 1.05 Mbits / sec
[4] 9.0-10.0 sec 129 KBytes 1.06 Mbits / sec
[4] 10,0-11,0 secondi 128 KByte 1,05 Mbits / sec
[4] 11,0-12,0 secondi 128 KByte 1,05 Mbits / sec
[4] 12,0-13,0 sec 128 KByte 1,05 Mbits / sec
[4] 13,0-14,0 secondi 128 KByte 1,05 Mbits / sec
[4] 14,0-15,0 secondi 128 KByte 1,05 Mbits / sec
[4] 15,0-16,0 sec 128 KByte 1,05 Mbits / sec
[4] 16,0-17,0 sec 128 KByte 1,05 Mbits / sec
[4] 17,0-18,0 sec 128 KByte 1,05 Mbits / sec
[4] 18,0-19,0 ​​secondi 131 KByte 1,07 Mbits / sec
[4] 19,0-20,0 sec 128 KByte 1,05 Mbits / sec
[4] 0,0-20,0 secondi 2,50 MByte 1,05 Mbits / sec
[4] Inviato 1785 datagrammi
[4] Rapporto del server:
[4] 0.0-20.0 sec 2.50 MBytes 1.05 Mbits / sec 0.257 ms 0/1785 (0%)
[3] porta locale 192.168.191.201 5001 collegata alla porta 192.168.191.200 50749
[3] 0,0- 1,0 sec 128 KByte 1,05 Mbits / sec 0,285 ms 0/89 (0%)
[3] 1,0-2,0 secondi 128 KByte 1,05 Mbits / sec 0,313 ms 0/89 (0%)
[3] 2,0- 3,0 sec 128 KByte 1,05 Mbits / sec 0,278 ms 0/89 (0%)
[3] 3.0- 4.0 sec 128 KBytes 1.05 Mbits / sec 0.241 ms 0/89 (0%)
[3] 4.0- 5.0 sec 128 KBytes 1.05 Mbits / sec 0.266 ms 0/89 (0%)
[3] 5,0-6,0 secondi 128 KByte 1,05 Mbits / sec 0,293 ms 0/89 (0%)
[3] 6.0- 7.0 sec 128 KBytes 1.05 Mbits / sec 0.314 ms 0/89 (0%)
[3] 7.0- 8.0 sec 128 KBytes 1.05 Mbits / sec 0.280 ms 0/89 (0%)
[3] 8.0- 9.0 sec 128 KBytes 1.05 Mbits / sec 0.242 ms 0/89 (0%)
[3] 9.0-10.0 sec 129 KBytes 1.06 Mbits / sec 0.250 ms 0/90 (0%)
[3] 10,0-11,0 sec 128 KByte 1,05 Mbits / sec 0,275 ms 0/89 (0%)
[3] 11,0-12,0 sec 128 KByte 1,05 Mbits / sec 0,299 ms 0/89 (0%)
[3] 12,0-13,0 sec 128 KByte 1,05 Mbits / sec 0,327 ms 0/89 (0%)
[3] 13,0-14,0 sec 128 KByte 1,05 Mbits / sec 0,290 ms 0/89 (0%)
[3] 14,0-15,0 sec 128 KByte 1,05 Mbits / sec 0,251 ms 0/89 (0%)
[3] 15,0-16,0 sec 128 KByte 1,05 Mbits / sec 0,275 ms 0/89 (0%)
[3] 16,0-17,0 sec 128 KByte 1,05 Mbits / sec 0,303 ms 0/89 (0%)
[3] 17.0-18.0 sec 128 KByte 1.05 Mbits / sec 0.333 ms 0/89 (0%)
[3] 18,0-19,0 ​​secondi 128 KByte 1,05 Mbits / sec 0,294 ms 0/89 (0%)
[3] 19,0-20,0 secondi 131 KByte 1,07 Mbits / sec 0,281 ms 0/91 (0%)
[3] 0.0-20.0 sec 2.50 MBytes 1.05 Mbits / sec 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 in ascolto sulla porta UDP 5001
Ricezione di datagrammi da 1470 byte
Dimensione buffer UDP: 64,0 KByte (impostazione predefinita)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Client connesso a 192.168.191.200, porta UDP 5001
Invio di datagrammi da 1470 byte
Dimensione buffer UDP: 64,0 KByte (impostazione predefinita)
-------------------------------------------------- ----------
[4] porta locale 192.168.191.201 61760 collegata alla porta 192168.191.200 5001
[ID] Larghezza di banda di trasferimento a intervalli
[4] 0,0- 1,0 sec 610 KByte 5,00 Mbits / sec
[4] 1,0- 2,0 secondi 609 KByte 4,99 Mbits / sec
[4] 2,0- 3,0 secondi 610 KByte 5,00 Mbits / sec
[4] 3.0- 4.0 sec 609 KBytes 4.99 Mbits / sec
[4] 4.0- 5.0 sec 610 KBytes 5.00 Mbits / sec
[4] 5.0- 6.0 sec 609 KBytes 4.99 Mbits / sec
[4] 6.0- 7.0 sec 610 KBytes 5.00 Mbits / sec
[4] 7.0- 8.0 sec 609 KBytes 4.99 Mbits / sec
[4] 8.0- 9.0 sec 610 KBytes 5.00 Mbits / sec
[4] 9.0-10.0 sec 619 KBytes 5.07 Mbits / sec
[4] 10,0-11,0 secondi 610 KByte 5,00 Mbits / sec
[4] 11,0-12,0 secondi 609 KByte 4,99 Mbits / sec
[4] 12,0-13,0 secondi 609 KByte 4,99 Mbits / sec
[4] 13,0-14,0 secondi 610 KByte 5,00 Mbits / sec
[4] 14,0-15,0 secondi 609 KByte 4,99 Mbits / sec
[4] 15,0-16,0 secondi 610 KByte 5,00 Mbits / sec
[4] 16,0-17,0 secondi 609 KByte 4,99 Mbits / sec
[4] 17.0-18.0 sec 610 KBytes 5.00 Mbits / sec
[4] 18,0-19,0 ​​secondi 619 KByte 5,07 Mbits / sec
[4] 19,0-20,0 secondi 609 KByte 4,99 Mbits / sec
[4] 0,0-20,0 sec 11,9 MByte 5,00 Mbits / sec
[4] Inviato 8504 datagrammi
[4] Rapporto del server:
[4] 0,0-20,0 sec 11,9 MByte 4,99 Mbits / sec 0,000 ms 12/8503 (0,14%)
[4] 0,0-20,0 sec 1 datagrammi ricevuti fuori servizio
[3] porta locale 192.168.191.201 5001 collegata con la porta 50750 192.168.191.200
[3] 0.0- 1.0 sec 606 KBytes 4.96 Mbits / sec 2.238 ms 1/423 (0,24%)
[3] 1.0- 2.0 sec 610 KBytes 5.00 Mbits / sec 2.739 ms 0/425 (0%)
[3] 2.0- 3.0 sec 609 KBytes 4.99 Mbits / sec 3.089 ms 1/425 (0,24%)
[3] 3.0- 4.0 sec 609 KBytes 4.99 Mbits / sec 3.605 ms 0/424 (0%)
[3] 4.0- 5.0 sec 607 KBytes 4.97 Mbits / sec 1.954 ms 0/423 (0%)
[3] 5,0-6,0 sec 612 KByte 5,01 Mbits / sec 2.666 ms 0/426 (0%)
[3] 6.0- 7.0 sec 607 KBytes 4.97 Mbits / sec 2.602 ms 0/423 (0%)
[3] 7.0- 8.0 sec 612 KBytes 5.01 Mbits / sec 2.960 ms 0/426 (0%)
[3] 8.0- 9.0 sec 609 KBytes 4.99 Mbits / sec 2.512 ms 0/424 (0%)
[3] 9.0-10.0 sec 619 KBytes 5.07 Mbits / sec 2.133 ms 0/431 (0%)
[3] 10,0-11,0 secondi 609 KByte 4,99 Mbits / sec 3,605 ms 1/425 (0,24%)
[3] 11,0-12,0 secondi 609 KByte 4,99 Mbits / sec 2,509 ms 0/424 (0%)
[3] 12,0-13,0 secondi 610 KByte 5,00 Mbits / sec 3.570 ms 0/425 (0%)
[3] 13,0-14,0 secondi 609 KByte 4,99 Mbits / sec 3.077 ms 1/425 (0,24%)
[3] 14,0-15,0 secondi 609 KByte 4,99 Mbits / sec 2.679 ms 0/424 (0%)
[3] 15.0-16.0 sec 609 KBytes 4.99 Mbits / sec 1.887 ms 0/424 (0%)
[3] 16.0-17.0 sec 610 KBytes 5.00 Mbits / sec 2.651 ms 0/425 (0%)
[3] 17.0-18.0 sec 609 KBytes 4.99 Mbits / sec 3.390 ms 0/424 (0%)
[3] 18,0-19,0 ​​secondi 617 KByte 5,06 Mbits / sec 2.601 ms 0/430 (0%)
[3] 19,0-20,0 sec 612 KByte 5,01 Mbits / sec 3.525 ms 0/426 (0%)
[3] 0,0-20,0 sec 11,9 MByte 4,99 Mbits / sec 3.156 ms 3/8503 (0,035%)
[3] 0,0-20,0 sec 1 datagrammi ricevuti fuori servizio

++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 9m
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Server in ascolto sulla porta UDP 5001
Ricezione di datagrammi da 1470 byte
Dimensione buffer UDP: 64,0 KByte (impostazione predefinita)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Client connesso a 192.168.191.200, porta UDP 5001
Invio di datagrammi da 1470 byte
Dimensione buffer UDP: 64,0 KByte (impostazione predefinita)
-------------------------------------------------- ----------
[4] porta 192.168.191.201 locale 61761 collegata alla porta 5001 192.168.191.200
[ID] Larghezza di banda di trasferimento a intervalli
[4] 0,0- 1,0 sec 1,07 MBytes 9,00 Mbits / sec
[4] 1.0- 2.0 sec 1.07 MBytes 8.98 Mbits / sec
[4] 2,0- 3,0 sec 1,07 MBytes 9,00 Mbits / sec
[4] 3.0- 4.0 sec 1.07 MBytes 8.98 Mbits / sec
[4] 4.0- 5.0 sec 1.07 MBytes 9.00 Mbits / sec
[4] 5.0- 6.0 sec 1.07 MBytes 8.98 Mbits / sec
[4] 6.0- 7.0 sec 1.07 MBytes 8.98 Mbits / sec
[4] 7.0- 8.0 sec 1.07 MBytes 9.00 Mbits / sec
[4] 8.0- 9.0 sec 1.07 MBytes 8.98 Mbits / sec
[4] 9.0-10.0 sec 1.09 MBytes 9.14 Mbits / sec
[4] 10,0-11,0 sec 1,07 MByte 9,00 Mbits / sec
[4] 11,0-12,0 sec 1,07 MBytes 8,98 Mbits / sec
[4] 12,0-13,0 sec 1,07 MBytes 8,98 Mbits / sec
[4] 13,0-14,0 secondi 1,07 MByte 9,00 Mbits / sec
[4] 14,0-15,0 sec 1,07 MBytes 8,98 Mbits / sec
[4] 15,0-16,0 sec 1,07 MBytes 9,00 Mbits / sec
[4] 16,0-17,0 sec 1,07 MBytes 8,98 Mbits / sec
[4] 17.0-18.0 sec 1.07 MBytes 8.98 Mbits / sec
[4] 18,0-19,0 ​​secondi 1,09 MByte 9,14 Mbits / sec
[4] 19,0-20,0 sec 1,07 MBytes 9,00 Mbits / sec
[4] 0,0-20,0 secondi 21,5 MByte 9,00 Mbits / sec
[4] Inviato 15315 datagrammi
[4] Rapporto del server:
[4] 0,0-20,0 sec 21,3 MByte 8,94 Mbits / sec 0,104 ms 96/15314 (0,63%) !!!!!!!!!!
[4] 0,0-20,0 sec 1 datagrammi ricevuti fuori servizio
[3] porta locale 192.168.191.201 5001 collegata alla porta 192.168.191.200 50751
[3] 0.0- 1.0 sec 1.06 MBytes 8.89 Mbits / sec 2.405 ms 0/756 (0%)
[3] 1.0- 2.0 sec 1.07 MBytes 9.00 Mbits / sec 2.308 ms 0/765 (0%)
[3] 2.0- 3.0 sec 1.07 MBytes 9.00 Mbits / sec 2.305 ms 0/765 (0%)
[3] 3.0- 4.0 sec 1.07 MBytes 8.97 Mbits / sec 2.290 ms 1/764 (0.13%)
[3] 4.0- 5.0 sec 1.07 MBytes 8.98 Mbits / sec 2.271 ms 1/765 (0,13%)
[3] 5.0- 6.0 sec 1.07 MBytes 8.98 Mbits / sec 2.313 ms 0/764 (0%)
[3] 6.0- 7.0 sec 1.07 MBytes 9.00 Mbits / sec 2.191 ms 0/765 (0%)
[3] 7.0- 8.0 sec 1.07 MBytes 8.95 Mbits / sec 2.314 ms 3/764 (0,39%)
[3] 8.0- 9.0 sec 1.07 MBytes 8.98 Mbits / sec 2.232 ms 1/765 (0.13%)
[3] 9.0-10.0 sec 1.09 MBytes 9.13 Mbits / sec 2.257 ms 0/776 (0%)
[3] 10.0-11.0 sec 1.07 MBytes 8.98 Mbits / sec 2.365 ms 0/764 (0%)
[3] 11,0-12,0 sec 1,07 MBytes 8,98 Mbits / sec 2.301 ms 1/765 (0,13%)
[3] 12,0-13,0 sec 1,07 MBytes 8,98 Mbits / sec 2.277 ms 0/764 (0%)
[3] 13,0-14,0 secondi 1,07 MByte 9,00 Mbits / sec 2,332 ms 0/765 (0%)
[3] 14,0-15,0 secondi 1,07 MByte 9,00 Mbits / sec 2,176 ms 0/765 (0%)
[3] 15,0-16,0 secondi 1,07 MByte 8,96 Mbits / sec 2,273 ms 2/764 (0,26%)
[3] 16,0-17,0 sec 1,07 MBytes 8,98 Mbits / sec 2.313 ms 0/764 (0%)
[3] 17.0-18.0 sec 1.07 MBytes 8.98 Mbits / sec 2.247 ms 1/765 (0.13%)
[3] 18,0-19,0 ​​secondi 1,09 MByte 9,11 Mbits / sec 2,276 ms 1/776 (0,13%)
[3] 19,0-20,0 sec 1,07 MBytes 8,97 Mbits / sec 2.394 ms 1/764 (0,13%)
[3] 0,0-20,0 secondi 21,5 MByte 8,99 Mbits / sec 2,665 ms 11/15314 (0,072%)
[3] 0,0-20,0 sec 1 datagrammi ricevuti fuori servizio

++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 9850k
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Server in ascolto sulla porta UDP 5001
Ricezione di datagrammi da 1470 byte
Dimensione buffer UDP: 64,0 KByte (impostazione predefinita)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Client connesso a 192.168.191.200, porta UDP 5001
Invio di datagrammi da 1470 byte
Dimensione buffer UDP: 64,0 KByte (impostazione predefinita)
-------------------------------------------------- ----------
[4] porta locale 192.168.191.201 61762 collegata alla porta 192168.191.200 5001
[ID] Larghezza di banda di trasferimento a intervalli
[4] 0.0- 1.0 sec 1.17 MBytes 9.84 Mbits / sec
[4] 1.0- 2.0 sec 1.17 MBytes 9.84 Mbits / sec
[4] 2,0- 3,0 sec 1,17 MBytes 9,84 Mbits / sec
[4] 3.0- 4.0 sec 1.17 MBytes 9.84 Mbits / sec
[4] 4.0- 5.0 sec 1.17 MBytes 9.84 Mbits / sec
[4] 5.0- 6.0 sec 1.17 MBytes 9.83 Mbits / sec
[4] 6.0- 7.0 sec 1.17 MBytes 9.84 Mbits / sec
[4] 7.0- 8.0 sec 1.17 MBytes 9.84 Mbits / sec
[4] 8.0- 9.0 sec 1.17 MBytes 9.84 Mbits / sec
[4] 9.0-10.0 sec 1.19 MBytes 10.0 Mbits / sec
[4] 10,0-11,0 sec 1,17 MByte 9,84 Mbits / sec
[4] 11,0-12,0 sec 1,17 MByte 9,84 Mbits / sec
[4] 12,0-13,0 sec 1,17 MByte 9,83 Mbits / sec
[4] 13,0-14,0 secondi 1,17 MByte 9,85 Mbits / sec
[4] 14,0-15,0 sec 1,17 MByte 9,83 Mbits / sec
[4] 15,0-16,0 sec 1,17 MBytes 9,85 Mbits / sec
[4] 16,0-17,0 sec 1,17 MByte 9,83 Mbits / sec
[4] 17.0-18.0 sec 1.17 MBytes 9.84 Mbits / sec
[4] 18,0-19,0 ​​sec 1,19 MBytes 10,0 Mbits / sec
[4] 19,0-20,0 sec 1,17 MByte 9,84 Mbits / sec
[4] 0,0-20,0 secondi 23,5 MByte 9,85 Mbits / sec
[4] Inviato 16765 datagrammi
[4] Rapporto del server:
[4] 0,0-20,0 sec 23,3 MByte 9,74 Mbits / sec 3.421 ms 156/16764 (0,93%) !!!!!!!!!!
[4] 0,0-20,0 sec 1 datagrammi ricevuti fuori servizio
[3] porta locale 192.168.191.201 5001 collegata alla porta 192.168.191.200 50752
[3] 0.0- 1.0 sec 1.16 MBytes 9.74 Mbits / sec 2.131 ms 0/828 (0%)
[3] 1.0- 2.0 sec 1.17 MBytes 9.84 Mbits / sec 2.140 ms 0/837 (0%)
[3] 2.0- 3.0 sec 1.17 MBytes 9.83 Mbits / sec 2.099 ms 1/837 (0,12%)
[3] 3.0- 4.0 sec 1.17 MBytes 9.84 Mbits / sec 2.113 ms 0/837 (0%)
[3] 4.0- 5.0 sec 1.17 MBytes 9.84 Mbits / sec 2.105 ms 0/837 (0%)
[3] 5.0- 6.0 sec 1.17 MBytes 9.83 Mbits / sec 2.058 ms 1/837 (0,12%)
[3] 6.0- 7.0 sec 1.17 MBytes 9.82 Mbits / sec 2.165 ms 1/836 (0.12%)
[3] 7.0- 8.0 sec 1.17 MBytes 9.84 Mbits / sec 2.156 ms 0/837 (0%)
[3] 8.0- 9.0 sec 1.17 MBytes 9.82 Mbits / sec 2.135 ms 2/837 (0.24%)
[3] 9.0-10.0 sec 1.19 MBytes 9.97 Mbits / sec 2.152 ms 2/850 (0.24%)
[3] 10,0-11,0 sec 1,17 MByte 9,83 Mbits / sec 2,153 ms 1/837 (0,12%)
[3] 11,0-12,0 sec 1,17 MByte 9,84 Mbits / sec 2,127 ms 0/837 (0%)
[3] 12,0-13,0 sec 1,17 MByte 9,83 Mbits / sec 2,136 ms 1/837 (0,12%)
[3] 13,0-14,0 sec 1,17 MByte 9,82 Mbits / sec 2,087 ms 2/837 (0,24%)
[3] 14,0-15,0 sec 1,17 MByte 9,83 Mbits / sec 2,061 ms 1/837 (0,12%)
[3] 15,0-16,0 sec 1,17 MByte 9,84 Mbits / sec 2.045 ms 0/837 (0%)
[3] 16,0-17,0 sec 1,17 MByte 9,82 Mbits / sec 2,203 ms 1/836 (0,12%)
[3] 17.0-18.0 sec 1.17 MBytes 9.84 Mbits / sec 2.165 ms 0/837 (0%)
[3] 18,0-19,0 ​​secondi 1,17 MByte 9,83 Mbits / sec 2,154 ms 1/837 (0,12%)
[3] 19,0-20,0 sec 1,19 MByte 9,98 Mbits / sec 2,209 ms 0/849 (0%)
[3] 0,0-20,0 sec 23,5 MByte 9,84 Mbits / sec 2.548 ms 13/16764 (0,078%)
[3] 0,0-20,0 sec 1 datagrammi ricevuti fuori servizio

La vera domanda rimane:

Non stiamo sottoscrivendo in eccesso il collegamento DC poiché è a 100 Mbps e non è possibile inviare più di 100 Mbps. Tuttavia, i siti remoti sono a 10 Mbps.

  • I buffer sul lato remoto traboccano e scartano i pacchetti?
  • Lo shaper del traffico del provider sta facendo qualcosa per il traffico? (Il traffico proveniente da un altro nodo sarebbe influenzato dallo shaper del traffico degli ISP o solo dal traffico che entra nel nodo (dall'esterno)) ...... Capisci cosa intendo?

Perché TCP non può gestire tutto da solo?

Aggiornamento n. 3 Ora ho usato il seguente scenario:

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

Ecco la perdita di pacchetti nella direzione remota DC->: (test UDP iperf 9 Mbps)

[  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

L'altra direzione va bene. Tuttavia , quando si esegue un test TCP la direzione remota-> DC non funziona molto meglio della direzione remota DC-> (circa 5 Mbps) .......

Non sono sicuro che abbiamo raggiunto il fondo di questo.

ethernet  tcp  troubleshooting  packet-analysis  metro-ethernet 
— Marki
fonte
Non proprio una risposta, ma la mia raccomandazione sarebbe quella di ottenere un JDSU e testare questo circuito. Se ti stanno sorvegliando, assicurati di avere il poliziotto, il "regolatore", le impostazioni ... Se hanno un piccolo CBS, limitano il tuo traffico TCP a una finestra essenzialmente più piccola. È possibile verificare questo tramite un test back-2-back. Ho trascorso molto tempo a fare avanti e indietro con i fornitori sui circuiti L2 per sapere che quando otteniamo un nuovo circuito lo
— testiamo a
Inoltre, solo una breve nota a margine. Il throughput TCP che viene visualizzato da un sistema operativo Windows rispetto a Linux sarà diverso perché le impostazioni TCP saranno diverse; vale a dire. dimensione del buffer, algoritmo, ecc. È possibile visualizzare le impostazioni per la propria macchina Linux tramite sysctldubbi su Windows ... forse netsh. Se avessi intenzione di indovinare cosa non va nel tuo circuito, direi che il CPE nel sito dei raggi è configurato con una CBS più grande rispetto al lato hub ... che di solito è il contrario. Ancora una volta, il JDSU punterà di nuovo la palla verso di loro o ti consentirà di concentrarti nuovamente sul problema.
— matak,
@matak Perché non dare una risposta aggiuntiva alle tue osservazioni? Quando parliamo del shaper, dove immagino questo dispositivo? Alla DC c'è una presa RJ45 senza CPE (visibile). Nei siti remoti ho principalmente un modem VDSL e una sorta di router compatibile con MPLS. Non sono sicuro se usano MPLS però. E inoltre quale direzione del traffico forma il shaper? Possiamo modellare ingress @ raggio (dal sito), egress @ raggio (verso il cloud ISP), ingress @ hub (da DC), egress @ hub (verso il cloud ISP) ... probabilmente mi manca il quadro generale. Puoi spiegare perché il problema con la CBS sarebbe un problema?
— Marki,

Risposte:

20

Facendo riferimento alla nostra chat di Stack Exchange ...

Per farla breve, è necessario controllare i disallineamenti di velocità su entrambi i lati dei collegamenti Ethernet della metropolitana ... Ho ridisegnato il diagramma per motivi di chiarezza ... Nota 1

Diagramma del problema

  • La transizione DC (mostrata in verde) passa da 10GE a 100M molto rapidamente ... questa è una transizione di velocità di 100 volte, e di solito è necessario implementare una qualche forma di qos (come la modellatura) per mitigare una transizione così ampia. Vedi il fondo di questa risposta per la prova che il DC ha bisogno di essere modellato (per sito) ...
  • Il lato remoto passa da 1GE a un CIR da 10 M molto rapidamente ... anche in questo caso è una transizione di velocità di 100 volte. In genere sono richieste soluzioni alternative per la modellazione o altri qos.
  • Sembra inoltre che vi sia una discrepanza di velocità tra la DC UNI (100M) e la remota UNI (10M); questo stesso richiede una soluzione per la gestione della larghezza di banda per sito.

Cordiali saluti, se il vostro fornitore implementa servizi conformi a MEF , non stanno modellando, ma stanno controllando . Il traffico TCP tende a funzionare meglio con la modellazione .

La necessità del tuo QoS

Sembri mettere in dubbio la necessità di qos , quindi citerò dal white paper MEF "Comprensione della portante Ethernet" , pagina 9 ... a titolo di revisione, il cliente nella figura 2 del white paper MEF ha una situazione migliore di te. .. hanno acquistato un CIR da 50 Mbps, ma la loro UNI è consegnata su 1GE ... il tuo sito remoto ha un CIR da 10 Mbps su una UNI 1GE.

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.

Risposta ad altre domande TCP in una modifica ...

Non stiamo sottoscrivendo in eccesso il collegamento DC poiché è a 100 Mbps e non è possibile inviare più di 100 Mbps ...

Non sono d'accordo, puoi inviare microburst a 10GE perché il tuo DC ha collegamenti 10GE, ma la metro UNI è 100 Mbps. Una domanda aperta è quanto buffer hai sullo switch LAN Enterasys (Switch A) quando effettui la transizione da 10GE a 100M.

Perché TCP non può gestire tutto da solo?

TCP gestisce le cose rallentando quando vede la perdita di pacchetti ... rallenta davvero (e potrebbe interrompere la connessione) per una grave perdita di pacchetti. Quindi, TCP sta facendo quello che dovrebbe ... come ingegnere di rete, il tuo obiettivo è costruire una rete con condizioni che rendano felice TCP.

Altre domande TCP dalla chat

Marki ha detto : Non capisco cosa viene abbandonato dove e da chi e perché e perché TCP non gestisce semplicemente il fatto che ci sono (reali) 100 Mb a un'estremità e solo 10 Mbps all'altra.

Per quanto riguarda la necessità di buffering di TCP e le conseguenze della mancanza di buffer :

Fatto numero 1: TCP ha bisogno del buffering per le transizioni di velocità perché è progettato come un sistema di controllo del feedback .

Usando un'analogia di guida: come buoni conducenti lasciamo sempre qualche secondo di spazio tra noi e la macchina di fronte a noi; in un certo senso, quello spazio tra le auto è approssimativamente analogo a un buffer di rete. Se la persona davanti a noi sbatte i freni quando un animale corre davanti a loro, lo spazio tra le nostre macchine (si spera) ci impedisce di colpire la loro auto. Lasciamo spazio perché ci vuole tempo perché i nostri occhi vedano le luci dei freni, il piede per reagire e i freni per dissipare abbastanza calore; i nostri occhi ci danno un sistema di controllo del feedback visivo.

Allo stesso modo, quando una sessione FTP viene espulsa a 10GE, esplosioni di traffico potrebbero essere lunghe fino a 4 MB (nel tuo caso) a causa delle dimensioni della finestra ridimensionate TCP prima che il socket debba arrestarsi e attendere un ACK TCP. Nel frattempo, se il flusso di traffico 10GE colpisce improvvisamente una "Fast Ethernet", TCP deve rallentare gradualmente. I buffer profondi nelle apparecchiature di rete consentono al TCP di rilasciare molti meno pacchetti quando effettua transizioni di velocità; tuttavia, se non si dispone di buffer, è possibile far cadere forse il 99% di quella finestra TCP da 4 MB quando è limitata da 10GE a 100M. Pensa a quella grave perdita del 99% come a un arresto del socket TCP; TCP reagisce prevedibilmente alla perdita di pacchetti relativamente graduale. TCP reagisce in modo molto meno prevedibile alla perdita di pacchetti in corso, grave Nota 3 .

Alla domanda sul perché non dovresti usare un CIR Ethernet asimmetrico Metro con 100 M sul DC e 10 M sul telecomando, poniti una domanda retorica "chi sta tamponando quel traffico da 100 Mbps quando esplode il NID Ethernet da 10 Mb a buon mercato che la tua metropolitana -Fornitore Ethernet ti ha dato? "... (suggerimento: nessuno sta bufferando).

Se nessuno esegue il buffering delle grandi transizioni di velocità (vedi Nota 2), quei punti sono potenziali luoghi in cui il traffico viene interrotto in modo intermittente.

Cosa viene abbandonato da chi :

Il traffico in uscita scende dalla DC

Quando il traffico TCP lascia il data center, ci sono tre posizioni in cui potrebbe essere eliminato:

  • A D1: perché gli switch LAN raramente hanno un buffer sufficientemente profondo per una transizione di velocità 100: 1
  • A D2: se il NID ha mai negoziato il collegamento UNI a una velocità superiore rispetto al CIR ; non è il caso adesso, quindi non mi aspetto che cali lì.
  • Al D3: per tutti i motivi che ho appena descritto sui CIR asimmetrici Ethernet Metro .

Quando il traffico TCP va al data center ...

Il traffico in ingresso scende verso la DC

  • A D4: perché hai una UNI 1GE e una CIR 10M ; questo è il caso patologico di D2 che ho menzionato sopra.

Come mitigare le differenze di velocità:

Una soluzione EVPL di esempio : EVPL con soluzione EVC point-to-point

  • In una topologia commutata come questa, un EVPL con EVC punto a punto dalla CC a ciascun telecomando è probabilmente l'opzione migliore (vedere il diagramma sopra). Ciò applicherebbe un singolo CIR a ciascun EVC. Nota: si applicano tutte le altre indicazioni QoS in questa risposta ... vale a dire evitare grandi transizioni di velocità Nota 2 senza testare se l'apparecchiatura sarà in grado di gestirla abbastanza bene.
  • In alternativa, potresti prendere in considerazione l'acquisto di servizi metropolitani con tariffe simmetriche tra DC e telecomando; anche se ammetterei che potrebbe non essere la guida più pratica.
  • Cordiali saluti, la soluzione classica a questo problema per i servizi di routing è quella di acquistare router che supportano la modellazione alle velocità richieste e quindi modellare il traffico della metropolitana verso il CIR appropriato (per sito remoto). Cordiali saluti, il lato remoto potrebbe cavarsela con un router ragionevolmente piccolo, dal momento che è solo un ingresso 1GE e un CIR da 10 Mbps ... Mesi fa, quando abbiamo parlato della progettazione di questo servizio, ho raccomandato il routing se ti sentivi a tuo agio con le tecnologie ...

  • Se non hai soldi extra da spendere e non riesci a riprogettare il tuo servizio metro-ethernet, potresti massaggiare i disallineamenti di velocità più gradualmente. Non l'ho mai fatto, ma in linea di principio potresti provare a effettuare le transizioni di velocità da 10 a 1, anziché 100 a 1 (che è quello che hai attualmente sia in DC che in remoto):

    • Invece di acquistare un router per modellare il telecomando a 10 M, potresti provare a forzare la UNI remota a negoziare automaticamente a 100 M anziché a 1GE; GigabitEthernet richiede tutti i pin di un cavo Cat5e , quindi è possibile forzarlo efficacemente a 100 M con una spina mod RJ45 che collega semplicemente i pin 1, 2, 3 e 6.
    • Invece di acquistare un router per modellare il DC su 100M, usa Enterasys per sorvegliare il link 10GE su 1GE quando invii traffico verso il link 100M

Analisi dei iperfrisultati ...

Ci sono due punti chiave da ricordare iperf(tutte le informazioni basate sulla iperfversione 2):

Pertanto, il seguente output mostra che la macchina DC (in iperf -cmodalità) si connette al iperfserver nel sito remoto (192.168.x) e invia i dati dal DC (100M UNI) al sito remoto (10M UNI) ...

./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

L'uscita sopra mostra chiaramente i problemi nella direzione CC verso la direzione remota; dovremmo aspettarci di vedere 9 Mbps o più quando le cose funzionano bene (vale a dire che ti aspetti almeno il 90% della capacità - 10 Mbps nel sito remoto). Ora, esaminiamo il traffico nella direzione opposta (quando si iperftrasferiscono i dati dal sito remoto alla DC) ...

[  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

Sei in grado di inviare circa l'80% della capacità del tuo CIR remoto, ma è comunque inferiore a quello che mi aspetto.

Illustrazione della mancata corrispondenza della velocità CC (10 Gbps -> 100 Mbps)

marki ha detto : Non dimenticare, il problema si presenta solo quando il flusso è 100 Mb -> 10 Mb, non viceversa.

Il problema si manifesta in entrambe le direzioni, ma i iperfsintomi sembrano peggiorare nella DC -> direzione remota. Vedi la mia analisi iperfdell'output sopra.

Per rendere concreto questo, diamo un'occhiata al tuo pcap FTP quando invii un file dal tuo server FTP DC (130.1.6.4) al sito remoto (192.168.191.2). Il trasferimento dal lato Ethernet della metropolitana 100M viene limitato in diversi punti durante il trasferimento. Potete vederlo se guardate il dc-to-remote_remote-side.pcapngpcap e filtrateexpert.message contains "segment not captured"

inserisci qui la descrizione dell'immagine

Note finali :

Nota 1 Scelgo valori CBS di 25 KB per MetroEthernet CIR da 1 Mbps; questo è un rapporto comune utilizzato dai provider ... YMMV
Nota 2 La mia regola personale: "grande" è una transizione di velocità che è significativamente più grande di una transizione di velocità 10: 1
Nota 3Non posso fornire numeri concreti per ciò che è e non è troppa perdita di pacchetti per TCP. Se la perdita è abbastanza grave da far soffrire le tue applicazioni, è troppo. La mia regola personale: quando si ha a che fare con una rete aziendale cablata completamente sotto il mio controllo, qualsiasi perdita (involontaria) di pacchetti è eccessiva. Detto questo, ci sono alcuni modelli di switch che tagliano gli angoli nel buffering; questi interruttori possono occasionalmente far cadere pacchetti ... è una decisione di giudizio sul fatto che si debba convivere con il problema o acquistare interruttori migliori. Cordiali saluti: Non è sempre ovvio, ma TCP aumenta periodicamente la velocità di trasmissione di un socket per garantire che stia ricevendo il massimo throughput possibile; molte implementazioni TCP sanno che stanno andando troppo veloci quando vedono cadere i pacchetti.

— Mike Pennington
fonte
Si noti che la velocità PHY del DC (porta Metro Ethernet) è già a 100 Mb. Ma non riesco nemmeno a inviare a 100M perché l'altro lato ha un massimo di 10 Mb ... In questo momento non mi è ancora chiaro dove debba avvenire esattamente la modellatura. Oh, e volevi dire "i sintomi dell'iperf sembrano peggiorare nella DC -> direzione remota "?
— Marki,
Ho aggiornato la risposta, sì "remoto -> DC" era un refuso nella risposta originale.
— Mike Pennington,
Sono d'accordo con Mike qui, a seconda di chi sia il tuo provider, se chiedi loro che ti diranno la velocità di linea alla loro estremità, fai in modo che corrisponda alle tue interfacce fisiche che pendono dalla tua metro-E. Per quanto riguarda WHERE to QoS, lo farei nei punti di accesso più grandi, quindi nei dispositivi da 10 Gb, prima di passare ai dispositivi upstream più piccoli. Dedico più tempo al firewalling e al routing piuttosto che al passaggio, ma spero che Mike possa confermare le mie affermazioni!
— AL
3
@MikePennington - Il blocco dell'uscita a causa di disallineamenti di velocità è qualcosa in cui mi imbatto molto con i collegamenti a microonde P2P. Ottima risposta, molte buone informazioni nel tuo post. Grazie!
— matak,
1
Verificare anche la mancata corrispondenza duplex, questo può causare problemi di velocità unidirezionale.
— cpt_fink,
2

Mentre discutere questo problema è stato molto interessante, nel frattempo l'ISP ha iniziato a scambiare i modem DSL sui diversi siti con un altro marchio. Alcuni problemi di frammentazione dei pacchetti dicono. Ehi, 9,5 Mbps in entrambe le direzioni senza problemi o impostazioni speciali.

— Marki
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.