Re: [TECH] Debug openvswitch/openstack
Erwan David via frnog <[email protected]>
| Newsgroups | gmane.org.operators.frnog |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Feb 05, 2026 at 04:35:06PM CET, Yanick Delarbre <[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 Les flux semblent bons, en surveillant on a vu que la mac de la VM est vue sur le port "vers l'extérieur" que ce soit sur br-int ou br-ex Dynamiquement : - la VM émet un DHCPDISCOVER - sur br-int la mac passe sur le bon port - sur br-ex elle passe sur le port vers br-int - quasi aussitôt elle rebascule sur le port "vers l'extérieur" sur les 2 Donc ça explique les move, mais du coup ça ne marche pas (le DHCPOFFER n'arrive pas à la VM). Forcément c'est juste sur de la prod, je vais voir si on peut redémarrer le neutron-agent -- Erwan David --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/