Bug 1732182 - [DOCS] crio.service does not start when there is no default route
Summary: [DOCS] crio.service does not start when there is no default route
Keywords:
Status: ASSIGNED
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Documentation
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.2.z
Assignee: Kathryn Alexander
QA Contact: Johnny Liu
Vikram Goyal
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-22 22:32 UTC by Eric Rich
Modified: 2019-11-04 17:44 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)

Description Eric Rich 2019-07-22 22:32:58 UTC
Description of problem:

> Jul 22 20:35:42 localhost.localdomain systemd[1]: Starting Open Container Initiative Daemon...
> Jul 22 20:35:42 localhost.localdomain crio[10396]: time="2019-07-22 20:35:42.483075415Z" level=fatal msg="no default routes found in "/proc/net/route" or "/proc/net/ipv6_route""
> Jul 22 20:35:42 localhost.localdomain systemd[1]: crio.service: Main process exited, code=exited, status=1/FAILURE
> Jul 22 20:35:42 localhost.localdomain systemd[1]: crio.service: Failed with result 'exit-code'.
> Jul 22 20:35:42 localhost.localdomain systemd[1]: Failed to start Open Container Initiative Daemon.

Version-Release number of selected component (if applicable): 4.1.6
How reproducible: 100% 


Steps to Reproduce:
1. Create an isolated network 
2. Complete a bare metal install 

Actual results:

The bootstrap process fails; because cri-o never starts. 


Expected results:

Cri-o should be able to start on a system without a default route. 


Additional info:

Comment 4 Seth Jennings 2019-07-23 16:54:33 UTC
Currently, crio uses the default route to determine the "primary IP" for the node.  It uses the IP address in the same subnet as the default route to determine this.

However, I think the default route should really only be used as a hint to resolve abiguity in the case of multiple IPs.  It a single IP case i.e. common case, it is trivial to determine the primary IP.

Comment 7 Seth Jennings 2019-07-29 22:00:49 UTC
Just got a change to test; doesn't seem to work https://github.com/cri-o/cri-o/pull/2662#issuecomment-516178852

Comment 10 Seth Jennings 2019-08-20 20:17:20 UTC
While testing our fix for this, I discovered that the kube-apiserver also can't start if there is no default route.

This will not be fixed in time for 4.2.  In fact, I'm less convinced that it is something we should "fix" now that I see the upstream kube components have the same limitation.

Disconnected and proxy documentation should indicate that a default route is required on nodes, even if that route can not reach the internet.


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