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 Le mer. 4 févr. 2026 à 16:01, Erwan David via frnog <[email protected]> a écrit : > Bonjour, > > Sur un compute openstack je me retrouve avec une adresse mac de VM interne > portée par le port de l'openvswitch vers l'extérieur du compute > Forcément ça marche moins bien. Je vois aussi que j'ai un taux quasi > constant de 3 mac_moved par secondes. Normalement une mac ne devrait > changer de port que lorsqu'on déplace une VM si j'ai bien compris, donc > pas en permanence. > > Pour investiguer ça, je cherche comment monitorer ces évènements de > mac_moved. J'ai essayé de mettre le vlog bridge:file:debug mais rine de > plus > dans les logs. Je cherche donc des pistes pour chercher la cause de ces > changements de mac > > Merci > > -- > Erwan David > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
