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/
