Open Stack

Sure, I will. I just think neutron guys should know this better.

Best Regards,
Dave Chen

-----Original Message-----
From: Slawomir Kaplonski [mailto:skaplons at redhat.com] 
Sent: Friday, June 15, 2018 5:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Question on the OVS configuration

Also, I think that You should sent such emails to openstack at lists.openstack.org or openstack-operators at lists.openstack.org in the future :)

> Wiadomość napisana przez Dave.Chen at Dell.com w dniu 15.06.2018, o godz. 10:17:
> 
> 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
>  
> ______________________________________________________________________
> ____ OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

—
Slawek Kaplonski
Senior software engineer
Red Hat


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev