VIO : configuration EtherChannel

J'ai été pas mal occupé dernièrement sur la mise en place de vio servers. J'en vois enfin le bout et je pense donc en faire une série de billets. Je commence par la mise en place de l'Etherchannel sur un vio server. En fait, je devrais plutôt parler de Link Aggregation (norme IEEE 802.3ad) mais le terme Etherchannel est sans doute plus parlant pour les gens du monde aix (merci smitty etherchannel :-). Je donne les commandes sous VIOS mais la logique est la même sous AIX.

description sommaire de la technologie

Le Link aggregationpermet d’agréger plusieurs interfaces réseaux physiques en une interface logique disposant de la bande passante équivalente à l’ensemble des interfaces physiques agrégés et pouvant continuer à fonctionner lorsqu'une des interfaces est indisponibles ou perd sa connection.

La norme 802.3ad est un standard IEEE pour normaliser la manière dont les liens sont agrégés.
L’utilisation du protocole LACP (Link Aggregation Control Protocol) permet une configuration dynamique de l’agrégation par l’envoi de paquet LACP (nommé LACPDU pour Link Aggregation Control Protocol Dat Unit) à l’autre élément de la paire.

Voici des liens sur des descriptions plus détaillées de la technologie :
Link aggregation

LACP

Configuration du switch Cisco

Je n’irai pas dans le détail de la configuration des switchs car c’est loin d’être ma spécialité. Les informations de cette section sont là à titre informatif pour un administrateur système afin de faciliter les échanges avec l’administrateur réseau lors des debugs de configuration.

Il faut préciser à l’administrateur réseau que l’on veut utiliser le LACP. Sur certains switchs Cisco le protocole par défaut est PAgP mais, à ma connaissance, il n’est pas utilisé pour faire de l’agrégation avec un serveur.
Pour faciliter le debug des problèmes de configuration, il est intéressant d’avoir la configuration des ports faisant partie du channel-group (Link Aggregation group).
Voici un extrait de la configuration des ports d’un groupe(je ne reprend que les paramètres pertinents pour le Link Aggregation) :
interface GigabitEthernet2/44 

description vio1
speed 1000
duplex full
channel-group 20 mode active

interface GigabitEthernet2/46

description vio2
speed 1000
duplex full
channel-group 20 mode active
Description des paramètres :
  • interface: précise le numéro du port du switch

  • description : un commentaire sur l’utilisation du port

  • speed : vitesse du port. Dans le cas d’un LA, il est conseillé de forcer la vitesse.

  • duplex : duplex du port. Dans le cas d’un LA, il est conseillé le duplex du port à full.

  • channel-group : spécifie le numéro de groupe auquel les ports appartiennent. Seul des ports appartenant au même groupe peuvent s’agréger ensemble.

  • mode : Le mode active correspond à l’utilisation du LACP.

Les paramètres speed et duplex de chaque port faisant partie du même channel-group doivent être identiques (des vitesses et modes différents sont en théorie supportés par le protocole 802.3ad mais vivement déconseillées).

A noter aussi que les ports utilisés doivent se trouver sur le même switch physique.

Remarque : Selon le type et le constructeur du switch, il peut exister des technologies permettant de s’affranchir de cette limitation (comme SMLT, DSMLT et RSMLT pour Nortel). A voir avec l’administrateur réseau.

Configuration du VIO Server


La section ci-dessous utilise les commandes VIOS pour réaliser la configuration mais on pourrait effectuer les mêmes opérations à travers les commandes AIX.
On vérifie les cartes ethernet disponibles pour réaliser le Link Aggregation :
$ lsdev -type adapter
name status description
ent0 Available 2-Port 10/100/1000 Base-TX PCI-X Adapter (1410890
ent1 Available 2-Port 10/100/1000 Base-TX PCI-X Adapter (1410890
ent2 Available 2-Port 10/100/1000 Base-TX PCI-X Adapter (1410890
ent3 Available 2-Port 10/100/1000 Base-TX PCI-X Adapter (1410890
ent4 Available Virtual I/O Ethernet Adapter (l-lan)
ent5 Available Virtual I/O Ethernet Adapter (l-lan)
fcs0 Available FC Adapter
fcs1 Available FC Adapter
fcs2 Available FC Adapter
fcs3 Available FC Adapter
scsi0 Available Wide/Ultra-3 SCSI I/O Controller
scsi1 Available Wide/Ultra-3 SCSI I/O Controller
vhost0 Available Virtual SCSI Server Adapter
vhost1 Available Virtual SCSI Server Adapter
vsa0 Available LPAR Virtual Serial Adapter

Pour identifier les ports à utiliser, il vaut mieux se baser sur les emplacements physiques des cartes, on utilise donc la commande suivante :
$ lsdev -dev ent0 -slot
# Slot Description Device(s)
U5791.001.992001F-P1-C01 PCI-X capable, 64 bit, 133MHz slot ent0 ent1
$ lsdev -dev ent2 -slot
# Slot Description Device(s)
U5791.001.992008G-P1-C01 PCI-X capable, 64 bit, 133MHz slot ent2 ent3
Comme sur les ports du switch, il est vivement recommandé de positionner le débit et le duplex du port. Ici à 1Gb full duplex. On active aussi les jumbo frames pour améliorer le débit maximum.
$ chdev -dev ent0 -attr media_speed=1000_Full_Duplex jumbo_frames=yes
ent0 changed
$ chdev -dev ent2 -attr media_speed=1000_Full_Duplex jumbo_frames=yes
ent2 changed

Une fois les interfaces configurés, il ne reste plus qu’à créer l’interface ieee 802.3ad
$ mkvdev -lnagg ent0 ent2 -attr mode=8023ad
ent5 Available
en5
et5
Description des paramètres :
  • -lnagg : spécifie les interfaces physiques qui vont être agrégés

  • -attr mode=8023ad : on spécifie que l’on utilise le mode d’agrégation 802.3ad.

Test de la configuration


Le plus simple est d’attribuer une adresse IP à la nouvelle interface sur le VIO Server pour qu’elle devienne active.

Remarque : cette adresse IP ne sera utilisé que pour les tests et devra être supprimé par la suite.

Attribution d’une adresse IP de test :
$ mktcpip -hostname test -inetaddr 195.51.51.67 -netmask 255.255.255.0 -interface en5

Il suffit ensuite de regarder son statut avec la commande netstat. La commande étant plutôt verbeuse, je me contenterais d’afficher les sections intéressantes et je ferais des interludes entre elles pour décrire les points intéressants. La commande est :
$ netstat -cdlistats

ETHERNET STATISTICS (ent5) :
Device Type: IEEE 802.3ad Link Aggregation
Hardware Address: 00:09:6b:6e:17:72
On voit apparaitre l’interface logique ent5 802.3ad ainsi que sa mac address.

Ensuite on voit apparaitre les statistiques concernant l’interface :
Statistics for every adapter in the IEEE 802.3ad Link Aggregation:
------------------------------------------------------------------

Number of adapters: 2
Operating mode: Standard mode (IEEE 802.3ad)
IEEE 802.3ad Link Aggregation Statistics:
Aggregation status: Aggregated
Received LACPDUs: 60877
Transmitted LACPDUs: 56256
Received marker PDUs: 0
Transmitted marker PDUs: 0
Received marker response PDUs: 0
Transmitted marker response PDUs: 0
Received unknown PDUs: 0
Received illegal PDUs: 0
Hash mode: Destination IP address

Les paramètres intéressants sont :
  • Number of adapters : cela indique que l’on a bien 2 interfaces physiques (dans notre cas).

  • Operating mode : le mode d’agrégation utilisé.

Les statistiques suivantes concernent le protocole 802.3ad :
  • Aggregation status : C’est LA statistique la plus importante. Cela donne le statut de l’agrégation. Tant que ce statut est différent de Aggregated, l’agrégation de lien n’est pas fonctionnelle.

  • Received LACPDUs : le nombre de paquets LACPDU reçu. Intéressant pour debugger.

  • Transmitted LACPDUs : le nombre de paquets LACPDU envoyés. Intéressant pour debugger.

Ensuite on obtient les statistiques par interface physiques :
-------------------------------------------------------------

ETHERNET STATISTICS (ent0) :
Device Type: 2-Port 10/100/1000 Base-TX PCI-X Adapter (14108902)
Hardware Address: 00:09:6b:6e:17:72

Ici on a le modèle physique ainsi que sa Mac Address.

Ensuite les informations nous donnant un statut sur le lien physique :
Link Status : Up
Media Speed Selected: 1000 Mbps Full Duplex
Media Speed Running: 1000 Mbps Full Duplex

La ligne Media Speed Running donne l’état actuel du lien. Il est important d’avoir le même débit en duplex Full sur les interfaces physiques.
On arrive ensuite aux informations les plus importantes pour le debug d’un problème de configuration. Le statut et les statistiques ieee 802.3ad par port.
IEEE 802.3ad Port Statistics:
-----------------------------
Actor System Priority: 0x8000
Actor System: 00-09-6B-6E-17-72
Actor Operational Key: 0xBEEF
Actor Port Priority: 0x0080
Actor Port: 0x0001
Actor State:
LACP activity: Active
LACP timeout: Long
Aggregation: Aggregatable
Synchronization: IN_SYNC
Collecting: Enabled
Distributing: Enabled
Defaulted: False
Expired: False

Partner System Priority: 0x8000
Partner System: 00-0E-D7-1F-29-00
Partner Operational Key: 0x0014
Partner Port Priority: 0x8000
Partner Port: 0x002F
Partner State:
LACP activity: Active
LACP timeout: Long
Aggregation: Aggregatable
Synchronization: IN_SYNC
Collecting: Enabled
Distributing: Enabled
Defaulted: False
Expired: False

Received LACPDUs: 30439
Transmitted LACPDUs: 28128
Received marker PDUs: 0
Transmitted marker PDUs: 0
Received marker response PDUs: 0
Transmitted marker response PDUs: 0
Received unknown PDUs: 0
Received illegal PDUs: 0
L’Actor system est l’identifiant du serveur AIX. Il sera donc identique pour l’ensemble des ports du Link Aggregation.

L’Actor Operational Key est la clé d’identification du Link Aggregation sur le serveur. Clé unique par LA.

Le Partner system est l’identifiant du switch.

Le Partner Operational Key est la clé d’identification du Link Aggregation sur le switch.

Il faut vérifier que les paramètres Actor Operational Key, Partner system et Partner Operational Key sont identiques pour toutes les interfaces faisant partie du même LA. L'Actor System ne change pas quand on reste sur le même serveur physique.

Chaque port (aussi bien coté switch que serveur ) doit avoir les états suivants :
  • LACP activity doit être à Active. Cela indique que l’on utilise LACP et le mode 802.3ad

  • Aggregation doit être à Aggregatable. Cela indique que le port peut faire partie d’un LA.

  • Synchronization doit être à IN SYNC. Cela indique que les ports du serveur et du switch sont synchronisés.

Conclusion


Une fois la configuration des ports switchs vérifiés, le problème le plus commun sur lequel je suis tombé est d’avoir les deux ports connectés physiquement à deux switchs différents(inversion lors du cablage). Le fait de vérifier le Partner System permet d’éviter ce genre de désagrément.

A noter aussi, que le mode IEEE 802.3ad nécessite quelques secondes à se mettre en place après activation de l’interface. C’est due à la négociation LACP qui nécessite que quelques paquets LACPDU soit échangés avant que la configuration soit activé. On peut lancer un ping sur l’interface pour accélérer l’établissement de l’agrégation.

Commentaires

1. Le mardi, février 5 2008, 09:14 par stephane

merci pour ces informations claires precises , ca vas bien m'aider pour la configuration de mes serveurs AIX

tres sympa ce petit blog d'entraide.

Amicalement
Stephane

2. Le lundi, février 18 2008, 19:34 par Alain Dejoux

Content d'apprendre que ca peut vous être utile :-)

3. Le vendredi, avril 4 2008, 16:09 par Brahim

Merci beaucoup pour cet article

4. Le lundi, octobre 20 2008, 19:16 par Philippe

Bonjour,

Votre petit topic est très interéssant, j'aime les documents courts qui traite un sujet en donnant l'essentiel. Donc Merci !!

Je suis tombé sur votre blog en recherchant des infos sur les VIO, car je vais devoir monter dans les jours à venir ma première conf VIO et j'avoue ne pas bien comprendre la différence entre les processeurs physique et les processeurs virtuel.
N'auriez vous pas un petit topic sous le coude à se propros ??


Merci encore

Philippe

5. Le lundi, octobre 20 2008, 19:17 par alain dejoux

Content que le billet vous ai plu :-)

La différence entre les processeurs logiques, virtuels et physiques est effectivement difficile à appréhender dans le modèle IBM. Le nombre de questions qu'on peut se poser dessus est impressionant surtout quand on rajoute les modes capped et uncapped.

J'ai un billet en cours de rédaction sur ce thème mais comme je ne sais pas quand je le sortirais je préfère vous indiquer le chapitre 5 du redbook "Advanced Power Virtualizationon IBM Eserver p5 Servers:
Architecture and Performance Considerations" SG245768 si vous ne le connaissez pas déjà. Ce redbook est mon document de référence sur le sujet.

6. Le jeudi, novembre 20 2008, 11:34 par youss59

Salut Alain,

Merci pour ton site, les billet que tu fait me servent beaucoup.

En ce qui concerne celui-ci j'ai tous suivi est à peu près compris, mais je n'arrive pas à faire la cmd "netstat -cdlistats" le paramètre n'est pas reconnus .....

7. Le jeudi, novembre 20 2008, 19:27 par Alain Dejoux

Hello,

Essaie de lancer la commande netstat -h sous padmin. Tu devrais voir "-cdlistats" apparaitre dans les options disponibles. Sinon tu peux aussi utiliser en root "entstat -d entX" où X correspond au numéro de ton interface SEA . Cela te donnera les mêmes informations.

Bye,

Alain

8. Le mercredi, avril 22 2009, 09:51 par Gilles

Bonjour Alain,
Nous faisons également de l'etherchannel, chez nous, mais, comme les débits sont tout à fait satisfaisants sur le giga (pour notre utilisation), nous passons en mode standard, ce qui permet d'utiliser 2 switch differents (pour eviter le SPOF). Par contre, du coup, il n'y a pas d'aggregation, mais juste un backup dormant. Par contre, je n'ai pas encore essayé sur les vio serveurs... Les conseils d'ibm etant de doubler les vio serveurs, (pour de la prod) on fera l'aggregation dans les partitions.
Bravo pour ton site, en tout cas.

9. Le mercredi, avril 22 2009, 14:58 par Alain Dejoux

Hello,

Effectivement quand je parlais de link aggregation, c'était dans le cas où on possède 2 vio servers sinon le NIB est largement préférable :-)
Comme vous, j'ai tendance à utiliser le NIB sur des serveurs connectés directement au réseau pour éviter le spof. Le temps de reprise du lien est aussi plus rapide par contre c'est plus dur à monitorer à partir d'aix. Les 2 solutions ont des avantages spécifiques.

Bye,

Alain

10. Le mercredi, mai 27 2009, 22:25 par Andruald

Bonjour,

Sujet très interessant. Une question à 2 octets : y'a-t-il des risques de boucles dans un environnement de niveau 2 lors du redémarrage d'un VIOs server ?
Merci encore Alain.
Cdt.

Andruald

11. Le mardi, juin 2 2009, 20:44 par Alain Dejoux

Hello,

En fait, à ma connaissance, un des moments où il peut y avoir des "bridge loops" est quand le control channel ente les sea est mal configuré. Par exemple, si les sea de chaque vio utilisent un vlan distinct pour le control channel. Dans le pire des cas, le vlan devient inaccessible mais ce n'est pas forcément au moment du reboot.

Cela dépend aussi de la configuration des switchs, si le spanning tree protocol est activé, il protège de ce cas de figure.

Je n'ai pas connaissances de tout les problèmes possibles mais si on configure correctement les sea et control channel, on ne risque pas grand chose voir rien et le reboot ou non d'un vio ne rentre pas vraiment en compte.

12. Le mardi, juin 2 2009, 20:53 par Alain Dejoux

Je voulais ajouter que SEA pour le même vlan avec des control channels pas ou mal configurés peuvent aussi entrainés des "broadcasts storms" qui peuvent aller jusqu'à rendre le réseau indisponible.

Tout dépend aussi de l'infrastructure réseau, je pense qu'il y a des protections possibles au niveau des switchs mais je manque d'infos pratiques à ce sujet.

13. Le mardi, septembre 15 2009, 16:07 par berni

bonjour, très bien en effet mais il manque le tagging 802.1q sur l'aggréga comme c'est souvent le cas. ce sont des machines avec plusieurs partitions logiques et donc des accès réseaux différents.
je regarde si j'ai l'info et vous le transmets.
cdlt

14. Le samedi, octobre 24 2009, 09:35 par mat

hello,

je suis preneur d'infos sur le vlan tagging avec une conf en SEA failover + Link Aggregation sur les VIOS.
Si berni ou d'joux ont des "case study" vous êtes les bienvenus ;-)

15. Le lundi, octobre 26 2009, 13:09 par Lorenzo

Hi,

j'ai un Blade JS23 avec une carte Ethernet/Qlogic 4Gb.
J'arrive à faire un aggrégat en suivant la procédure mais je n'ai pas de failover, est ce que quelqu'un peut me donner un coup de main.

Merci d'avance

16. Le mercredi, octobre 28 2009, 21:48 par Alain Dejoux

Hello,

Je prépare un billet sur le sea failover et en particulier sur les différentes storms réseaux. J'espère pouvoir le poster bientot(je suis bien pris par le travail en ce moment :-(.
Pour le problème de JS23, j'aurais besoin d'un peu plus de détail. Est-ce une perte d'accès totale quand un lien tombe ? Dans quel état est le satut d'aggrégation quand le problème survient ?

Bye,

Alain

17. Le dimanche, avril 11 2010, 17:45 par John

Merci pour ce post.

Par contre, le résultat coté bande passante globale d'un etherchannel en LACP ne m'est pas claire.
En agrégeant 3 ports de 1Gbits, par exemple, je m'attends à pouvoir avoir un débit théorique de 3 Gbits sur une connexion ... et il n'en n'est rien semble-t-il.
Coté réseau on me dit que l'agrégat ne pourra pas délivrer cette bande passante pour un seul flux de connexion, le LACP utilise un algorithme XOR entre les IPs destinataire/client ou les MAC ou les ports de services et calcule ainsi un dispatch des flux de connexion mais ne semble pas répartir les packets unitairement sur chaque port physique de l'agrégat !? ... Pourtant certaines documentations semblent parler d'augmentation de bande passante ...

Est il réellement possible d'augmenter le débit via un agrégat en LACP sur une connexion réseau ? (par exemple pour avoir un débit de 3 ou 4 Gbits sur un montage NFS vers un NAS)

Merci.

18. Le lundi, avril 12 2010, 20:22 par Alain Dejoux

Bonjour,

Effectivement le débit d'une seule connexion ne peut pas dépasser le débit maximum d'un seul élément. C'est du aux algortithmes de répartition des paquets.
En gros si une même session tcp circulait par tout les liens physiques d'une aggrégation LACP, il y aurait un gros risque que l'ordre d'arrivée des paquets tcp ne soient pas bon. Ce qui serait très pénalisant.
Une explication plus complète est disponible sur wikipedia :
http://en.wikipedia.org/wiki/Link_a...

C'est la section "Order of frames".

L'intérêt est qu'on a rarement qu'une seule session en cours surtout sur un vio. Si c'est une obligation, il vaut mieux se baser sur des protocoles comme UDP ou SCTP(http://en.wikipedia.org/wiki/Stream...)

Alain

19. Le dimanche, avril 18 2010, 12:10 par John

Bonjour,

Merci de ce complément,

> En gros si une même session tcp circulait par tout les liens physiques
> d'une aggrégation LACP, il y aurait un gros risque que l'ordre
> d'arrivée des paquets tcp ne soient pas bon. Ce qui serait très
> pénalisant.

Vu que le LACP impose que les ports, coté Cisco, soient contrôlés par le même ASIC ... on aurait pu s'attendre à ce que celui-ci assure le bon ordonnancement des packets.

Si le LACP ne fait pas l'affaire pour augmenter la bande passante d'une connexion, y a t il un autre moyen ? Un mode round robin ou
équilibrage de charge au niveau packet ?

John

20. Le mardi, mai 25 2010, 21:25 par NextID

Bonsoir Alain,

Nous utilisons des lames JS 43 (VIOS) dans un châssis Blade H avec des switches Cisco 3110G. Nous avons configuré le lien SOL en ETH0, un EtherChannel en ETH1+ETH3 et un backup en ETH2. Nous souhaitons une configuration redondée, mais lorsque nous faisons un power off via l'AMM sur un des CISCO 3120G nous perdons l'EtherChannel constituée et la configuration de failover ne suit pas (nous utilisons des virtual switches sur les 3110G stackés).

Par avance, merci pour les retours sur les failover d'EtherChannel sur JS43.

JPJF

21. Le jeudi, mai 27 2010, 19:59 par Alain Dejoux

Hello,

Je ne suis pas sur d'avoir une bonne vision de votre configuration surtout la partie sur la perte de configuration. Le mieux est d'ouvrir un ticket au support vu que cela peut nécessiter pas mal de logs pour comprendre.

J'ai bien eu un cas où il fallait positionner le paramètre netaddr(qui permet de pinguer une adresse externe) pour que le failover est lieu mais c'est dans des configs avec des ports l-hea.

Bon courage,

Alain

22. Le jeudi, mai 27 2010, 20:02 par Alain Dejoux

Pour John,

Pas vu le message avant :-( . Une solution logicielle serait d'utiliser le protocole udp ou sctp au lieu de tcp. Sinon personnellement je ne vois pas. Je n'ai jamais eu le cas.

Bye,

Alain

23. Le mercredi, juin 2 2010, 21:37 par John

Merci Alain.

Mon architecte réseau préféré (sic) ne veut même plus qu'on lui parle de LACP ... il ne jure que par "Mac-Pinning" ... je ne sais pas de quoi il en retourne et cela ne semble pas correspondre à mon besoin.
Du coup ... on fait pression pour passer en 10Go :-) .

Merci pour tout.