|
| 1 | +// Module included in the following assemblies: |
| 2 | +// |
| 3 | +// * networking/advanced_networking/bgp_evpn_udn/about-bgp-evpn-user-defined-networks.adoc |
| 4 | + |
| 5 | +:_mod-docs-content-type: CONCEPT |
| 6 | +[id="nw-bgp-evpn-about_{context}"] |
| 7 | += Overview of BGP EVPN with OVN-Kubernetes |
| 8 | + |
| 9 | +[role="_abstract"] |
| 10 | +Border Gateway Protocol (BGP) Ethernet Virtual Private Network (EVPN) extends BGP with address families that distribute Ethernet and IP VPN routes, for example, MAC reachability in a MAC-VRF and IP prefixes in an IP-VRF. On {product-title} with the OVN-Kubernetes network plugin, you can attach primary cluster-scoped user-defined networks (CUDNs) to an external EVPN fabric. |
| 11 | + |
| 12 | +This integration lets you extend segmentation and reachability for tenant namespaces beyond the cluster boundary by using the same BGP-based standards as your physical or virtual network infrastructure, instead of relying on SDN-specific integration only. |
| 13 | + |
| 14 | +OVN-Kubernetes drives EVPN integration with FRR-K8s: FRR establishes BGP EVPN sessions toward your fabric, while OVN-Kubernetes programs overlay and underlay state for the selected CUDNs. A `VTEP` custom resource defines how the cluster exposes Virtual Tunnel Endpoints for EVPN encapsulation, and `RouteAdvertisements` objects select which primary CUDNs are advertised and which FRR configuration to use. |
| 15 | + |
| 16 | +[id="about-bgp-evpn-other-features_{context}"] |
| 17 | +== About BGP EVPN, BGP routing, and route advertisements |
| 18 | + |
| 19 | +BGP EVPN for primary CUDNs is not a separate routing stack. It requires the same platform pieces as OVN-Kubernetes BGP: |
| 20 | + |
| 21 | +* FRR-K8s must be deployed through Cluster Network Operator `additionalRoutingCapabilities` so that `FRRConfiguration` objects can express BGP and EVPN toward peers on the provider network. |
| 22 | + |
| 23 | +* Route advertisements must be enabled in the OVN-Kubernetes configuration so that `RouteAdvertisements` CRs can associate fabric-facing FRR configuration with primary CUDNs that use EVPN transport. |
| 24 | + |
| 25 | +You configure BGP neighbors, address families, and related policies in `FRRConfiguration` CRs. You then use `RouteAdvertisements` to tie those configurations to `ClusterUserDefinedNetwork` objects that are labeled or selected according to your design. |
| 26 | + |
| 27 | +[id="bgp-evpn-gateway-mode_{context}"] |
| 28 | +== Gateway mode and node forwarding |
| 29 | + |
| 30 | +EVPN for primary CUDNs is supported when the cluster uses local gateway mode. The `spec.defaultNetwork.ovnKubernetesConfig.gatewayConfig.routingViaHost` resource must be `true` in the `Network` Operator API. Invalid combinations are rejected through resource status conditions. |
| 31 | + |
| 32 | +[id="bgp-evpn-supported-platforms_{context}"] |
| 33 | +== Supported platforms |
| 34 | + |
| 35 | +BGP EVPN for primary CUDNs is intended for bare metal deployments where nodes peer with an external BGP EVPN fabric. |
| 36 | + |
| 37 | +[id="bgp-evpn-compatibility_{context}"] |
| 38 | +== Compatibility and limitations |
| 39 | + |
| 40 | +The following cluster networking features are incompatible with EVPN on primary CUDNs: |
| 41 | + |
| 42 | +* EgressIP |
| 43 | +* IPsec encryption for OVN-Kubernetes |
| 44 | +* Overlay topologies |
| 45 | + |
| 46 | +The following limitations apply to load balancer service IPs and MetalLB and FRR-K8s: |
| 47 | + |
| 48 | +Load balancer service IPs:: Advertising Kubernetes `LoadBalancer` service IPs over EVPN is not handled the same way as unicast pod or CUDN routes. MetalLB can advertise services over BGP in many environments, but EVPN address-family support for those advertisements might require additional configuration outside the scope of a default integration. Until product integration catches up, advertising load balancer IPs on EVPN might require explicit, fabric-specific configuration. |
| 49 | + |
| 50 | +MetalLB and FRR-K8s:: MetalLB and OVN-Kubernetes share the FRR-K8s deployment. Follow the namespace and migration guidance for `FRRConfiguration` CRs so that MetalLB-owned configuration and cluster routing configuration do not conflict. |
| 51 | + |
| 52 | +[id="bgp-evpn-cudn-lifecycle_{context}"] |
| 53 | +== Cluster user-defined network lifecycle |
| 54 | + |
| 55 | +You enable EVPN by setting EVPN-related fields on a primary `ClusterUserDefinedNetwork` resource, for example, EVPN transport and VNI or route-target settings. You cannot retroactively enable EVPN on an existing CUDN whose specification is already immutable. You must plan EVPN when you create the network or create a new CUDN for EVPN workloads. |
| 56 | + |
| 57 | +[id="bgp-evpn-custom-resources_{context}"] |
| 58 | +== Custom resources involved in EVPN |
| 59 | + |
| 60 | +The following custom resources are commonly used in an EVPN deployment: |
| 61 | + |
| 62 | +`FRRConfiguration`:: |
| 63 | +Defines BGP peers, autonomous system numbers, and EVPN-related address-family configuration toward the provider fabric. Namespaced; used with FRR-K8s. |
| 64 | + |
| 65 | +`VTEP`:: |
| 66 | +Describes Virtual Tunnel Endpoint parameters (for example, address ranges or mode) so that OVN-Kubernetes can align tunnel endpoints with your underlay. |
| 67 | + |
| 68 | +`RouteAdvertisements`:: |
| 69 | +Selects which networks to advertise (including primary CUDNs), which `FRRConfiguration` instances to use, and optional node selectors. |
| 70 | + |
| 71 | +`ClusterUserDefinedNetwork`:: |
| 72 | +Defines the primary CUDN topology (layer 2 or layer 3), attaches namespaces, and carries EVPN transport settings that link the logical network to the configured VTEP and VPN identifiers. |
| 73 | + |
| 74 | +Together, these objects separate fabric peering policy (FRR), what to advertise (`RouteAdvertisements`), tunnel endpoint context (`VTEP`), and tenant network definition (CUDN). |
0 commit comments