Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1518830 - [Docs][RFE] Clarify/standardize OCP networks [NEEDINFO]
Summary: [Docs][RFE] Clarify/standardize OCP networks
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Documentation
Version: 3.6.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: Vikram Goyal
QA Contact: Vikram Goyal
Vikram Goyal
Depends On:
Blocks: 1542093
TreeView+ depends on / blocked
Reported: 2017-11-29 15:51 UTC by Thom Carlin
Modified: 2018-09-12 22:16 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Target Upstream Version:
dmoessne: needinfo? (bfallonf)

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1466118 None None None Never

Internal Links: 1466118

Description Thom Carlin 2017-11-29 15:51:16 UTC
Document URL:

Section Number and Name: 

Chapter 5. Networking

Describe the issue: 

1) Unable to find a high-level summary of the various OCP networks
2) "cluster network" and "pod network" are used interchangeably

Suggestions for improvement: 

1) Provide a high-level overview of the various networks, preferably with illustration(s)
2) Consistently use either "cluster network" or "pod network"

Additional information: 

Similarly for

Comment 2 Ben Bennett 2018-02-14 12:25:21 UTC
The cluster network is the "real" network that allows the nodes to communicate with one another and with the internet.

The pod network is the SDN that allows the pods to talk to one another (when allowed) across the cluster.

Comment 3 brice 2018-02-15 00:57:15 UTC
I've added a PR for this:

Thom, does this fulfill the BZ? The only other section I'm questioning is the "Design on Masters" section of the SDN doc [1]. It looks correct, but perhaps Ben can clear that up.

As for some diagrams on the setup, is there anything specific you're after? I can potentially work with the design team to get something together, but some more information on what you're after specifically might be needed.


Comment 5 Thom Carlin 2018-02-24 15:13:19 UTC
brice, the intent is an overview of the different types of networks used by OpenShift and consistent terminology.  Part of the confusion in comment 0 may have come from my misunderstanding of the various networks due to this.

Thank you, the review has improved my understanding of OpenShift Networking:
* [ClusterNetworkCIDR] Cluster network (a.k.a. node network, overlay network).  the "real" network that allows the OpenShift nodes to communicate with one another and with the internet 
* [ServiceNetwork, ServiceNetworkCIDR] Pod network (a.k.a. sdn network, interpod network, service network): the SDN that allows the pods to talk to one another (when allowed) across the cluster mentions
* IngressIPNetworkCIDR ingress IP network
* [ExternalIPNetworkCIDRs] external IP network 
and links to

I am unclear if these differ from the cluster network or if there are any other networks?

A simple, high-level overview diagram of OpenShift networking would be helpful to clarify the distinction between the various network.  Specific details could come in separate diagrams once the basic concepts are understood.

Comment 8 Ben Bennett 2018-07-11 11:34:54 UTC
ClusterNetwork - Virtual (overlay) network that the Pod IP addresses are allocated from
ServiceNetwork - Virtual (overlay) network that the Service IP addresses are allocated from

The service and cluster are both virtual networks, the service network is more virtual since nothing in the cluster will have the address... traffic to the service is natted to an endpoint address (usually a clusternetwork address allocated to a pod).

ExternalIPNetworkCIDRs - IP addresses on the underlay (real) network that the administrator has allowed to be used as externalIPs in services.  i.e. if set, and the person creating the service has sufficient privilege, they can put an address from that range into a service in the externalIP field, and then traffic arriving at a node with that as the target address will pass into the cluster to one of the service's endpoints.

IngressIPNetworkCIDR - This is a way for a cluster admin to allow self-provisioning of externalIPs.  If this is set up, users can create services of type LoadBalancer (on bare metal) and OpenShift will provision the ip address from this range and add it as an ExternalIP to the service.  This range must be included in ExternalIPNetworkCIDRs.

Note You need to log in before you can comment on or make changes to this bug.