openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Code Issues Releases Activity

OSDOCS-16832: MNW-1: Multiple Networks Core Concepts and VRF Overview

Browse Source
This commit is contained in:
“Shauna Diaz”
2025-12-05 10:41:12 -05:00
committed by openshift-cherrypick-robot
parent ffb87cfbf7
commit ef41a19320
10 changed files with 178 additions and 94 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
_topic_maps/_topic_map.yml
View File

@@ -1556,6 +1556,8 @@ Topics:
Topics: Topics:
- Name: Understanding multiple networks - Name: Understanding multiple networks
File: understanding-multiple-networks File: understanding-multiple-networks
- Name: Use cases for a secondary network
File: use-cases-secondary-network
- Name: Primary networks - Name: Primary networks
Dir: primary_networks Dir: primary_networks
Distros: openshift-enterprise, openshift-origin Distros: openshift-enterprise, openshift-origin

9
modules/cnf-about-virtual-routing-and-forwarding.adoc
View File

@@ -6,11 +6,10 @@
[id="cnf-about-virtual-routing-and-forwarding_{context}"] [id="cnf-about-virtual-routing-and-forwarding_{context}"]
= About virtual routing and forwarding = About virtual routing and forwarding
Virtual routing and forwarding (VRF) devices combined with IP rules provide the ability to create virtual routing and forwarding domains. VRF reduces the number of permissions needed by CNF, and provides increased visibility of the network topology of secondary networks. VRF is used to provide multi-tenancy functionality, for example, where each tenant has its own unique routing tables and requires different default gateways. [role="_abstract"]
You can use virtual routing and forwarding (VRF) to provide multi-tenancy functionality. For example, where each tenant has its own unique routing tables and requires different default gateways.
Processes can bind a socket to the VRF device. Packets through the binded socket use the routing table associated with the VRF device. An important feature of VRF is that it impacts only OSI model layer 3 traffic and above so L2 tools, such as LLDP, are not affected. This allows higher priority IP rules such as policy based routing to take precedence over the VRF device rules directing specific traffic. VRF reduces the number of permissions needed by cloud-native network function (CNF), and provides increased visibility of the network topology of secondary networks. VRF devices combined with IP address rules provide the ability to create virtual routing and forwarding domains.
[id="cnf-benefits-secondary-networks-telecommunications-operators_{context}"] Processes can bind a socket to the VRF device. Packets through the binded socket use the routing table associated with the VRF device. An important feature of VRF is that it impacts only OSI model layer 3 traffic and above so L2 tools, such as LLDP, are not affected. This allows higher priority IP address rules such as policy-based routing to take precedence over the VRF device rules directing specific traffic.
== Benefits of secondary networks for pods for telecommunications operators
In telecommunications use cases, each CNF can potentially be connected to multiple different networks sharing the same address space. These secondary networks can potentially conflict with the cluster's main network CIDR. Using the CNI VRF plugin, network functions can be connected to different customers' infrastructure using the same IP address, keeping different customers isolated. IP addresses are overlapped with {product-title} IP space. The CNI VRF plugin also reduces the number of permissions needed by CNF and increases the visibility of network topologies of secondary networks.

14
modules/cnf-benefits-secondary-networks-telco-ops.adoc Normal file
View File

@@ -0,0 +1,14 @@
// Module included in the following assemblies:
//
// networking/multiple_networks/about-virtual-routing-and-forwarding.adoc
:_mod-docs-content-type: CONCEPT
[id="cnf-benefits-secondary-networks-telco-ops_{context}"]
= Benefits of secondary networks for pods for telecommunications operators
[role="_abstract"]
You can connect network functions to different customers' infrastructure by using the same IP address with the Container Network Interface (CNI) virtual routing and forwarding (VRF) plugin. Using the CNI VRF plugin keeps different customers isolated.
In telecommunications use cases, each CNF can potentially be connected to many different networks sharing the same address space. These secondary networks can potentially conflict with the cluster's main network CIDR.
With the CNI VRF plugin, IP addresses are overlapped with the {product-title} IP address space. The CNI VRF plugin also reduces the number of permissions needed by CNF and increases the visibility of the network topologies of secondary networks.

6
modules/nw-about-multicast.adoc
View File

@@ -6,12 +6,14 @@
[id="nw-about-multicast_{context}"] [id="nw-about-multicast_{context}"]
= About multicast = About multicast
[role="_abstract"]
With IP multicast, data is broadcast to many IP addresses simultaneously. With IP multicast, data is broadcast to many IP addresses simultaneously.
[IMPORTANT] [IMPORTANT]
==== ====
* At this time, multicast is best used for low-bandwidth coordination or service discovery and not a high-bandwidth solution. * At this time, multicast is best used for low-bandwidth coordination or service discovery and not a high-bandwidth solution.
* By default, network policies affect all connections in a namespace. However, multicast is unaffected by network policies. If multicast is enabled in the same namespace as your network policies, it is always allowed, even if there is a `deny-all` network policy. Cluster administrators should consider the implications to the exemption of multicast from network policies before enabling it. * By default, network policies affect all connections in a namespace. However, multicast is unaffected by network policies. If multicast is enabled in the same namespace as your network policies, it is always allowed, even if there is a `deny-all` network policy.
* Cluster administrators must consider the implications of the exemption of multicast from network policies before enabling it.
==== ====
Multicast traffic between {product-title} pods is disabled by default. If you are using the OVN-Kubernetes network plugin, you can enable multicast on a per-project basis. Multicast traffic between {product-title} pods is disabled by default. If you are using the OVN-Kubernetes network plugin, you can enable multicast on a per-project basis.

4
modules/nw-enabling-multicast.adoc
View File

@@ -15,10 +15,12 @@ endif::[]
[id="nw-enabling-multicast_{context}"] [id="nw-enabling-multicast_{context}"]
= Enabling multicast between pods = Enabling multicast between pods
[role="_abstract"]
You can enable multicast between pods for your project. You can enable multicast between pods for your project.
.Prerequisites .Prerequisites
* Install the OpenShift CLI (`oc`).
* Install the {oc-first}.
* You must log in to the cluster with a user that has the `cluster-admin` * You must log in to the cluster with a user that has the `cluster-admin`
ifdef::openshift-rosa,openshift-dedicated[] ifdef::openshift-rosa,openshift-dedicated[]
or the `dedicated-admin` or the `dedicated-admin`

48
modules/support-matrix-for-udn-nad.adoc
View File

@@ -1,21 +1,32 @@
//module included in the following assembly: //module included in the following assembly:
// //
// *networkking/multiple_networks/understanding-user-defined-networks.adoc // *networking/multiple_networks/understanding-user-defined-networks.adoc
:_mod-docs-content-type: CONCEPT :_mod-docs-content-type: REFERENCE
[id="support-matrix-for-udn-nad_{context}"] [id="support-matrix-for-udn-nad_{context}"]
= UserDefinedNetwork and NetworkAttachmentDefinition support matrix = UserDefinedNetwork and NetworkAttachmentDefinition support matrix
The `UserDefinedNetwork` and `NetworkAttachmentDefinition` custom resources (CRs) provide cluster administrators and users the ability to create customizable network configurations and define their own network topologies, ensure network isolation, manage IP addressing for workloads, and configure advanced network features. A third CR, `ClusterUserDefinedNetwork`, is also available, which allows administrators the ability to create and define secondary networks spanning multiple namespaces at the cluster level. [role="_abstract"]
You can use user defined networks and network attachment definitions to define and configure customized networks for your needs.
User-defined networks and network attachment definitions can serve as both the primary and secondary network interface, and each support `layer2` and `layer3` topologies; a third network topology, Localnet, is also supported with network attachment definitions with secondary networks. By creating `UserDefinedNetwork` and `NetworkAttachmentDefinition` custom resources (CRs), cluster administrators can complete the following tasks:
* Create customizable network configurations
* Define their own network topologies
* Ensure network isolation
* Manage IP addressing for workloads
* Configure advanced network features
By creating a `ClusterUserDefinedNetwork` CR, administrators can create and define secondary networks that span multiple namespaces at the cluster level.
User-defined networks and network attachment definitions can serve as both the primary and secondary network interface, and each support `layer2` and `layer3` topologies.
[NOTE] [NOTE]
==== ====
As of {product-title} 4.19, the use of the `Localnet` topology by `ClusterUserDefinedNetwork` CRs is generally available. This configuration is the preferred method for connecting physical networks to virtual networks. Alternatively, the `NetworkAttachmentDefinition` CR can also be used to create secondary networks with `Localnet` topologies. As of {product-title} 4.19, the use of the `Localnet` topology by `ClusterUserDefinedNetwork` CRs is generally available. This configuration is the preferred method for connecting physical networks to virtual networks. Or, you can use the `NetworkAttachmentDefinition` CR to create secondary networks with `Localnet` topologies.
==== ====
The following section highlights the supported features of the `UserDefinedNetwork` and `NetworkAttachmentDefinition` CRs when they are used as either the primary or secondary network. A separate table for the `ClusterUserDefinedNetwork` CR is also included. The following section highlights the supported features of the `UserDefinedNetwork` and `NetworkAttachmentDefinition` CRs when used as either the primary or secondary network. A separate table for the `ClusterUserDefinedNetwork` CR is also included.
.Primary network support matrix for `UserDefinedNetwork` and `NetworkAttachmentDefinition` CRs .Primary network support matrix for `UserDefinedNetwork` and `NetworkAttachmentDefinition` CRs
[cols="1a,1a,1a, options="header"] [cols="1a,1a,1a, options="header"]
@@ -46,11 +57,11 @@ The following section highlights the supported features of the `UserDefinedNetwo
^| ✓ ^| ✓
^| ✓ ^| ✓
^| Multicast ^[1]^ ^| Multicast
^| X ^| X
^| ✓ ^| ✓
^| `NetworkPolicy` resource ^[2]^ ^| `NetworkPolicy` resource
^| ✓ ^| ✓
^| ✓ ^| ✓
@@ -59,12 +70,16 @@ The following section highlights the supported features of the `UserDefinedNetwo
^| X ^| X
|=== |===
1. Multicast must be enabled in the namespace, and it is only available between OVN-Kubernetes network pods. For more information about multicast, see "Enabling multicast for a project". where:
Multicast:: Must be enabled in the namespace, and it is only available between OVN-Kubernetes network pods. For more information, see "About multicast".
+
`NetworkPolicy` resource:: When creating a `ClusterUserDefinedNetwork` CR with a primary network type, network policies must be created _after_ the `UserDefinedNetwork` CR.
.Secondary network support matrix for `UserDefinedNetwork` and `NetworkAttachmentDefinition` CRs .Secondary network support matrix for `UserDefinedNetwork` and `NetworkAttachmentDefinition` CRs
[cols="1a,1a,1a,1a, options="header"] [cols="1a,1a,1a,1a, options="header"]
|=== |===
^| Network feature ^| Layer2 topology ^|Layer3 topology ^|Localnet topology ^[1]^ ^| Network feature ^| Layer2 topology ^|Layer3 topology ^|Localnet topology
^| east-west traffic ^| east-west traffic
^| ✓ ^| ✓
@@ -112,7 +127,7 @@ The following section highlights the supported features of the `UserDefinedNetwo
^| ✓ (`NetworkAttachmentDefinition` CR only) ^| ✓ (`NetworkAttachmentDefinition` CR only)
|=== |===
1. The Localnet topology is unavailable for use with the `UserDefinedNetwork` CR. It is only supported on secondary networks for `NetworkAttachmentDefinition` CRs. The Localnet topology is unavailable for use with the `UserDefinedNetwork` CR. It is only supported on secondary networks for `NetworkAttachmentDefinition` CRs.
.Support matrix for `ClusterUserDefinedNetwork` CRs .Support matrix for `ClusterUserDefinedNetwork` CRs
[cols="1a,1a,1a,1a, options="header"] [cols="1a,1a,1a,1a, options="header"]
@@ -149,7 +164,7 @@ The following section highlights the supported features of the `UserDefinedNetwo
^| ✓ ^| ✓
^| ^|
^| Multicast ^[1]^ ^| Multicast
^| X ^| X
^| ✓ ^| ✓
^| ^|
@@ -159,11 +174,14 @@ The following section highlights the supported features of the `UserDefinedNetwo
^| X ^| X
^| ✓ ^| ✓
^| `NetworkPolicy` resource ^[2]^ ^| `NetworkPolicy` resource
^| ✓ ^| ✓
^| ✓ ^| ✓
^| ^|
|=== |===
1. Multicast must be enabled in the namespace, and it is only available between OVN-Kubernetes network pods. For more information, see "About multicast". where:
2. When creating a `ClusterUserDefinedNetwork` CR with a primary network type, network policies must be created _after_ the `UserDefinedNetwork` CR.
Multicast:: must be enabled in the namespace, and it is only available between OVN-Kubernetes network pods. For more information, see "About multicast".
+
`NetworkPolicy` resource:: When creating a `ClusterUserDefinedNetwork` CR with a primary network type, network policies must be created _after_ the `UserDefinedNetwork` CR.

34
modules/understanding-multiple-networks-con.adoc Normal file
View File

@@ -0,0 +1,34 @@
//module included in the following assembly:
//
// *networking/multiple_networks/understanding-user-defined-networks.adoc
:_mod-docs-content-type: CONCEPT
[id="understanding-multiple-networks-con_{context}"]
= Multiple networks with the OVN-K CNI
[role="_abstract"]
By default, OVN-Kubernetes serves as the Container Network Interface (CNI) of an {product-title} cluster. This network interface is what administrators use to create default networks.
Both user-defined networks and Network Attachment Definitions can serve as the following network types:
* *Primary networks*: Act as the primary network for the pod. By default, all traffic passes through the primary network unless you have configured a pod route to send traffic through other networks.
* *Secondary networks*: Act as secondary, non-default networks for a pod. Secondary networks offer separate interfaces dedicated to specific traffic types or purposes. Only pod traffic that you explicitly configure to use a secondary network routes through its interface.
The following diagram shows a cluster that has an existing default network infrastructure that uses a physical network interface, `eth0`, to connect to two namespaces. Pods or virtual machines (VMs) in one namespace run in isolation from pods or VMs in the other namespace. You can create only one primary network. However, you can create multiple secondary networks for each namespace.
.Diagram showing namespaces with multiple secondary UDNs
image::501_OpenShift_UDN_pri_sec_0925.png[Diagram showing namespaces with multiple secondary UDNs]
During cluster installation, {product-title} administrators can configure alternative default secondary pod networks by leveraging the Multus CNI plugin. With Multus, you can use multiple CNI plugins such as ipvlan, macvlan, or Network Attachment Definitions together to serve as secondary networks for pods.
[IMPORTANT]
====
User-defined networks are only supported when OVN-Kubernetes is used as the CNI. UDNs are not supported for use with other CNIs.
====
You can define an secondary network based on the available CNI plugins and attach one or more of these networks to your pods. You can define more than one secondary network for your cluster depending on your needs. This gives you flexibility when you configure pods that deliver network functionality, such as switching or routing. For more information, see the the links in the Additional resources:
* For a complete list of supported CNI plugins, see "Secondary networks in {product-title}".
* For information about user-defined networks, see "About user-defined networks (UDNs)".
* For information about Network Attachment Definitions, "Creating primary networks by using a NetworkAttachmentDefinition".

2
networking/multiple_networks/about-virtual-routing-and-forwarding.adoc
View File

@@ -7,3 +7,5 @@ include::_attributes/common-attributes.adoc[]
toc::[] toc::[]
include::modules/cnf-about-virtual-routing-and-forwarding.adoc[leveloffset=+1] include::modules/cnf-about-virtual-routing-and-forwarding.adoc[leveloffset=+1]
include::modules/cnf-benefits-secondary-networks-telco-ops.adoc[leveloffset=+2]

78
networking/multiple_networks/understanding-multiple-networks.adoc
View File

@@ -6,82 +6,18 @@ include::_attributes/common-attributes.adoc[]
toc::[] toc::[]
By default, OVN-Kubernetes serves as the Container Network Interface (CNI) of an {product-title} cluster. With OVN-Kubernetes as the default CNI of a cluster, {product-title} administrators or users can leverage xref:../../networking/multiple_networks/primary_networks/about-user-defined-networks.adoc#about-user-defined-networks[user-defined networks (UDNs)] or xref:../../networking/multiple_networks/primary_networks/about-primary-nwt-nad.adoc#understanding-multiple-networks[NetworkAttachmentDefinition (NADs)] to create one, or multiple, default networks that handle all ordinary network traffic of the cluster. Both user-defined networks and Network Attachment Definitions can serve as the following network types: [role="_abstract"]
{product-title} administrators and users can use user-defined networks (UDNs) or `NetworkAttachmentDefinition` (NADs) to define the networks that handle all of the ordinary network traffic of the cluster.
* *Primary networks*: Act as the primary network for the pod. By default, all traffic passes through the primary network unless a pod route is configured to send traffic through other networks. include::modules/understanding-multiple-networks-con.adoc[leveloffset=+1]
* *Secondary networks*: Act as secondary, non-default networks for a pod. Secondary networks provide separate interfaces dedicated to specific traffic types or purposes. Only pod traffic that is explicitly configured to use a secondary network is routed through its interface.
The following diagram shows a cluster that has an existing default network infrastructure that uses a physical network interface, `eth0`, to connect to two namespaces. Pods or virtual machines (VMs) in one namespace run in isolation from pods or VMs in the other namespace. You can create only one primary network but multiple secondary networks for each namespace.
.Diagram showing namespaces with multiple secondary UDNs
image::501_OpenShift_UDN_pri_sec_0925.png[Diagram showing namespaces with multiple secondary UDNs]
During cluster installation, {product-title} administrators can configure alternative default secondary pod networks by leveraging the Multus CNI plugin. With Multus, multiple CNI plugins such as ipvlan, macvlan, or Network Attachment Definitions can be used together to serve as secondary networks for pods.
[NOTE]
====
User-defined networks are only available when OVN-Kubernetes is used as the CNI. They are not supported for use with other CNIs.
====
You can define an secondary network based on the available CNI plugins and attach one or more of these networks to your pods. You can define more than one secondary network for your cluster depending on your needs. This gives you flexibility when you configure pods that deliver network functionality, such as switching or routing.
For a complete list of supported CNI plugins, see xref:additional-networks-provided_understanding-multiple-networks["Secondary networks in {product-title}"].
For information about user-defined networks, see xref:../../networking/multiple_networks/primary_networks/about-user-defined-networks.adoc#about-user-defined-networks[About user-defined networks (UDNs)].
For information about Network Attachment Definitions, see xref:../../networking/multiple_networks/primary_networks/about-primary-nwt-nad.adoc#understanding-multiple-networks[Creating primary networks using a NetworkAttachmentDefinition].
[id="additional-network-considerations"]
== Usage scenarios for a secondary network
You can use a secondary network in situations where network isolation is needed, including data plane and control plane separation. Isolating network traffic is useful for the following performance and security reasons:
. Performance
+
**Traffic management**: You can send traffic on two different planes to manage how much traffic is along each plane.
. Security
+
**Network isolation**: You can send sensitive traffic onto a network plane that is managed specifically for security considerations, and you can separate private data that must not be shared between tenants or customers.
All of the pods in the cluster still use the cluster-wide default network to maintain connectivity across the cluster. Every pod has an `eth0` interface that is attached to the cluster-wide pod network. You can view the interfaces for a pod by using the `oc exec -it <pod_name> \-- ip a` command. If you add secondary network interfaces that use Multus CNI, they are named `net1`,
`net2`, ..., `netN`.
To attach secondary network interfaces to a pod, you must create configurations that define how the interfaces are attached. You specify each interface by using either a `UserDefinedNetwork` custom resource (CR) or a `NetworkAttachmentDefinition` CR. A CNI configuration inside each of these CRs defines how that interface is created.
For more information about creating a `UserDefinedNetwork` CR, see xref:../../networking/multiple_networks/primary_networks/about-user-defined-networks.adoc#about-user-defined-networks[About user-defined networks].
For more information about creating a NetworkAttachmentDefinition CR, see xref:../../networking/multiple_networks/primary_networks/about-primary-nwt-nad.adoc#understanding-multiple-networks[Creating primary networks using a NetworkAttachmentDefinition].
[id="additional-networks-provided_{context}"]
== Secondary networks in {product-title}
{product-title} provides the following CNI plugins for creating secondary
networks in your cluster:
* *bridge*: xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc#nw-multus-bridge-object_configuring-additional-network-cni[Configure a bridge-based secondary network] to allow pods on the same host to communicate with each other and the host.
* *bond-cni*: xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc#nw-multus-bond-cni-object_configuring-additional-network-cni[Configure a Bond CNI secondary network] to provide a method for aggregating multiple network interfaces into a single logical _bonded_ interface.
* *host-device*: xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc#nw-multus-host-device-object_configuring-additional-network-cni[Configure a host-device secondary network] to allow pods access to a physical Ethernet network device on the host system.
* *ipvlan*: xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc#nw-multus-ipvlan-object_configuring-additional-network-cni[Configure an ipvlan-based secondary network] to allow pods on a host to communicate with other hosts and pods on those hosts, similar to a macvlan-based secondary network. Unlike a macvlan-based secondary network, each pod shares the same MAC address as the parent physical network interface.
* *vlan*: xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc#nw-multus-vlan-object_configuring-additional-network-cni[Configure a VLAN-based secondary network] to allow VLAN-based network isolation and connectivity for pods.
* *macvlan*: xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc#nw-multus-macvlan-object_configuring-additional-network-cni[Configure a macvlan-based secondary network] to allow pods on a host to communicate with other hosts and pods on those hosts by using a physical network interface. Each pod that is attached to a macvlan-based secondary network is provided a unique MAC address.
* *TAP*: xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc#nw-multus-tap-object_configuring-additional-network-cni[Configure a TAP-based secondary network] to create a tap device inside the container namespace. A TAP device enables user space programs to send and receive network packets.
* *SR-IOV*: xref:../../networking/hardware_networks/about-sriov.adoc#about-sriov[Configure an SR-IOV based secondary network] to allow pods to attach to a virtual function (VF) interface on SR-IOV capable hardware on the host system.
* *route-override*: xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc#nw-route-override-cni_configuring-additional-network-cni[Configure a `route-override` based secondary network] to allow pods to override and set routes.
// UserDefinedNetwork and NetworkAttachmentDefinition support matrix // UserDefinedNetwork and NetworkAttachmentDefinition support matrix
include::modules/support-matrix-for-udn-nad.adoc[leveloffset=+1] include::modules/support-matrix-for-udn-nad.adoc[leveloffset=+1]
[id="additional-resources_understanding-multiple-networks"]
[role="_additional-resources"] [role="_additional-resources"]
.Additional resources == Additional resources
* xref:../../networking/multiple_networks/primary_networks/about-user-defined-networks.adoc#about-user-defined-networks[About user-defined networks (UDNs)]
* xref:../../networking/multiple_networks/primary_networks/about-primary-nwt-nad.adoc#understanding-multiple-networks[Creating primary networks using a NetworkAttachmentDefinition]
* xref:../../networking/ovn_kubernetes_network_provider/enabling-multicast.adoc#nw-ovn-kubernetes-enabling-multicast[Enabling multicast for a project] * xref:../../networking/ovn_kubernetes_network_provider/enabling-multicast.adoc#nw-ovn-kubernetes-enabling-multicast[Enabling multicast for a project]

75
networking/multiple_networks/use-cases-secondary-network.adoc Normal file
View File

@@ -0,0 +1,75 @@
:_mod-docs-content-type: ASSEMBLY
[id="use-cases-secondary-network"]
= Use cases for a secondary network
include::_attributes/common-attributes.adoc[]
:context: use-cases-secondary-network
toc::[]
[role="_abstract"]
You can use a secondary network in situations where you require network isolation, including data plane and control plane separation.
Isolating network traffic is useful for the following performance and security reasons:
* Performance
+
**Traffic management**: You can send traffic on two different planes to manage how much traffic is along each plane.
* Security
+
**Network isolation**: You can send sensitive traffic onto a network plane that is managed specifically for security considerations, and you can separate private data that must not be shared between tenants or customers.
All of the pods in the cluster still use the cluster-wide default network to maintain connectivity across the cluster. Every pod has an `eth0` interface that is attached to the cluster-wide pod network. You can view the interfaces for a pod by using the `oc exec -it <pod_name> \-- ip a` command. If you add secondary network interfaces that use the Multus Container Network Interface (CNI). These secondary networks are named `net1`, `net2`, and so on.
To attach secondary network interfaces to a pod, you must create configurations that define how the interfaces are attached. Use either a `UserDefinedNetwork` custom resource (CR) or a `NetworkAttachmentDefinition` CR to specify each interface. A CNI configuration inside each of these CRs defines how that interface is created.
//assembly not further modularized because the following section acts as an index page:
[id="additional-networks-provided_{context}"]
== Secondary networks in {product-title}
{product-title} provides the following CNI plugins for creating secondary networks in your cluster:
* *bridge*: To configure a bridge-based secondary network to allow pods on the same host to communicate with each other and the host, use the following procedure:
** xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc#nw-multus-bridge-object_configuring-additional-network-cni[Configure a bridge-based secondary network]
* *bond-cni*: To provide a method for aggregating multiple network interfaces into a single logical _bonded_ interface, use the following procedure:
** xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc#nw-multus-bond-cni-object_configuring-additional-network-cni[Configure a Bond CNI secondary network]
* *host-device*: To allow pods access to a physical Ethernet network device on the host system, use the following procedure:
** xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc#nw-multus-host-device-object_configuring-additional-network-cni[Configure a host-device secondary network]
* *ipvlan*: Allow pods on a host to communicate with other hosts and pods on those hosts, similar to a macvlan-based secondary network. Unlike a macvlan-based secondary network, each pod shares the same MAC address as the parent physical network interface. Use the following procedure:
** xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc#nw-multus-ipvlan-object_configuring-additional-network-cni[Configure an ipvlan-based secondary network]
* *VLAN*: To allow VLAN-based network isolation and connectivity for pods, use the following procedure:
** xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc#nw-multus-vlan-object_configuring-additional-network-cni[Configure a VLAN-based secondary network]
* *macvlan*: To allow pods on a host to communicate with other hosts and pods on those hosts by using a physical network interface. Each pod that is attached to a macvlan-based secondary network is provided a unique MAC address:
** xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc#nw-multus-macvlan-object_configuring-additional-network-cni[Configure a macvlan-based secondary network]
* *TAP*: A TAP device enables user space programs to send and receive network packets. To create a TAP device inside the container namespace, use the following procedure:
** xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc#nw-multus-tap-object_configuring-additional-network-cni[Configure a TAP-based secondary network]
* *SR-IOV*: To allow pods to attach to a virtual function (VF) interface on SR-IOV capable hardware on the host system.
** xref:../../networking/hardware_networks/about-sriov.adoc#about-sriov[Configure an SR-IOV based secondary network]
* *route-override*: To allow pods to override and set routes, use the following procedure:
** xref:../../networking/multiple_networks/secondary_networks/creating-secondary-nwt-other-cni.adoc#nw-route-override-cni_configuring-additional-network-cni[Configure a `route-override` based secondary network]
// UserDefinedNetwork and NetworkAttachmentDefinition support matrix
include::modules/support-matrix-for-udn-nad.adoc[leveloffset=+1]
[id="additional-resources_use-cases-secondary-network"]
[role="_additional-resources"]
== Additional resources
* xref:../../networking/ovn_kubernetes_network_provider/enabling-multicast.adoc#nw-ovn-kubernetes-enabling-multicast[Enabling multicast for a project]