-
Bug
-
Resolution: Done
-
Undefined
-
None
-
4.12
-
+
-
No
-
False
-
-
NA
-
Customer Escalated
-
-
3/2: telco review pending (EG/CG)
Description of problem:
When applying a custom routing table different from the main one, nmstate takes the first route with destination 0.0.0.0 even if it does not belong to the main routing table
Version-Release number of selected component (if applicable):
How reproducible:
I didn't hit this in the previous deployment, so I think it depends on the order with nmstate returns the routes. So, not always
Steps to Reproduce:
1. File a route with a different table id, with a default gateway, like - destination: 0.0.0.0/0 next-hop-interface: eth0 next-hop-address: 169.254.169.4 table-id: 56 2. 3.
Actual results:
if we hit the bug, knmstate will try to ping 169.254.169.4
Expected results:
knmstate should ping the actual default gateway to understand if the node is healthy
Additional info:
- blocks
-
OCPBUGS-11077 [release-4.12] NMstate complains about ping not working when adding multiple routing tables with different gateways
- Closed
- clones
-
OCPBUGS-8229 NMstate complains about ping not working when adding multiple routing tables with different gateways
- Closed
- depends on
-
OCPBUGS-8229 NMstate complains about ping not working when adding multiple routing tables with different gateways
- Closed
- is cloned by
-
OCPBUGS-11077 [release-4.12] NMstate complains about ping not working when adding multiple routing tables with different gateways
- Closed
- links to