Learn MetalLB - Layer 2 Mode

#Introduction

Now that you understand IP pools from episode 4, let's talk about how to announce IPs to the network. Layer 2 mode is the simplest and most commonly used mode to start with — it doesn't need routers, doesn't need BGP, and works on almost any switch network.

But this simplicity comes with trade-offs you need to understand well: only one node actively handles traffic for a given IP, so all Service traffic flows through that single node. This episode covers the ARP/NDP mechanism, leader election, failover, and the limitations you must keep in mind.

#What Is Layer 2 Mode

#The Basic Idea

In Layer 2 mode, the speaker on one elected node announces the Service IP using ARP (for IPv4) or NDP (for IPv6). When a device on the network asks "who owns 192.168.1.200?", the elected node answers with its MAC address. From the network's point of view, the Service IP appears to live on a node.

Each Service IP is announced by one node independently. That means Service A could be announced from node 1, while Service B is announced from node 2. The announcing node is called the leader for that IP.

#Why It's Called Layer 2

The protocols used (ARP/NDP) operate at the second layer of the OSI model — the data link layer. No routing is involved: every device in the same broadcast domain can reach the Service IP directly because they know its MAC address.

#L2Advertisement: Configuring Announcements

#The Resource That Activates the Mode

L2Advertisement is the resource that makes IPs announced over Layer 2. Its minimal configuration references a pool:

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2-basic
  namespace: metallb-system
spec:
  ipAddressPools:
    - first-pool

#Verifying the Announcement

Once a Service gets its IP, check that the elected node's MAC address actually answers on the network:

arping -c 3 192.168.1.200
ip neigh show 192.168.1.200

arping -c 3 192.168.1.200 run from another machine on the network will be answered by the MetalLB leader node. The ip neigh show 192.168.1.200 output shows the MAC of the announcing node — real proof that Layer 2 mode works.

#Leader Election and Failover

#How the Leader Is Chosen

For each Service IP, the speakers on all nodes take part in an election process. The winner becomes the leader that announces the IP. The election result is easy to see:

kubectl get pods -n metallb-system -o wide
kubectl logs -n metallb-system -l component=speaker --tail=20

The speaker logs show lines like Announcing 192.168.1.200 from node worker-2 for the elected node. kubectl logs -n metallb-system -l component=speaker is the standard way to check who leads each IP.

#Failover When a Node Dies

This is Layer 2 mode's main advantage: if the leader node dies, speakers on other nodes detect it and one of them becomes the new leader automatically. Failover usually takes a few seconds to a dozen seconds, depending on the detection configuration.

kubectl drain worker-2 --ignore-daemonsets
kubectl get pods -n metallb-system -o wide

After kubectl drain worker-2 --ignore-daemonsets, notice that the IP announcement moves to another node. One important thing: L2 failover depends on the network detecting the ARP change — client hosts typically redo their ARP lookup when a connection breaks, so failover is felt as a brief session interruption.

#Characteristics and Limitations

#All Traffic Through One Node

Because only the leader answers ARP, all inbound and outbound traffic for that IP goes through the leader node. Inbound traffic is received by the leader node, then forwarded to pods using kube-proxy or the CNI. No other node ever receives traffic for that IP unless it becomes the new leader.

The direct implication: a Service's throughput capacity is limited by the leader node's bandwidth and resources. For large scale, this mode isn't the best choice — that's where BGP mode (episode 6) excels with ECMP.

#No BGP, No Special Router

Layer 2 mode doesn't need a router that supports BGP, doesn't need peering configuration, and works on simple switch networks. This is the main reason this mode is recommended for getting started. As a consequence, MetalLB IPs must be in the same subnet as the devices accessing them.

#Tolerance for ARP Cache Limitations

Client devices cache ARP entries, so when the leader changes, clients' caches still point at the old MAC. MetalLB sends gratuitous ARP to update the cache, but clients that cache aggressively may need a few seconds to catch up. For Services with strict session persistence, factor this into your design.

#Practice: Setting Up L2 for Multiple Pools

#One Advertisement for Multiple Pools

Advertisements can reference more than one pool. This is useful when you want to announce all pools over Layer 2 with a single resource:

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2-multi
  namespace: metallb-system
spec:
  ipAddressPools:
    - first-pool
    - reserved-pool

#Per-Node and Per-Interface Limits

By default, a single leader node can announce many IPs at once. Controlling which interfaces and nodes may announce is covered in full in episode 8. For now, what matters is that each IP is announced independently, and leader election runs per IP.

#Conclusion

Episode 5 completes Layer 2 mode: how ARP/NDP is used to announce IPs from the leader node, how the leader is chosen and failover works when a node dies, and the trade-off where all Service traffic must pass through one node.

Key takeaways:

• Layer 2 mode uses ARP (IPv4) and NDP (IPv6) from one leader node per IP.
• L2Advertisement activates Layer 2 announcements for a given pool.
• If the leader node dies, another node is automatically elected as the new leader.
• All Service traffic enters through the leader node — throughput is limited by that node.
• This mode needs neither BGP nor a special router, and is a great way to get started.

In the next episode, episode 6, we'll discuss BGP mode — how MetalLB peers with routers (Cisco, Juniper, Mikrotik, or FRR), the BGPPeer and BGPAdvertisement configuration, and the ECMP advantage that lets traffic spread across many nodes at once. This is the way out of Layer 2's single-node limitation.