Dans ce post, le terme LAG (Link Aggregation protocol) fait référence au protocole normalisé LACP et au protocole propriétaire CISCO PaGP. Ces protocoles ont pour objectif de mutualiser plusieurs interfaces physiques au sein d’une seule interface logique appelée « PortChannel » dans le monde CISCO.
les limites de la norme
Comme d’habitude, ces protocoles ne sont absolument pas protégés. Mais heureusement, ils ne sont pas activés par défaut. De ce fait, la plupart des dysfonctionnements sont purement accidentels, même si un acte de malveillance est théoriquement possible.
La norme prévoit un algorime de distribution qui permet de choisir une des interfaces physiques pour envoyer chaque trame. Le gros problème, c’est que la norme ne dit rien sur cet algoritme.
« This standard does not impose any particular distribution algorithm on the Distributor. Whatever algorithm is used should be appropriate for the MAC Client being supported. ».
De ce fait, des machines différentes peuvent avoir des algoritmes différents. Les machines que je connais ont des algoritmes déterministes. A noter que, sur les équipements que je connais, les protocoles LAG utilisent toujours un nombre pair d’interfaces physiques. Un LAG sur 3 interfaces physiques n’en utilisera que 2 ! Dans un LAG sur 4 interfaces physiques, si une des interfaces est en panne, on se retrouve avec 3 interfaces. Au final, seulement 2 seront utilisées.
Si, en plus, les algorithmes de distribution sont différents d’une machine à l’autre, on comprend que la maintenance du réseau devient délicate. En pratique, je recommande que les switches qui font du LAG soient de la même famille et de se limiter à deux interfaces physiques.
limites de la bande passante disponible
Si on se fie à l'intuition, avec deux interfaces à 100M, on peut compter sur 200M. Pour que cela marche bien, il faut avoir de multiples flux avec des débits comparables. Sinon, on peut être très déçu... Exemple d’un cas réel :
Un seul flux FTP, lié à la synchronisation nocturne de deux systèmes, sature une des deux interfaces physiques Fast Ethernet. En effet, l'algoritme de distribution attribue toujours la même interface à ce flux. Par contre, les multiples flux opérationnels sont à peu près répartis entre les deux interfaces. Résultat, sur l'interface saturée, il y a des pertes de trames, alors que l’autre interface est très peu chargée. Les utilisateurs sont (très) mécontents, il faut en urgence passer en Gigabit Ethernet.
l’expérience opérationnelle que j’en ai
En présence de Port Channel, il est facile d’obtenir des configurations qui ne marchent pas ou qui marchent mal.
Par exemple, si on fait marcher un trunk sur un Port Channel, il faut que les interfaces physiques soient cohérentes en termes de VLANs. La liste des VLANs autorisés doit être gérée au niveau du Port Channel. Une erreur classique est de modifier la liste des VLANs autorisés sur l’une des interfaces physiques et pas sur l’autre. L’interface « déviante » est alors sortie du Port Channel, et, comme on a des liens parallèles, si jamais il y a des VLANs en commun, on se retrouve avec une belle boucle de niveau 2 et la tempête qui va avec.
Un autre phénomène désagréable, c’est l’apparition de boucles transitoires. Ces boucles sont dues au fait que le protocole ne réagit pas immédiatement aux changement d’état des interfaces physiques. Ces boucles transitoires sont normalement brèves, de sorte qu’elles ne s’accompagnent pas d’une tempête de diffusion. Mais cependant, j’ai déjà vu des cas où le CTP loopback détectait une telle boucle.
Concernant les sites que j’ai conçus, il y a trois cas de figure :
- la configuration Port Channel est faite lors de l’installation, personne ne modifie ensuite la liste des VLANs autorisés et les équipements sont dans le même batiment (en 5 ans, aucun souci sur plus de 100 sites)
- la configuration est automatisée et les équipements sont séparés par plusieurs kilomètres (ça marche aussi très bien, il y a de rares incidents, liés au CTP loopback).
- la configuration est manuelle et on a, disons, un gros problème par an et par site.
Pour éviter les ennuis du cas 3, on a décidé d’autoriser tous les VLANs susceptibles de traverser le trunk, de façon à se retrouver dans le cas 1, quitte à avoir des trunks trop permissifs. Il faut parfois choisir entre la peste et le choléra.
Vos remarques, questions et autres interventions sont les bienvenues.
Pascal BONNARD
Les articles de la série "Ethernet" :
Ethernet, un niveau à ne pas négliger
Les attaques « classiques » : interception de trafic, dénis de service
A éliminer d’urgence : DTP
Les VLANs pour les Nuls : je configure les VLANs de mes trunks bien propres
Les VLANs pour les Nuls : VTP / MRP
Les boucles et les tempêtes : STP et comment s’en dispenser
L’art d’en dire trop : CDP et LLDP
Incroyable, mais vrai : CTP loopback
A utiliser sans (trop) d’ illusions : LAG (PaGP, LACP)
Conclusion, la configuration ultime pour mes switches
copyright image : © dampoint - Fotolia.com
Jeu de briques
Snake
Pacman
Bubble