Skip to content

OCPBUGS#55102: Include reserved HCP CIDR ranges #93269

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

OCPBUGS#55102: Include reserved HCP CIDR ranges #93269

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions hosted_control_planes/hcp-prepare/hcp-requirements.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,3 +22,10 @@ include::modules/hcp-fips.adoc[leveloffset=+1]
* link:https://access.redhat.com/articles/7099674[The {mce} 2.8 support matrix]
* link:https://access.redhat.com/labs/ocpouic/?operator=multicluster-engine&&upgrade_path=4.14%20to%204.16[Red{nbsp}Hat {product-title} Operator Update Information Checker]
* xref:../../hosted_control_planes/hcp-prepare/hcp-sizing-guidance.adoc#hcp-shared-infra_hcp-sizing-guidance[Shared infrastructure between hosted and standalone control planes]

include::modules/hcp-cidr-ranges.adoc[leveloffset=+1]

[role="_additional-resources"]
.Additional resources

* xref:../../networking/cidr-range-definitions.adoc#cidr-range-definitions[CIDR range definitions]
16 changes: 16 additions & 0 deletions modules/hcp-cidr-ranges.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
// Module included in the following assemblies:
//
// * hosted_control_planes/hcp-prepare/hcp-requirements.adoc

:_mod-docs-content-type: CONCEPT
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
:_mod-docs-content-type: CONCEPT
:_mod-docs-content-type: REFERENCE

[id="hcp-cidr-ranges_{context}"]
= CIDR ranges for {hcp}

For deploying {hcp} on {product-title}, consider the following required Classless Inter-Domain Routing (CIDR) subnet ranges:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If these are required, should we use a more active verb like "use" or "adhere to"?

Suggested change
For deploying {hcp} on {product-title}, consider the following required Classless Inter-Domain Routing (CIDR) subnet ranges:
For deploying {hcp} on {product-title}, use the following required Classless Inter-Domain Routing (CIDR) subnet ranges:


* `v4InternalSubnet`: 100.65.0.0/16 (OVN-Kubernetes)
* `clusterNetwork`: 10.132.0.0/14 (pod network)
* `serviceNetwork`: 172.31.0.0/16


For more information about {product-title} CIDR range definitions, see "CIDR range definitions".
17 changes: 13 additions & 4 deletions networking/cidr-range-definitions.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ endif::openshift-dedicated,openshift-rosa[]

toc::[]

If your cluster uses OVN-Kubernetes, you must specify non-overlapping ranges for Classless Inter-Domain Routing (CIDR) subnet ranges.
If your cluster uses OVN-Kubernetes, you must specify non-overlapping ranges for Classless Inter-Domain Routing (CIDR) subnet ranges.

[IMPORTANT]
====
Expand All @@ -18,9 +18,9 @@ For {product-title} 4.17 and later versions, clusters use `169.254.0.0/17` for I

The following subnet types and are mandatory for a cluster that uses OVN-Kubernetes:

* Join: Uses a join switch to connect gateway routers to distributed routers. A join switch reduces the number of IP addresses for a distributed router. For a cluster that uses the OVN-Kubernetes plugin, an IP address from a dedicated subnet is assigned to any logical port that attaches to the join switch.
* Join: Uses a join switch to connect gateway routers to distributed routers. A join switch reduces the number of IP addresses for a distributed router. For a cluster that uses the OVN-Kubernetes plugin, an IP address from a dedicated subnet is assigned to any logical port that attaches to the join switch.
* Masquerade: Prevents collisions for identical source and destination IP addresses that are sent from a node as hairpin traffic to the same node after a load balancer makes a routing decision.
* Transit: A transit switch is a type of distributed switch that spans across all nodes in the cluster. A transit switch routes traffic between different zones. For a cluster that uses the OVN-Kubernetes plugin, an IP address from a dedicated subnet is assigned to any logical port that attaches to the transit switch.
* Transit: A transit switch is a type of distributed switch that spans across all nodes in the cluster. A transit switch routes traffic between different zones. For a cluster that uses the OVN-Kubernetes plugin, an IP address from a dedicated subnet is assigned to any logical port that attaches to the transit switch.

[NOTE]
====
Expand Down Expand Up @@ -121,4 +121,13 @@ endif::openshift-rosa,openshift-dedicated[]

ifdef::openshift-enterprise[]
For example, if the host prefix is set to `/23`, each machine is assigned a `/23` subnet from the pod CIDR address range. The default is `/23`, allowing 510 cluster nodes, and 510 pod IP addresses per node.
endif::openshift-enterprise[]
endif::openshift-enterprise[]

[id="hcp-cidr-description_{context}"]
== {hcp-capital} CIDR

For {hcp} on {product-title}, consider the following required CIDR ranges:

* `v4InternalSubnet`: 100.65.0.0/16 (OVN-Kubernetes)
* `clusterNetwork`: 10.132.0.0/14 (pod network)
* `serviceNetwork`: 172.31.0.0/16
Comment on lines +126 to +133
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this content needs to be maintained at all (like if there will be changes to this list), finding a way to write it only once and reuse it in both places will avoid errors creeping in from folks not realizing there are two versions of the same content in the repo. Maybe a snippet, or just including the module in this assembly?