Roteamento otimizado de aplicativos em um roteador de balanceamento de carga?

Question

Eu tenho 2 linhas de banda larga de entrada ambas c.10mb abaixo / c.0.8 para cima. (uma linha é ligeiramente mais rápida que a outra)

Eu recentemente instalei um roteador de balanceamento de carga TP Link - TL-R470T + depois de pesquisá-lo e assistir ESTE VIDEO . Eu corro as 2 linhas adsl separadas em meus 2 modems separados, de lá eu corro 2 cat5s dos modems para o balanceador de carga e então 1 cat5 do balanceador de carga para um roteador wifi, todos os dispositivos se conectam através do roteador wifi.

No vídeo, eles falam sobre a desativação de "Ativar roteamento otimizado de aplicativos" - se eu executar um teste de velocidade com ele ativado, basicamente, é só pegar o resultado de velocidade da linha de banda larga mais rápida. Se eu desabilitar a configuração acima e executar um teste de velocidade, obtenho a velocidade combinada de ambas as linhas.

Próximo à opção, diz o comentário abaixo:

Enable Application Optimized Routing With this box checked, all the data packets of the same network application on multi-connections will be forwarded via the same WAN ports, which avoids abnormity caused by forwarding the data packets of this application via different WAN ports.

O que isso significa exatamente? - Eu uso alguns 'sites de sincronização ao vivo' como o Google Drive e o Trello, o que nos faz uma mistura de sockets, node js e long polling para transmitir dados de um lado para o outro através de uma conexão contínua se esses serviços fossem efetivados?

Eu também uso um serviço de backup em nuvem em algumas máquinas, algo assim seria afetado?

Eu entendo que, se eu tiver essa configuração ativada, ainda posso obter o benefício de comutação automática de ambas as linhas, mas não as usar ao mesmo tempo. Que tipo de problemas / que tipo de serviços irá / colidar em problemas se eu deixar esta opção desmarcada?

    

Answer 1

Com relação ao IPv4:

Uma conexão TCP (não UDP, não Multicast, etc) sobre quais sessões os aplicativos estabelecem para conduzir transações e o conteúdo presente é entre um e apenas um IP de origem: port e um e somente um IP de destino: port. O protocolo não permite conexões um-para-muitos para uma única sessão, no que diz respeito à Internet pública. Devido à natureza stateful do TCP, embora seja possível ter vários hosts privados conduzindo partes de uma única sessão, intermediados por um balanceador de carga, isso provavelmente não é prático.

A rota entre esses dois hosts IP: port pode ser infinitamente dinâmica, desde que nenhum dos hosts fique sem recursos ou exceda quaisquer timers. Isso inclui o manuseio de pacotes fora de seqüência, contanto que nenhum limite, hard ou soft, seja excedido.

Isso significa que, para balancear a carga de uma sessão em dois links separados na direção de saída, os dois caminhos devem poder encaminhar o tráfego do mesmo IP de origem para o mesmo IP de destino.

Quando os dois links pertencem ao mesmo ISP, isso geralmente não é um problema, a menos que haja filtros IP de origem estritos (explícitos ou implícitos) em cada conexão. Na verdade, se não houver restrições específicas, pode-se balancear na direção de saída em dois links separados sem qualquer assistência do ISP.

Não é assim para balanceamento de carga do tráfego de entrada, no entanto. O ISP quase sempre precisa entrar para ativar o balanceamento de carga na direção de entrada.

Vamos supor que o ISP esteja integrado ao implementar o balanceamento de carga para você:

Uma das maneiras mais fáceis de conseguir isso é atribuir sua própria sub-rede, além das redes usuais servidas pelo DSLAM. Essa sub-rede pode ser tão pequena quanto um único host / 32, ou, para um escritório, talvez até várias centenas de hosts.

Para balanceamento de carga confiável entre dois links IP e CPE (Customer Premise Equipment), o balanceador de carga deve ter pelo menos 3 interfaces separadas, e as duas interfaces ISP devem pertencer a duas redes diferentes, para eliminar qualquer problema ambíguo. decisões de roteamento ou comutação

Digamos que uma das suas interfaces de balanceador de carga voltadas para ISP seja a 10.2.2.2/30, a outra 10.2.2.254/30. Sua rede CPE é 65.172.1.0/24 e a interface voltada para CPE do balanceador de carga é 65.172.1.1.

Seu load-balacner teria que fazer alguma das seguintes formas:

ip route 0.0.0.0 0.0.0.0 10.2.2.1
ip route 0.0.0.0 0.0.0.0 10.2.2.253

Isso cria duas rotas padrão estáticas de igual prioridade para cada conexão com o ISP.

Em um roteador cisco comportando-se como um balanceador de carga, o método padrão era balancear a carga por destino, já que a maneira como o fluxo do roteamento de cache funciona é menor para o roteador. No entanto, havia a opção

ip load-sharing per-packet

que encaminhará tráfego com mais de uma rota equivalente, em um round-robin de ambas as interfaces.

ip load-sharing per-destination

define o esquema padrão.

Essa configuração balanceará suas conexões de saída.

O seu ISP teria que configurar estas duas rotas estáticas no seu dispositivo, com a mesma opção por pacote ou por destino, muito provavelmente a primeira:

ip route 65.172.1.0 255.255.255.0 10.2.2.2
ip route 65.172.1.0 255.255.255.0 10.2.2.254

Se configurado corretamente em ambos os lados, as interfaces WAN do seu balanceador de carga devem informar o mesmo pacote por segundo recebido e as mesmas estatísticas transmitidas por pacote por segundo.

Os recursos sobre os quais você faz perguntas são muito semelhantes ao compartilhamento de carga por pacote e ao destino. No entanto, se for o mesmo ISP, você pode seguramente deixá-lo por pacote; A opção 'otimizada' é mais para as duas conexões de balanceamento de carga para provedores diferentes. Observe que a alteração dessa opção afeta apenas o tráfego de saída e não afeta a entrada.

É muito improvável que você possa implementar uma conexão bidirecional com balanceamento de carga sem ajuda (e provavelmente uma taxa) do seu provedor de serviços de Internet. O seu ISP deve ser capaz de aconselhá-lo sobre as configurações que se adequam à sua situação.

No entanto, é na minha opinião, dado o que sei sobre o design da sua rede, que haverá algum problema perceptível com o pacote por pacote.

    

Answer 2

Então você tem 2 linhas de banda larga - significa que você tem 2 portas WAN. Quando você ativa o balanceamento de carga em duas ou mais portas WAN, os pacotes IP gerados com seus aplicativos passam pela primeira porta WAN disponível ou usam Algoritmo Round Robin , ou pode ser um algoritmo mais complicado suportado por hardware e firmware do seu balanceador de carga.

Isso significa que, às vezes, os servidores remotos podem obter pacotes IP de seus aplicativos com endereços de origem diferentes. Algumas vezes pode ser confuso ou tratado como ataque Man-in-the-middle . É por isso que a maioria das conexões criptografadas, como VPN criptografada HTTPS, TLS e SSL, talvez alguns jogos on-line não funcionem ou possam se comportar mal com esse tipo de conexão.

Roteamento otimizado para aplicativos significa que todos os pacotes IP de um aplicativo passarão somente através de uma porta WAN (é por isso que você viu "resultado de velocidade da linha de banda larga mais rápida" com o teste de velocidade). Se você executar mais de um aplicativo, por exemplo, dois navegadores com dois speedtests, o Application Optimized Routing deverá usar uma WAN para o seu primeiro aplicativo e outra WAN para o segundo aplicativo, e assim por diante. Concluindo, se você executar o Roteamento Otimizado do Aplicativo, poderá usar ambas as conexões, mas a velocidade de conexão para determinada aplicação será igual à velocidade de conexão de uma linha de banda larga (c.10mb abaixo / c.0.8 acima)

    

Answer 3

O protocolo TCP espera que os pacotes cheguem em ordem sequencial. Se você usar duas ou mais interfaces WAN, é possível que os pacotes cheguem no outro lado da ordem. Isso pode fazer com que a taxa de transferência geral caia devido à ação de recuperação que será ser desnecessariamente tomadas pelo receptor.

No seu caso, isso significaria, por exemplo, que se você "vincular" duas interfaces WAN de 5 Mbps sobre TCP, o throughput total pode ser um pouco menor que o máximo teórico de 10 Mbps. A solução para pacotes descartados é ligar uma conexão específica a apenas uma WAN pela duração da conexão.

O Guia do usuário do TL-R480T explica essa opção (embora isso não seja seu modelo):

With the box before Enable Application Optimized Routing checked, the Router will consider the source IP address and destination IP address of the packets as a whole and record the WAN port they pass through. And then the packets with the same source IP address and destination IP address or destination port will be forwarded to the recorded WAN port. This feature is to ensure the multi-connected applications to work properly.

O termo endereço IP merece algumas análises, já que seu computador não está na Internet. Em vez disso, é o roteador que está conectado à Internet, enquanto o seu computador está um membro em sua rede local que é totalmente separado da Internet. Portanto, o endereço IP do seu computador provavelmente será semelhante ao 192.168.0.xxx enquanto o endereço IP do site que você está conectando é totalmente diferente.

No texto acima, portanto, "endereço IP de origem" significa o endereço do seu computador dentro da rede interna, enquanto "endereço IP de destino" estará na Internet. O resultado seria que, mesmo que você tenha aberto várias conexões do seu computador, tudo para o mesmo site, o roteador considerará todos como sendo entre os mesmos endereços IP.

Assim, a explicação para seus testes é:

• Com Enable Application Optimized Routing em , o roteador usou apenas uma WAN, então a velocidade medida foi a dessa WAN. O roteador também pode ser inteligente o suficiente para preferir a WAN mais rápida sobre a mais lenta.
• Com Enable Application Optimized Routing desativado , o roteador usou as WANs, então a velocidade total era a soma das larguras de banda de ambos.

Para o segundo caso, uma vez que a largura de banda total observada foi aproximadamente igual à soma das larguras de banda, isso significa que o protocolo usado pelo speedtest não é muito sensível para pacotes fora de ordem.