// Module included in the following assemblies:
//
// * networking/metallb/about-metallb.adoc

:_mod-docs-content-type: CONCEPT
[id="nw-metallb-layer2-limitations_{context}"]
= Limitations for layer 2 mode

[role="_abstract"]
In {product-title}, MetalLB layer 2 mode is limited to single-node bandwidth and failover depends on client ARP handling. Avoid using the same VLAN for MetalLB and an additional network to prevent connection failures.

[id="nw-metallb-layer2-limitations-bottleneck_{context}"]
== Single-node bottleneck

MetalLB routes all traffic for a service through a single node, the node can become a bottleneck and limit performance.

Layer 2 mode limits the ingress bandwidth for your service to the bandwidth of a single node.
This is a fundamental limitation of using ARP and NDP to direct traffic.

[id="nw-metallb-layer2-limitations-failover_{context}"]
== Slow failover performance

Failover between nodes depends on cooperation from the clients.
When a failover occurs, MetalLB sends gratuitous ARP packets to notify clients that the MAC address associated with the service IP has changed.

Most client operating systems handle gratuitous ARP packets correctly and update their neighbor caches promptly.
When clients update their caches quickly, failover completes within a few seconds.
Clients typically fail over to a new node within 10 seconds.
However, some client operating systems either do not handle gratuitous ARP packets at all or have outdated implementations that delay the cache update.

Recent versions of common operating systems such as Windows, macOS, and Linux implement layer 2 failover correctly.
Issues with slow failover are not expected except for older and less common client operating systems.

// FIXME: I think "leadership" is from an old algorithm.
// If there is a way to perform a planned failover, let's cover it. `oc drain`?
To minimize the impact from a planned failover on outdated clients, keep the old node running for a few minutes after flipping leadership.
The old node can continue to forward traffic for outdated clients until their caches refresh.

During an unplanned failover, the service IPs are unreachable until the outdated clients refresh their cache entries.

[id="additional_network_and_metallb_limitation_{context}"]
== Additional Network and MetalLB cannot use same network

Using the same VLAN for both MetalLB and an additional network interface set up on a source pod might result in a connection failure. This occurs when both the MetalLB IP and the source pod reside on the same node.

To avoid connection failures, place the MetalLB IP in a different subnet from the one where the source pod resides. This configuration ensures that traffic from the source pod will take the default gateway. Consequently, the traffic can effectively reach its destination by using the OVN overlay network, ensuring that the connection functions as intended.