:_mod-docs-content-type: PROCEDURE [id="configuring-networking-for-control-plane-services_{context}"] = Configuring isolated networks on control plane services [role="_abstract"] After the NMState operator creates the desired hypervisor network configuration for isolated networks, you must configure the {rhos_prev_long} ({OpenStackShort}) services to use the configured interfaces. You define a `NetworkAttachmentDefinition` custom resource (CR) for each isolated network. In some clusters, these CRs are managed by the Cluster Network Operator, in which case you use `Network` CRs instead. For more information, see link:{defaultOCPURL}/networking/cluster-network-operator#nw-cluster-network-operator_cluster-network-operator[Cluster Network Operator] in _Networking_. .Procedure . Define a `NetworkAttachmentDefinition` CR for each isolated network. For example: + ---- apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: internalapi spec: config: | { "cniVersion": "0.3.1", "name": "internalapi", "type": "macvlan", "master": "enp6s0.20", "ipam": { "type": "whereabouts", "range": "172.17.0.0/24", "range_start": "172.17.0.20", "range_end": "172.17.0.50" } } ---- + [IMPORTANT] Ensure that the interface name and IPAM range match the configuration that you used in the `NodeNetworkConfigurationPolicy` CRs. . Optional: When reusing existing IP ranges, you can exclude part of the range that is used in the existing deployment by using the `exclude` parameter in the `NetworkAttachmentDefinition` pool. For example: + ---- apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: internalapi spec: config: | { "cniVersion": "0.3.1", "name": "internalapi", "type": "macvlan", "master": "enp6s0.20", "ipam": { "type": "whereabouts", "range": "172.17.0.0/24", "range_start": "172.17.0.20", <1> "range_end": "172.17.0.50", <2> "exclude": [ <3> "172.17.0.24/32", "172.17.0.44/31" ] } } ---- + <1> Defines the start of the IP range. <2> Defines the end of the IP range. <3> Excludes part of the IP range. This example excludes IP addresses `172.17.0.24/32` and `172.17.0.44/31` from the allocation pool. . If your {OpenStackShort} services require load balancer IP addresses, define the pools for these services in an `IPAddressPool` CR. For example: + [NOTE] The load balancer IP addresses belong to the same IP range as the control plane services, and are managed by MetalLB. This pool should also be aligned with the {OpenStackShort} configuration. + ---- - apiVersion: metallb.io/v1beta1 kind: IPAddressPool spec: addresses: - 172.17.0.60-172.17.0.70 ---- + Define `IPAddressPool` CRs for each isolated network that requires load balancer IP addresses. . Optional: When reusing existing IP ranges, you can exclude part of the range by listing multiple entries in the `addresses` section of the `IPAddressPool`. For example: + ---- - apiVersion: metallb.io/v1beta1 kind: IPAddressPool spec: addresses: - 172.17.0.60-172.17.0.64 - 172.17.0.66-172.17.0.70 ---- + The example above would exclude the `172.17.0.65` address from the allocation pool. // TODO: is there anything specific to mention about BGP L3 mode here?