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

Bug 2103668

Summary:	ovnkube-node pod fails to start - unable to add OVN masquerade route to host, error: failed to add route for subnet - after upgrading to 4.10
Product:	OpenShift Container Platform	Reporter:	siva kanakala <skanakal>
Component:	Networking	Assignee:	Tim Rozet <trozet>
Networking sub component:	ovn-kubernetes	QA Contact:	Anurag saxena <anusaxen>
Status:	CLOSED ERRATA	Docs Contact:
Severity:	high
Priority:	high	CC:	ffernand, rravaiol, skharat, trozet, tschaibl
Version:	4.10
Target Milestone:	---
Target Release:	4.12.0
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-01-17 19:51:19 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:

Comment 3 Tim Rozet 2022-07-12 19:27:29 UTC

The issue here is that the default gateway route is changing to another interface other than br-ex before ovnkube comes up. This coupled with 4.10.18 which is missing the fix: https://github.com/ovn-org/ovn-kubernetes/pull/2782 causes an invalid route to be added via the wrong interface. With 4.10.20 and later the fix is present, however that would have also resulted in error because there is no default route available via br-ex. There are however, other non-default routes available via br-ex. In Local gateway mode all of the traffic egresses via the kernel routing stack, so egress traffic out another non-br-ex interface would work. Due to this behavior, there really is no logical reason that we *have* to use a default route next hop via br-ex for masquerade/service routes. Any next hop would do. Therefore to fix this issue we can add code to also consider non-default routes legitimate to identify next hops for these routes. I believe this should only be supported for local gateway mode. In shared gateway mode traffic egresses the br-ex bridge directly, and therefore if there is no default route via br-ex we cannot send external pod traffic. I don't really see this as a valid use case.

Comment 9 Tim Rozet 2022-09-08 22:22:32 UTC

We have come up with a better fix that requires no routes at all or a valid next hop external the cluster. This has been posted upstream and will be backportable to 4.10.

Comment 14 errata-xmlrpc 2023-01-17 19:51:19 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 (Moderate: OpenShift Container Platform 4.12.0 bug fix and security 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/RHSA-2022:7399