geir's profile - activity

2015-02-24 04:36:32 -0500 received badge  Nice Answer (source)
2014-10-22 00:03:17 -0500 commented question Instances don't get an IP address assigned

The ovs-vsctl show command on your network node reveals that the tap interface used for the dhcp is tagged to vlan 4095. I believe that this is how OVS sets a port "dead". This means that OVS drop all packets leaving the tap interface. Might be something to check.

2014-09-30 02:45:22 -0500 received badge  Teacher (source)
2014-09-30 02:45:22 -0500 received badge  Self-Learner (source)
2014-09-22 21:23:32 -0500 received badge  Famous Question (source)
2014-09-21 06:31:13 -0500 received badge  Notable Question (source)
2014-09-21 02:50:00 -0500 answered a question VM's can't get DHCP

Forgot to update this, but my problem was solved when I found out that my physical interface used with the VM-configuration network was down. Simply running ifup interface, where interface refers to the particular interface, solved it. I configured my ifcfg file to start the interface at boot time, adding the ONBOOT=YES parameter.

2014-09-21 02:31:32 -0500 answered a question Problem with neutron-openvswitch-agent on Compute Node


This is what I would've done.

  1. Since your virtual instances actually lives and sends DHCP discovers, do some tcpdumps on the different interfaces on the compute node to find out how far your discovers go.
  2. If the discovers go out from your compute node, then do some tcpdumps on the network node to see where the discovers end up there.

I've had similar problems as well, and the problem for me was simply the physical interface on the VM-configuration network was down. So, check your interfaces with; ip a. If the interface used in the VM-config network is down, try ifup int where int refers to the particular interface. If this solves it for you, then you can have the interface to be started at boot time so you don't have to run this command every time. I believe you run some Fedora OS? In my case, I ran CentOS, so I added the parameter ONBOOT=YES in my /etc/sysconfig/network-scripts/ifcfg-ethX file

2014-09-14 08:49:01 -0500 received badge  Popular Question (source)
2014-09-08 02:51:56 -0500 edited question VM's can't get DHCP


I'm running an openstack multinode configuration (3 compute nodes), IceHouse, CentOS 6.5. I use flat networking with VLAN tagging.

When I boot up and instance, it does not get any DHCP from the network node.

I've set the VLAN range to be from 1401 to 1403, but when I boot up and instance and do this on the compute node; cat /var/log/neutron/openvswitch-agent.log | grep "tag=" I can only see networks tagged for VLAN 1 og 2.

When I do; tail -f /var/log/neutron/openvswitch-agent.log I get this message constantly popping up;

014-09-08 09:41:24.035 7085 DEBUG neutron.agent.linux.utils [req-591a544b-4608-4b38-8dc9-b98359f7a5df None] Running command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ovs-ofctl', 'dump-flows', 'br-int', 'table=22'] create_process /usr/lib/python2.6/site-packages/neutron/agent/linux/
2014-09-08 09:41:24.092 7085 DEBUG neutron.agent.linux.utils [req-591a544b-4608-4b38-8dc9-b98359f7a5df None] 
Command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ovs-ofctl', 'dump-flows', 'br-int', 'table=22']
Exit code: 0
Stdout: 'NXST_FLOW reply (xid=0x4):\n cookie=0x0, duration=1119.772s, table=22, n_packets=0, n_bytes=0, idle_age=1119, priority=0 actions=drop\n'
Stderr: '' execute /usr/lib/python2.6/site-packages/neutron/agent/linux/
2014-09-08 09:41:24.093 7085 DEBUG neutron.plugins.openvswitch.agent.ovs_neutron_agent [req-591a544b-4608-4b38-8dc9-b98359f7a5df None] Agent rpc_loop - iteration:559 completed. Processed ports statistics: {'ancillary': {'removed': 0, 'added': 0}, 'regular': {'updated': 0, 'added': 0, 'removed': 0}}. Elapsed:0.058 rpc_loop /usr/lib/python2.6/site-packages/neutron/plugins/openvswitch/agent/

The same message is popping up on the compute nodes hosting virtual machines.

The control-flows on the network node seems ok as well(?);

[root@network ~]# ovs-ofctl dump-flows br-int
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=1265.329s, table=0, n_packets=0, n_bytes=0, idle_age=1265, priority=3,in_port=5,dl_vlan=1401 actions=mod_vlan_vid:1,NORMAL
 cookie=0x0, duration=1266.638s, table=0, n_packets=6, n_bytes=468, idle_age=1256, priority=2,in_port=5 actions=drop
 cookie=0x0, duration=1267.577s, table=0, n_packets=6, n_bytes=252, idle_age=997, priority=1 actions=NORMAL
 cookie=0x0, duration=1267.519s, table=22, n_packets=0, n_bytes=0, idle_age=1267, priority=0 actions=drop

[root@network ~]# ovs-ofctl dump-flows br-eth1
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=1358.995s, table=0, n_packets=0, n_bytes=0, idle_age=1358, priority=4,in_port=4,dl_vlan=1 actions=mod_vlan_vid:1401,NORMAL
 cookie=0x0, duration=1360.185s, table=0, n_packets=12, n_bytes=724, idle_age=1091, priority=2,in_port=4 actions=drop
 cookie=0x0, duration=1360.919s, table=0, n_packets=46, n_bytes=8142, idle_age=9, priority=1 actions=NORMAL

And on one of the compute nodes hosting a virtual machine;

[root@compute1 ~]# ovs-ofctl dump-flows br-int
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=1443.474s, table=0, n_packets=0, n_bytes=0, idle_age=1443, priority=3,in_port=7,dl_vlan=1401 actions=mod_vlan_vid:1,NORMAL
 cookie=0x0, duration=1445.137s, table=0, n_packets=6, n_bytes=468, idle_age=1435, priority=2,in_port=7 actions=drop
 cookie=0x0, duration=1446.381s, table=0, n_packets=0 ...
2014-09-08 02:51:56 -0500 received badge  Editor (source)