Table MAC Dell Networking non synchronisée pour le canal de port multi-homing EVPN sur SONiC
Résumé: Lors de l’utilisation du réseau privé virtuel Ethernet (EVPN) MultiHoming (MH) avec des interfaces PortChannel exécutant SONiC, les clients peuvent rencontrer un retard ou une défaillance dans la synchronisation des adresses MAC sur les points de terminaison de tunnel virtuel (VTEP) lors des scénarios de basculement du pare-feu. Ce problème a été observé principalement avec les pare-feu Fortinet FortiGate, mais peut se produire avec d’autres appareils utilisant des mécanismes de basculement similaires. Le problème entraîne une interruption partielle ou totale du trafic jusqu’à ce que les tables MAC convergent, ce qui peut prendre jusqu’à 30 minutes sans intervention manuelle. ...
Symptômes
Comment collecter des informations à partir du commutateur :
-
Collectez le bundle show tech-supportà partir de tous les commutateurs concernés. Il comprend les éléments suivants :
-
-
Syslog
-
-
-
Journaux FDB (Forwarding Database)
-
-
-
Tables de routage EVPN BGP (Border Gateway Protocol)
-
-
Autres commandes utiles :
1 show mac address-table | grep <MAC>
2 show bgp l2vpn evpn route type macip mac <MAC>
3 sudo bridge fdb | grep <MAC> Comment identifier le problème :
-
Après un basculement du pare-feu, les adresses MAC associées au pare-feu peuvent :
-
-
Conservez l’apprentissage en utilisant VXLAN au lieu du PortChannel local.
-
-
-
Afficher les entrées incohérentes entre les VTEP.
-
-
Le trafic vers ou depuis le pare-feu peut échouer pour plusieurs VLAN.
-
Les logs indiquent la suppression de la mobilité MAC et les interférences d’apprentissage du noyau.
Exemple de table MAC lors du problème :
58422722133@switches-hostname:~$ show mac | grep -i 00:09:0f:09:00:1a
1 2 00:09:0F:09:00:1A 10.39.0.167,10.39.0.168 Dynamic
235 153 00:09:0F:09:00:1A 10.39.0.167,10.39.0.168 Dynamic
236 154 00:09:0F:09:00:1A PortChannel212 Dynamic <--- It should be a VxLAN tunnel
238 160 00:09:0F:09:00:1A 10.39.0.167,10.39.0.168 Dynamic
240 162 00:09:0F:09:00:1A 10.39.0.167,10.39.0.168 Dynamic
251 167 00:09:0F:09:00:1A 10.39.0.167,10.39.0.168 Dynamic
277 200 00:09:0F:09:00:1A 10.39.0.167,10.39.0.168 Dynamic
315 201 00:09:0F:09:00:1A 10.39.0.167,10.39.0.168 Dynamic
343 600 00:09:0F:09:00:1A 10.39.0.167,10.39.0.168 Dynamic
526 601 00:09:0F:09:00:1A 10.39.0.167,10.39.0.168 Dynamic
664 602 00:09:0F:09:00:1A 10.39.0.167,10.39.0.168 Dynamic
Cause
-
Lors du basculement du pare-feu, des paquets ARP gratuits (GARP) sont envoyés, mais des paquets supplémentaires (par exemple, IGMP à partir de VRRP ou de connexions persistantes HA) peuvent entraîner le réapprentissage de l’adresse MAC par SONiC sur la mauvaise interface (apprentissage du noyau).
-
Il en résulte :
-
-
Les entrées MAC oscillent entre PortChannel et VXLAN Tunnel
-
-
-
Mises à jour incohérentes dans les tables de la base de données de transfert (FDB) et BGP EVPN
-
-
Les incohérences dans la détection d’adresses en double (DAD) et dans l’ID du routeur peuvent aggraver le problème.
Amélioration de l’exemple d’extrait de journal
- L’adresse Mac se déplace vers le VTEP, puis est apprise à l’aide du noyau de PO212 en raison des paquets reçus de PO212 après la migration.
sonic_dump_switches-hostname_20250819_062857/log/fdbsync.log.gz:Aug 19 06:22:38.943540-03:00 2025 DC2BR01B NOTICE swss#fdbsyncd: :- onMsgNbr: Netlink Msg Key:Vlan154:00:09:0f:09:00:1a MAC:00:09:0f:09:00:1a Vtep:0x0 NHID:536870920 VNI:10154 VLAN:154 Op_type:1 Static:0 IfName:vtep1-154 PERM:0, EXT:0 ES:0, flags:0x12 nfy:0x0
sonic_dump_switches-hostname_20250819_062857/log/fdbsync.log.gz:Aug 19 06:22:39.032196-03:00 2025 DC2BR01B NOTICE swss#fdbsyncd: :- onMsgNbr: Netlink Msg Key:Vlan154:00:09:0f:09:00:1a MAC:00:09:0f:09:00:1a Vtep:0x0 NHID:0 VNI:0 VLAN:154 Op_type:1 Static:1 IfName:PortChannel212 PERM:0, EXT:0 ES:1, flags:0x0 nfy:0x1
sonic_dump_switches-hostname_20250819_062857/log/fdbsync.log.gz:Aug 19 06:32:58.670774-03:00 2025 DC2BR01B NOTICE swss#fdbsyncd: :- onMsgNbr: Netlink Msg Key:Vlan154:00:09:0f:09:00:1a MAC:00:09:0f:09:00:1a Vtep:0x0 NHID:0 VNI:0 VLAN:154 Op_type:1 Static:1 IfName:PortChannel212 PERM:0, EXT:0 ES:1, flags:0x0 nfy:0x3
sonic_dump_switches-hostname_20250819_062857/log/fdbsync.log.gz:Aug 19 06:32:59.043189-03:00 2025 DC2BR01B NOTICE swss#fdbsyncd: :- processNetlinkData: KEY:Vlan154:00:09:0f:09:00:1a Vlan:154 Vni:0 Mac:00:09:0f:09:00:1a vtep:0.0.0.0 NHID:0 ifname:PortChannel212 type:1 Op:ADD Perm:0, Ext:0, ES:1 Résolution
-
Effectuez une mise à niveau vers SONiC 4.5.1 ou une version ultérieure. Cette version inclut le correctif pour ce problème.
-
Appliquez les modifications de configuration ci-dessous (obligatoires même après la mise à niveau) :
-
-
Désactivez la détection d’adresses en double (DAD) dans le VRF par défaut:
-
1 router bgp <ASN>
2 address-family l2vpn evpn
3 no dup-addr-detection -
Pour un VRF autre que celui par défaut, il est recommandé de modifier les valeurs par défaut de DAD en «dup-addr-detection max-moves 20 time 60».
-
Alignez les ID de routeur BGP sur tous les VRF.
-
Définissez l’intervalle d’annonce BGP sur 0sur toutes les sessions BGP afin d’accélérer la propagation de la route MAC/IP.
-
-
LKB 000333271 l’apprentissage lent des points de terminaison dans les fabrics BGP EVPN
-
Si la mise à niveau du firmware n’est pas immédiatement possible.
Vous pouvez réduire la probabilité de ce problème en apportant les mêmes modifications de configuration :
-
Désactivez la détection d’adresses en double dans le VRF par défaut.
-
Utilisez la configuration recommandée pour la détection d’adresses en double dans un VRF autre que celui par défaut.
-
Alignez les ID de routeur BGP sur tous les VRF.
-
Définissez l’intervalle d’annonce BGP sur 0.