Hi, I was able to verify the BZ on OVN cluster using `curl` command to curl 172.30.0.1 as per the instructions. Here's the snippet of one of the curl calls: =========================================================================================== for i in 22623 22624; do curl --local-port $i https://172.30.0.1/ -k; done { "kind": "Status", "apiVersion": "v1", "metadata": { }, "status": "Failure", "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"", "reason": "Forbidden", "details": { }, "code": 403 }{ "kind": "Status", "apiVersion": "v1", "metadata": { }, "status": "Failure", "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"", "reason": "Forbidden", "details": { }, "code": 403 } =========================================================================================== Nightly Build used: 4.6.0-0.nightly-2021-02-04-091446 For a cluster with SDN, I could not get the curl to work as it gave operation timed out. I also checked the iptable rules on the 4.6 SDN cluster vs 4.7 SDN cluster: 4.6 Cluster: ============= -A OPENSHIFT-BLOCK-OUTPUT -p tcp -m tcp --dport 22623 -j REJECT --reject-with icmp-port-unreachable -A OPENSHIFT-BLOCK-OUTPUT -p tcp -m tcp --dport 22624 -j REJECT --reject-with icmp-port-unreachable 4.7 Cluster: ============= -A OPENSHIFT-BLOCK-OUTPUT -p tcp -m tcp --dport 22623 --tcp-flags FIN,SYN,RST,ACK SYN -j REJECT --reject-with icmp-port-unreachable -A OPENSHIFT-BLOCK-OUTPUT -p tcp -m tcp --dport 22624 --tcp-flags FIN,SYN,RST,ACK SYN -j REJECT --reject-with icmp-port-unreachable Kindly let me know if the BZ is intended to fix the problem with SDN similar to 1915027(fixes both SDN/OVN). I am assuming the fix should have been on applied to both, hence moving it back to Assigned. Thanks, KK.
(In reply to Kedar Kulkarni from comment #2) > I was able to verify the BZ on OVN cluster using `curl` command to curl > 172.30.0.1 as per the instructions. > Kindly let me know if the BZ is intended to fix the problem with SDN similar > to 1915027(fixes both SDN/OVN). I am assuming the fix should have been on > applied to both, hence moving it back to Assigned. No, we only did the backport for ovn-kubernetes, so this was the expected behavior. Sorry for not clarifying that.
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 (OpenShift Container Platform 4.6.17 bug fix update), 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-2021:0424
Added QE testcase: https://polarion.engineering.redhat.com/polarion/#/project/OSE/workitem?id=OCP-44939