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

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1623529

Summary:	ovn-trace: ct_lb action not implemented
Product:	Red Hat Enterprise Linux 7	Reporter:	Dan Williams <dcbw>
Component:	openvswitch	Assignee:	lorenzo bianconi <lorenzo.bianconi>
Status:	CLOSED ERRATA	QA Contact:	haidong li <haili>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.6	CC:	atelang, atragler, ctrautma, fleitner, haili, kfida, lorenzo.bianconi, ovs-qe, qding, zzhao
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openvswitch-2.9.0-73.el7fdn	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1635344 (view as bug list)		Environment:
Last Closed:	2019-01-02 17:54:40 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1635344

Description Dan Williams 2018-08-29 14:39:25 UTC

[root@openshift-node-2 /]# ovn-trace --db=tcp:172.17.0.2:6642 5c948d6d-5f85-422c-82d5-a949913b06ff 'inport=="default_nginx1" && eth.dst == 00:00:00:4c:72:3e && eth.src == 0a:00:00:00:00:01 && ip4.dst == 4.2.2.1 && ip4.src == 10.128.2.3'
# ip,reg14=0x3,vlan_tci=0x0000,dl_src=0a:00:00:00:00:01,dl_dst=00:00:00:4c:72:3e,nw_src=10.128.2.3,nw_dst=4.2.2.1,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0

ingress(dp="openshift-node-2", inport="default_nginx1")
-------------------------------------------------------
 0. ls_in_port_sec_l2 (ovn-northd.c:3556): inport == "default_nginx1", priority 50, uuid b72644d2
    next;
 3. ls_in_pre_acl (ovn-northd.c:2882): ip, priority 100, uuid 98f44a34
    reg0[0] = 1;
    next;
 5. ls_in_pre_stateful (ovn-northd.c:3016): reg0[0] == 1, priority 100, uuid 18a398ee
    ct_next;

ct_next(ct_state=est|trk /* default (use --ct to customize) */)
---------------------------------------------------------------
 8. ls_in_lb (ovn-northd.c:3401): ct.est && !ct.rel && !ct.new && !ct.inv, priority 65535, uuid 74b85991
    reg0[2] = 1;
    next;
 9. ls_in_stateful (ovn-northd.c:3433): reg0[2] == 1, priority 100, uuid f756bd25
    ct_lb;
    *** ct_lb action not implemented

Comment 2 Dan Williams 2018-08-29 14:40:35 UTC

Makes it kinda hard to debug issues with ovn-kubernetes since it uses a couple of LBs here and there in the datapath for almost all containers.

Comment 4 haidong li 2018-11-25 12:19:26 UTC

I have tested on the latest version,and get some info here.But there is nothing displayed under ct_lb datapath,is it expected?

[root@dell-per730-42 ovn]# uname -a
Linux dell-per730-42.rhts.eng.pek2.redhat.com 3.10.0-957.el7.x86_64 #1 SMP Thu Oct 4 20:48:51 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[root@dell-per730-42 ovn]# rpm -qa | grep openvswitch
openvswitch2.10-ovn-host-2.10.0-28.el7fdp.x86_64
openvswitch2.10-2.10.0-28.el7fdp.x86_64
openvswitch2.10-ovn-central-2.10.0-28.el7fdp.x86_64
openvswitch-selinux-extra-policy-1.0-8.el7fdp.noarch
openvswitch2.10-ovn-common-2.10.0-28.el7fdp.x86_64
kernel-kernel-networking-openvswitch-ovn-1.0-108.noarch
[root@dell-per730-42 ovn]#
[root@dell-per730-42 ovn]# ovn-nbctl show
switch 91ca2013-b8ea-4a2a-9320-c897258c5179 (s2)
    port hv1_vm01_vnet1
        addresses: ["00:de:ad:01:01:01 172.16.102.12 2001:db8:102::12"]
    port hv1_vm00_vnet1
        addresses: ["00:de:ad:01:00:01 172.16.102.11 2001:db8:102::11"]
    port s2_r1
        type: router
        addresses: ["00:de:ad:ff:01:02 172.16.102.1 2001:db8:102::1"]
        router-port: r1_s2
switch 55b5dfb3-4dad-42cf-8e3c-343d05d2337c (s3)
    port hv0_vm00_vnet1
        addresses: ["00:de:ad:00:00:01 172.16.103.11 2001:db8:103::11"]
    port s3_r1
        type: router
        addresses: ["00:de:ad:ff:01:03 172.16.103.1 2001:db8:103::1"]
        router-port: r1_s3
    port hv0_vm01_vnet1
        addresses: ["00:de:ad:00:01:01 172.16.103.12 2001:db8:103::12"]
router 2f1fd078-951b-4863-a3d4-f1eb489cfad4 (r1)
    port r1_s2
        mac: "00:de:ad:ff:01:02"
        networks: ["172.16.102.1/24", "2001:db8:102::1/64"]
    port r1_s3
        mac: "00:de:ad:ff:01:03"
        networks: ["172.16.103.1/24", "2001:db8:103::1/64"]
[root@dell-per730-42 ovn]# 
[root@dell-per730-42 ovn]# ovn-trace --detail  s2  'inport == "hv1_vm00_vnet1" &&  ip4.dst == 30.0.0.2 && ip4.src == 172.16.102.11' 
# ip,reg14=0x2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,nw_src=172.16.102.11,nw_dst=30.0.0.2,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0

ingress(dp="s2", inport="hv1_vm00_vnet1")
-----------------------------------------
 0. ls_in_port_sec_l2 (ovn-northd.c:4080): inport == "hv1_vm00_vnet1", priority 50, uuid 1d044f9f
    next;
 4. ls_in_pre_lb (ovn-northd.c:3316): ip && ip4.dst == 30.0.0.2, priority 100, uuid 25462170
    reg0[0] = 1;
    next;
 5. ls_in_pre_stateful (ovn-northd.c:3339): reg0[0] == 1, priority 100, uuid c77b1b03
    ct_next;

ct_next(ct_state=est|trk /* default (use --ct to customize) */)
---------------------------------------------------------------
 9. ls_in_lb (ovn-northd.c:3918): ct.est && !ct.rel && !ct.new && !ct.inv, priority 65535, uuid ee8156ff
    reg0[2] = 1;
    next;
10. ls_in_stateful (ovn-northd.c:3950): reg0[2] == 1, priority 100, uuid adfd6e44
    ct_lb;

ct_lb
-----
16. ls_in_l2_lkup: no match (implicit drop)

Comment 5 haidong li 2018-11-26 11:32:52 UTC

verified after add --ct=new:
[root@dell-per730-42 ovn]# ovn-trace --ct=new --detail  s2  'inport == "hv1_vm00_vnet1" &&  ip4.dst == 30.0.0.2 && ip4.src == 172.16.102.11 && tcp.dst == 8000' 
# tcp,reg14=0x2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,nw_src=172.16.102.11,nw_dst=30.0.0.2,nw_tos=0,nw_ecn=0,nw_ttl=0,tp_src=0,tp_dst=8000,tcp_flags=0

ingress(dp="s2", inport="hv1_vm00_vnet1")
-----------------------------------------
 0. ls_in_port_sec_l2 (ovn-northd.c:4080): inport == "hv1_vm00_vnet1", priority 50, uuid f5487e7a
    next;
 4. ls_in_pre_lb (ovn-northd.c:3316): ip && ip4.dst == 30.0.0.2, priority 100, uuid dccc1f18
    reg0[0] = 1;
    next;
 5. ls_in_pre_stateful (ovn-northd.c:3339): reg0[0] == 1, priority 100, uuid dfc9d91c
    ct_next;

ct_next(ct_state=new|trk)
-------------------------
10. ls_in_stateful (ovn-northd.c:3991): ct.new && ip4.dst == 30.0.0.2 && tcp.dst == 8000, priority 120, uuid 44f01d6a
    ct_lb(172.16.103.11:80, 172.16.103.12:80);

ct_lb
-----
16. ls_in_l2_lkup: no match (implicit drop)
[root@dell-per730-42 ovn]#

Comment 7 errata-xmlrpc 2019-01-02 17:54:40 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:0014