Missing veth pair bond and wrong/superfluous physical interface? [closed]

asked 2015-08-21 12:22:49 -0500

bnordgren gravatar image

Problem: most of the Linux virtual networking stuff (ovs, brctl, veth, etc.) is new to me and I'm attempting to come up to speed on a broken Openstack deployment. I describe the situation and ask two questions regarding what the tools are telling me about my setup.

Background: My 5 compute, 1 controller, neutron/OVS/VXLAN Openstack Kilo RDO cluster installed via packstack is misbehaving such that VMs can ping each other and the router (and the router's external interface), but there is no communication either out or in. This setup used to work fine and I was content to not learn openstack networking, but the controller went down and I reinstalled a new one using the same answer file. Now it's broken.

Environment: As far as I can tell, packstack set up networking on the compute node similar to the diagram on the OpenVSwitch Under the hood page, but there's two OVS bridges, br-tun (tenant network tunnels) and br-ex (connection to the external network) :

depiction of openstack networking on a compute node

My understanding is that the VM's eth0 is represented as a tap device connected to one side of a veth pair via a brctl bridge. The other side of the veth pair sits on an OVS bridge (br-int) which has another veth endpoint connecting to two other OVS bridges, br-tun provides access to vxlan tunnels internal to the cluster, and br-ex seems to be trying to provide access to a physical interface named "enp2s0".

Question #1: My first problem is that there is no enp2s0 interface on this compute node. The head node has an enp2s0, but this compute node has eno[134] and "ten" for tenant. This may be moot because: 1] it worked previously; and 2] enp2s0 was the interface connected to the external network on the original controller, no compute node ever had direct access to the external network. So the first question is: Does br-ex need to exist at all on the compute node, and if so, why?

Question #2: My next problem is that I can't see how my qvb* is connected to my qvo. My qvo has no peer listed. Since I'm able to ping the router on my controller and there is no other path to/from the VM, clearly it is connected, I just can't see it. OTOH, the router does not route between "external" and "tenant" networks. My second question is: How can I get the computer to show me that qvb* is connected to qvo*?

[root@compute-0-4 ~]# ovs-vsctl show
f5e60ebf-8d37-4320-9ac5-8bddec6d45d7
    Bridge br-int
        fail_mode: secure
        Port int-br-ex
            Interface int-br-ex
                type: patch
                options: {peer=phy-br-ex}
        Port "qvo883f4fa1-e2"
            tag: 1
            Interface "qvo883f4fa1-e2"
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port br-int
            Interface br-int
                type: internal

[root@compute-0-4 ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
qbr883f4fa1-e2          8000.aab6dfcaf909       no              qvb883f4fa1-e2
                                                        tap883f4fa1-e2

[root@compute-0-4 ~]# ip a show qvb883f4fa1-e2
15: qvb883f4fa1-e2: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master qbr883f4fa1-e2 state UP qlen 1000
    link/ether aa ...
(more)
edit retag flag offensive reopen merge delete

Closed for the following reason question is not relevant or outdated by rbowen
close date 2016-06-21 13:49:18.706439

Comments

The linked image is not loading.

rbowen gravatar imagerbowen ( 2015-10-14 15:36:16 -0500 )edit

Kilo is now EOL, and the above image is not loading. Closing "outdated", but please reopen with new information if this is still a problem. Thanks.

rbowen gravatar imagerbowen ( 2016-06-21 13:49:12 -0500 )edit