:_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?
