Routage Asymétrique

Une architecture standard pour les sites distants

Quand un site distant (et souvent critique) avec de nombreux utilisateurs est « raccordé » au Data Center, il y a très souvent 2 liens qui permettent une garantie de service 24/7 pour accéder aux serveurs.

Suivant le choix de l’entreprise, les 2 liens peuvent être utilisés en :

• Actif/Actif. Les 2 liens sont utilisés ;
• L’un des liens est Actif et l’autre de Secours.

Dans le premier cas, il existe diverses règles pour exploiter au mieux les 2 liens : parité des IP, nombre de sessions actives, taux d’usage des liens, choix des protocoles, … Bref il n’y a que l’embarras du choix !!

Dans la seconde solution (Actif/Secours), il n’y a qu’un chemin possible mais on n’exploite pas de façon optimale les 2 liens.

Etudions le cas de 2 liens Actif/Actif. Les utilisateurs se plaignent de lenteur dans l’usage des applications sur le DC ou simplement le partage de fichiers sous Windows.

Partons du principe que les premières analyses ont montré que les serveurs n’étaient pas saturés, que les métriques sur applications ne montraient pas d’alertes et que les postes utilisateurs sont récents… Il reste donc le réseau !! Les métriques fournies par le FAI ne montrent pas de saturations des liens.

Alors, il est où le problème ?

Qu’en est-il réellement des échanges TCP/IP entre l’utilisateur et un serveur ? Et quel est l’impact sur les temps de réponses pour celui-ci ?

Pour voir et surtout comprendre les échanges de données entre les utilisateurs (près de 1000 dans notre cas) et le DC, nous avons installé une sonde réseau sur le site distant qui permet de voir ces échanges.

Premier constat : sur 1 journée d’analyse, le taux de perte de paquets en IN et OUT est particulièrement élevé. Constat confirmé sur plusieurs semaines d’enregistrement.

Pour rappel : un taux de perte de plus de 3% est considéré comme critique pour le réseau. Entre 1,5 % et 3%, cela semble déjà anormal même sur du WAN. On note aussi un point important, il n’y a plus de paquets perdus dans un sens (OUT) que dans l’autre (IN).

Il existe deux possibilités :

• Il y a un seul chemin entre un utilisateur et le serveur :

L’utilisateur prendra toujours le même chemin durant la durée des échanges avec un serveur. Les paquets TCP/IP prendront un unique chemin et certains n’arrivent pas au bout dans un sens.

• Il y a deux chemins possibles pour une même conversation :

Premier cas, les données peuvent prendre un chemin durant un certain temps pour le même port TCP client, jusqu’à l’arrivée d’un reset (RST). Puis en prendre un autre pour un nouveau port TCP.

Second cas, les données ALLER prennent un chemin (rouge sur le dessin) et les données RETOUR (paquet d’acquittement par exemple ACK) prennent un autre chemin (violet sur le dessin).

Une analyse Wireshark va nous permettre de creuser ce point.

Dans ce fichier .pcap, il y a un changement d’équipement lors d’une conversation entre une IP cliente et un serveur.

Dans un premier temps la communication TCP/55173 à TCP/8080 s’effectue entre :

Client ßà Serveur : HP (–:–:–:–:1c:b7) et le CISCO (–:–:–:–:d0:82)

Soit un seul chemin.

Puis on remarque que pour un flux similaire TCP/55179 à TCP/8080 :

Client à Serveur : HP (–:–:–:–:1c:b7) et le CISCO (–:–:–:–:d0:82)

Serveur à Client : CISCO (–:–:–:–:df:02) et le HP (–:–:–:–:81:21)

Soit 2 chemins différents : l’un pour l’aller et l’autre pour le retour.

Le fait que sur la connexion TCP/55179 il y ait deux chemins ne devrait pas en théorie entrainer de perturbation durant les échanges de données. TCP est suffisamment robuste pour palier aux problèmes réseaux. Mais il s’avère que nous avons constaté que pour chaque communication asymétrique, quelques soient les conversations, les paquets passant par un des deux chemins étaient en grand partie retransmis.

Les raisons peuvent être multiples de ce phénomène :

• le chemin B est plus long que le chemin A : les ACK arrivent trop tard et les données sont déjà retransmises ;
• le chemin B est mutualisé par le FAI avec d’autres clients, il est saturé ;
• le chemin B a une défaillance technique,…

Mais les conséquences sont bien réelles.