Solucionando problemas de baixa taxa de transferência TCP Metro Ethernet

14

A configuração

Alugamos algumas linhas alugadas que se apresentam como uma rede de camada 2, ou seja, você tem um grande canal no datacenter e os sites remotos têm canais menores. Dentro da rede da camada 2, você pode fazer o que quiser. Provavelmente, eles usam o 802.1ad para fornecer a cada cliente sua rede separada dentro de sua rede. A maioria dos sites do AFAICS é conectada via VDSL simples.

Decidimos colocar um roteador em cada site e dar a cada site sua própria VLAN. O firewall no controlador de domínio tem, assim, tantas VLANs definidas quanto existem sites. Cada site, portanto, usa seu intervalo de endereços na sua própria VLAN.

Diagrama de rede:

diagrama de rede

O problema

Agora, estamos diante de problemas de taxa de transferência:

  • A execução de uma transferência FTP do site para o DC funciona bem em cerca de 10 Mb / s, que é a velocidade da linha.
  • A execução de uma transferência FTP do controlador de domínio para o site não funciona bem a 6 Mb / s ou menos.

Não importa de que lado inicia a transferência. A única coisa consistente é que uma direção não está funcionando bem. Pena que é a direção do site, porque essa seria a largura de banda que mais precisamos, pois gostaríamos de usar os clientes do servidor de terminal.

Cerca de 10 segundos após a transferência, a taxa de transferência cai. Vemos DUP ACKs ao cheirar. O que talvez me leve a limitar a taxa no final do provedor? (Atualmente, eles não têm idéia, e eu gosto de garantir que não tenhamos culpa antes de escalar)

NOTA Os sites remotos estão limitados a 10 Mb de alguma forma. Definir a porta do switch para Metro como 10Mb também não ajuda. Na verdade, é o pior da época (máx. 30 KB / s). Definir 100Mb funciona bem, mas já começa a produzir o problema descrito. Mesmo para 1G.

As capturas do problema podem ser baixadas aqui:

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

Diagnóstico

Na imagem, você vê o gráfico do Wireshark IO com alguns detalhes de erro:

  • à esquerda: transferência de FTP do DC para o site
  • à direita: transferência de FTP do site para o DC

acks duplicados

Caso o outro lado inicie a transferência (ou seja, coloque de dc, em vez de obter de remoto), o problema permanece inalterado.

Mime-me com o que você acha que poderia ser o problema aqui.

ATUALIZAÇÃO # 1 (integrada acima)

ATUALIZAÇÃO # 2 ( ATUALIZADA )

Isso deve ser uma coisa de controle de congestionamento.

Observe que do DC para o remoto temos 10G-> 1G-> 100M-> 10M-> 1G links. <- não está funcionando

Na outra direção, temos o inverso: 1G-> 10M-> 100M-> 1G-> 10G. <- muito bem

O primeiro "1G-> 10M" é o 10M "invisível" no site remoto, onde tudo, incluindo a velocidade da porta de uplink, é definido em 1G, embora haja apenas 10M por trás (sendo vendido).

No entanto, os 100 Mbps no DC são 100 Mbps reais, a interface é configurada a 100 Mbps na camada física.

Eu agora usei o iperf:

  • Os testes TCP funcionam bem apenas em uma direção (cliente = DC, servidor = remoto)
./iperf -c 192.168.x -i2 -t 60 -r
-------------------------------------------------- ----------
Servidor escutando na porta TCP 5001
Tamanho da janela TCP: 85,3 KByte (padrão)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Cliente que se conecta a 192.168.x, porta TCP 5001
Tamanho da janela TCP: 16,0 KByte (padrão)
-------------------------------------------------- ----------
[3] porta 10.x local 38195 conectada à porta 500.1 192.168.x
[3] 0,0- 2,0 s 1,44 MBytes 6,03 Mbits / s
[3] 2,0- 4,0 s 2,23 MBytes 9,37 Mbits / s
[3] 4,0-6,0 s 2,28 MBytes 9,57 Mbits / s
[3] 6.0- 8.0 s 1.88 MBytes 7.90 Mbits / s
[3] 8.0-10.0 s 1.00 MBytes 4.19 Mbits / s
[3] 10,0-12,0 s 1,30 MBytes 5,47 Mbits / s
[3] 12,0-14,0 s 688 KBytes 2,82 Mbits / s
[3] 14.0-16.0 s 840 KBytes 3,44 Mbits / s
[3] 16,0-18,0 s 1,03 MBytes 4,33 Mbits / s
[3] 18,0-20,0 s 1,01 MBytes 4,23 Mbits / s
[3] 20,0-22,0 s 1,03 MBytes 4,33 Mbits / s
[3] 22,0-24,0 s 1,18 MBytes 4,95 Mbits / s
[3] 24,0-26,0 s 904 KBytes 3,70 Mbits / s
[3] 26,0-28,0 s 840 KBytes 3,44 Mbits / s
[3] 28,0-30,0 s 936 KBytes 3,83 Mbits / s
[3] 30,0-32,0 s 1,09 MBytes 4,59 Mbits / s
[3] 32,0-34,0 s 960 KBytes 3,93 Mbits / s
[3] 34,0-36,0 s 752 KBytes 3,08 Mbits / s
[3] 36.0-38.0 s 1.09 MBytes 4.59 Mbits / s
[3] 38,0-40,0 s 1,09 MBytes 4,59 Mbits / s
[3] 40,0-42,0 s 840 KBytes 3,44 Mbits / s
[3] 42,0-44,0 s 1,27 MBytes 5,34 Mbits / s
[3] 44,0-46,0 s 1,16 MBytes 4,85 Mbits / s
[3] 46,0-48,0 s 840 KBytes 3,44 Mbits / s
[3] 48,0-50,0 s 960 KBytes 3,93 Mbits / s
[3] 50,0-52,0 s 1,28 MBytes 5,37 Mbits / s
[3] 52,0-54,0 s 1,09 MBytes 4,59 Mbits / s
[3] 54,0-56,0 s 992 KBytes 4,06 Mbits / s
[3] 56,0-58,0 s 1,00 MBytes 4,19 Mbits / s
[3] 58.0-60.0 s 1.09 MBytes 4.59 Mbits / s
[3] 0.0-60.2 s 33.9 MBytes 4.73 Mbits / s
[5] porta 10.x local 5001 conectada à porta 192.168.x 10965
[5] 0,0- 2,0 s 1,85 MBytes 7,75 Mbits / s
[5] 2,0- 4,0 s 1,90 MBytes 7,98 Mbits / s
[5] 4,0-6,0 s 1,89 MBytes 7,93 Mbits / s
[5] 6.0- 8.0 s 1.92 MBytes 8.07 Mbits / s
[5] 8.0-10.0 s 1.91 MBytes 8.02 Mbits / s
[5] 10,0-12,0 s 1,83 MBytes 7,69 Mbits / s
[5] 12,0-14,0 s 1,86 MBytes 7,78 Mbits / s
[5] 14.0-16.0 s 1.79 MBytes 7.52 Mbits / s
[5] 16,0-18,0 s 1,79 MBytes 7,52 Mbits / s
[5] 18,0 a 20,0 s 1,89 MBytes 7,91 Mbits / s
[5] 20,0-22,0 s 1,91 MBytes 8,00 Mbits / s
[5] 22,0-24,0 s 1,88 MBytes 7,91 Mbits / s
[5] 24,0-26,0 s 1,95 MBytes 8,16 Mbits / s
[5] 26,0-28,0 s 1,90 MBytes 7,99 Mbits / s
[5] 28,0-30,0 s 1,87 MBytes 7,84 Mbits / s
[5] 30,0-32,0 s 1,85 MBytes 7,77 Mbits / s
[5] 32,0-34,0 s 1,55 MBytes 6,49 Mbits / s
[5] 34,0-36,0 s 1,92 MBytes 8,07 Mbits / s
[5] 36,0-38,0 s 1,90 MBytes 7,99 Mbits / s
[5] 38,0-40,0 s 1,84 MBytes 7,73 Mbits / s
[5] 40,0-42,0 s 1,66 MBytes 6,95 Mbits / s
[5] 42,0-44,0 s 1,92 MBytes 8,07 Mbits / s
[5] 44,0-46,0 s 1,91 MBytes 7,99 Mbits / s
[5] 46,0-48,0 s 1,90 MBytes 7,98 Mbits / s
[5] 48,0-50,0 s 1,84 MBytes 7,70 Mbits / s
[5] 50,0-52,0 s 1,93 MBytes 8,09 Mbits / s
[5] 52,0-54,0 s 1,80 MBytes 7,54 Mbits / s
[5] 54,0-56,0 s 1,83 MBytes 7,67 Mbits / s
[5] 56,0-58,0 s 1,88 MBytes 7,86 Mbits / s
[5] 58.0-60.0 s 1.85 MBytes 7.78 Mbits / s
[5] 0.0-60.3 s 56.0 MBytes 7.79 Mbits / s
  • Para entender melhor, aqui estão os testes UDP de dois hosts na mesma VLAN, usando a conexão Metro, 200 = remote, 201 = DC

Vemos a perda de pacotes aumentando com o aumento da largura de banda (quando nos aproximamos de 10 Mbps, temos 0,93%, começa a ser crítico ... e também explicaria por que o TCP tem problemas em executar)

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Servidor escutando na porta UDP 5001
Recebendo datagramas de 1470 bytes
Tamanho do buffer UDP: 64,0 KByte (padrão)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Cliente que se conecta a 192.168.191.200, porta UDP 5001
Enviando datagramas de 1470 bytes
Tamanho do buffer UDP: 64,0 KByte (padrão)
-------------------------------------------------- ----------
[4] porta local 192.168.191.201 61759 conectada com a porta 5001 192.168.191.200
Largura de banda de transferência de intervalo [ID]
[4] 0,0- 1,0 s 128 KBytes 1,05 Mbits / s
[4] 1,0 - 2,0 s, 128 KBytes 1,05 Mbits / s
[4] 2,0- 3,0 s 129 KBytes 1,06 Mbits / s
[4] 3.0- 4.0 s 128 KBytes 1.05 Mbits / s
[4] 4,0 - 5,0 s 128 KBytes 1,05 Mbits / s
[4] 5,0-6,0 s 128 KBytes 1,05 Mbits / s
[4] 6,0-7,0 s 128 KBytes 1,05 Mbits / s
[4] 7.0- 8.0 s 128 KBytes 1.05 Mbits / s
[4] 8,0-9,0 s 128 KBytes 1,05 Mbits / s
[4] 9.0-10.0 s 129 KBytes 1.06 Mbits / s
[4] 10.0-11.0 s 128 KBytes 1.05 Mbits / s
[4] 11.0-12.0 s 128 KBytes 1.05 Mbits / s
[4] 12,0-13,0 s 128 KBytes 1,05 Mbits / s
[4] 13,0-14,0 s 128 KBytes 1,05 Mbits / s
[4] 14.0-15.0 s 128 KBytes 1.05 Mbits / s
[4] 15.0-16.0 s 128 KBytes 1.05 Mbits / s
[4] 16,0-17,0 s 128 KBytes 1,05 Mbits / s
[4] 17.0-18.0 s 128 KBytes 1.05 Mbits / s
[4] 18.0-19.0 s 131 KBytes 1.07 Mbits / s
[4] 19.0-20.0 s 128 KBytes 1.05 Mbits / s
[4] 0,0-20,0 s 2,50 MBytes 1,05 Mbits / s
[4] Enviou 1785 datagramas
[4] Relatório do servidor:
[4] 0,0-20,0 s 2,50 MBytes 1,05 Mbits / s 0,257 ms 0/1785 (0%)
[3] porta local 5001 192.168.191.201 conectada à porta 50749 192.168.191.200
[3] 0,0- 1,0 s 128 KBytes 1,05 Mbits / s 0,285 ms 0/89 (0%)
[3] 1,0 - 2,0 s 128 KBytes 1,05 Mbits / s 0,313 ms 0/89 (0%)
[3] 2,0- 3,0 s 128 KBytes 1,05 Mbits / s 0,278 ms 0/89 (0%)
[3] 3,0- 4,0 s 128 KBytes 1,05 Mbits / s 0,241 ms 0/89 (0%)
[3] 4,0 - 5,0 s 128 KBytes 1,05 Mbits / s 0,266 ms 0/89 (0%)
[3] 5,0-6,0 s 128 KBytes 1,05 Mbits / s 0,293 ms 0/89 (0%)
[3] 6,0-7,0 s 128 KBytes 1,05 Mbits / s 0,314 ms 0/89 (0%)
[3] 7,0 - 8,0 s 128 KBytes 1,05 Mbits / s 0,280 ms 0/89 (0%)
[3] 8,0-9,0 s 128 KBytes 1,05 Mbits / s 0,242 ms 0/89 (0%)
[3] 9,0-10,0 s 129 KBytes 1,06 Mbits / s 0,250 ms 0/90 (0%)
[3] 10,0-11,0 s 128 KBytes 1,05 Mbits / s 0,275 ms 0/89 (0%)
[3] 11,0-12,0 s 128 KBytes 1,05 Mbits / s 0,299 ms 0/89 (0%)
[3] 12,0-13,0 s 128 KBytes 1,05 Mbits / s 0,327 ms 0/89 (0%)
[3] 13,0-14,0 s 128 KBytes 1,05 Mbits / s 0,290 ms 0/89 (0%)
[3] 14.0-15.0 s 128 KBytes 1.05 Mbits / s 0.251 ms 0/89 (0%)
[3] 15.0-16.0 s 128 KBytes 1.05 Mbits / s 0.275 ms 0/89 (0%)
[3] 16,0-17,0 s 128 KBytes 1,05 Mbits / s 0,303 ms 0/89 (0%)
[3] 17,0-18,0 s 128 KBytes 1,05 Mbits / s 0,333 ms 0/89 (0%)
[3] 18,0-19,0 ​​s 128 KBytes 1,05 Mbits / s 0,294 ms 0/89 (0%)
[3] 19,0-20,0 s 131 KBytes 1,07 Mbits / s 0,281 ms 0/91 (0%)
[3] 0,0-20,0 s 2,50 MBytes 1,05 Mbits / 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
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Servidor escutando na porta UDP 5001
Recebendo datagramas de 1470 bytes
Tamanho do buffer UDP: 64,0 KByte (padrão)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Cliente que se conecta a 192.168.191.200, porta UDP 5001
Enviando datagramas de 1470 bytes
Tamanho do buffer UDP: 64,0 KByte (padrão)
-------------------------------------------------- ----------
[4] porta 61760 local 192.168.191.201 conectada à porta 5001 192.168.191.200
Largura de banda de transferência de intervalo [ID]
[4] 0.0 - 1.0 s 610 KBytes 5.00 Mbits / s
[4] 1,0 - 2,0 s 609 KBytes 4,99 Mbits / s
[4] 2,0 - 3,0 s, 610 KBytes 5,00 Mbits / s
[4] 3.0- 4.0 s 609 KBytes 4.99 Mbits / s
[4] 4,0 - 5,0 s 610 KBytes 5,00 Mbits / s
[4] 5,0-6,0 s 609 KBytes 4,99 Mbits / s
[4] 6.0- 7.0 s 610 KBytes 5.00 Mbits / s
[4] 7.0- 8.0 s 609 KBytes 4.99 Mbits / s
[4] 8,0-9,0 s 610 KBytes 5,00 Mbits / s
[4] 9.0-10.0 s 619 KBytes 5.07 Mbits / s
[4] 10.0-11.0 s 610 KBytes 5.00 Mbits / s
[4] 11.0-12.0 s 609 KBytes 4.99 Mbits / s
[4] 12,0-13,0 s 609 KBytes 4,99 Mbits / s
[4] 13,0-14,0 s 610 KBytes 5,00 Mbits / s
[4] 14.0-15.0 s 609 KBytes 4.99 Mbits / s
[4] 15.0-16.0 s 610 KBytes 5.00 Mbits / s
[4] 16.0-17.0 s 609 KBytes 4.99 Mbits / s
[4] 17.0-18.0 s 610 KBytes 5.00 Mbits / s
[4] 18.0-19.0 s 619 KBytes 5.07 Mbits / s
[4] 19.0-20.0 s 609 KBytes 4.99 Mbits / s
[4] 0.0-20.0 s 11.9 MBytes 5.00 Mbits / s
[4] Enviados 8504 datagramas
[4] Relatório do servidor:
[4] 0,0-20,0 s 11,9 MBytes 4,99 Mbits / s 0,000 ms 12/8503 (0,14%)
[4] datagramas de 0,0 a 20,0 s 1 recebidos fora de ordem
[3] porta local 192.168.191.201 5001 conectada com porta 50.150 192.168.191.200
[3] 0,0- 1,0 s 606 KBytes 4,96 Mbits / s 2,238 ms 1/423 (0,24%)
[3] 1.0 - 2.0 s 610 KBytes 5.00 Mbits / s 2.739 ms 0/425 (0%)
[3] 2,0- 3,0 s 609 KBytes 4,99 Mbits / s 3.089 ms 1/425 (0,24%)
[3] 3.0- 4.0 s 609 KBytes 4.99 Mbits / s 3.605 ms 0/424 (0%)
[3] 4,0- 5,0 s 607 KBytes 4,97 Mbits / s 1,954 ms 0/423 (0%)
[3] 5,0-6,0 s 612 KBytes 5,01 Mbits / s 2,666 ms 0/426 (0%)
[3] 6.0- 7.0 s 607 KBytes 4.97 Mbits / s 2.602 ms 0/423 (0%)
[3] 7,0 - 8,0 s 612 KBytes 5,01 Mbits / s 2,960 ms 0/426 (0%)
[3] 8,0-9,0 s 609 KBytes 4,99 Mbits / s 2.512 ms 0/424 (0%)
[3] 9.0-10.0 s 619 KBytes 5,07 Mbits / s 2.133 ms 0/431 (0%)
[3] 10.0-11.0 s 609 KBytes 4.99 Mbits / s 3.605 ms 1/425 (0,24%)
[3] 11,0-12,0 s 609 KBytes 4,99 Mbits / s 2.509 ms 0/424 (0%)
[3] 12,0-13,0 s 610 KBytes 5,00 Mbits / s 3.570 ms 0/425 (0%)
[3] 13,0-14,0 s 609 KBytes 4,99 Mbits / s 3.077 ms 1/425 (0,24%)
[3] 14.0-15.0 s 609 KBytes 4.99 Mbits / s 2.679 ms 0/424 (0%)
[3] 15.0-16.0 s 609 KBytes 4.99 Mbits / s 1.887 ms 0/424 (0%)
[3] 16,0-17,0 s 610 KBytes 5,00 Mbits / s 2,661 ms 0/425 (0%)
[3] 17,0-18,0 s 609 KBytes 4,99 Mbits / s 3.390 ms 0/424 (0%)
[3] 18,0-19,0 ​​s 617 KBytes 5,06 Mbits / s 2,601 ms 0/430 (0%)
[3] 19.0-20.0 s 612 KBytes 5.01 Mbits / s 3.525 ms 0/426 (0%)
[3] 0,0-20,0 s 11,9 MBytes 4,99 Mbits / s 3.156 ms 3/8503 (0,035%)
[3] 0,0-20,0 seg. 1 datagramas recebidos fora de ordem

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 9m
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Servidor escutando na porta UDP 5001
Recebendo datagramas de 1470 bytes
Tamanho do buffer UDP: 64,0 KByte (padrão)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Cliente que se conecta a 192.168.191.200, porta UDP 5001
Enviando datagramas de 1470 bytes
Tamanho do buffer UDP: 64,0 KByte (padrão)
-------------------------------------------------- ----------
[4] porta local 192.168.191.201 61761 conectada com a porta 5001 192.168.191.200
Largura de banda de transferência de intervalo [ID]
[4] 0,0 - 1,0 s 1,07 MBytes 9,00 Mbits / s
[4] 1,0 a 2,0 s 1,07 MBytes 8,98 Mbits / s
[4] 2,0- 3,0 s 1,07 MBytes 9,00 Mbits / s
[4] 3,0- 4,0 s 1,07 MBytes 8,98 Mbits / s
[4] 4,0- 5,0 s 1,07 MBytes 9,00 Mbits / s
[4] 5,0-6,0 s 1,07 MBytes 8,98 Mbits / s
[4] 6,0-7,0 s 1,07 MBytes 8,98 Mbits / s
[4] 7,0 - 8,0 s 1,07 MBytes 9,00 Mbits / s
[4] 8,0-9,0 s 1,07 MBytes 8,98 Mbits / s
[4] 9.0-10.0 s 1.09 MBytes 9.14 Mbits / s
[4] 10,0-11,0 s 1,07 MBytes 9,00 Mbits / s
[4] 11,0-12,0 s 1,07 MBytes 8,98 Mbits / s
[4] 12,0-13,0 s 1,07 MBytes 8,98 Mbits / s
[4] 13,0-14,0 s 1,07 MBytes 9,00 Mbits / s
[4] 14.0-15.0 s 1.07 MBytes 8.98 Mbits / s
[4] 15.0-16.0 s 1.07 MBytes 9.00 Mbits / s
[4] 16,0-17,0 s 1,07 MBytes 8,98 Mbits / s
[4] 17,0-18,0 s 1,07 MBytes 8,98 Mbits / s
[4] 18,0-19,0 ​​s 1,09 MBytes 9,14 Mbits / s
[4] 19.0-20.0 s 1.07 MBytes 9.00 Mbits / s
[4] 0.0-20.0 s 21.5 MBytes 9.00 Mbits / s
[4] Enviou 15315 datagramas
[4] Relatório do servidor:
[4] 0.0-20.0 s 21.3 MBytes 8.94 Mbits / s 0.104 ms 96/15314 (0,63%) !!!!!!!!!!
[4] datagramas de 0,0 a 20,0 s 1 recebidos fora de ordem
[3] porta local 192.168.191.201 5001 conectada com porta 50.181 192.168.191.200
[3] 0,0- 1,0 s 1,06 MBytes 8,89 Mbits / s 2,405 ms 0/756 (0%)
[3] 1,0 - 2,0 s 1,07 MBytes 9,00 Mbits / s 2,308 ms 0/765 (0%)
[3] 2,0- 3,0 s 1,07 MBytes 9,00 Mbits / s 2,305 ms 0/765 (0%)
[3] 3,0- 4,0 s 1,07 MBytes 8,97 Mbits / s 2.290 ms 1/764 (0,13%)
[3] 4,0- 5,0 s 1,07 MBytes 8,98 Mbits / s 2,271 ms 1/765 (0,13%)
[3] 5,0-6,0 s 1,07 MBytes 8,98 Mbits / s 2,313 ms 0/764 (0%)
[3] 6,0-7,0 s 1,07 MBytes 9,00 Mbits / s 2.191 ms 0/765 (0%)
[3] 7,0 - 8,0 s 1,07 MBytes 8,95 Mbits / s 2,314 ms 3/764 (0,39%)
[3] 8,0-9,0 s 1,07 MBytes 8,98 Mbits / s 2.232 ms 1/765 (0,13%)
[3] 9,0-10,0 s 1,09 MBytes 9,13 Mbits / s 2,257 ms 0/776 (0%)
[3] 10,0-11,0 s 1,07 MBytes 8,98 Mbits / s 2.365 ms 0/764 (0%)
[3] 11,0-12,0 s 1,07 MBytes 8,98 Mbits / s 2,301 ms 1/765 (0,13%)
[3] 12,0-13,0 s 1,07 MBytes 8,98 Mbits / s 2.277 ms 0/764 (0%)
[3] 13,0-14,0 s 1,07 MBytes 9,00 Mbits / s 2,333 ms 0/765 (0%)
[3] 14.0-15.0 s 1.07 MBytes 9.00 Mbits / s 2.176 ms 0/765 (0%)
[3] 15,0 a 1,0 s 1,07 MBytes 8,96 Mbits / s 2,273 ms 2/764 (0,26%)
[3] 16,0-17,0 s 1,07 MBytes 8,98 Mbits / s 2,313 ms 0/764 (0%)
[3] 17,0-18,0 s 1,07 MBytes 8,98 Mbits / s 2,247 ms 1/765 (0,13%)
[3] 18,0-19,0 ​​s 1,09 MBytes 9,11 Mbits / s 2,276 ms 1/776 (0,13%)
[3] 19,0-20,0 s 1,07 MBytes 8,97 Mbits / s 2,394 ms 1/764 (0,13%)
[3] 0,0-20,0 s 21,5 MBytes 8,99 Mbits / s 2,659 ms 11/15314 (0,072%)
[3] 0,0-20,0 seg. 1 datagramas recebidos fora de ordem

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 9850k
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
-------------------------------------------------- ----------
Servidor escutando na porta UDP 5001
Recebendo datagramas de 1470 bytes
Tamanho do buffer UDP: 64,0 KByte (padrão)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Cliente que se conecta a 192.168.191.200, porta UDP 5001
Enviando datagramas de 1470 bytes
Tamanho do buffer UDP: 64,0 KByte (padrão)
-------------------------------------------------- ----------
[4] porta local 192.168.191.201 61762 conectada à porta 5001 192.168.191.200
Largura de banda de transferência de intervalo [ID]
[4] 0,0 - 1,0 s 1,17 MBytes 9,84 Mbits / s
[4] 1,0 - 2,0 s 1,17 MBytes 9,84 Mbits / s
[4] 2,0 - 3,0 s 1,17 MBytes 9,84 Mbits / s
[4] 3,0- 4,0 s 1,17 MBytes 9,84 Mbits / s
[4] 4,0- 5,0 s 1,17 MBytes 9,84 Mbits / s
[4] 5,0-6,0 s 1,17 MBytes 9,83 Mbits / s
[4] 6,0-7,0 s 1,17 MBytes 9,84 Mbits / s
[4] 7,0 - 8,0 s 1,17 MBytes 9,84 Mbits / s
[4] 8,0-9,0 s 1,17 MBytes 9,84 Mbits / s
[4] 9.0-10.0 s 1.19 MBytes 10.0 Mbits / s
[4] 10.0-11.0 s 1.17 MBytes 9.84 Mbits / s
[4] 11,0-12,0 s 1,17 MBytes 9,84 Mbits / s
[4] 12,0-13,0 s 1,17 MBytes 9,83 Mbits / s
[4] 13,0-14,0 s 1,17 MBytes 9,85 Mbits / s
[4] 14.0-15.0 s 1.17 MBytes 9.83 Mbits / s
[4] 15.0-16.0 s 1.17 MBytes 9.85 Mbits / s
[4] 16,0-17,0 s 1,17 MBytes 9,83 Mbits / s
[4] 17,0-18,0 s 1,17 MBytes 9,84 Mbits / s
[4] 18,0-19,0 ​​s 1,19 MBytes 10,0 Mbits / s
[4] 19.0-20.0 s 1.17 MBytes 9.84 Mbits / s
[4] 0.0-20.0 s 23.5 MBytes 9.85 Mbits / s
[4] Enviou 16765 datagramas
[4] Relatório do servidor:
[4] 0.0-20.0 s 23.3 MBytes 9.74 Mbits / s 3.421 ms 156/16764 (0,93%) !!!!!!!!!!
[4] datagramas de 0,0 a 20,0 s 1 recebidos fora de ordem
[3] porta local 192.168.191.201 5001 conectada à porta 50.192 192.168.191.200
[3] 0.0 - 1.0 s 1.16 MBytes 9.74 Mbits / s 2.131 ms 0/828 (0%)
[3] 1,0 - 2,0 s 1,17 MBytes 9,84 Mbits / s 2,140 ms 0/837 (0%)
[3] 2,0- 3,0 s 1,17 MBytes 9,83 Mbits / s 2,099 ms 1/837 (0,12%)
[3] 3,0- 4,0 s 1,17 MBytes 9,84 Mbits / s 2.113 ms 0/837 (0%)
[3] 4,0 - 5,0 s 1,17 MBytes 9,84 Mbits / s 2,105 ms 0/837 (0%)
[3] 5,0 - 6,0 s 1,17 MBytes 9,83 Mbits / s 2,058 ms 1/837 (0,12%)
[3] 6,0-7,0 s 1,17 MBytes 9,82 Mbits / s 2,165 ms 1/836 (0,12%)
[3] 7,0 - 8,0 s 1,17 MBytes 9,84 Mbits / s 2,156 ms 0/837 (0%)
[3] 8,0 - 9,0 s 1,17 MBytes 9,82 Mbits / s 2,135 ms 2/837 (0,24%)
[3] 9,0-10,0 s 1,19 MBytes 9,97 Mbits / s 2,152 ms 2/850 (0,24%)
[3] 10,0-11,0 s 1,17 MBytes 9,83 Mbits / s 2,153 ms 1/837 (0,12%)
[3] 11,0-12,0 s 1,17 MBytes 9,84 Mbits / s 2,127 ms 0/837 (0%)
[3] 12,0-13,0 s 1,17 MBytes 9,83 Mbits / s 2,136 ms 1/837 (0,12%)
[3] 13,0-14,0 s 1,17 MBytes 9,82 Mbits / s 2,087 ms 2/837 (0,24%)
[3] 14,0-15,0 s 1,17 MBytes 9,83 Mbits / s 2,061 ms 1/837 (0,12%)
[3] 15.0-16.0 s 1.17 MBytes 9.84 Mbits / s 2.045 ms 0/837 (0%)
[3] 16,0-17,0 s 1,17 MBytes 9,82 Mbits / s 2,203 ms 1/836 (0,12%)
[3] 17,0-18,0 s 1,17 MBytes 9,84 Mbits / s 2,165 ms 0/837 (0%)
[3] 18,0-19,0 ​​s 1,17 MBytes 9,83 Mbits / s 2,154 ms 1/837 (0,12%)
[3] 19,0-20,0 s 1,19 MBytes 9,98 Mbits / s 2,209 ms 0/849 (0%)
[3] 0,0-20,0 s 23,5 MBytes 9,84 Mbits / s 2.548 ms 13/16764 (0,078%)
[3] 0,0-20,0 seg. 1 datagramas recebidos fora de ordem

A verdadeira questão permanece:

Não estamos assinando demais o link DC, pois ele está a 100 Mbps e não pode enviar mais de 100 Mbps. No entanto, os sites remotos estão em 10 Mbps.

  • Os buffers no lado remoto estão transbordando e descartando pacotes?
  • O modelador de tráfego do provedor está fazendo algo com o tráfego? (O tráfego proveniente de outro nó seria influenciado pelo modelador de tráfego dos ISPs ou apenas pelo tráfego que entra no nó (de fora)) ...... Você entende o que quero dizer?

Por que o TCP não pode lidar com isso sozinho?

Atualização # 3 Agora, usei o seguinte cenário:

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

Aqui está a perda de pacotes na direção remota DC->: (teste UDP iperf de 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

A outra direção está bem. No entanto , ao executar um teste TCP, a direção remota-> CC não apresenta um desempenho muito melhor que a direção remota-> DC (cerca de 5 Mbps) .......

Não sei se chegamos ao fundo disso.

ethernet tcp troubleshooting packet-analysis metro-ethernet Marki
fonte
Não é realmente uma resposta, mas minha recomendação seria obter uma JDSU e testar este circuito. Se eles estão policiando você, certifique-se de obter o policer, "regulador", configurações ... Se eles têm um CBS pequeno, eles estão confinando o tráfego TCP a essencialmente um tamanho de janela menor. Você pode testar isso por meio de um teste de retorno de retorno. Eu passei muito tempo fazendo a frente e para trás com provedores em circuitos L2 saber que quando nós começamos um novo teste de circuito-lo completamente, não só no CIR mas ao CBS ...
Matak
Além disso, apenas uma nota lateral rápida. A taxa de transferência TCP vista de um sistema operacional Windows versus Linux será diferente porque as configurações de TCP serão diferentes; ie tamanho do buffer, algoritmo, etc. Você pode visualizar as configurações da sua máquina Linux sysctlsem ter certeza sobre o Windows ... talvez netsh. Se eu quisesse adivinhar o que há de errado com o seu circuito, diria que o CPE no site spoke está configurado com um CBS maior que o lado do hub ... o que geralmente é o contrário. Novamente, a JDSU lançará a bola de volta para eles ou permitirá que você se concentre novamente no problema.
matak 30/07
@matak Por que não fazer uma resposta adicional às suas observações? Quando falamos sobre o modelador, onde imagino esse dispositivo? No DC, há um plugue RJ45 sem CPE (visível). Nos sites remotos, tenho principalmente um modem VDSL e algum tipo de roteador compatível com MPLS. Não tenho certeza se eles usam MPLS embora. Além disso, em que direção do tráfego o modelador se forma? Podemos moldar ingress @ spoke (do site), egress @ spoke (em direção à nuvem do ISP), ingress @ hub (da DC), egress @ hub (em direção à nuvem do ISP) ... Provavelmente estou perdendo o quadro geral. Você pode ilustrar por que o problema com a CBS seria um problema?
Marki

Respostas:

20

Fazendo referência ao nosso bate-papo Stack Exchange ...

Em resumo , você precisa controlar as diferenças de velocidade nos dois lados dos seus links Ethernet metropolitanos ... Redefinei seu diagrama por uma questão de clareza ... Nota 1

Diagrama de problemas

  • O DC (mostrado em verde) faz a transição de 10GE para 100M muito rapidamente ... essa é uma transição de velocidade de 100 vezes, e geralmente é necessário implementar alguma forma de qo (como modelagem) para mitigar uma transição tão grande. Consulte a parte inferior desta resposta para obter evidências de que o DC precisa ser modelado (por site) ...
  • O lado remoto faz a transição de 1GE para um 10M CIR muito rapidamente ... isso novamente, é uma transição de velocidade de 100 vezes. Normalmente, são necessárias formas alternativas ou de modelagem ou qos.
  • Também parece haver uma incompatibilidade de velocidade entre o DC UNI (100M) e o remoto UNI (10M); isso por si só implora por uma solução de gerenciamento de largura de banda por site.

Para sua informação, se seu provedor implementa serviços compatíveis com MEF , eles não estão moldando, estão policiando . O tráfego TCP tende a ter melhor desempenho com a modelagem .

A necessidade de sua própria QoS

Você parece questionar a necessidade de qos , portanto, citarei o white paper do MEF "Noções básicas sobre a taxa de transferência de Ethernet da operadora" , página 9 ... a título de revisão, o cliente na Figura 2 do whitepaper do MEF tem uma situação melhor do que a sua. .. eles compraram um CIR de 50 Mbps, mas o UNI é entregue em um 1GE ... seu site remoto possui um CIR de 10 Mbps em um 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.

Respondendo a outras perguntas de TCP em uma edição ...

Não estamos assinando demais o link DC, pois ele está a 100 Mbps e não pode enviar mais de 100 Mbps ...

Eu discordo, você pode enviar microburst s a 10GE porque seu DC possui links 10GE, mas o metro UNI é 100Mbps. Uma questão em aberto é a quantidade de buffer que você possui no switch LAN da Enterasys (Switch A) ao fazer a transição de 10GE para 100M.

Por que o TCP não pode lidar com isso sozinho?

O TCP lida com as coisas diminuindo a velocidade quando vê a perda de pacotes ... realmente diminui a velocidade (e pode interromper a conexão), causando sérias perdas de pacotes. Então, o TCP está fazendo o que deveria ... como engenheiro de rede, seu objetivo é construir uma rede com condições que tornem o TCP feliz.

Outras questões TCP do chat

Marki disse : Eu não entendo o que está sendo descartado, onde e por quem, por que e por que e porque o TCP simplesmente não lida com o fato de que existem 100 Mbps (reais) em uma extremidade e apenas 10 Mbps na outra.

Em relação à necessidade de buffer do TCP e às conseqüências de nenhum buffer :

Fato número 1: o TCP precisa de buffer para transições de velocidade porque foi projetado como um sistema de controle de feedback .

Usando uma analogia de direção: como bons motoristas, sempre deixamos alguns segundos no espaço entre nós e o carro à nossa frente; de certa forma, esse espaço entre carros é aproximadamente análogo a um buffer de rede. Se a pessoa na nossa frente pisar no freio quando um animal corre na frente deles, o espaço entre nossos carros (espero) nos impede de bater no carro deles. Deixamos espaço porque leva tempo para os nossos olhos verem as luzes do freio, o pé reagir e o freio dissipar calor suficiente; nossos olhos nos dão um sistema de controle de feedback visual.

Da mesma forma, quando uma sessão FTP é interrompida em 10GE, as explosões de tráfego podem ter até 4 MB (no seu caso) devido ao tamanho da janela em escala TCP antes que o soquete precise parar e aguardar um TCP ACK. Enquanto isso, se o fluxo de tráfego 10GE atingir repentinamente uma "Fast Ethernet", o TCP precisará desacelerar gradualmente. Buffers profundos em equipamentos de rede permitem que o TCP descarte muito menos pacotes quando faz transições de velocidade; no entanto, se você não tiver buffers, poderá reduzir talvez 99% dessa janela TCP de 4 MB quando for regulada de 10GE para 100M. Pense nessa perda severa de 99% como uma falha no soquete TCP; O TCP reage previsivelmente à perda de pacotes relativamente gradual. O TCP reage muito menos previsivelmente à perda severa e contínua de pacotes Nota 3 .

Para a questão de por que você não deve usar um CIR Metro Ethernet assimétrico com 100M no DC e 10M no controle remoto, faça uma pergunta retórica "quem está armazenando o buffer do tráfego de 100Mbps quando atinge o NID Ethernet de 10Mbps barato que seu metro -net provedor lhe deu? "... (dica: ninguém está armazenando buffer).

Se ninguém estiver armazenando buffer em grandes transições de velocidade (consulte a Nota 2), esses pontos são locais em potencial para eliminar intermitentemente o tráfego.

O que está sendo descartado por quem :

O tráfego de saída cai do DC

Quando o tráfego TCP sai do datacenter, há três locais em que ele pode ser descartado:

  • No D1: porque os comutadores LAN raramente possuem buffer suficiente para uma transição de velocidade de 100: 1
  • No D2: se o NID negociar o link UNI a uma velocidade mais alta que o CIR ; esse não é o caso agora, então não espero que ocorra lá.
  • No D3: por todas as razões que acabei de descrever sobre assimétrica Metro Ethernet CIR s.

Quando o tráfego TCP vai para o data center ...

O tráfego de entrada cai para o controlador de domínio

  • No D4: porque você tem um 1GE UNI e um 10M CIR ; este é o caso patológico de D2 que mencionei acima.

Como atenuar as diferenças de velocidade:

Um exemplo de solução EVPL : EVPL com solução EVC ponto a ponto

  • Em uma topologia comutada como essa, um EVPL com EVCs ponto a ponto do controlador de domínio para cada controle remoto é provavelmente a melhor opção (consulte o diagrama acima). Isso aplicaria um CIR individual a cada EVC. Nota: todas as outras orientações de QoS nesta resposta se aplicam ... ou seja, evite grandes transições de velocidade Nota 2 sem testar se o seu equipamento irá lidar com isso suficientemente bem.
  • Como alternativa, você pode considerar comprar serviços de metrô com taxas simétricas entre o controlador de domínio e o controle remoto; apesar de admitir que essa pode não ser a orientação mais prática.
  • Para sua informação, a solução clássica para esse problema para serviços roteados é comprar roteadores que suportam modelagem nas velocidades necessárias e, em seguida, moldar seu tráfego de metro para o CIR apropriado (por site remoto). FYI, o lado remoto pode se safar com um roteador razoavelmente pequeno, já que é apenas uma entrada 1GE e um CIR de 10 Mbps ... Meses atrás, quando falamos sobre o design deste serviço, eu recomendei o roteamento se você se sentisse confortável com as tecnologias ...

  • Se você não tiver dinheiro extra para gastar e não puder reprojetar seu serviço de metrô-ethernet, poderá massagear as diferenças de velocidade mais gradualmente. Eu nunca fiz isso, mas, em princípio, você poderia tentar fazer as transições de velocidade de 10 para 1, em vez de 100 para 1 (que é o que você tem atualmente no DC e no controle remoto):

    • Em vez de comprar um roteador para moldar o controle remoto para 10M, você pode tentar forçar o UNI remoto a negociar automaticamente a 100M em vez de 1GE; O GigabitEthernet requer todos os pinos em um cabo Cat5e , para que você possa efetivamente forçá-lo a 100M com um plugue mod RJ45 que apenas conecta os pinos 1, 2, 3 e 6.
    • Em vez de comprar um roteador para configurar o DC em 100M, use o Enterasys para policiar o link 10GE para 1GE ao enviar tráfego para o link 100M

Analisando seus iperfresultados ...

Há dois pontos principais a serem lembrados iperf(todas as informações baseadas na iperfversão 2):

Assim, a saída a seguir mostra que a máquina DC (no iperf -cmodo) se conecta ao iperfservidor no site remoto (192.168.x) e envia os dados do DC (100M UNI) para o site 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

A saída acima mostra claramente problemas no DC para a direção remota; devemos esperar ver 9 Mbps ou mais quando tudo funcionar bem (ou seja, você espera pelo menos 90% da capacidade - 10 Mbps no site remoto). Agora, vejamos o tráfego na direção oposta (quando iperfenvia dados do site remoto para o 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

Você é capaz de enviar cerca de 80% da capacidade do seu CIR remoto, mas isso ainda é menor do que eu espero.

Ilustração da incompatibilidade de velocidade CC (10 Gbps -> 100Mbps)

marki disse : Não se esqueça, o problema só aparece quando o fluxo é de 100Mb -> 10Mb, não o contrário.

O problema aparece nas duas direções, mas os iperfsintomas parecem ser piores na direção DC -> remota. Veja minha análise da iperfsaída acima.

Para tornar isso concreto, vejamos o seu pcap FTP ao enviar um arquivo do servidor FTP DC (130.1.6.4) para o site remoto (192.168.191.2). A transferência do lado Ethernet da 100M fica limitada em vários pontos durante a transferência. Você pode ver isso se olhar para o dc-to-remote_remote-side.pcapngpcap e filtrarexpert.message contains "segment not captured"

insira a descrição da imagem aqui

Notas finais :

Nota 1 Escolho valores CBS de 25 KB por CIR MetroEthernet de 1 Mbps; essa é uma proporção comum usada pelos provedores ... YMMV
Nota 2 Minha regra pessoal: "grande" é uma transição de velocidade significativamente maior que uma transição de velocidade de 10: 1
Nota 3Não posso fornecer números concretos para o que é e o que não é perda excessiva de pacotes para o TCP. Se a perda é ruim o suficiente para seus aplicativos sofrerem, é demais. Minha regra pessoal: ao lidar com uma rede corporativa com fio completamente sob meu próprio controle, qualquer perda de pacote (não intencional) é demais. Dito isto, existem alguns modelos de switch que cortam os cantos no buffer; esses comutadores podem ocasionalmente soltar pacotes ... é uma decisão sobre se você precisa conviver com o problema ou comprar comutadores melhores. FYI: nem sempre é óbvio, mas o TCP aumenta periodicamente a taxa de transmissão de um soquete para garantir que ele esteja obtendo o máximo de rendimento possível; muitas implementações de TCP sabem que estão indo rápido demais quando veem queda de pacotes.

Mike Pennington
fonte
Observe que a velocidade PHY do DC (porta Metro Ethernet) já está em 100Mb. Mas também não posso enviar a 100M porque o outro lado tem no máximo 10Mb ... No momento, ainda não está claro para mim onde exatamente a forma deve ter que ocorrer. Ah, e você quis dizer "os sintomas do iperf parecem ser piores na direção DC -> remota "?
Marki
Eu atualizei a resposta, sim "remote -> DC" foi um erro de digitação na resposta original.
Mike Pennington
Eu concordo com o Mike aqui, dependendo de quem é seu provedor, se você perguntar a eles que eles lhe dirão a taxa de linha no final, faça com que ela corresponda às suas interfaces físicas penduradas no seu metro-E. Quanto ao WHERE to QoS, eu faria nos seus maiores pontos de entrada, então nos seus dispositivos de 10 Gb, antes de subirem para os dispositivos upstream menores. Eu gasto mais tempo com firewall e roteamento do que comutando, mas espero que Mike possa corroborar minhas reivindicações!
AL
3
@ MikePennington - O bloqueio de saída devido a diferenças de velocidade é algo que me atrapalha bastante com os links de microondas P2P. Ótima resposta, muitas informações boas no seu post. Obrigado!
Matak
1
Verifique também se há incompatibilidade duplex, pois isso pode causar problemas de velocidade unidirecional.
Ct_fink
2

Embora discutir esse problema fosse muito interessante, o ISP começou a trocar os modems DSL nos diferentes sites por outra marca. Algum problema de fragmentação de pacotes, eles dizem. E ei, 9,5 Mbps em ambas as direções, sem problemas ou configurações especiais.

Marki
fonte