Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

DHCP request does not reach tapXXX (qdhcp-XXX) network interface

To learn a little about OpenStack, a have installed 3 VMs using libvirt/KVM. I followed the http://docs.openstack.org/juno/install-guide/install/yum/content/

I am using CentOS 7, OPenStack Juno and neutron with openvswitch. One VM is the controller, the other is network node and the third is compute node. I am using a cirros image (cirros-0.3.3-x86_64).

Right now I can start an instance but DHCP does not work. I can configure manually the IP DHCP allocates and it works, I can access the instance using ssh from outside and also can access external network from the instance.

I found that the instance DHCP request is reaching network node using the wrong interface:

[root@network neutron]# ip netns
qrouter-89fe919a-0659-4e18-a609-aa698a110c9c
qdhcp-2a920ddf-60ac-4e9f-8731-ca64b02f37df

[root@network neutron]# ip netns exec qrouter-89fe919a-0659-4e18-a609-aa698a110c9c ip link
1: lo: <loopback,up,lower_up> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
11: qr-27520527-5c: <broadcast,multicast,up,lower_up> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT
link/ether fa:16:3e:b0:3d:2c brd ff:ff:ff:ff:ff:ff
12: qg-79330b81-77: <broadcast,multicast,up,lower_up> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT
link/ether fa:16:3e:56:e3:d2 brd ff:ff:ff:ff:ff:ff

[root@network neutron]# ip netns exec qrouter-89fe919a-0659-4e18-a609-aa698a110c9c tcpdump -n -i qr-27520527-5c
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on qr-27520527-5c, link-type EN10MB (Ethernet), capture size 65535 bytes
(at this point I ran /etc/init.d/S40network start at instance console)
18:38:27.335127 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fa:16:3e:63:f5:86, length 290
18:39:27.414937 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fa:16:3e:63:f5:86, length 290

"fa:16:3e:63:f5:86" is the instance MAC address.
So the DHCP request reaches the network node, but using the wrong interrface.

Dnsmasq is listening on tap8dc583ac-23 interface that is on qdhcp-XXX namespace.

root@network neutron]# ip netns exec qdhcp-2a920ddf-60ac-4e9f-8731-ca64b02f37df ip link
1: lo: <loopback,up,lower_up> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
9: tap8dc583ac-23: <broadcast,multicast,up,lower_up> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT
link/ether fa:16:3e:69:91:f2 brd ff:ff:ff:ff:ff:ff

As far as I know, the correct interface is tap8dc583ac-23, but there are something very strange maybe on openvswitch configuration.

Thanks for any help

DHCP request does not reach tapXXX (qdhcp-XXX) network interface

To learn a little about OpenStack, a have installed 3 VMs using libvirt/KVM. I followed the http://docs.openstack.org/juno/install-guide/install/yum/content/

I am using CentOS 7, OPenStack Juno and neutron with openvswitch. One VM is the controller, the other is network node and the third is compute node. I am using a cirros image (cirros-0.3.3-x86_64).

Right now I can start an instance but DHCP does not work.
I can configure manually the IP DHCP allocates and it works, I can access the instance using ssh from outside and also can access external network from the instance.

instance.

I found that the instance DHCP request is reaching network node using the wrong interface:

[root@network neutron]# ip netns
qrouter-89fe919a-0659-4e18-a609-aa698a110c9c
qdhcp-2a920ddf-60ac-4e9f-8731-ca64b02f37df

netns<br> qrouter-89fe919a-0659-4e18-a609-aa698a110c9c<br> qdhcp-2a920ddf-60ac-4e9f-8731-ca64b02f37df [root@network neutron]# ip netns exec qrouter-89fe919a-0659-4e18-a609-aa698a110c9c ip link
**qrouter-89fe919a-0659-4e18-a609-aa698a110c9c** ip link<br> 1: lo: <loopback,up,lower_up> <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
DEFAULT<br> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
00:00:00:00:00:00<br> 11: qr-27520527-5c: <broadcast,multicast,up,lower_up> **qr-27520527-5c**: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT
DEFAULT<br> link/ether fa:16:3e:b0:3d:2c brd ff:ff:ff:ff:ff:ff
ff:ff:ff:ff:ff:ff<br> 12: qg-79330b81-77: <broadcast,multicast,up,lower_up> <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT
<br> link/ether fa:16:3e:56:e3:d2 brd ff:ff:ff:ff:ff:ff

ff:ff:ff:ff:ff:ff<br> [root@network neutron]# ip netns exec qrouter-89fe919a-0659-4e18-a609-aa698a110c9c tcpdump -n -i qr-27520527-5c
qr-27520527-5c<br> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
decode<br> listening on qr-27520527-5c, link-type EN10MB (Ethernet), capture size 65535 bytes
(at
bytes<br> **(at this point I ran /etc/init.d/S40network start at instance console)
console)**<br> 18:38:27.335127 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fa:16:3e:63:f5:86, length 290
290<br> 18:39:27.414937 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fa:16:3e:63:f5:86, length 290

290<br> "fa:16:3e:63:f5:86" is the instance MAC address.
address.<br> So the DHCP request reaches the network node, but using the wrong interrface.

interrface. Dnsmasq is listening on tap8dc583ac-23 interface that is on qdhcp-XXX namespace.

namespace. root@network neutron]# ip netns exec qdhcp-2a920ddf-60ac-4e9f-8731-ca64b02f37df ip link
**qdhcp-2a920ddf-60ac-4e9f-8731-ca64b02f37df** ip link<br> 1: lo: <loopback,up,lower_up> <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
<br> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
00:00:00:00:00:00<br> 9: tap8dc583ac-23: <broadcast,multicast,up,lower_up> **tap8dc583ac-23**: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT
<br> link/ether fa:16:3e:69:91:f2 brd ff:ff:ff:ff:ff:ff

ff:ff:ff:ff:ff:ff<br>

As far as I know, the correct interface is tap8dc583ac-23, but there are something very strange maybe on openvswitch configuration.

Thanks for any help