Bug 1795454 - Unable to bring up OVNKubernetes cluster on custom geneve port
Summary: Unable to bring up OVNKubernetes cluster on custom geneve port
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 4.4
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.4.0
Assignee: Tim Rozet
QA Contact: Anurag saxena
Depends On:
TreeView+ depends on / blocked
Reported: 2020-01-28 01:34 UTC by Anurag saxena
Modified: 2020-05-04 11:27 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-05-04 11:27:25 UTC
Target Upstream Version:

Attachments (Terms of Use)
install log bundle file (4.04 MB, application/gzip)
2020-01-28 01:34 UTC, Anurag saxena
no flags Details

System ID Private Priority Status Summary Last Updated
Github openshift ovn-kubernetes pull 87 0 None closed Bug 1795454: Resync to upstream 2020-07-17 08:24:48 UTC
Red Hat Product Errata RHBA-2020:0581 0 None None None 2020-05-04 11:27:50 UTC

Description Anurag saxena 2020-01-28 01:34:02 UTC
Created attachment 1655844 [details]
install log bundle file

Description of problem: Trying to bring up ovnkube cluster on geneve port 9081 but its failing in early stages. Also 9000-9999 are allowed in inbound rules on AWS. However cluster configures fine on default udp geneve port 6081.

Version-Release number of selected component (if applicable): 4.4.0-0.nightly-2020-01-24-141203

How reproducible: Always

Steps to Reproduce:

1. Create "cluster-network-03-config.yml" manifest and bring up cluster

apiVersion: operator.openshift.io/v1
kind: Network
  name: cluster
  - cidr:
    hostPrefix: 23
    type: OVNKubernetes
      mtu: 1600
      genevePort: 9081  <<<<<<<<<<<<<<<<<

2. ./openshift-install create cluster

Actual results: Cluster fails to come up when geneveport is set to 9081

Expected results: Cluster should come up fine when geneve port is set to 9081

Additional info:logs bundle file is attached with this bug

$ oc get nodes
NAME                                          STATUS     ROLES    AGE   VERSION
ip-10-0-132-75.ap-south-1.compute.internal    NotReady   master   89m   v1.17.1
ip-10-0-157-36.ap-south-1.compute.internal    NotReady   master   89m   v1.17.1
ip-10-0-173-125.ap-south-1.compute.internal   NotReady   master   89m   v1.17.1

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 02:2e:5f:bd:e9:62 brd ff:ff:ff:ff:ff:ff
    inet brd scope global dynamic noprefixroute ens3
       valid_lft 2673sec preferred_lft 2673sec
    inet6 fe80::5248:4e16:a88f:7a6b/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Comment 1 Phil Cameron 2020-01-28 14:30:03 UTC
@anurag Did you also do the "create install-config" and change type to OVN? It also didn't pick up the mtu change.

Comment 2 Anurag saxena 2020-01-28 14:35:39 UTC
@Phil Yes, and I exactly followed these steps https://bugzilla.redhat.com/show_bug.cgi?id=1793720#c5 except I added "genevePort: 9081" as well along with mtu as mentioned in comment1

Comment 3 Phil Cameron 2020-01-28 18:19:12 UTC
@anurag See: https://bugzilla.redhat.com/show_bug.cgi?id=1793720 comment #5 for testing this. 
# oc get cm ovnkube-config -n openshift-ovn-kubernetes -oyaml | grep "^data:" -A17

should show the "encap-port=" to have your selected port. "mtu=" will show the mtu. Both 1793720 and 1795454 can use the same test. This also shows that SDN-456 is working.

Comment 5 Tim Rozet 2020-01-28 22:46:41 UTC
This appears to me to be a real bug. The geneve tunnel is being configured wrong by ovnkube. Testing a fix.

Comment 6 Tim Rozet 2020-01-28 23:01:49 UTC
Have a fix that works for me on an upstream setup here:

Comment 11 errata-xmlrpc 2020-05-04 11:27:25 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.


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