On this page
Context and Problem Statement
The 1H2026 OpenShift implementation needs IP allocations for nodes, pods, services, and supporting networks without colliding with existing RWS routes. The plan must also be compatible with the long-term SDN design.
Decision Drivers
- Adequate address space for node, pod, and service networks per cluster.
- Routable management access from approved control points.
- Alignment with long-term SDN addressing and DC 3.0 conventions.
- Accommodation for storage and out-of-band management networks.
Considered Options
- Dedicated RFC1918 ranges per datacenter and cluster type.
- Extend existing enterprise ranges with reserved OpenShift subnets.
- Hybrid: dedicated pod/service ranges, reuse existing management ranges.
Decision Outcome
Chosen option: Dedicated RFC1918 ranges per datacenter and cluster type.
Implementation baseline:
- Location A and Location B each use dedicated, non-overlapping prefix groups in NetBox.
- Addressing is separated by function class (
management,node,pod,service,oob, andstorage). - Prefix allocation and capacity checks are validated in CI from NetBox-exported intent artifacts before deployment pipelines run.
- Reuse of enterprise shared ranges for pod/service networks is not allowed.
Scope boundary
- This ADR remains the accepted baseline for 1H2026 RFC1918 delivery scope.
- Forward IPv6 numberplan strategy, government IPv6 category alignment, and multi-hundred-cluster profile planning are tracked in adr-023-ipv6-numberplan-and-cluster-scale-strategy.
- High-density routed CUDN sizing guidance (including the
/21-per-node confusion case) is documented in topic-network-ip-addressing-scale-and-vrf-model.
Pros and Cons of the Options
Option 1 – Dedicated ranges per datacenter (chosen)
Pros
- Clean separation and predictable growth planning.
- Simplifies SDN migration and multi-site routing policy.
Cons
- Requires coordination for new allocations and route propagation.
Option 2 – Extend existing enterprise ranges
Pros
- Lower initial change cost and fewer new route advertisements.
Cons
- Higher risk of overlap and limited growth headroom.
Option 3 – Hybrid approach
Pros
- Balances isolation for pod/service networks with existing management routing.
Cons
- Mixed model adds operational complexity and documentation burden.