This bug was initially created as a copy of Bug #1671776 I am copying this bug because: It's also bugged in OVS 2.9 Description of problem: When two VMs each with a floating IP try to talk to each other through the floating IP address and they are located on different compute nodes, it's expected that the traffic won't go to any controller/network node. However, the traffic is pushed via the tunnel interface. On the other hand, if from the external network, we try to reach VM's FIP, traffic will be fully distributed. Expected behavior: When VM1 tries to ping VM2 FIP, all the traffic has to be directly from compute to compute and never through the tunnel interface. $ ovn-nbctl find nat type=dnat_and_snat _uuid : dc792041-9b4c-4943-9d50-537beabf974c external_ids : {"neutron:fip_external_mac"="fa:16:3e:cf:1a:33", "neutron:fip_id"="3c958c0c-ca81-4f9b-86df-024cc8470a6d", "neutron:fip_port_id"="9b8bb3bf-fab3-42ca-8db1-a428270b632e", "neutron:revision_number"="1", "neutron:router_name"="neutron-701cf876-fc3e-4958-b7af-5498199d8677"} external_ip : "172.24.4.106" external_mac : "fa:16:3e:cf:1a:33" logical_ip : "10.0.0.21" logical_port : "9b8bb3bf-fab3-42ca-8db1-a428270b632e" type : dnat_and_snat _uuid : 0c27232d-059e-40a6-b0f9-5333c938169b external_ids : {} external_ip : "172.24.4.170" external_mac : "fa:16:3e:14:2c:0e" logical_ip : "10.0.0.18" logical_port : "c2be57b3-c443-4968-b4df-4c6ed4263cb8" type : dnat_and_snat From VM1 (10.0.0.21) I ping 172.24.4.106 and I can see the traffic in the tunnel interface of the controller node: $ sudo tcpdump -i genev_sys_6081 -vvnnS not port 3784 tcpdump: listening on genev_sys_6081, link-type EN10MB (Ethernet), capture size 262144 bytes 15:42:19.374091 IP (tos 0x0, ttl 63, id 55722, offset 0, flags [DF], proto ICMP (1), length 84) 10.0.0.18 > 172.24.4.106: ICMP echo request, id 21880, seq 9, length 64 15:42:19.374711 IP (tos 0x0, ttl 62, id 2993, offset 0, flags [none], proto ICMP (1), length 84) 172.24.4.106 > 10.0.0.18: ICMP echo reply, id 21880, seq 9, length 64 Not sure if this happens in OSP13 (OVS 2.9).
verified on the latest version: can't capture icmp packet from geneve port of server.Only capture from the chassis on which vm exist. [root@hp-dl388g8-21 ~]# uname -a Linux hp-dl388g8-21.rhts.eng.pek2.redhat.com 3.10.0-1048.el7.x86_64 #1 SMP Sat May 11 16:13:21 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux [root@hp-dl388g8-21 ~]# rpm -qa | grep openvswitch openvswitch-2.9.0-106.el7fdp.x86_64 openvswitch-ovn-host-2.9.0-106.el7fdp.x86_64 openvswitch-ovn-central-2.9.0-106.el7fdp.x86_64 openvswitch-ovn-common-2.9.0-106.el7fdp.x86_64 openvswitch-selinux-extra-policy-1.0-11.el7fdp.noarch [root@hp-dl388g8-21 ~]# [root@hp-dl388g8-21 ~]# ovn-nbctl show switch 7abb9c69-2f72-4cd9-8937-8777a88abca3 (s2) port hv1_vm00_vnet1 addresses: ["00:de:ad:01:00:01 172.16.102.11"] port s2_r1 type: router addresses: ["00:de:ad:ff:01:02 172.16.102.1"] router-port: r1_s2 port hv1_vm01_vnet1 addresses: ["00:de:ad:01:01:01 172.16.102.12"] switch e0b25821-f1b6-43ac-937a-3378afd3e780 (s3) port s3_r1 type: router addresses: ["00:de:ad:ff:01:03 172.16.103.1"] router-port: r1_s3 port hv0_vm00_vnet1 addresses: ["00:de:ad:00:00:01 172.16.103.11"] port hv0_vm01_vnet1 addresses: ["00:de:ad:00:01:01 172.16.103.12"] router bfadacd4-4bd8-47b0-9e9e-2b78f8959b79 (r1) port r1_s3 mac: "00:de:ad:ff:01:03" networks: ["172.16.103.1/24"] port r1_s2 mac: "00:de:ad:ff:01:02" networks: ["172.16.102.1/24"] nat f18790cc-0fb5-4857-bdc7-ab911c9eb49f external ip: "172.16.102.200" logical ip: "172.16.103.11" type: "dnat_and_snat" [root@hp-dl388g8-21 ~]# [root@hp-dl388g8-21 ~]# ovn-sbctl show Chassis "hv0" hostname: "dell-per730-19.rhts.eng.pek2.redhat.com" Encap geneve ip: "20.0.0.26" options: {csum="true"} Port_Binding "hv0_vm01_vnet1" Port_Binding "hv0_vm00_vnet1" Chassis "hv1" hostname: "dell-per730-57.rhts.eng.pek2.redhat.com" Encap geneve ip: "20.0.0.25" options: {csum="true"} Port_Binding "hv1_vm00_vnet1" Port_Binding "hv1_vm01_vnet1" Port_Binding "cr-r1_s2" [root@hp-dl388g8-21 ~]# [root@dell-per730-19 ovn]# tcpdump -ei p4p1 -nn | grep ICMP tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on p4p1, link-type EN10MB (Ethernet), capture size 262144 bytes 22:51:53.343749 90:e2:ba:29:c0:ac > f8:f2:1e:02:c4:80, ethertype IPv4 (0x0800), length 156: 20.0.0.25.26424 > 20.0.0.26.6081: Geneve, Flags [C], vni 0x3, proto TEB (0x6558), options [8 bytes]: 00:de:ad:ff:01:03 > 00:de:ad:00:00:01, ethertype IPv4 (0x0800), length 98: 172.16.102.11 > 172.16.103.11: ICMP echo request, id 10809, seq 277, length 64 22:51:53.344010 f8:f2:1e:02:c4:80 > 90:e2:ba:29:c0:ac, ethertype IPv4 (0x0800), length 156: 20.0.0.26.13832 > 20.0.0.25.6081: Geneve, Flags [C], vni 0x1, proto TEB (0x6558), options [8 bytes]: 00:de:ad:ff:01:02 > 00:de:ad:01:00:01, ethertype IPv4 (0x0800), length 98: 172.16.103.11 > 172.16.102.11: ICMP echo reply, id 10809, seq 277, length 64 22:51:54.343799 90:e2:ba:29:c0:ac > f8:f2:1e:02:c4:80, ethertype IPv4 (0x0800), length 156: 20.0.0.25.26424 > 20.0.0.26.6081: Geneve, Flags [C], vni 0x3, proto TEB (0x6558), options [8 bytes]: 00:de:ad:ff:01:03 > 00:de:ad:00:00:01, ethertype IPv4 (0x0800), length 98: 172.16.102.11 > 172.16.103.11: ICMP echo request, id 10809, seq 278, length 64
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:1383