On this page
Topic - IP addressing scale and VRF interaction model
Overview
Practical addressing model for routed EVPN and OpenShift designs at multi-cluster scale. This note explains overlap behavior, route leaking limits, and capacity profiles used in review.
Context
Current baseline is CUDN-first routed attachment with scoped UDN usage. Teams need one model for overlap handling and scale planning that aligns with adr-023-ipv6-numberplan-and-cluster-scale-strategy and source-logius-overheidsbreed-ipv6-nummerplankader.
Applicable Principles
- Automation First - address allocation and validation stay intent-driven.
- Reliability and Resilience - routing behavior stays deterministic at scale.
- Security by Design - segmentation and exception handling are explicit.
Decisions
- Routed default uses unique prefixes per routed VRF scope.
- Overlap is exception-only and allowed only in isolated VRFs.
- Route leaking enables controlled reachability for unique prefixes; it does not resolve overlapping destination ambiguity.
- Overlap plus shared services requires boundary translation or proxy controls with identity-impact evidence.
- Government-facing IPv6 usage aligns to Logius category guidance via source-logius-overheidsbreed-ipv6-nummerplankader.
Current State
Reachability and overlap rules
| Scenario | Prefix overlap | Route leaking | Direct communication | Boundary translation |
|---|---|---|---|---|
Routed default (CUDN) | Not allowed | Used for controlled reachability | Yes, when policy allows | Not required |
Isolated UDN or VRF domain | Allowed | No implicit reachability | No | Not required while isolated |
| Overlap plus shared services/internet | Allowed | Does not disambiguate identical prefixes | No direct overlap-to-overlap flow | Required at controlled boundary |
- Encapsulation choice does not reduce address demand; it changes routing visibility and uniqueness requirements.
- Do not leak overlapping prefixes into shared routed domains.
- Apply translation at boundary endpoints only and record source-identity impact in change evidence.
- Block duplicate-prefix leaks in CI before promotion.
Tenant request flow
- If tenant-to-tenant communication is required, allocate unique routed prefixes.
- If strict isolation is required and no direct cross-tenant communication exists, overlap can be approved.
- If overlap plus shared services is requested, require boundary endpoint pattern with explicit translation policy.
Capacity and profile guidance
Worked IPv4 example (capacity math only): with 10 nodes and 1500 pods per node, /21 per node implies 10 x 2048 = 20480 addresses, so cluster pod space is approximately /17.
Promotion for sizing changes requires all three evidence layers:
| Layer | Required evidence |
|---|---|
| Address-capacity math | Capacity worksheet and selected profile |
| Product support envelope | Vendor support reference for target release |
| Local policy cap | Architecture owner approval and policy ID |
IPv6 scale profiles from one internal /46 pool:
| Cluster prefix | Clusters per /46 | /64 per cluster | Typical use |
|---|---|---|---|
/56 | 1024 | 256 | High cluster count |
/54 | 256 | 1024 | Balanced default |
/53 | 128 | 2048 | High-density profile |
Future Work
- Add NetBox intent fields for cluster prefix profile selection (
/56,/54,/53) with CI capacity validation. - Add route-policy checks that reject overlapping-prefix leaks on shared routed domains.
- Promote adr-023-ipv6-numberplan-and-cluster-scale-strategy to accepted after implementation evidence closes.