One more hint: The problem seems to be on the controller side. I added the
compute role to the controller/network node and booted a VM on it, and I
still can’t get an IP address from the DHCP server.
Andreas, in regards to your comment about qrxxx and qgxxx (I think you
mean qgxxx, because I don’t have a port named qqxxx), this was setup by
the openstack software, and I did not modify it. Furthermore, since these
bridges all have patches between them, shouldn’t they really act like a
single bridge? I assumed the separation was just for ease of understanding
and better organization.
I also wasn’t able to get vnc working on the compute host. I assume this
is probably because the VM doesn’t have an IP address other than the
loopback.
Tyler
On 11/18/15, 3:56 PM, "Tyler Couto" <tco...@certain.com> wrote:
>Ok, we’ve figured out that my VM is not getting an ip address. Here’s the
>dhcp part of the console.log:
>Starting network...
>udhcpc (v1.20.1) started
>Sending discover...
>Sending discover...
>Sending discover...
>Usage: /sbin/cirros-dhcpc <up|down>
>No lease, failing
>
>
>I looked at the dnsmasq logs after a VM reboot, and I also straced the
>dnsmasq process during a VM reboot. Both show that dnsmasq isn’t doing
>anything when I reboot the machine. It should be giving out an ip address
>to my VM right?
>
>I’ve read that GRE doesn’t work on kernels below 3.11, and I’m running
>CentOS 7 with 3.10, but I’ve also read otherwise.
>
>I’m trying to see if this is a problem with the GRE tunnel, but I’m
>getting very confusing results. I’ll try to explain it. I have four
>tcpdumps running.
>On the compute node I have the following:
>1. tcpdump -i br-int
>2. tcpdump -i br-tun
>3. tcpdump -i gre-mirror1 # <— This is a mirror of the gre port on br-tun
>
>On the controller/network node I have the following:
>1. tcpdump -i gre-mirror2 # <— Also a gre port mirror on br-tun of
>controller node
>
>I’ve done a few things with this setup. I’ll try to explain a couple of
>them and tell you where I see traffic.
>1. ping -I br-tun 192.168.1.1 # <— It shouldn’t matter where I send it
>right?
>- - I see identical ARP traffic on br-tun and gre-mirror1 (compute node),
>but no traffic on br-int and gre-mirror2
>- - 15:03:49.994644 ARP, Request who-has 192.168.1.1 tell
>openstack102.example.com, length 28
>2. nova reboot demo-instance1
>- - I see identical BOOTPC/BOOTPS traffic on br-int and gre-mirror2
>(controller/network node), but no traffic on br-tun or gre-mirror1
>- - 15:26:06.583855 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
>BOOTP/DHCP, Request from fa:16:3e:1d:9a:9d (oui Unknown), length 290
>
>The first test suggests that the gre tunnel is broken, and there’s
>something wrong with the patch between br-tun and br-int.
>The second test seems to show that the gre tunnel is working well.
>
>What am I missing here? Is something terribly wrong with this test?
>
>Thanks,
>Tyler
>
>On 11/17/15, 12:58 PM, "James Denton" <james.den...@rackspace.com> wrote:
>
>>Hi Tyler,
>>
>>You might try verifying that the instance properly received its IP
>>address. You can try using ‘nova console-log <id>’ to view the console
>>log of the instance. Look for the cloud-init info. Also, take a look at
>>the syslog of the network node to see if the DHCP request made it and was
>>acknowledged. If it looks like it got its IP, try hitting the instance
>>from within the DHCP or router namespace to see if you can hit the fixed
>>IP from something in the same network before trying to hit the floating
>>IP. You may also want to run some packet captures on the respective qbr
>>bridge and physical interfaces while doing these tests to see if/where
>>traffic is getting dropped.
>>
>>James
>>
>>> On Nov 17, 2015, at 11:31 AM, Tyler Couto <tco...@certain.com> wrote:
>>>
>>> Thanks Andreas. My security groups do allow icmp traffic.
>>>
>>>+---------+-------------------------------------------------------------
>>>-
>>>--
>>> ------+
>>> | name | security_group_rules
>>> |
>>>
>>>+---------+-------------------------------------------------------------
>>>-
>>>--
>>> ------+
>>> | default | egress, IPv4
>>> |
>>> | | egress, IPv6
>>> |
>>> | | ingress, IPv4, 22/tcp, remote_ip_prefix: 0.0.0.0/0
>>> |
>>> | | ingress, IPv4, icmp, remote_ip_prefix: 0.0.0.0/0
>>> |
>>> | | ingress, IPv4, remote_group_id:
>>> d404679b-aeed-4d2f-bea9-2c7d19ff3fb1 |
>>> | | ingress, IPv6, remote_group_id:
>>> d404679b-aeed-4d2f-bea9-2c7d19ff3fb1 |
>>> +---------+‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹‹+
>>>
>>> I can¹t access my VM¹s console, so I do not know whether I can ping
>>>from
>>> my VM. I figured this might be a related issue. I receive this error on
>>> when trying to access the noVNC console:
>>> Failed to connect to server (code: 1006)
>>>
>>>
>>> This is a two node setup. I have one controller/neutron-network node.
>>> Here¹s the output of 'ovs-vsctl show¹:
>>>
>>> Bridge br-tun
>>> fail_mode: secure
>>> Port "gre-ac10183d"
>>> Interface "gre-ac10183d"
>>> type: gre
>>> options: {df_default="true", in_key=flow,
>>>local_ip="172.16.24.60",
>>> out_key=flow, remote_ip="172.16.24.61"}
>>> Port gre-mirror
>>> Interface gre-mirror
>>> Port br-tun
>>> Interface br-tun
>>> type: internal
>>> Port patch-int
>>> Interface patch-int
>>> type: patch
>>> options: {peer=patch-tun}
>>> Bridge br-ex
>>> Port "enp4s0f0"
>>> Interface "enp4s0f0"
>>> Port phy-br-ex
>>> Interface phy-br-ex
>>> type: patch
>>> options: {peer=int-br-ex}
>>> Port br-ex
>>> Interface br-ex
>>> type: internal
>>> Port "enp4s0f1"
>>> Interface "enp4s0f1"
>>> Bridge br-int
>>> fail_mode: secure
>>> Port "qr-a81f0614-0e"
>>> tag: 2
>>> Interface "qr-a81f0614-0e"
>>> type: internal
>>> Port "qg-289ea4d2-29"
>>> tag: 5
>>> Interface "qg-289ea4d2-29"
>>> type: internal
>>> Port br-int
>>> Interface br-int
>>> type: internal
>>> Port patch-tun
>>> Interface patch-tun
>>> type: patch
>>> options: {peer=patch-int}
>>> Port int-br-ex
>>> Interface int-br-ex
>>> type: patch
>>> options: {peer=phy-br-ex}
>>> Port "tap468d3ee4-c0"
>>> tag: 4095
>>> Interface "tap468d3ee4-c0"
>>> type: internal
>>> ovs_version: "2.3.1"
>>>
>>>
>>> I have on compute node. Here¹s the output of 'ovs-vsctl show':
>>>
>>> Bridge br-int
>>> fail_mode: secure
>>> Port "qvoc6d01e4b-1d"
>>> tag: 1
>>> Interface "qvoc6d01e4b-1d"
>>> Port br-int
>>> Interface br-int
>>> type: internal
>>> Port patch-tun
>>> Interface patch-tun
>>> type: patch
>>> options: {peer=patch-int}
>>> Bridge br-tun
>>> fail_mode: secure
>>> Port br-tun
>>> Interface br-tun
>>> type: internal
>>> Port patch-int
>>> Interface patch-int
>>> type: patch
>>> options: {peer=patch-tun}
>>> Port "gre-ac10183c"
>>> Interface "gre-ac10183c"
>>> type: gre
>>> options: {df_default="true", in_key=flow,
>>>local_ip="172.16.24.61",
>>> out_key=flow, remote_ip="172.16.24.60"}
>>> Port gre-mirror
>>> Interface gre-mirror
>>> Port "tap0"
>>> Interface "tap0"
>>> ovs_version: "2.3.1"
>>>
>>>
>>> I also have a laptop on the same network as the openstack machines. I
>>>can
>>> successfully ping the interface of the neutron router from my laptop.
>>>
>>> As far as the physical interfaces, I am only using one physical
>>>interface
>>> on each openstack machine. I know this is not the recommended setup,
>>>but
>>> since this is only a POC, I wanted to keep it simple.
>>>
>>> -Tyler
>>>
>>>
>>>
>>> On 11/17/15, 12:48 AM, "Andreas Scheuring"
>>><scheu...@linux.vnet.ibm.com>
>>> wrote:
>>>
>>>> ease check your Security Groups first.
>>>
>>>
>>> _______________________________________________
>>> Mailing list:
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>> Post to : openstack@lists.openstack.org
>>> Unsubscribe :
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
