Ask Your Question

# Revision history [back]

### DHCP Discover not tunneled through OVS/GRE

Hi,

The short version: When we create a VM we see that it sends a DHCP discover directly through eth0 instead of tunneling it through GRE to our quantum-gateway. It doesn't get the right IP and hence we can not connect to it. Does anybody have an idea what we are doing wrong? Thanks!

The longer version: We have set up OpenStack Icehouse (Ubuntu 14.04) using juju charms and MAAS. The MAAS network runs on 192.168.0.0/24. We have 3 machines. One machine is running the quantum-gateway, one machine the computing node and one is running everything else (nova-cloud-controller, cinder, horizon, etc.).

All machines have eth0 connected to the MAAS network and eth5 to our public network (even though it's only the eth5 on quantum-gateway that is being used for external traffic).

We have set up one private network and one public network and connected them by a router:

> neutron net-list

| id | name | subnets |

| 18b0cba6-6616-413d-adba-4da8c5c30f9a | private | c474ca84-e534-4d93-a1ee-56c9eb1117ae 10.0.0.0/24 |

| b099d341-e3be-4e8f-a928-1ad0b373483c | public | 9e1c7663-26ca-46be-a53b-3241128a001b 10.6.0.0/16 |

> neutron subnet-list

| id | name | cidr | allocation_pools |

| 9e1c7663-26ca-46be-a53b-3241128a001b | public_subnet | 10.6.0.0/16 | {"start": "10.6.101.101", "end": "10.6.101.250"} |

| c474ca84-e534-4d93-a1ee-56c9eb1117ae | private_subnet | 10.0.0.0/24 | {"start": "10.0.0.2", "end": "10.0.0.254"} |

> neutron router-port-list 79303269-432d-48da-a31c-71055dd8345c

| id | name | mac_address | fixed_ips |

| 3b55d50e-0d1d-4d40-96db-e153edb2f367 | | fa:16:3e:76:bb:e7 | {"subnet_id": "c474ca84-e534-4d93-1ee-56c9eb1117ae", "ip_address": "10.0.0.1"} |

| 3ce4f867-9ea9-4a62-8bec-9335d3c40968 | | fa:16:3e:01:c2:b6 | {"subnet_id": "9e1c7663-26ca-46be-a53b-241128a001b", "ip_address": "10.6.101.101"} |

The router seems to work, since when we ping a floating IP allocated to our VM on the private network we see an ARP packet on VM's tap interface, which is not answered. So NAT seems to work.

On our compute node we see that the chain of bridges should be set up properly (tap.. <-> qbr.. <-> qvb.. <-> qvo.. <-> br-int <-> patch-tun <-> patch-int <-> br-tun <-> gre-..).

In /var/lib/nova/instances/98ebad44-380d-41ac-a5e4-9f6bf3b85c6d/libvirt.xml we see that the VM interface is linked to the tap device:

<interface type="bridge">

<mac address="fa:16:3e:b7:bd:bc"/>

<model type="virtio"/>

<source bridge="qbreeae80ff-a9"/>

<target dev="tapeeae80ff-a9"/>

</interface>

Our problem is that when we start a VM (image from http://cloud-images.ubuntu.com/) on the compute node it seems to send the DHCP Offer directly to eth0 (verified by tcpdump) and not to the tap interface assigned to it. The offer is then not tunneled through GRE to our quantum-gateway as we would expect it to be, but is answer by our MAAS DHCP server instead (with an IP from 192.168.0.0/24 instead of 10.0.0.0/24).

We are trying to debug it, but we are slowly running out of ideas.

Any ideas are welcome, thanks!