le tromboning du trafic

C’est quoi le trafic tromboning ?

Le trafic tromboning est le passage forcé (aller/retour) du trafic par un point spécifique (trombone) avant d’atteindre sa destination finale.

Dans le domaine du réseau, le phénomène est régulièrement constaté lorsque:

• On introduit un routeur ou un service L4/L7 de type Firewall, LoadBalancer ..Etc et que ce dernier est utilisé comme passerelle par défaut pour les WorkLoads.
• On force le trafic à l’aide du routage statiques ou des protocoles de routage dynamique de passer par un service L4/L7.

Le principe est illustré dans l’architecture Clos (Leaf & Spine) ci-dessous :

Le phénomène du tromboning introduit : 

• La duplication de la bande passante consommée à cause de l’aller/retour du trafic 
• Une latence supplémentaire surtout quand les deux WorkLoads sont connectés dans le même switch mais dans deux Vlans différents.
• La création d’un goulot d’étranglement qui réduit la scalabilité offerte par l’architecture Clos. 

Si les deux premiers point ci-dessus ne me gêne pas vraiment dans les architectures Leaf & Spine car la bande passante pourra être augmentée facilement en ajoutant des Spines supplémentaires et la latence ajoutées n’est pas trop significative dans la majorité des cas sauf s’il s’agit d’un réseau HFT (High frequency Trading).

Toutefois, le troisième point représente un vrai challenge. La nature ou le mode de fonctionnement (Statefull) de la plupart des services L4/L7, ne nous permet pas de rajouter facilement des appliances L4/L7 supplémentaire pour corriger le problème d’étranglement parce que :

• Le trafic traversant le service L4/L7 doit être symétrique, c’est-à-dire qu’il doit traverser bi-directionnellement par le même équipement.
• Les informations (states) entre les différents équipements doivent être synchronisées.

Le trafic Nord/Sud vs Est/Ouest 

Attentions, pas tous les trombones représentent un goulot d’étranglement (heureusement). Prenant l’exemple d’un FW qu’interconnecte notre réseau LAN à l’internet, dans la majorité des cas le goulot d’étranglement est bien le lien WAN vers l’ISP et non pas le FW lui-même. Sans oublier que les Firewalls d’aujourd’hui sont assez performants pour atteindre une capacité de traitement avoisinant les 100Gbps.

En revanche, la morphologie du trafic a changé au sein de nos DCs dans les dernières années dû à l’arrivée de la virtualisation, les nouvelles solutions émergeante comme le Big Data et l’hyper-Convergé, par conséquent le trafic Est/Ouest devient plus dominant dans les DCs par rapport au trafic Nord/Sud. 

Selon des études, le trafic Est/Ouest d’aujourd’hui représente dix fois plus que le trafic Nord/Sud, Conséquence, l’insertion des trombones pour le trafic Est/Ouest pourrait créer un goulot d’étranglement .

Comment le trafic tromboning est créé ?

 Au début de l’article, j’ai listé les deux méthodes communes qui permettent d’insérer des trombones dans le DC. 

La première méthode nécessite un réseau niveau 2 entre les Workloads et le trombone

Autrement dit, cette méthode nécessite que la passerelle par défaut des Workloads soit belle et bien le trombone et automatiquement un réseau niveau 2 entre les Workloads et leurs Gateway.

Prenant l’exemple d’une architecture Leaf & Spine basée sur le protocole VxLAN/EVPN dans la figure ci-dessous :

Afin que le FW soit la passerelle par défaut de chaque VLAN, il faut :

• Créer le Vlan 10 et Vlan 20 et les associer au VNI (VxLAN Network Identifier) 1000 et 2000 respectivement.

• Configurer les ports qui interconnectent les deux Workloads en mode accès et les associer au bon vlan 

• Configurer le lien qui relie le FW au L1 en mode Trunk afin de transiter les vlans 10 vers le FW

Le Workflow du trafic

le trafic du Workload associé au Vlan10 vers le Workload associé au Vlan20 arrive sur le port d’accès du Leaf L3, ce dernier l’encapsule dans un entête VxLAN en associant le VNI 1000 et l’adresse IP TEP du L3 et L1 comme IP source et destination avant de le router vers un des deux Spines selon le Hash ECMP choisi. Le Spine à son tour ne fait que router le trafic vers le Leaf de destination à la base de l’adresse IP de destination du paquet VxLAN.

À l’arrrivé du paquet, le leaf L1 compare le VNI 1000 du paquet reçu avec la table du mapping VLAN/VNI locale,il trouve que le VNI 1000 est associé au Vlan 100, il décapsule l’entête VxLAN puis il redirige le trafic vers le port trunk connectant le FW. Le trafic de retour se fera de la même manière.

L’utilisation du VxLAN dans ce scénario est nécessaire dû au besoin d’une communication niveau 2 entre le FW et les Workloads.

La deuxième méthode est basée sur le redirection du trafic vers le service L4-L7 via le routage.

Dans cette approche, on n’a pas forcément besoin du protocole VxLAN pour forcer le trafic de passer par le FW car la passerelle par défaut des Workloads n’est plus le FW.

Le trafic passe par le trombone dans ce scénario à l’aide des VRFs.

Le principe est simple : 

• associer le VLAN 10 et vlan 20 à deux VRFs différentes
• mettre une patte du FW dans chaque VRF.
• À l’aide du routage dynamique, injecter la route par défaut depuis le FW vers les deux VRFs afin qu’elle soit utilisée lorsqu’il n y’a pas une route plus spécifique vers le réseau de destination.

La table par défaut de la VRF Orange contient le subnet du Vlan10 et la route par défaut qui pointe le trafic vers le FW et celle de la VRF Verte contient le subnet du vlan20 ainsi que la route par défaut qui amène vers le FW.

Résultat, le trafic du vlan 10 vers le vlan 20 suivra la route par défaut et passera forcément par le trombone. 

Il existe une troisième méthode basée sur la technologie PBR (Policy Based Routing) que j’estime trop complexe à déployer et à maintenir donc elle n’est pas présentée dans cet article.

Comment éviter le tromboning du trafic ?

La réponse est simple, lorsque cela est possible, éviter l’utilisation des appliances centralisés pour le trafic Est/Ouest car ils introduisent :

• un goulot d’étranglement,
• de la latence
•  de l’utilisation non optimale de la bande passante.

La solution ?

Au lieu d’utiliser un appliance centralisé (Scale UP), on peut par exemple opter pour une solution distribuée (Scale Out).

Dans le domaine de la virtualisation et des conteneurs, cela peut être achevé soit : 

• En implémentant le service L4/L7 dans des VMs malgré que cela pourrait introduire des petits phénomènes de tromboning entre les VMs et le trombone instanciés dans le même serveur physique. 
• En implémentant le service L4/ L7 directement dans l’hyperviseur, précisément au niveau du switch virtuel.

Malheureusement, les deux solutions ci-dessus ne sont pas valable si notre infrastructure repose lourdement sur des BareMetals.

La solution idéale pour répondre aux environnements physiques et virtuels serait sans doute l’utilisation d’un module spécifique dédié au niveau de la carte réseau de chaque serveur dans lequel on peut démarrer les services L4/L7 d’une manière performante (LineRate) et scalable, ou une solution moins attractive basée sur un agent installé au niveau du BareMetal.

Si vous avez des questions, un autre avis sur le sujet ou vous avez besoin d’un complément d’informations, n’hésitez pas à laisser un message en commentaire de la page ou nous contacter directement à l’adresse : contact@mhd-experts.com.