-
Feature
-
Resolution: Unresolved
-
Major
-
None
-
None
Feature Overview (aka. Goal Summary)
Make the route table ID predictable for VRF lite Cluster-scoped UDNs (CUDNs).
Goals (aka. expected user outcomes)
Add support for a vrfName in NNCP, to match UDN's ability to craft custom VRF names, so that we can make the route table ID predictable for VRF lite Cluster-scoped UDNs (CUDNs).
Requirements (aka. Acceptance Criteria):
| Deployment considerations | List applicable specific needs (N/A = not applicable) |
| Self-managed, managed, or both | |
| Classic (standalone cluster) | |
| Hosted control planes | |
| Multi node, Compact (three node), or Single node (SNO), or all | |
| Connected / Restricted Network | |
| Architectures, e.g. x86_x64, ARM (aarch64), IBM Power (ppc64le), and IBM Z (s390x) | |
| Operator compatibility | |
| Backport needed (list applicable versions) | |
| UI need (e.g. OpenShift Console, dynamic plugin, OCM) | |
| Other (please specify) |
Use Cases (Optional):
Questions to Answer (Optional):
Out of Scope
Background
- When CUDNs are advertised via BGP using VRFs, the route table ID for the created VRF is auto generated in response to the VRF being created by the FRRConfiguration CR. This route table ID is randomly picked by each host where the VRF is being created. This makes it especially hard to create static routes using nmstate to handle eBGP multihop connections.
- The short lived workaround (this workaround does not survive reboots) is to discover the route table on each host using "ip vrf list" and craft a NNCP targeting the explicitly route table ID.
Customer Considerations
Documentation Considerations
Interoperability Considerations
- is related to
-
-
- Approved
-