Multiple VM ports on provider networks / dhcp fails

Eric K. Miller emiller at
Thu Dec 10 22:41:37 UTC 2020



We ran into an issue recently that I haven't been able to figure out
(this environment is on Stein which uses DVR).  It involves an
environment with many provider networks that connect to a legacy
environment as well as many tenant networks.


We create a server on a tenant network and add ports to this afterwards
with each port attached to its respective provider network.  The
provider networks have "None" for the "gateway" property, so we don't
have multiple default routes added to the routing table.


We have a single subnet which has DHCP enabled and a proper allocation
pool on its subnet.


Note that this is a CentOS 8 server we are testing with, which has "no"
ifcfg files for the additional ports, and so we rely on CentOS using
DHCP by default.


After adding the first port, the DHCP client does its job and requests
an IP, which succeeds - so the DHCP server in the respective network
namespace is responding fine.


However, after adding the second port, it appears the DHCP client is
sending requests out the network (we can see this traffic when
tcpdump'ing the respective tap interface on the host), but the DHCP
server is not replying.  After looking at OpenVSwitch flows, it appears
that DHCP broadcast traffic is being dropped for the second network.


This does NOT happen with tenant networks.  I can add multiple ports,
each connected to its respective tenant network, and an IP is assigned
to each interface that appears in CentOS immediately after the port has
been added.


Is there something special that is blocking the creation of the DHCP
flow for subsequent provider network ports?


NOTE that non-DHCP traffic flows fine if we create an ifcfg file with a
static IP set to the address that DHCP should have set the interface to
- it just appears that DHCP traffic is not flowing to the DHCP namespace
for second and subsequent ports/networks.






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openstack-discuss mailing list