Open Stack

Hi All,

Let me brief my question, I have two NIC ports, one is connect to internal (eno1) and the other (eno2) is external, my openstack cluster is based on the devstack and neutron is configured as OVS + vxlan, How can I make my VM could be able to access external with eno2 port?

I tried to add the port to br-ex but it seems doesn't work, the VM still  go to the default route on the physical node which is via eno1.

$ ovs-vsctl add-port br-ex eno2


Thanks in the advance for any comments!


Best Regards,
Dave Chen

From: Chen2, Dave
Sent: Friday, June 15, 2018 4:17 PM
To: 'openstack-dev at lists.openstack.org'
Cc: Chen2, Dave
Subject: [neutron] Question on the OVS configuration

Dear folks,

I have setup a pretty simple OpenStack cluster in our lab based on devstack, couples of guest VM are running on one controller node (this doesn't looks like a right behavior anyway),  the Neutron network is configured as OVS + vxlan, the bridge "br-ex" configured as below:

    Bridge br-ex
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port phy-br-ex
            Interface phy-br-ex
                type: patch
                options: {peer=int-br-ex}
        Port br-ex
            Interface br-ex
                type: internal
ovs_version: "2.8.0"



As you see, there is no external physical NIC bound to "br-ex", so I guess the traffic from the VM to external will use the default route set on the controller node,  since there is a NIC (eno2) that can access external so I bind it to "br-ex" like this: ovs-vsctl add-port br-ex eno2. now the "br-ex" is configured as below:

    Bridge br-ex
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port phy-br-ex
            Interface phy-br-ex
                type: patch
                options: {peer=int-br-ex}
        *Port "eno2"*
            Interface "eno2"
        Port br-ex
            Interface br-ex
                type: internal
    ovs_version: "2.8.0"



Looks like this is how it should be configured according to lots of wiki/blog suggestion I have googled, but it doesn't work as expected, ping from the VM, the tcpdump shows the traffic still go the "eno1" which is the default route on the controller node.

Inside of VM
ubuntu at test-br:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=38 time=168 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=38 time=168 ms
...

Dump the traffic on the "eno2", got nothing
$ sudo tcpdump -nn -i eno2 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno2, link-type EN10MB (Ethernet), capture size 262144 bytes
...

Dump the traffic on the "eno1" (internal NIC),  catch it!
$ sudo tcpdump -nn -i eno1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
16:08:59.609888 IP 192.168.20.132 > 8.8.8.8: ICMP echo request, id 1439, seq 1, length 64
16:08:59.781042 IP 8.8.8.8 > 192.168.20.132: ICMP echo reply, id 1439, seq 1, length 64
16:09:00.611453 IP 192.168.20.132 > 8.8.8.8: ICMP echo request, id 1439, seq 2, length 64
16:09:00.779550 IP 8.8.8.8 > 192.168.20.132: ICMP echo reply, id 1439, seq 2, length 64


$ sudo ip route
default via 192.168.18.1 dev eno1  proto static  metric 100
default via 192.168.8.1 dev eno2  proto static  metric 101
169.254.0.0/16 dev docker0  scope link  metric 1000 linkdown
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 linkdown
192.168.8.0/24 dev eno2  proto kernel  scope link  src 192.168.8.101  metric 100
192.168.16.0/21 dev eno1  proto kernel  scope link  src 192.168.20.132  metric 100
192.168.42.0/24 dev br-ex  proto kernel  scope link  src 192.168.42.1


What's going wrong here? Do I miss something? Or some service need to be restarted?

Anyone could help me out?  This question made me sick for many days!  Huge thanks in the advance!


Best Regards,
Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20180615/d037c15c/attachment.html>