Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

The FDP team is no longer accepting new bugs in Bugzilla. Please report your issues under FDP project in Jira. Thanks.

Bug 1704869

Summary:	[OVN] Traffic is not distributed from VM1 FIP to VM2 FIP even if DVR is enabled
Product:	Red Hat Enterprise Linux Fast Datapath	Reporter:	Timothy Redaelli <tredaelli>
Component:	openvswitch	Assignee:	lorenzo bianconi <lorenzo.bianconi>
openvswitch sub component:	other	QA Contact:	haidong li <haili>
Status:	CLOSED ERRATA	Docs Contact:
Severity:	unspecified
Priority:	unspecified	CC:	atragler, ctrautma, kfida, pvauter, qding, yinxu
Version:	FDP 18.11
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openvswitch-2.9.0-106.el7fdn	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-06-05 14:57:30 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Timothy Redaelli 2019-04-30 17:20:55 UTC

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).

Comment 2 haidong li 2019-05-29 02:53:35 UTC

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

Comment 4 errata-xmlrpc 2019-06-05 14:57:30 UTC

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