Configurer le Link Aggregation (LAG) sur Sophos Firewall
Un Link Aggregation Group (LAG) regroupe deux à quatre ports physiques de Sophos Firewall en une seule interface logique. Cela augmente soit la bande passante disponible vers le switch, soit assure une redondance en cas de panne d’un port ou d’un câble. Selon le fabricant, le LAG est aussi appelé trunking, NIC teaming, NIC bonding ou EtherChannel.
Configurer les zones et interfaces Sophos Firewall situe déjà le LAG de manière générale à côté de VLAN, Bridge et RED, et explique quand un LAG est préférable à un simple port trunk. Cet article va plus loin : il montre la configuration concrète dans le WebAdmin, la contrepartie nécessaire côté switch, la Xmit Hash Policy et comment tester proprement un LAG après sa mise en place.
Quand un LAG est pertinent
Un LAG est particulièrement utile lorsque :
- le switch core doit être raccordé de manière redondante, afin qu’une panne de port isolée ou un câble défectueux n’interrompe pas toute la connexion,
- plusieurs VLAN passent par le même uplink et certains ports atteignent leur limite de capacité,
- le firewall a besoin de plus de débit entre firewall et switch qu’un seul port physique ne peut fournir,
- une structure de zones et de VLAN existante doit rester inchangée, mais la connexion physique doit devenir plus robuste.
Pour les petits environnements avec un seul port trunk proprement configuré, un LAG n’est souvent pas nécessaire. Un LAG ne remplace en outre pas une zonation propre : au final, l’interface LAG reste une interface unique à laquelle une zone est affectée et sur laquelle des interfaces VLAN peuvent être construites.
Prérequis
- Deux à quatre interfaces physiques qui ne sont pas encore liées d’une autre manière, par exemple pas déjà partie d’un bridge, d’un VLAN ou d’un autre LAG.
- Toutes les interfaces membres doivent être du même type et prendre en charge la même vitesse ainsi que le full-duplex.
- Un switch managé avec support LACP, si 802.3ad doit être utilisé.
- Un accès physique ou planifié au switch, pour configurer la contrepartie de manière appropriée.
- Une fenêtre de maintenance, car la création d’un LAG détache temporairement les ports physiques concernés de leur zone et configuration actuelles.
⚠️ Les interfaces PPPoE, Cellular WAN et WLAN ne peuvent pas être utilisées comme membres d’un LAG. Seules les interfaces physiques non liées (unbound) sont disponibles comme membres.
1. Choisir le mode de bonding
Sophos Firewall prend en charge deux modes de bonding :
- Active-Backup : un lien membre est actif, les autres restent en standby. Si le lien actif tombe en panne, un lien standby prend le relais. Ce mode est simple, ne nécessite aucune configuration particulière du switch et convient surtout pour la redondance.
- 802.3ad (LACP) : plusieurs liens sont utilisés en parallèle pour la répartition de charge. LACP doit être activé des deux côtés, toutes les interfaces membres doivent avoir le même type et la même vitesse, et tous les liens doivent fonctionner en full-duplex.
Pour une redondance pure sans bande passante supplémentaire, Active-Backup est la solution la plus simple. Qui a besoin d’un véritable débit accru entre firewall et switch devrait choisir 802.3ad, mais doit alors aussi configurer correctement le côté switch.
2. Créer le LAG dans WebAdmin
- Ouvrir Network > Interfaces.
- Sélectionner Add interface, puis Add LAG.
- Sous Name, donner un nom explicite, par exemple
LAG_Core_Uplink. - Sous Hardware name, définir un nom technique court, maximum 10 caractères, uniquement alphanumérique et underscores. Ce nom ne peut plus être modifié après la création et ne doit pas utiliser un nom système réservé comme
all,gre,ethouWLAN. - Sous Member interface, ajouter deux à quatre interfaces physiques appropriées.
- Sous Bonding mode, choisir Active-Backup ou 802.3ad.
- En 802.3ad, définir en plus la Xmit Hash Policy : Layer2, Layer2+3 ou Layer3+4.
- Affecter une Zone, adaptée à l’usage prévu, par exemple
LANou une zone core dédiée. - Choisir l’IP assignment : statique ou DHCP, y compris l’adresse IPv4 ou IPv6 en cas d’attribution statique.
- Adapter éventuellement le MTU, si le réseau utilise des jumbo frames ou d’autres valeurs différentes.
- Définir éventuellement sous MAC address une adresse propre, au lieu de reprendre celle du premier port membre.
- Sélectionner Save.
Après l’enregistrement, l’interface LAG, par exemple lag0, est disponible comme interface autonome. Des interfaces VLAN peuvent ensuite y être créées de la même manière que sur un port physique. La procédure pour les interfaces VLAN sur un LAG est identique à celle du VLAN sur une interface physique et est décrite dans Configurer et tester un VLAN sur Sophos Firewall.
Bien choisir la Xmit Hash Policy
La Xmit Hash Policy ne détermine, uniquement en 802.3ad, que la manière dont le trafic entrant est réparti sur les différents liens membres. Elle n’influence pas si le LAG fonctionne, mais la façon dont la charge est répartie uniformément sur les ports membres.
- Layer2 : répartition selon l’adresse MAC source et destination. Simple, mais souvent déséquilibrée avec peu de partenaires de communication.
- Layer2+3 : répartition en plus selon les adresses IP. En général un bon réglage de base pour un trafic réseau mixte.
- Layer3+4 : répartition en plus selon les numéros de port. Peut offrir une meilleure répartition avec de nombreuses connexions parallèles entre les mêmes hôtes, mais ne fonctionne pas aussi bien pour tous les types de trafic, par exemple un trafic fortement fragmenté ou non classiquement TCP/UDP.
La policy choisie doit correspondre entre le firewall et le switch, afin que les deux côtés répartissent le trafic de manière cohérente. Une différence ne provoque pas forcément une panne complète, mais peut entraîner une charge inégale sur certains liens.
3. Configurer le côté switch
Un LAG ne fonctionne de manière fiable que si le côté switch est configuré en conséquence. Le firewall et le switch doivent s’accorder sur le même mode de bonding.
Avec Active-Backup, une configuration de port simple sans regroupement trunk spécial suffit sur de nombreux switches, car un seul lien transporte du trafic actif à un moment donné. Il faut néanmoins vérifier si le switch a configuré le Spanning Tree ou la sécurité de port de manière à ne pas retarder davantage un changement de lien actif.
Avec 802.3ad (LACP), les ports switch concernés doivent :
- se trouver dans le même groupe de link aggregation, par exemple un port-channel chez Cisco ou un groupe LAG chez d’autres fabricants,
- utiliser activement LACP, pas seulement un bonding statique sans protocole,
- utiliser la même vitesse et le même mode duplex que le côté firewall,
- être configurés dans le même mode de VLAN trunking, correspondant à la structure VLAN prévue sur le firewall.
Si un LAG n’est créé que sur le firewall, alors que le switch continue d’exploiter des ports individuels indépendants, des problèmes difficiles à diagnostiquer apparaissent souvent : perte de paquets partielle, comportement asymétrique, ou un LAG affiché comme actif mais qui ne fournit pas le débit attendu.
4. Tester le LAG après la mise en place
Un LAG nouvellement créé ne devrait pas être vérifié uniquement sur son statut vert, mais sur son comportement réel en cas de panne et sous charge.
Tests pertinents :
- Test de connexion en fonctionnement normal : vérifier le débit et la joignabilité via le LAG avant de simuler une panne.
- Déconnecter un lien membre isolé : débrancher un câble d’un port membre et vérifier si la connexion continue sans interruption perceptible.
- Reconnecter le second lien membre : vérifier si le lien est proprement réintégré dans le LAG, sans intervention manuelle nécessaire.
- Répartir la charge sur plusieurs connexions : en 802.3ad, générer plusieurs connexions parallèles avec des combinaisons source/destination différentes et vérifier si le trafic passe réellement par plusieurs ports membres.
- Vérifier le statut côté switch : contrôler sur le switch si le groupe port-channel ou LACP affiche tous les ports attendus comme actifs.
Pour la vérification du statut des interfaces sur le firewall, la démarche générale de Configurer les zones et interfaces Sophos Firewall convient. Si l’accès de gestion, le DNS ou l’authentification sont affectés après la bascule, Résoudre les problèmes ARP après une migration Sophos Firewall aide également, si plusieurs interfaces sont concernées dans le même sous-réseau.
Erreurs typiques
- Interfaces membres avec vitesse ou duplex différents : 802.3ad ne fonctionne pas de manière fiable, voire pas du tout. Tous les ports membres doivent être configurés de manière identique.
- Switch non basculé sur LACP : le firewall peut afficher le LAG comme actif alors qu’en réalité seul un lien fonctionne proprement ou le trafic est instable. Vérifier la configuration port-channel ou LACP côté switch.
- Interface déjà liée d’une autre manière : une interface déjà membre d’un bridge ou d’un VLAN n’est pas disponible comme membre LAG. Résoudre d’abord la liaison existante.
- Interface PPPoE, Cellular ou WLAN choisie comme membre : ces types d’interface ne sont pas pris en charge par Sophos Firewall comme membre LAG.
- Xmit Hash Policy différente entre firewall et switch : le LAG fonctionne, mais la charge se répartit de manière inégale sur certains liens. Aligner la policy des deux côtés.
- Vouloir modifier le Hardware name après coup : ce n’est pas possible. En cas de nom mal choisi, le LAG doit être recréé.
- Aucun test de failover effectué : un LAG jamais testé sous une panne réelle peut réagir différemment que prévu en cas d’incident. Effectuer le test de câble débranché avant la mise en production.
- Zones et règles firewall non adaptées : après le déplacement de ports dans un LAG, d’anciennes règles restent parfois liées aux mauvaises interfaces. Vérifier l’affectation des zones et des règles après la migration.
Checklist
- Deux à quatre interfaces physiques appropriées et non liées (unbound) identifiées.
- Mode de bonding choisi consciemment : Active-Backup pour la redondance, 802.3ad pour la répartition de charge.
- Côté switch configuré avec le port-channel ou LACP approprié.
- Xmit Hash Policy alignée entre firewall et switch, si 802.3ad est utilisé.
- Zone, attribution IP et MTU définies selon l’usage prévu.
- Failover testé avec un câble débranché.
- Répartition de charge en 802.3ad vérifiée avec plusieurs connexions parallèles.
- Règles firewall et affectation des zones contrôlées après la bascule.
- Fenêtre de maintenance planifiée pour la mise en place, car les ports existants sont temporairement déconnectés.