[openstack-dev] [neutron] Question on the OVS configuration
Dave.Chen at Dell.com
Dave.Chen at Dell.com
Fri Jun 15 09:18:31 UTC 2018
Thanks Slawomir for your reply, so what's the right configuration if I want my VM could be able to access external with physical NIC "eno2"? Do I still need add that NIC into "br-ex"?
Best Regards,
Dave Chen
-----Original Message-----
From: Slawomir Kaplonski [mailto:skaplons at redhat.com]
Sent: Friday, June 15, 2018 5:09 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Question on the OVS configuration
Hi,
If You have vxlan network than traffic from it is going via vxlan tunnel which is in br-tun bridge instead of br-ex.
> 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
More information about the OpenStack-dev
mailing list