Re: [TECH] Debug openvswitch/openstack

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/