Routage asymétrique - causes et effets?

Il arrive que je rencontre des clients qui ont ce que je définis comme un "routage asymétrique" dans leurs réseaux. En termes simples, ils ont deux passerelles sur le même sous-réseau IP. Les clients sont configurés pour pointer vers une passerelle (c.-à-d. 172.16.1.1) mais il existe un autre périphérique (c.-à-d. 172.16.1.2) qui se connecte et achemine vers quelque part. La plupart du temps, j'ai vu ce type de configuration lorsqu'il existe 2 types différents de connexions WAN: 1 connexion Internet et 1 connexion MPLS d'entreprise.

Personnellement, je ne suis pas attiré par le type de conception de réseau ci-dessus: chaque sous-réseau doit avoir une et une seule passerelle. De mon point de vue, le scénario ci-dessus peut créer des problèmes pour les clients, car ils envoient un paquet à leur passerelle par défaut (172.16.1.1) et ces paquets sont ensuite transférés vers l'autre routeur (172.16.1.2) et lorsqu'ils reçoivent une réponse à, ils atteignent le client en passant simplement par 172.16.1.2. Les clients devraient ou devraient s'attendre à ce que les paquets de réponse proviennent de 172.16.1.1, ou je me trompe ici?

Je serais heureux d'avoir vos opinions et vos points de vue techniques sur cette question.

Je recommanderais que vous examiniez les protocoles de redondance du premier hop comme HSRP ou VRRP.

En fait, avoir deux passerelles peut être une très bonne conception de réseau, car si un routeur venait à tomber en panne, l'autre routeur peut prendre le relais de manière quelque peu transparente. Cependant, comme vous le savez, il n'est pas facile d'effectuer cette transition si vous devez effectuer une reconfiguration manuelle de chaque client sur un sous-réseau.

Des protocoles comme HSRP (ou VRRP si vous avez des équipements non Cisco) vous permettent d'avoir deux (ou plus) routeurs (ou commutateurs L3) sur un sous-réseau partageant une seule adresse IP. Vous aurez votre premier routeur avec une adresse de .2, le deuxième avec une adresse de .3 et une "adresse IP virtuelle" de .1 que les deux routeurs connaissent grâce à la configuration. Lorsque le routeur principal tombe en panne, le secondaire est capable de le détecter et de prendre en charge l'adresse IP virtuelle, ce qui signifie que vos clients doivent simplement avoir .1 configuré comme passerelle et vous êtes prêt à partir.

En termes de conception de routage, cela dépendrait largement de la configuration actuelle. Il est possible que les deux passerelles conduisent à la même périphérie Internet, auquel cas vous ne rencontrez pas de problème. Le routage asymétrique peut être mauvais, principalement parce que vous risquez d'être livré dans le mauvais ordre, mais encore une fois, cela dépend beaucoup de la topologie dont vous parlez.

Beaucoup de principes de conception impliqués dans ce que je viens de dire. Je vous suggère de rechercher les deux protocoles et de déterminer ce qui convient le mieux à votre environnement. Si vous utilisez un équipement Cisco, HSRP est une méthode largement utilisée et bien comprise pour résoudre ce problème.

L'Internet entier est construit sur un routage asymétrique, c'est donc très courant. Les clients sont intéressés par l'interface sur laquelle ils reçoivent le paquet et la source du paquet, et non par quel routeur leur a été transmis sur cette interface.

Cependant, le routage asymétrique peut devenir problématique lorsque des périphériques surveillant l'état (en particulier les pare-feu) et NAT sont impliqués, mais pour autant que je sache, ce n'est pas le cas dans votre exemple.

Les clients du réseau identifient les flux de trafic en fonction de la combinaison de 4 valeurs:

• Adresse source
• Port source
• Adresse de destination
• Le port de destination

Pour chaque connexion différente, les 4 valeurs ci-dessus forment une combinaison différente qui est utilisée pour faire correspondre les paquets de réponse au bon flux. Comme vous pouvez le voir, l'adresse de passerelle ou de saut suivant n'est pas incluse dans la liste et donc le client ne se souciera pas si un paquet revient via la même passerelle qu'il a utilisé pour envoyer ses paquets. Ainsi, les clients réseau ne se soucient pas du routage asymétrique dès qu'ils peuvent recevoir le trafic de l'extrémité distante. En fait, TCP / IP a été conçu à l'origine pour prendre en charge le routage asymétrique.

Cependant, si nous nous concentrons sur les périphériques intermédiaires du réseau, le routage asymétrique n'est pas toléré dès que vous utilisez un périphérique / une technologie qui a besoin de voir tous les paquets dans une connexion pour fournir une fonctionnalité donnée. Par exemple: NAT, pare-feu avec état ou certains optimiseurs WAN. Un routage asymétrique dans un tel scénario entraînerait la non-fourniture de la fonctionnalité prévue ou, pire encore, la perte de paquets rendant la communication impossible.

Je suis d'accord avec les réponses qui m'ont été fournies, mais je dois ajouter quelque chose: s'il y a un filtrage sur l'une des passerelles, ou sur n'importe quel saut qui est passé via seulement 1 des 2 passerelles, des problèmes sont susceptibles de survenir! (les sauts transmis via les deux passerelles, telles que la machine source, la machine de destination et les sauts "communs aux deux chemins de passerelle", ne sont pas concernés par les scénarios suivants)

Par exemple, si A envoie des paquets à B via la passerelle 1 et que les paquets reviennent via la passerelle 2, il est fort probable que le paquet de réponse soit supprimé si la passerelle 2 effectue le filtrage (car cette passerelle n'a pas vu le paquet de connexion initiateur, il ne le fait donc pas '' t attendre une réponse, donc si le dest / port du paquet de réponse est généralement filtré, il sera filtré.)

(Il existe, bien sûr, de nombreux scénarios similaires)

Les deux autres domaines où les routes asymétriques causeront des problèmes sont les suivants: 1. Découverte de MTU - si la plus petite MTU des deux chemins diffère, la découverte de chemin de MTU au point final pourrait entraîner la plus grande des deux MTU, ce qui entraînera à son tour une chute de paquets de taille maximale. Par exemple, si un chemin passe par un tunnel VPN et l'autre non, le tunnel VPN aura un MTU plus petit. ping fonctionnera correctement, mais le transfert de fichiers volumineux échouera de manière cohérente. 2. La résolution des problèmes de connectivité sera plus difficile si l'un des deux chemins est rompu mais pas l'autre. Un bon vieux "traceroute" ne sera d'aucune aide, car il ne pourra pas détecter les points intermédiaires de chemin inverse, à moins qu'il ne soit exercé des deux côtés de la connexion, ce qui nécessite un canal de gestion hors bande ...