[ovs-discuss] Openstack VM to VM Communication so slow when using OVN+GENEVE

Dan Sneddon dsneddon at redhat.com
Mon Sep 21 09:31:20 UTC 2020


I have seen this behavior many times when the MTU is not large enough at
some point in the tunnel path for the encapsulated data plus the Geneve
header plus the VLAN tag.

You can either decrease the MTU on the overlay (encapsulated) network, or
increase the MTU at all hops on the underlay network to compensate.

Neutron has a parameter in the ml2_conf.ini file in the “[ml2]” section
named “path_mtu” which should match the lowest MTU of any hop in the path
between the tunnel endpoints. The correct MTU will be calculated and
advertised via DHCP if the “asvertise_mtu” parameter is true (default) in
the neutron.conf file.

This value may be set separately from the “global_physnet_mtu” in
neutron.conf which will set a default MTU for provider networks, as well as
the “physical_network_mtus” map in the “[ml2]” section of the ml2_conf.ini
which sets specific physical network MTUs.

For more information, see:
https://docs.openstack.org/newton/networking-guide/config-mtu.html


-Dan

On Mon, Sep 21, 2020 at 2:16 AM Popoi Zen <alterriu at gmail.com> wrote:

> I have Openstack cluster with following environments:
> * 3 Controller+ 2 Compute
> * Interfaces example:
> bond0: provider network mapped to here using vlan
> bond0.2602 at bond0: interface for overlay
> br-tun:  172.28.237.13/24 --> bond0.2602 attached to here --> this is
> overlay endpoint for Geneve.
>
> On each compute node, I exec this command:
>
> ```
> ovs-vsctl add-br br-tun
> ovs-vsctl add-port br-tun bond0.2602
> ip addr delete 172.28.237.13/24 dev bond0.2602
> ip addr add 172.28.237.13/24 dev br-tun
> sudo ip link set br-tun up
> ```
>
> I create 2 VM ubuntu0(on compute2) and ubuntu1 (on compute3) then testing
> SSH between VM using private IP. It took times ~1 minutes until login
> prompt appear.
>
> It seams normal when pinging:
> ```
> ubuntu at ubuntu1:~$ ping ubuntu0
> PING ubuntu0 (192.168.5.187) 56(84) bytes of data.
> 64 bytes from ubuntu0 (192.168.5.187): icmp_seq=1 ttl=64 time=1.13 ms
> 64 bytes from ubuntu0 (192.168.5.187): icmp_seq=2 ttl=64 time=0.968 ms
> 64 bytes from ubuntu0 (192.168.5.187): icmp_seq=3 ttl=64 time=0.911 ms
> 64 bytes from ubuntu0 (192.168.5.187): icmp_seq=4 ttl=64 time=0.567 ms
> 64 bytes from ubuntu0 (192.168.5.187): icmp_seq=5 ttl=64 time=0.645 ms
> 64 bytes from ubuntu0 (192.168.5.187): icmp_seq=6 ttl=64 time=0.602 ms
> 64 bytes from ubuntu0 (192.168.5.187): icmp_seq=7 ttl=64 time=0.635 ms
> 64 bytes from ubuntu0 (192.168.5.187): icmp_seq=8 ttl=64 time=0.380 ms
> 64 bytes from ubuntu0 (192.168.5.187): icmp_seq=9 ttl=64 time=0.640 ms
> 64 bytes from ubuntu0 (192.168.5.187): icmp_seq=10 ttl=64 time=0.523 ms
> 64 bytes from ubuntu0 (192.168.5.187): icmp_seq=11 ttl=64 time=0.907 ms
> 64 bytes from ubuntu0 (192.168.5.187): icmp_seq=12 ttl=64 time=0.725 ms
> 64 bytes from ubuntu0 (192.168.5.187): icmp_seq=13 ttl=64 time=0.574 ms
> 64 bytes from ubuntu0 (192.168.5.187): icmp_seq=14 ttl=64 time=0.724 ms
> 64 bytes from ubuntu0 (192.168.5.187): icmp_seq=15 ttl=64 time=1.16 ms
> 64 bytes from ubuntu0 (192.168.5.187): icmp_seq=16 ttl=64 time=0.947 ms
> 64 bytes from ubuntu0 (192.168.5.187): icmp_seq=17 ttl=64 time=0.457 ms
> 64 bytes from ubuntu0 (192.168.5.187): icmp_seq=18 ttl=64 time=0.428 ms
> 64 bytes from ubuntu0 (192.168.5.187): icmp_seq=19 ttl=64 time=1.08 ms
> ```
>
> Could someone give me some hint where to start to debug or where is the
> issue?
>
>
>
>
>
>
> _______________________________________________
>
> discuss mailing list
>
> discuss at openvswitch.org
>
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
> --
Dan Sneddon         |  Senior Principal Software Engineer
dsneddon at redhat.com |  redhat.com/cloud
dsneddon:irc        |  @dxs:twitter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20200921/0bbb6514/attachment.html>


More information about the discuss mailing list