DHCP-agent works in a separate namespace but is connected to br-int in ovs, after creating a demo-net it can be seen that an interface on which dhcp (tap3b4d7bf0-12) server works is assigned to VLAN 4095 (so called “dead-vlan”) on the br-int making it inaccessible for a running instance which has an interface in demo-net.
|
ovs-vsctl show (...) Bridge br-int fail_mode: secure (...) Port "qr-914553af-37" tag: 1 Interface "qr-914553af-37" type: internal (...) Port "tap3b4d7bf0-12" tag: 4095 Interface "tap3b4d7bf0-12" type: internal |
Changing tag statically to 1 (same tag as used by qr* interface where DHCP requests from an example instance are seen with tcpdump):
|
ip netns <qrouter_uuid> tcpdump -i qr-914553af-37 ovs-vsctl port tap3b4d7bf0 12 tag=1 |
Does not solve the problem, DHCP requests reach DHCP agent and are replied but replies are not forwarded to the instance (probably some more static changes are required in OVS)
DHCP port (in this example 10.0.0.2) is visible in neutron as DOWN:
|
neutron port-list +--------------------------------------+------+-------------------+---------------------------------------------------------------------------------------+ | id | name | mac_address | fixed_ips | +--------------------------------------+------+-------------------+---------------------------------------------------------------------------------------+ | 26dbf0f3-250f-4c1d-9a37-f70027f83908 | | fa:16:3e:20:5d:98 | {"subnet_id": "e14870b5-3e2f-45f2-bcae-cccc3d0151fc", "ip_address": "192.168.242.41"} | | 914553af-37ae-44c4-b695-865f95eea120 | | fa:16:3e:fe:b6:ef | {"subnet_id": "bddace66-ffe3-482e-879c-0e342fbc4cff", "ip_address": "10.0.0.1"} | | 94e0f1ce-bf2a-49e9-be90-c0d072a47095 | | fa:16:3e:2b:3c:e8 | {"subnet_id": "93dd6884-041d-4445-bae6-ffa5b0c67398", "ip_address": "10.0.1.2"} | | aad18265-0903-45f8-bdd1-aaa7c024ecb8 | | fa:16:3e:d2:10:8e | {"subnet_id": "e14870b5-3e2f-45f2-bcae-cccc3d0151fc", "ip_address": "192.168.242.40"} | | bd3818bd-e076-4502-9d8e-a09ebe12e90f | | fa:16:3e:74:98:2a | {"subnet_id": "e14870b5-3e2f-45f2-bcae-cccc3d0151fc", "ip_address": "192.168.242.42"} | | bfe570b1-ae46-4935-a274-2e29d64d3b11 | | fa:16:3e:b4:e0:a7 | {"subnet_id": "e14870b5-3e2f-45f2-bcae-cccc3d0151fc", "ip_address": "192.168.242.43"} | | dea7c53b-fc1a-424c-b64d-37338f6db14a | | fa:16:3e:d0:d1:54 | {"subnet_id": "bddace66-ffe3-482e-879c-0e342fbc4cff", "ip_address": "10.0.0.2"} | | efcf95fb-8e14-4ba4-9842-321a4abe5291 | | fa:16:3e:0d:a6:59 | {"subnet_id": "bddace66-ffe3-482e-879c-0e342fbc4cff", "ip_address": "10.0.0.20"} | +--------------------------------------+------+-------------------+---------------------------------------------------------------------------------------+ |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
|
neutron port-show dea7c53b-fc1a-424c-b64d-37338f6db14a +-----------------------+---------------------------------------------------------------------------------+ | Field | Value | +-----------------------+---------------------------------------------------------------------------------+ | admin_state_up | True | | allowed_address_pairs | | | binding:host_id | ubuntu-openstack-aio | | binding:profile | {} | | binding:vif_details | {} | | binding:vif_type | binding_failed | | binding:vnic_type | normal | | device_id | dhcp429da08c-ea53-5d37-8723-97a3cc88198f-a10831e0-735c-4b97-b98d-b4fc55f9f8bd | | device_owner | network:dhcp | | extra_dhcp_opts | | | fixed_ips | {"subnet_id": "bddace66-ffe3-482e-879c-0e342fbc4cff", "ip_address": "10.0.0.2"} | | id | dea7c53b-fc1a-424c-b64d-37338f6db14a | | mac_address | fa:16:3e:d0:d1:54 | | name | | | network_id | a10831e0-735c-4b97-b98d-b4fc55f9f8bd | | security_groups | | | status | DOWN | | tenant_id | 8abce6089268440a858321538596facb | +-----------------------+---------------------------------------------------------------------------------+ |
Solution:
Rather simple one. Disable and enable back DHCP service on the network (I did it from horizon) -> after this DHCP port’s status changes to ACTIVE (and probably something more internally in OVS is changed so as to make DHCP replies being forwarded properly to the instance).