Roteamento assimétrico - causas e efeitos?

Ocorre que encontro clientes que possuem o que eu defino como um "roteamento assimétrico" em suas redes. Simplesmente, eles têm dois gateways na mesma sub-rede IP. Os clientes estão configurados para apontar para um gateway (por exemplo, 172.16.1.1), mas há outro dispositivo (por exemplo, 172.16.1.2) que se conecta e roteia para algum lugar. Eu já vi esse tipo de configuração principalmente quando existem 2 tipos diferentes de conexões WAN: 1 conexão à Internet e 1 conexão MPLS corporativa.

Pessoalmente, não sou atraído pelo tipo de design de rede acima: cada sub-rede precisa ter um e apenas um gateway. Do meu ponto de vista, o cenário acima pode criar alguns problemas para os clientes, porque eles enviam um pacote para o gateway padrão (172.16.1.1) e esses pacotes são encaminhados para o outro roteador (172.16.1.2) e quando são respondidos para, eles alcançam o cliente simplesmente passando por 172.16.1.2. Os clientes esperariam ou deveriam esperar que os pacotes de resposta fossem 172.16.1.1, ou estou errado aqui?

Ficaria feliz em ter suas opiniões e pontos de vista técnicos sobre esse problema.

Eu recomendo que você analise os protocolos de redundância de primeiro salto, como HSRP ou VRRP.

Na verdade, ter dois gateways pode ser um projeto de rede muito bom, porque se um roteador falhar, o outro roteador poderá assumir um controle sem problemas. No entanto, como você sabe, não é fácil fazer essa transição se você precisar fazer uma reconfiguração manual de cada cliente em uma sub-rede.

Protocolos como HSRP (ou VRRP, se você tiver equipamentos que não sejam da Cisco) permitem que você tenha dois (ou mais) roteadores (ou switches L3) em uma sub-rede que compartilhem um único endereço IP. Você terá seu primeiro roteador com um endereço .2, o segundo com um endereço .3 e um "endereço IP virtual" de .1 que ambos os roteadores conhecem através da configuração. Quando o roteador principal falha, o secundário é capaz de detectar isso e assumir o endereço IP virtual, o que significa que seus clientes precisam ter o .1 configurado como gateway e você estará pronto.

Em termos de design de roteamento, isso dependeria amplamente da configuração atual. É possível que ambos os gateways levem à mesma borda da Internet; nesse caso, você pode não ter um problema. O roteamento assimétrico pode ser ruim, principalmente porque você corre o risco de os pacotes serem entregues na ordem errada, mas, novamente, depende muito da topologia da qual você está falando.

Muitos princípios de design estavam implícitos no que acabei de dizer. Sugiro que você pesquise os dois protocolos e determine o que é melhor para o seu ambiente. Se você estiver usando o Cisco gear, o HSRP é um método amplamente utilizado e bem compreendido para solucionar esse problema.

Toda a internet é construída com roteamento assimétrico, portanto é muito comum. Os clientes estão interessados ​​na interface em que recebem o pacote e na origem do pacote, e não em qual roteador os passou nessa interface.

O roteamento assimétrico pode se tornar problemático, no entanto, quando dispositivos que controlam o estado (especialmente firewalls) e o NAT estão envolvidos, mas até onde eu sei, esse não é o caso no seu exemplo.

Os clientes de rede identificam fluxos de tráfego com base na combinação de 4 valores:

• Endereço de Origem
• Porta de Origem
• Endereço de destino
• Porto de destino

Para cada conexão diferente, os 4 valores acima formam uma combinação diferente que é usada para corresponder os pacotes de resposta ao fluxo correto. Como você pode ver, o gateway ou o endereço do próximo salto não está incluído na lista e, portanto, o cliente não se importará se um pacote retornar através do mesmo gateway usado para enviar seus pacotes. Portanto, os clientes da rede não se preocupam com o roteamento assimétrico, assim que podem receber o tráfego da extremidade remota. Na verdade, o TCP / IP foi projetado originalmente para oferecer suporte ao roteamento assimétrico.

No entanto, se focarmos nos dispositivos intermediários da rede, o roteamento assimétrico não será tolerado assim que você estiver usando qualquer dispositivo / tecnologia que precise ver todos os pacotes em uma conexão para fornecer uma determinada funcionalidade. Por exemplo: NAT, firewalls com estado ou alguns otimizadores de WAN. O roteamento assimétrico nesse cenário faria com que a funcionalidade pretendida não fosse fornecida ou, ainda pior, os pacotes fossem descartados, impossibilitando a comunicação.

Concordo com as respostas diante de mim, mas tenho que acrescentar algo: se houver alguma filtragem em qualquer um dos gateways ou em qualquer salto que seja passado por apenas um dos dois gateways, é provável que surjam problemas! (os saltos que são transmitidos pelos dois gateways, como a máquina de origem, a máquina de destino e quaisquer saltos "comuns aos dois caminhos de gateway", não se preocupam com os seguintes cenários)

Por exemplo, se A enviar pacotes para B pelo gateway1 e os pacotes retornarem pelo gateway2, é altamente provável que o pacote de resposta seja descartado se o gateway2 estiver fazendo a filtragem (porque esse gateway não viu o pacote de conexão inicial, por isso t espera resposta, portanto, se o destino / porta do pacote de resposta geralmente é filtrado, ele será filtrado.)

(Existem, é claro, muitos cenários semelhantes)

Outras duas áreas em que as rotas assimétricas causam problemas são: 1. Descoberta da MTU - se a menor MTU dos dois caminhos diferir, a descoberta do caminho da MTU do ponto final poderá resultar em uma maior das duas MTU, que por sua vez resultará em queda de pacotes de tamanho máximo. Por exemplo, se um caminho passa por um túnel VPN e o outro não, o túnel VPN terá uma MTU menor. o ping funcionará bem, mas a transferência de arquivos grandes falhará consistentemente. 2. A resolução de problemas de conectividade será mais difícil se um dos dois caminhos estiver quebrado, mas o outro não. O bom e velho "traceroute" não ajudará em nada, pois não poderá detectar os pontos intermediários do caminho reverso, a menos que seja exercido nos dois lados da conexão, o que exige um canal de gerenciamento fora da banda ...