Linux : trouver la bonne adresse MAC sur un lien réseau de type bonding
Sommaire
I. Présentation
Nous avons vu il y a quelques temps comment mutualiser les ressources du réseau sur une machine GNU/Linux en créant un lien réseau de type bonding. Cela permet d’avoir de meilleures performances et surtout une résilience aux pannes physiques.
Seulement, d’après le fonctionnement d’une telle architecture, le bond réseau s’appuyant sur l’adresse MAC de l’interface réseau principale faisant partie intégrante du bond lui-même, l’adresse en question ne se modifie donc pas dynamiquement.
Aussi, lorsque l’on intègre de nouveaux membres à ce lien bond, et que l’on supprime les anciennes interfaces, l’adresse MAC virtuelle ne change pas. Par contre, lors du reboot suivant, le réseau prendra l’adresse MAC du nouveau membre principal et ne fonctionnera plus.
Dans ce tutoriel, je vous propose de voir comment retrouver et modifier l’adresse MAC de la nouvelle interface réseau afin de pouvoir conserver un service réseau fonctionnel, même après redémarrage de la machine.
REMARQUE : dans l’exemple que j’ai choisi d’illustrer, je suis sur une distribution CentOS7.3 64bits.
II. Intégration des interfaces physiques
Avant tout, rappelons comment intégrer de nouvelles interfaces à notre lien bond, en supprimant ensuite les anciennes:
# ifenslave bond0 eth4 # ifenslave bond0 eth5 # ifenslave -d bond0 eth1 # ifenslave -d bond0 eth0
Lorsque l’on interroge la configuration réseau, on se retrouve malgré tout avec l’association de nos nouvelles interfaces et l’adresse MAC de l’ancienne interface eth0, liée au bond.
# ip a … 8: eth4: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000 link/ether e0:07:1b:f6:8f:b4 brd ff:ff:ff:ff:ff:ff 9: eth5: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP qlen 1000 link/ether e0:07:1b:f6:8f:b4 brd ff:ff:ff:ff:ff:ff 10: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether e0:07:1b:f6:8f:b4 brd ff:ff:ff:ff:ff:ff inet 192.168.1.199/20 brd 192.168.15.255 scope global bond0 inet6 fe80::e207:1bff:fef6:8fb4/64 scope link valid_lft forever preferred_lft forever
On constate clairement que l’adresse MAC propagée par la configuration bond de notre architecture possède la même adresse MAC, quel que soit l’interface, soit e0:07:1b:f6:8f:b4. C’est lors du prochain redémarrage de la machine que les choses risquent de ne plus fonctionner, puisque les interfaces de l’exemple ci-dessus eth4 et eth5 ne possèdent pas la même adresse MAC que leurs prédécesseurs eth0 et eth1.
III. Identification des adresses MAC
Maintenant, pour pouvoir corriger cet état de fait, on va commencer par identifier l’adresse PCI des différentes interfaces, en exécutant la commande lspci:
# lspci|grep Broadcom
REMARQUE: dans le cas où vos contrôleurs ne sont pas "Broadcom" mais d’un autre fournisseur, pensez à changer la commande ci-dessus en remplaçant ‘Broadcom’ par le nom de votre fournisseur.
Théoriquement, on devrait alors visualiser les lignes ci-dessous. Seules les deux dernières lignes nous intéressent, car elles représentent les deux interfaces physiques que nous souhaitons explorer :
Dans notre cas, les interfaces en question sont de type Fiber Channel 10Gb. L’adresse PCI est celle mentionnée en tête de ligne. Il s’agit des adresses 81:00.0 et 81:00.1. Sous GNU/Linux tout est représenté sous forme de fichiers, y compris les interfaces PCI décrites ci-dessus. Les informations recherchées se trouvent dans le pseudo-filesystem /sys:
# cd /sys/devices/pci0000:80/0000:80.01.0/0000:81:00.0/net/eth4/bonding_slave # mode perm_hwaddr 8c:dc:d4:16:96:50
Ainsi, en remontant de quatre sous-répertoires et en redescendant on peut également trouver le même genre d’information concernant l’interface eth5:
# cd /sys/devices/pci0000:80/0000:80.01.0/0000:81:00.1/net/eth5/bonding_slave # mode perm_hwaddr 8c:dc:d4:16:96:54
Fort de ces informations, il ne reste plus qu’à aller modifier les adresses MAC du fichier 70-persistent-net.rules du répertoire /etc/udev/rules.d afin de pouvoir redémarrer la machine de façon transparente sans avoir à reconfigurer le réseau après.
IV. Modification du fichier de règles UDEV
On peut donc éditer le fichier 70-persistent-net.rules du répertoire /etc/udev/rules.d afin de ne laisser que les deux règles de nommage UDEV suivantes en corrélation avec le sinformations récoltées précédemment sur les interfaces eth4 et eth5:
# PCI device 0x14e4:0x1657 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="8c:dc:d4:16:96:50", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4"
# PCI device 0x14e4:0x1657 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="8c:dc:d4:16:96:54", ATTR{type}=="1", KERNEL=="eth*", NAME="eth5"
REMARQUE: dans la mesure du possible, lorsque l’on effectue une telle modification, même si l’on est certain de la qualité des informations modifiées, il est fortement conseillé de tester un redémarrage pour s’assurer que tout fonctionne correctement après.
V. Conclusion
Ce genre de manipulation propose une solution élégante de modifier le réseau grâce aux propriétés du bonding. Cela permet en outre d’effectuer ces modifications à chaud sans interrompre le service réseau et/ou le trafic applicatif. Bien sûr, on ne peut pratiquer ainsi qu’à la condition de disposer d’un réseau au format de type bond. J’espère que cela vous permettra d’être plus à l’aise avec votre réseau GNU/Linux tout en favorisant les services aux utilisateurs et éviter les interruptions.
