Duplicate IP address on LSPs in the same LS lead to unpredictable flow output
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| neutron |
New
|
Undecided
|
Unassigned | ||
| ovn (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
In a busy CI cloud we ran into an issue that took us days to get to the bottom of.
Essentially what happens is that the CMS is sometimes unable to complete deletion of a LSP (being worked on separately [0]).
Subsequently a new LSP is created using the same IP address but a different MAC address. There exists duplicate IP checks in the ovn-nbctl administration tool [1], but the current database schema does not apply any constraints on a CMS adding duplicates and despite [1] citing ovn-northd should log this, it does not appear to do so.
When a system is in the above described state the flow output on hypervisors is unpredictable, and this leads to instances not being able to reach the router nor the outside world.
What happens inside the ovn-controller is that the function looking up installed flows [2] only does a table, priority and miniflow match, and does not consider the possibility of other collisions.
Subsequently an attempt to link an desired flow to an installed flow unexpectedly fails, and the flow is just not processed at all [3].
At the very least I think we need to investigate why this situation is not logged in ovn-northd, but I don't think just logging this is enough.
Is there something we can change in the database model that would prevent a CMS from getting itself into this situation in the first place?
Should we consider also not generating the lflows?
Example lflows:
table=
table=
table=
table=
table=
table=
table=
table=
table=
table=
table=
table=
table=
table=
Resulting flow table:
cookie=0xe683b51c, duration=0.128s, table=23, n_packets=0, n_bytes=0, idle_age=0, priority=
cookie=0xe683b51c, duration=0.128s, table=23, n_packets=0, n_bytes=0, idle_age=0, priority=
cookie=0xe683b51c, duration=0.128s, table=23, n_packets=0, n_bytes=0, idle_age=0, priority=
cookie=0xe683b51c, duration=0.128s, table=23, n_packets=0, n_bytes=0, idle_age=0, priority=
cookie=0xed4bbf00, duration=0.120s, table=23, n_packets=0, n_bytes=0, idle_age=0, priority=
cookie=0x601769fe, duration=0.114s, table=23, n_packets=0, n_bytes=0, idle_age=0, priority=
cookie=0x92b4073a, duration=0.118s, table=23, n_packets=0, n_bytes=0, idle_age=0, priority=
cookie=0x87dacd46, duration=0.118s, table=23, n_packets=0, n_bytes=0, idle_age=0, priority=
cookie=0xa7d4ecf1, duration=0.113s, table=23, n_packets=0, n_bytes=0, idle_age=0, priority=
cookie=0xb595291d, duration=0.128s, table=23, n_packets=0, n_bytes=0, idle_age=0, priority=
cookie=0xb595291d, duration=0.128s, table=23, n_packets=0, n_bytes=0, idle_age=0, priority=
cookie=0xb7e18e6b, duration=0.127s, table=23, n_packets=0, n_bytes=0, idle_age=0, priority=
cookie=0xb7e18e6b, duration=0.127s, table=23, n_packets=0, n_bytes=0, idle_age=0, priority=
cookie=0xb60abbb8, duration=0.125s, table=23, n_packets=0, n_bytes=0, idle_age=0, priority=
cookie=0xb60abbb8, duration=0.125s, table=23, n_packets=0, n_bytes=0, idle_age=0, priority=
As you can see the mac address to program the flow for is chosen at "random":
idle_age=0, priority=
0: https:/
1: https:/
2: https:/
3: https:/
| description: | updated |
| Frode Nordahl (fnordahl) wrote | #1 |
| no longer affects: | charm-ovn-central |
| tags: | added: ovn |
Adding the OpenStack Neutron project to this bug after a discussion with the OVN team [4], which suggest that although the current OVN DB schema allows duplicates to occur it is the CMS's responsibility to avoid them.
There is an related neutron bug 1960006 that did attempt to address a similar situation with stale ports in the OVN DB. However it does not appear to be sufficient to avoid this situation.
I wonder if Neutron should do a pre-flight check along the lines of what the ``ovn-nbctl`` tool does [5].
4: https:/
5: https:/