Bug 2014025

Description of problem:
This issue has been reproduced on a virtualized OSP16.2 environment with two compute nodes and with ML2/OVS and DVR enabled.

It was reproduced running the tobiko scenario tests with "tox -e scenario".

Several VMs using a common tenant network and a router connecting them to the external network were created. Some of these VMs were spawned on the compute-0 and others on the compute-1. Those created on the comp-0 could not obtain information from the metadata service, while metadata worked fine for those created on comp-1.


We found that the following rule was not included in the iptables rules from the corresponding qrouter namespace on the compute-0:
-A neutron-l3-agent-PREROUTING -d 169.254.169.254/32 -i qr-+ -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 9697

The rule existed on the compute-1.

The issue was fixed when the neutron_l3_agent container was restarted on comp-0.



Version-Release number of selected component (if applicable):
RHOS-16.2-RHEL-8-20211006.n.1
openstack-neutron-15.3.5-2.20210608154815.el8ost.4.noarch


How reproducible:
Not very often, but I believe it affects some tobiko tests during the create-resources stage from time to time.
For example, the test_ssh failed here due to metadata not reachable by a cirros instance:
http://rhos-ci-logs.lab.eng.tlv2.redhat.com/logs/staging/DFG-network-networking-ovn-16.1_director-rhel-virthost-3cont_2comp-ipv4-vxlan-ml2ovs-to-ovn-migration/12/infrared/.workspaces/workspace_2021-10-04_11-14-05/tobiko_create-resources/tobiko_create-resources_create_resources_scenario.html


Steps to Reproduce:
1. run tobiko create resources test stage
2.
3.