Open Stack

1. Check brctl showmacs br100
If you see the mac address of the vnic of VM by lggiing into VM - do ifconfig to compare the mac address.

2. Then check Firwall configs in both Host and VM. Check stopping FW service and doing iptables -F.

3. Do tcpdump -i -e vnet0  while sening ping to the GW from VM.

Those would give you some clue to what's going on.

-Arindam


-----Original Message-----
From: Dimitri Maziuk [mailto:dmaziuk at bmrb.wisc.edu] 
Sent: Wednesday, January 15, 2014 1:30 PM
To: openstack at lists.openstack.org
Subject: Re: [Openstack] CentOS Network Create problem

On 01/15/2014 08:23 AM, Georgios Dimitrakakis wrote:
> Hi again...Long day with OpenStack today...
> 
> It seems that the problem with the br100 interface has been solved 
> partially since I can launch an instance but I am not able to ssh nor 
> ping the machine (although I have configured the security group rules).

Here's what I have on a working node with 2 instances running. Ignore virbr0, it's created by libvirt, vnet0 & 1 are the openstack instances:

# brctl show
bridge name     bridge id               STP enabled     interfaces
br100           8000.003048c53032       no              eth0
                                                        vnet0
                                                        vnet1
virbr0          8000.52540025455f       yes             virbr0-nic

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:30:48:c5:30:32 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::230:48ff:fec5:3032/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:30:48:c5:30:33 brd ff:ff:ff:ff:ff:ff
4: br100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:30:48:c5:30:32 brd ff:ff:ff:ff:ff:ff
    inet X.X.X.X/25 brd X.X.X.X scope global br100
    inet6 fe80::230:48ff:fec5:3032/64 scope link
       valid_lft forever preferred_lft forever
5: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 52:54:00:25:45:5f brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
    link/ether 52:54:00:25:45:5f brd ff:ff:ff:ff:ff:ff
10: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether fe:16:3e:48:30:5c brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc16:3eff:fe48:305c/64 scope link
       valid_lft forever preferred_lft forever
38: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether fe:16:3e:16:b3:55 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc16:3eff:fe16:b355/64 scope link
       valid_lft forever preferred_lft forever

# lsmod | grep _net
vhost_net              30520  2
macvtap                 9980  1 vhost_net
tun                    17095  6 vhost_net

("modprobe vhost_net" if you don't have it.)

# route -n
Kernel IP routing table
Destination   Gateway      Genmask         Flags Metric Ref  Use Iface
X.X.X.X       0.0.0.0      255.255.255.128 U     0      0    0   br100
192.168.122.0 0.0.0.0      255.255.255.0   U     0      0    0   virbr0
169.254.0.0   0.0.0.0      255.255.0.0     U     1004   0    0   br100
0.0.0.0       X.X.X.X      0.0.0.0         UG    0      0    0   br100

You should have a route to your nova network in there (I use flat network so my nova net is X.X.X.X, same as my "real" subnet).

With all that in place try disabling iptables in the instance and pinging the host. On the host, run tcpdump on vnet0 and br100 to see if you get any traffic. I didn't initially, I think modprobe vhost_net was what fixed it. (I was poking at & restarting several things at once, so I'm not 100% sure exactly which of them did it.)

--
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu