//module included in the following assembly:
//
// * networking/multiple_networks/primary_networks/about-user-defined-networks.adoc

:_mod-docs-content-type: CONCEPT
[id="limitations-for-udn_{context}"]
= Limitations of a user-defined network

[role="_abstract"]
To deploy a successful user-defined networks (UDN), you must consider their limitations including DNS resolution behavior, restricted access to default network services such as the image registry, network policy constraints between isolated networks, and the requirement to create namespaces and networks before pods.

Consider the following limitations before implementing a UDN.

//Check on the removal of the DNS limitation for 4.18 or 4.17.z.
* *DNS limitations*:
** DNS lookups for pods resolve to the pod's IP address on the cluster default network. Even if a pod is part of a user-defined network, DNS lookups will not resolve to the pod's IP address on that user-defined network. However, DNS lookups for services and external entities will function as expected.
** When a pod is assigned to a primary UDN, it can access the Kubernetes API (KAPI) and DNS services on the cluster's default network.

* *Initial network assignment*: You must create the namespace and network before creating pods. Assigning a namespace with pods to a new network or creating a UDN in an existing namespace will not be accepted by OVN-Kubernetes.

//Check in 4.18 or 4.17.z for this capability.
//* *Service reachability*: Services created in namespaces that are served by the UDN are only accessible by namespaces connected to the UDN. Services in a UDN are reachable by other namespaces that share the same network. This can limit the flexibility of services across different networks.

* *Health check limitations*: Kubelet health checks are performed by the cluster default network, which does not confirm the network connectivity of the primary interface on the pod. Consequently, scenarios where a pod appears healthy by the default network, but has broken connectivity on the primary interface, are possible with user-defined networks.

* *Network policy limitations*: Network policies that enable traffic between namespaces connected to different user-defined primary networks are not effective. These traffic policies do not take effect because there is no connectivity between these isolated networks.

* *Creation and modification limitation*: The `ClusterUserDefinedNetwork` CR and the `UserDefinedNetwork` CR cannot be modified after being created.

* *Default network service access*: A user-defined network pod is isolated from the default network, which means that most default network services are inaccessible. For example, a user-defined network pod cannot currently access the {product-title} image registry. Because of this limitation, source-to-image builds do not work in a user-defined network namespace. Additionally, other functions do not work, including functions to create applications based on the source code in a Git repository, such as `oc new-app <command>`, and functions to create applications from an {product-title} template that use source-to-image builds. This limitation might also affect other `openshift-*.svc` services.

* *Connectivity limitation*: NodePort services on user-defined networks are not guaranteed isolation. For example, NodePort traffic from a pod to a service on the same node is not accessible, whereas traffic from a pod on a different node succeeds.

* *Unclear error message for IP address exhaustion*: When the subnet of a user-defined network runs out of available IP addresses, new pods fail to start. When this occurs, the following error is returned: `Warning: Failed to create pod sandbox`. This error message does not clearly specify that IP depletion is the cause. To confirm the issue, you can check the *Events* page in the pod's namespace on the {product-title} web console, where an explicit message about subnet exhaustion is reported.

* *Layer2 egress IP limitations* (`UserDefinedNetwork` CRs only):

** Egress IP does not work without a default gateway.

** Egress IP does not work on {gcp-first}.

** Egress IP does not work with multiple gateways and instead will forward all traffic to a single gateway.