Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1605121 - [3.10][SslccZYc][ha-egressip] Should not check the table=100 for the out packets count
Summary: [3.10][SslccZYc][ha-egressip] Should not check the table=100 for the out pack...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 3.10.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 3.10.z
Assignee: Casey Callendrello
QA Contact: Meng Bo
URL:
Whiteboard:
Depends On: 1605079
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-20 08:42 UTC by Meng Bo
Modified: 2018-07-20 13:01 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1605079
Environment:
Last Closed: 2018-07-20 13:01:30 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Meng Bo 2018-07-20 08:42:32 UTC
+++ This bug was initially created as a clone of Bug #1605079 +++

Description of problem:
For the new ha egress IP feature, it is watching table=100 with keywords "set_field" and "->tun_dst" for counting the out packets
https://github.com/openshift/origin/blob/master/pkg/network/node/vxlan_monitor.go#L133

But there is no such flow in table=100 which will cause that the out packet will always be 0.

Version-Release number of selected component (if applicable):
v3.11.0-0.7.0

How reproducible:
always

Steps to Reproduce:
1. Setup OCP cluster with multitenant or networkpolicy plugin
2. Check the openflow on the ovs pod
# docker exec 6a8d293c9c2e ovs-ofctl dump-flows br0 -O openflow13 | awk '/set_field/ && /tun_dst/'
 cookie=0x391d6873, duration=554.839s, table=50, n_packets=0, n_bytes=0, priority=100,arp,arp_tpa=10.128.0.0/23 actions=move:NXM_NX_REG0[]->NXM_NX_TUN_ID[0..31],set_field:10.66.140.72->tun_dst,output:1
 cookie=0x391d6873, duration=554.839s, table=90, n_packets=0, n_bytes=0, priority=100,ip,nw_dst=10.128.0.0/23 actions=move:NXM_NX_REG0[]->NXM_NX_TUN_ID[0..31],set_field:10.66.140.72->tun_dst,output:1
 cookie=0x0, duration=554.834s, table=111, n_packets=0, n_bytes=0, priority=100 actions=move:NXM_NX_REG0[]->NXM_NX_TUN_ID[0..31],set_field:10.66.140.72->tun_dst,output:1,goto_table:120
3.

Actual results:
There is no matched flow in table=100

Expected results:
Should check table=90 instead

Additional info:

Comment 1 Dan Winship 2018-07-20 13:01:30 UTC
The flow doesn't exist when a node is first created, but flows in table 100 will be created when there are active egress IPs on other nodes. So we only care about monitoring the nodes that have flows in table 100, because those are the only nodes hosting egress IPs.

(So, if you're observing some problem with the auto egress IP HA feature, then this isn't the cause, but feel free to reopen this bug or open a new bug with more details.)


Note You need to log in before you can comment on or make changes to this bug.