mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
49 lines
2.9 KiB
Plaintext
49 lines
2.9 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
|
|
|
|
:_mod-docs-content-type: REFERENCE
|
|
[id="telco-core-networking_{context}"]
|
|
= Networking
|
|
|
|
The following diagram describes the telco core reference design networking configuration.
|
|
|
|
.Telco core reference design networking configuration
|
|
image::openshift-telco-core-rds-networking.png[Overview of the telco core reference design networking configuration]
|
|
|
|
|
|
New in this release::
|
|
* No reference design updates in this release
|
|
|
|
[NOTE]
|
|
====
|
|
If you have custom `FRRConfiguration` CRs in the `metallb-system` namespace, you must move them under the `openshift-network-operator` namespace.
|
|
====
|
|
|
|
Description::
|
|
|
|
* The cluster is configured for dual-stack IP (IPv4 and IPv6).
|
|
* The validated physical network configuration consists of two dual-port NICs.
|
|
One NIC is shared among the primary CNI (OVN-Kubernetes) and IPVLAN and MACVLAN traffic, while the second one is dedicated to SR-IOV VF-based pod traffic.
|
|
* A Linux bonding interface (`bond0`) is created in active-active IEEE 802.3ad LACP mode with the two NIC ports attached.
|
|
The top-of-rack networking equipment must support and be configured for multi-chassis link aggregation (mLAG) technology.
|
|
* VLAN interfaces are created on top of `bond0`, including for the primary CNI.
|
|
* Bond and VLAN interfaces are created at cluster install time during the network configuration stage of the installation.
|
|
Except for the `vlan0` VLAN used by the primary CNI, all other VLANs can be created during Day 2 activities with the Kubernetes NMstate Operator.
|
|
* MACVLAN and IPVLAN interfaces are created with their corresponding CNIs.
|
|
They do not share the same base interface.
|
|
For more information, see "Cluster Network Operator".
|
|
* SR-IOV VFs are managed by the SR-IOV Network Operator.
|
|
* To ensure consistent source IP addresses for pods behind a LoadBalancer Service, configure an `EgressIP` CR and specify the `podSelector` parameter.
|
|
EgressIP is further discussed in the "Cluster Network Operator" section.
|
|
* You can implement service traffic separation by doing the following:
|
|
.. Configure VLAN interfaces and specific kernel IP routes on the nodes using `NodeNetworkConfigurationPolicy` CRs.
|
|
.. Create a MetalLB `BGPPeer` CR for each VLAN to establish peering with the remote BGP router.
|
|
.. Define a MetalLB `BGPAdvertisement` CR to specify which IP address pools should be advertised to a selected list of `BGPPeer` resources. The following diagram illustrates how specific service IP addresses are advertised externally through specific VLAN interfaces. Services routes are defined in `BGPAdvertisement` CRs and configured with values for `IPAddressPool1` and `BGPPeer1` fields.
|
|
|
|
|
|
.Telco core reference design MetalLB service separation
|
|
image::openshift-telco-core-rds-metallb-service-separation.png[Telco core reference design MetalLB service separation]
|
|
|
|
|