// Module included in the following assemblies:
//
// * networking/advanced_networking/bgp_evpn_udn/about-bgp-evpn-user-defined-networks.adoc

:_mod-docs-content-type: CONCEPT
[id="nw-bgp-evpn-about_{context}"]
= Overview of BGP EVPN with OVN-Kubernetes

[role="_abstract"]
Border Gateway Protocol Ethernet Virtual Private Networking (BGP EVPN) is a standards-based control plane that exchanges layer 2 and layer 3 overlay network reachability within the data center. Enabling this feature on {product-title} allows a `ClusterUserDefinedNetwork` (CUDN) overlay network to use the EVPN control plane for deeper integration with the data center network.

Before EVPN support for primary cluster user-defined networks (CUDNs), VRF-lite was the only way to advertise CUDNs into one or more Virtual Routing and Forwarding (VRF) tables while keeping them isolated on the network. However, that approach required a VLAN interface per VRF and a separate BGP session for each VRF.

BGP EVPN simplifies that workflow: you avoid extra VLAN interfaces and per-VRF BGP sessions by using a single multiprotocol BGP (MP-BGP) session toward the fabric.

EVPN defines the following two VPN types that you can deploy with primary CUDNs when you attach the overlay to the fabric:

MAC-VRF:: Stretches a layer 2 segment across the EVPN fabric for east-west bridged traffic and workloads such as VM live migration.
IP-VRF:: Provides layer 3 routing across the EVPN fabric for routed north-south traffic.

Enabling EVPN transport on a primary cluster user-defined network (CUDN) implements EVPN using VXLAN overlay. FRR implements the BGP EVPN control plane and integrates with Linux network devices for the VXLAN data plane.

This design does not model the cluster default pod network as an EVPN VPN. EVPN applies only to primary CUDNs that you configure for EVPN transport. EVPN on primary CUDNs requires and builds on the OVN-Kubernetes route advertisements feature. You use `RouteAdvertisements` custom resources to associate fabric-facing FRR configuration with labeled primary CUDNs that use EVPN transport. For more information, see "About route advertisements".

[id="bgp-evpn-primary-use-cases_{context}"]
== Benefits of BGP EVPN with primary CUDNs

BGP EVPN extends the isolated primary network in each namespace to an external BGP EVPN fabric, improving segmentation between tenants and external sites while simplifying network operations by aligning CUDNs with fabric route targets and shared uplinks instead of complex per-node routes and host-specific wiring.

Primary CUDNs that use BGP EVPN offer the following benefits:

Fabric integration:: Map tenant networks to the same route-target and external virtual routing and forwarding (VRF) segments that you already use on an external BGP EVPN fabric.

Layer 2 stretch for mobility:: Extend a layer 2 segment into the cluster so that virtual machines or pods can keep addresses stable. EVPN MAC mobility can help when workloads move between nodes.

Simpler attachment than per-node local wiring:: Reduce dependence on host-specific local attachment patterns when the fabric can carry many tenant VNIs over shared uplinks.

Isolation for overlapping tenant networks:: Connect primary CUDNs that use overlapping address space to different external EVPN segments while preserving isolation between tenants.

[id="bgp-evpn-supported-platforms_{context}"]
== Platform support and feature compatibility

BGP EVPN with primary CUDNs is supported only on bare-metal clusters.

The following table lists the supported and unsupported features when EVPN is enabled on primary CUDNs.

.BGP EVPN with primary CUDNs feature compatibility
[cols="1a,1a",options="header"]
|===
^| Network feature ^| Supported

^| Egress firewall
^| Supported

^| Egress QoS
^| Supported

^| Network QoS
^| Supported

^| Network Policy
^| Supported

^| Services (Cluster IP)
^| Supported

^| Services (NodePort, External IP, LoadBalancer)
^| Limited^[1]^

^| Multicast (MAC-VRF)
^| Supported

^| Multicast (IP-VRF)
^| Unsupported

^| Multiple External Gateways (MEG)
^| Unsupported

^| EgressIP
^| Unsupported

^| Egress Service
^| Unsupported

^| IPsec
^| Unsupported

|===
--
. For `Service` objects (NodePort, External IP, and LoadBalancer), the node IP, external IP, and LoadBalancer IP must be reachable on the EVPN fabric at the appropriate cluster nodes. OVN-Kubernetes does not advertise those addresses onto the fabric. Service traffic behaves normally when the fabric delivers packets to the nodes.
--

[id="bgp-evpn-limitations_{context}"]
== Limitations

The following limitations apply to BGP EVPN with primary CUDNs:

* BGP EVPN with primary CUDNs is supported only on bare-metal clusters.
* BGP EVPN with primary CUDNs requires setting `gatewayConfig.routingViaHost` to `true` and `gatewayConfig.ipForwarding` to `Global` in the Cluster Network Operator configuration. For more information, see "Configuring a gateway".
* A maximum of 4094 combined MAC-VRF and IP-VRF instances per `VTEP` applies because OVN-Kubernetes uses one shared VXLAN device per `VTEP`, maps VLAN IDs to VNIs on that device, and the Linux bridge VLAN space is limited to 4094.
* Only IPv4 VTEP addresses are supported. IPv6 VTEPs are not supported because of limitations in FRR, which implements the BGP EVPN control plane.
* The VXLAN destination UDP port is 4789. Customizing the UDP port is not supported.