Routage vers des interfaces multiples

Mais dès lors que d’autres interfaces sont ajoutées, et que des interfaces telles que VIPA qui n’ont pas de connexion physique unique au réseau sont ajoutées, le routage devient beaucoup plus complexe.

Supposons que VIPA soit utilisée pour faire migrer un système servant deux réseaux en chevauchement. Dans ce cas, deux firmes ont fusionné. Toutes les deux utilisent les adresses 10.0.0.0, et l’espace d’adresses est en chevauchement. Les clients des deux réseaux doivent atteindre un serveur IBM i, et l’objectif est d’avoir le moins de reconfiguration possible pendant que les réseaux fusionnent lentement en un seul.

Ce tracé est intentionnellement simplifié, pour illustrer simplement les principes concernés. Deux réseaux (« l’ancien » étant fusionné avec le « nouveau ») utilisent l’espace 10.3.1.0. En fait, tous deux ont des unités avec les mêmes adresses (10.3.1.131). Le serveur Power Systems a quatre interfaces physiques : deux sur le réseau 10.4.1.0 sur le « nouveau » côté et deux sur un réseau créé pour s’interfacer avec l’ancien réseau (172.16.1.0). Une VIPA est établie en utilisant RIPv2, afin que toutes les unités sur tous les réseaux connaissent le serveur Power Systems en tant que 192.168.1.10.

Quand un paquet provenant de 10.3.1.131 sur « l’ancien » réseau vise 192.168.1.10, il est converti par NAT en une adresse 172.24.2.0 (dans ce cas 172.24.2.123, mais NAT est souvent configuré pour être dynamique, et donc cette adresse pourrait changer chaque fois que l’unité du client se connecte). À l’inverse, l’unité 10.3.1.131 sur le « nouveau » réseau est vue par le serveur Power Systems simplement comme 10.3.1.131.

L’important ici est de ne pas supposer qu’une réponse sortira par la même interface qu’une requête qui entre. Par exemple, supposons que l’écran de la figure 8 (CFGTCP option 2) montre les routes par défaut sur le serveur Power Systems dans notre exemple. Dans ce cas, l’unité provenant de l’ancien réseau à 10.3.1.131 cible VIPA 192.168.1.10 et le système envoie la réponse au routeur sur la première route par défaut, 10.4.1.1. On aurait alors un timeout sur la connexion vers l’unité sur « l’ancien » réseau. C’est le problème du « routage asymétrique, » (merci à mon collègue de Chase, David Mishels, pour son aide dans ce domaine.) Pour corriger ce problème, il faut créer une route vers le bon routeur (soit avec Navigator, soit avec la commande CFGTCP).

Routage vers des interfaces multiples

À noter qu’il vaut peut-être la peine de spécifier l’interface préférée (bien qu’on la laisse ici à sa valeur par défaut *NONE). Les routes se lient aux interfaces physiques, et, en l’absence d’interface préférée, elles se lient avec la première qui est active. Ce comportement peut créer des problèmes si toutes vos interfaces ne sont pas valides pour revenir à une adresse donnée. Par exemple, si l’extrémité à distance cible votre système par l’intermédiaire d’une adresse NAT et que cette adresse NAT cible une interface physique unique, vous devez vous assurer que le trafic provenant de ces clients ne passe que sur cette interface.

Bien entendu, le routage est critique et sa complexité est égale à celle du réseau. Vous ne voulez sûrement pas qu’une partie du trafic disparaisse à tout jamais dans un trou noir !

Configurez vos routes avec soin, en collaboration étroite avec vos spécialistes réseaux. Vous devez savoir quelles routes existent et quel est leur état. Citons deux outils pour cela : (pour IPv4) NETSTAT option 2 (pour voir toute l’information actuelle sur les routes) et CFGTCP option 2 pour voir les routes statiques qui ont été configurées. Attention aux routes redondantes : faute de mieux, elles peuvent compliquer les choses. À noter que dans l’IBM i 6.1, les routes TCP/IP ont un champ description de texte. Utilisez-le : il aidera vos collègues  (et peut-être vous-même) Quand ils essaieront de savoir pourquoi une route existe.

En général, en raison de la manière dont les routes se lient, il vaut mieux spécifier l’interface préférée pour toutes les routes. Cette recommandation est particulièrement importante si vous utilisez des Schowler Routes, puisque les paquets sortants utilisent toutes les interfaces qu’ils peuvent.

Navigator est le meilleur moyen de voir ce comportement de liage. Faites un clic droit sur une interface (system, Network, TCP/IP Configuration, IPv4, Interfaces) et choisissez Associated Routes. À noter que la route par défaut vers le routeur n’est définie que pour l’une de ces interfaces. Dans la pratique, c’est la première interface qui se présente. Si vous avez un étrange IPL et si soudainement votre réseau se comporte différemment, peut-être utilisez-vous une interface que vous n’utilisiez pas auparavant !

Donc, si la seconde interface est choisie pour le trafic sortant, le système ne saura pas vers où l’acheminer (sauf, bien entendu, s’il y a une route statique ou une route directe). La meilleure pratique est de créer des routes pour chaque interface pour laquelle cette route est valide. Certes, il faut un peu plus de configuration, mais il y aura moins de soucis par la suite.