Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
After the IPv4/IPv6 patch, our customer now tested with multiple default routes.
With RHEL, right now cloud-init injects all default routes into the
interface configuration files, then the kernel only accepts the first
default route and will reject all others.
It seems that Windows does PBR by default and does not run into this issue.
To be more precise: if I create a neutron network with a router and
default route, and a second network with a default gateway as well,
and I attach both to an instance .. IMO there are 3 ways to handle
this:
i) implement PBR (for the inbound case) and for traffic from the
instance outbound "roll the dice"
ii) reject multiple default routes with an error message
iii) accept multiple default routes but roll the dice for the one that
wins (which is the first default route that gets configured) - this is
the current behavior at least for RHEL
In any case, this seems like a feature request or asks for general
consensus in cloud-init about how the hosts should behave in the
presence of multiple default routes.
Any input on this?
Comment 2Lars Kellogg-Stedman
2017-06-01 18:09:41 UTC
I'm not sure that cloud-init should arbitrate this process. I would argue that cloud-init should continue in its current behavior, and it should be up to the operating system how to handle multiple default routes.
This is exactly the situation you would end up with if you were to plug your system into multiple DHCP-enabled networks that provide default gateway
information. I think that from cloud-init's perspective, the behavior should be the same(let the OS sort it out) for both DHCP and static network situations.
If the OS itself is not handling this situation correctly, that should probably result in an RFE against RHEL.
A few comments:
- It actually seems to be the LAST interface that "wins" and gets the associated default route configured. With a RHEL instance with four vNICS, the eth3 interface has the default route.
- cloudbase-init in conjunction with Windows Server results in a default route for EACH vNIC (tested with up to four interfaces). The IP addresses associated with each interface are all reachable, since no asymmetric routing occurs.
- With cloud-init and RHEL in conjunction with the current behavior, asymmetric routing occurs with only a single default route (traffic arrives on one interface of the instance and return traffic uses a different interface). This means that all IP addresses of the instance are unreachable if firewalling/security groups are in place except for the IP address on the same subnet as the default route.
If cloud-init wants to be able to support properly configuring instances with more than one interface, than I think configuring policy-based routing is the only option.
Comment 4Lars Kellogg-Stedman
2017-06-15 16:25:57 UTC
> than I think configuring policy-based routing is the only option.
I agree that PBR is the solution, but I'm not convinced this is a cloud-init problem. I think that given multiple interface configurations that configure default gateways, NetworkManager should handle the routing setup. It is entirely possible to end up in this situation in a non-cloud-init world, so I believe ths fix has to be somewhere other than cloud-init.