<div dir="ltr">Thanks Dan for your answer. In my case, it seems Geneve port (6081) didn't  work (don't know why), so I change Geneve port to 6082 for temporary workaround.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 21, 2020 at 4:31 PM Dan Sneddon <<a href="mailto:dsneddon@redhat.com">dsneddon@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">You can either decrease the MTU on the overlay (encapsulated) network, or increase the MTU at all hops on the underlay network to compensate. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">For more information, see:</div><div dir="auto"><div><a href="https://docs.openstack.org/newton/networking-guide/config-mtu.html" target="_blank">https://docs.openstack.org/newton/networking-guide/config-mtu.html</a></div><br></div><div dir="auto"><br></div><div dir="auto">-Dan</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 21, 2020 at 2:16 AM Popoi Zen <<a href="mailto:alterriu@gmail.com" target="_blank">alterriu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I have Openstack cluster with following environments:<div>* 3 Controller+ 2 Compute</div><div>* Interfaces example:</div><div>bond0: provider network mapped to here using vlan </div><div>bond0.2602@bond0: interface for overlay<br>br-tun:  <a href="http://172.28.237.13/24" target="_blank">172.28.237.13/24</a> --> bond0.2602 attached to here --> this is overlay endpoint for Geneve.<br></div><div><br></div><div>On each compute node, I exec this command:</div><div><br></div><div>```</div><div>ovs-vsctl add-br br-tun<br>ovs-vsctl add-port br-tun bond0.2602<br>ip addr delete <a href="http://172.28.237.13/24" target="_blank">172.28.237.13/24</a> dev bond0.2602<br>ip addr add <a href="http://172.28.237.13/24" target="_blank">172.28.237.13/24</a> dev br-tun<br>sudo ip link set br-tun up<br></div><div>```</div><div><br></div><div>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.<br><br>It seams normal when pinging:</div><div>```<br></div><div>ubuntu@ubuntu1:~$ ping ubuntu0<br>PING ubuntu0 (192.168.5.187) 56(84) bytes of data.<br>64 bytes from ubuntu0 (192.168.5.187): icmp_seq=1 ttl=64 time=1.13 ms<br>64 bytes from ubuntu0 (192.168.5.187): icmp_seq=2 ttl=64 time=0.968 ms<br>64 bytes from ubuntu0 (192.168.5.187): icmp_seq=3 ttl=64 time=0.911 ms<br>64 bytes from ubuntu0 (192.168.5.187): icmp_seq=4 ttl=64 time=0.567 ms<br>64 bytes from ubuntu0 (192.168.5.187): icmp_seq=5 ttl=64 time=0.645 ms<br>64 bytes from ubuntu0 (192.168.5.187): icmp_seq=6 ttl=64 time=0.602 ms<br>64 bytes from ubuntu0 (192.168.5.187): icmp_seq=7 ttl=64 time=0.635 ms<br>64 bytes from ubuntu0 (192.168.5.187): icmp_seq=8 ttl=64 time=0.380 ms<br>64 bytes from ubuntu0 (192.168.5.187): icmp_seq=9 ttl=64 time=0.640 ms<br>64 bytes from ubuntu0 (192.168.5.187): icmp_seq=10 ttl=64 time=0.523 ms<br>64 bytes from ubuntu0 (192.168.5.187): icmp_seq=11 ttl=64 time=0.907 ms<br>64 bytes from ubuntu0 (192.168.5.187): icmp_seq=12 ttl=64 time=0.725 ms<br>64 bytes from ubuntu0 (192.168.5.187): icmp_seq=13 ttl=64 time=0.574 ms<br>64 bytes from ubuntu0 (192.168.5.187): icmp_seq=14 ttl=64 time=0.724 ms<br>64 bytes from ubuntu0 (192.168.5.187): icmp_seq=15 ttl=64 time=1.16 ms<br>64 bytes from ubuntu0 (192.168.5.187): icmp_seq=16 ttl=64 time=0.947 ms<br>64 bytes from ubuntu0 (192.168.5.187): icmp_seq=17 ttl=64 time=0.457 ms<br>64 bytes from ubuntu0 (192.168.5.187): icmp_seq=18 ttl=64 time=0.428 ms<br>64 bytes from ubuntu0 (192.168.5.187): icmp_seq=19 ttl=64 time=1.08 ms<br></div><div>```</div><div><br></div><div>Could someone give me some hint where to start to debug or where is the issue?</div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><br>_______________________________________________<br><br>discuss mailing list<br><br><a href="mailto:discuss@openvswitch.org" target="_blank">discuss@openvswitch.org</a><br><br><a href="https://mail.openvswitch.org/mailman/listinfo/ovs-discuss" rel="noreferrer" target="_blank">https://mail.openvswitch.org/mailman/listinfo/ovs-discuss</a><br><br></blockquote></div></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font face="monospace, monospace">Dan Sneddon         |  Senior Principal Software Engineer<br><a href="mailto:dsneddon@redhat.com" target="_blank">dsneddon@redhat.com</a> |  <a href="http://redhat.com/cloud" target="_blank">redhat.com/cloud</a><br>dsneddon:irc        |  @dxs:twitter</font><br></div></div></div></div></div></div>
</blockquote></div>