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 pour un VLAN donné. 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.
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 rebouclages transitoires. Par rebouclage, j'entends que les trames orientés vers une interface "rebondissent" vers leur émetteur, sans aller bien loin. Ceci est lié au fait que le protocole ne réagit pas immédiatement aux changements d’état des interfaces physiques. Ces rebouclages ne provoquent pas de tempêtes 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, au lieu de configurer le trunk bien propre, 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
Depuis 2004, je m’occupe d'ingénierie de commutateurs Ethernet (switches en anglais). Comme je suis curieux de nature, j'ai voulu savoir ce qu'il y avait sous le capot ... et c'est là que j'ai vu tous ces protocoles qui ne nous veulent que du bien, mais qui posent d'inévitables questions de sécurité. Sont-ils fiables ? Peuvent-ils être trompés ? Il me semble que ce domaine est peu documenté, et que les informations disponibles sont souvent incomplètes, parfois erronées. Je désire vous faire partager mes connaissances qui s'appuient sur des tests en laboratoire ainsi que sur plusieurs centaines de machines opérationnelles.