Hello, D'avoir pu redémarrer l'hyperviseur, sans effet notable sur le problème, signifie probablement que l'origine de ce mac move vient d'une donnée "corrompue". Sur ce compute, toutes les instances sont-elles concernées ou seulement une ? Un dénominateur commun se dégage-t-il de ce problème ? Voici quelques pistes/commandes pour creuser ce problème:
* Comparer le port neutron d'une instance saine, d'une instance KO via openstack port show / la table ports de la base de donnée de neutron * La fonctionnalité "port-security" est-elle activée / désactivée ? Le port neutron a-t-il des "allowed pair address" ? * Simuler une requête DHCP via ovs-appctl ofproto/trace et comparer le résultat entre une instance KO et une instance saine * exemple: ovs-appctl ofproto/trace br-int in_port=<ID Port instance>,udp,dl_src=<MAC source_instance>,dl_dst=ff:ff:ff:ff:ff:ff,nw_dst=255.255.255.255,udp_dst=67,udp_src=68 * https://docs.openvswitch.org/en/stable/topics/tracing/ * Vérifier les règles openflow d'un compute sain, d'un compute ko: ovs-appctl dpctl/dump-flows * Vérifier les logs de neutron-server et de l'agent L2 et passer si nécessaire le log du L2 en debug. Le lun. 9 févr. 2026 à 14:59, Erwan David via frnog <[email protected]> a écrit : > On Thu, Feb 05, 2026 at 04:35:06PM CET, Yanick Delarbre via frnog < > [email protected]> said: > > Hello, > > > > Pour troubleshooter ce problème, cette page donne des commandes ovs > > intéressantes: > > > https://developers.redhat.com/blog/2018/09/19/troubleshooting-fdb-table-wrapping-in-open-vswitch#troubleshooting_an_fdb_wrapping_issue > > > > * Notamment pour voir les mac move au sein d'ovs: ovs-appctl > fdb/stats-show > > <nom du bridge ovs> > > * Pour voir la table MAC: ovs-appctl fdb/show <nom du bridge ovs> > > * Avoir les numéros de ports associés à la table MAC: ovs-ofctl show <nom > > du bridge ovs> > > > > Il s'agit d'une mac associée à un réseau privée OpenStack ? à un réseau > > public ? à un réseau de provider ? > > > > J'ai déjà vu ce phénomène arrivé quand les règles openflow d'ovs > n'étaient > > plus correctement synchronisées via l'agent L2 sur le compute et > laissaient > > passer les macs du bridge interne (br-int) vers le bridge externe > (br-pub / > > br-prov). Dans les logs de l'agent L2, ou de neutron serveur, des > messages > > comme "Timed out waiting for a reply to message" sont-ils présents ? > > > > Un restart de l'agent L2 génère bien un full sync et arrête ce "mac > move" ? > > > > Cordialement, > > Yanick > > J'ai pas pu le faire avant aujourd'hui, mais le réponse est non. Le > retsart de neutron-openvswitch-agent ne change rien, > et même le reboot de l'hyperviseur ne change rien : > > Toujours ces DHCPDISCOVER qui sortent (vers les contrôleurs) et la mac qui > passe sur l'intreface vers la VM sur br-int > (sur l'interface vers br-int sur br-ex) puis revient sur l'interface vers > br-ex sur br-int (vers l'extérieur) sur br-ex. > > > -- > Erwan David > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
