Ask Your Question

rrolim's profile - activity

2019-05-02 07:42:13 -0500 received badge  Notable Question (source)
2019-05-02 07:42:13 -0500 received badge  Famous Question (source)
2019-05-02 07:42:13 -0500 received badge  Popular Question (source)
2015-01-22 07:01:46 -0500 received badge  Famous Question (source)
2014-10-31 08:02:32 -0500 received badge  Notable Question (source)
2014-08-07 21:25:45 -0500 received badge  Popular Question (source)
2013-06-03 12:20:23 -0500 answered a question Open vSwitch not forwarding tagged frames

I was using vconfig to create a vlan-device for VLAN 212 since apparently the network interface driver was stripping inbound 802.1Q tags. Once I had bond2.212 created I could see tagged frames, which were expected by my br-int bridge. However, as I mentioned above, for some reason openswitch didn't allow these frames through. What I did was remove the vlan-device for VLAN 212 and added a new one for an unused VLAN (in my case VLAN 4094). This new virtual interface device and the absence of the previous one immediately allowed tagged frames through openvswitch. This is very weird to me as frames were already being correctly tagged by the vlan-device created by vconfig before. As a side node, bond2.4094 doesn't even needed to be up.

2013-05-29 22:40:21 -0500 asked a question Open vSwitch not forwarding tagged frames

Hi,

while setting up a VLAN network I ran across an issue with an Open vSwitch bridge that refuses to forward tagged frames. Untagged traffic flows as expected, though. As can be observed in the following output, br-data is the bridge I defined to connect VMs betweens hosts and bond2 is the (bonded) physical interface that carries VM traffic in their own VLANs.

http://paste.openstack.org/show/37883/

The problem is that tagged traffic that comes from bond2 -- ARP requests on VLAN 212 -- don't get to phy-br-data where it could be forwarded to the virtual router on brigde br-int. This doesn't affect untagged traffic -- the IGMP queries in the sample. Is this expected behavior or is there something I can do about it?

I copy it here for easy reference: Bridge br-data Port phy-br-data Interface phy-br-data Port br-data Interface br-data type: internal Port "bond2" Interface "bond2"

Thanks

2012-12-13 15:00:26 -0500 answered a question Quantum overlapping IPs recommended procedure

Thanks a lot, yong. Some related questions:

  • Does the nova-api-metadata service should be stopped on the compute nodes, as well? It this its only purpose?
  • Should I set 'enabled_apis=' (blank) in nova.conf on the compute node?
  • My VMs take an extremely long time to boot while they look for the metadata service, because of cloud-init. Is this normal?
  • And mainly, if I disable the metadata service, as the manual suggests, how am I supposed to configure the virtual machines? Manually, I'm affraid?

Regards

2012-12-13 09:24:13 -0500 answered a question Gateway addresses for subnets are one off.

Sorry, I didn't see you're using the docs.openstack.org/folsom/basic-install/content/basic-install_intro.html guide where namespaces are disabled. That's why you don't see anything with 'ip netns'. So if you don't see the router's gateway interface IP in the network (.1), did you add an interface in the router for that network (quantum router-interface-add)?

2012-12-12 22:33:06 -0500 asked a question Quantum overlapping IPs recommended procedure

The limitations chapter of the Quantum administration manual (chapter 10), says that "If you enable [allow_overlapping_ips], you must disable both Nova security groups and the Nova metadata service." How do I do that?

One thing I noticed when I enabled overlapping IPs is that during booting my VMs would get stuck a very long time waiting for a response from the metadata server. When I disable overlapping IP, I still cannot connect to the metadata server, but each of the 30 iterations the VM goes through trying to reach the server goes by way faster.

2012-12-12 14:25:50 -0500 answered a question Gateway addresses for subnets are one off.

It surely will. By default Quantum uses namespaces, so that each tenant runs in a separated namespace with their own network interfaces, IP addresses, routing tables, iptables rules, etc. You're not seeing your gateway interface because your looking for it in the initial namespace, where commands run if not explictly specified:

Run 'ip netns' and will see a list of your namespaces, for example qdhcp-5ceadbb9-33d0-4080-83fd-066f9e672d8e qrouter-9839d33c-cda7-4509-b93d-52cc55a3a174

The qrouter-* namespace corresponds to each router that you have, where the hexadecimal string corresponds to the id of the router (quantum router-list). There you'll find the router's external network IP address if any configured and the router's interface in that network (acting as the gateway). Example:

ip netns exec qrouter-9839d33c-cda7-4509-b93d-52cc55a3a174 ifconfig

(...) qg-01f0ca8d-a7 Link encap:Ethernet HWaddr fa:16:3e:bf:a7:b8
inet addr:192.168.100.225 Bcast:192.168.100.255 Mask:255.255.255.0 (...) qr-56c3fa8b-63 Link encap:Ethernet HWaddr fa:16:3e:85:0c:85
inet addr:10.5.5.1 Bcast:10.5.5.255 Mask:255.255.255.0 (...)

qr-* is the gateway you're looking for and qg-* is my router's external network interface. The string is port id of the router.

The same command 'ip netns exec <namespace>' can be used with all other ordinary network tools like 'iptables, route, netstat, tcpdump, ping, ifup/down, ip *, etc. That's how Linux makes it possible for overlapping IPs, since each network namespace is an isolated environment (virtualization at the OS level).

Hope that helps.

2012-12-10 12:33:08 -0500 answered a question Gateway addresses for subnets are one off.

Hi, Doug. The second IP address (.2 in this case) is used by the DHCP agent. If you list your running processes and look for dnsmasq you'll see a command line option --interface=tap882a8e75-ee for one agent and --interface=tap3680cb06-ab for the other. If you use namespaces, the DHCP agent will also have its own namespace qdhcp-*.

2012-12-09 17:30:23 -0500 answered a question No access between provider and tenant networks

I've solved the problem. It turns out that my virtualization software was silently ignoring my guest OS request to set the virtual NIC in promiscuous mode. Other computers in the external network couldn't reach the virtual router's gateway port or floating IPs because the external interface (eth0), not being in promiscuous mode, was not accepting packets to other MAC addresses and hence the bridge was not taking traffic to all attached interfaces.

Reading about network namespaces on the lxc site e trying out their step-by-step configuration with ethernet bridges ( http://lxc.sourceforge.net/index.php/about/kernel-namespaces/network/configuration/ (http://lxc.sourceforge.net/index.php/...) ) I noticed that the behavior I was observing was not the expected result. Even without any OpenStack component installed, I couldn't ping other computers on the external network from a secondary namespace and, conversely, couldn't ping an interface in this secondary namespace from another computer but only the bridge IP address. Exactly the same problem I was having with my OpenStack setup.

The bottom line is that if you can't access interfaces in different namespaces from different computers you should check if your virtualization software is configured to allow promiscuous mode on that VM. Since so many people try out OpenStack on virtual machines it's a bit surpring not to see such remark on any installation guide. I bet others have run into the same kind of problem. Anyway now I understand the basics of how Quantum works with namespaces and hope this little tip can save others the same troubles I met.

2012-12-07 17:49:34 -0500 asked a question No access between provider and tenant networks

Hi,

I've installed Openstack in a controller/compute two node structure according to Emilien Macchi's Folsom install guide ( http://docs.openstack.org/folsom/basic-install/content (http://docs.openstack.org/folsom/basi...) ) and later changed the configuration to use namespaces. Most things seem fine, except that from a computer on the external network I'm unable to ping either the router's external network interface on the controller node or the floating IP that should lead me to the VMs on the internal (tenant) network. The same holds true in the opposite direction: VMs cannot ping any computers on the external (provider) network.

On the controller node I have eth0 bridged to the external network: br-ex has IP address 192.168.100.224/24 and eth0 has no IP. My virtual router's interface on this network is 192.168.100.225 and the provider network gateway is 192.168.100.254. There's also a floating IP configured as 192.168.100.226, connecting to a VM out of 10.5.5.3/24.

From another computer I can ping 192.168.100.224 (br-ex), but not the floating IP or the router's gateway interface (192.168.100.225). Secgroup rules have been added but didn't help.

From the controller node itself, I can ping any of these external network addresses when I don't use a namespace name. When I'm in the qrouter- namespace, I can ping all IP addresses that belong to the controller's external network as well, but cannot access any other computer in the external network. Also, I can ping VMs if I'm in the dhcp- namespace.

From a VM's perspective, I can ping any IP address on the controller external network (.224, .225 and .226), but nothing on another host (the external network gateway, for instance). VMs can ping each other.

I've pasted quite a lot of output about my setup here so that I could be as clear as possible: http://paste.openstack.org/show/27583/

If anyone could help me on this issue I would be grateful. I've spent an awful lot of time for the past several days trying to figure out what could be wrong with this interconnection problem, but couldn't find anything that would solve it. Any direction on this matter will be much appreciated. Thanks.