Learn MetalLB - BGP Mode

#Introduction

In episode 5 you felt the main limitation of Layer 2 mode: all Service traffic must pass through a single leader node. BGP mode is the answer to that problem. Instead of announcing IPs via ARP, the speaker does BGP peering with external routers and advertises Service IP prefixes as network routes.

With BGP, every node advertises the same routes to the routers. The routers can then use ECMP (Equal-Cost Multi-Path) to spread traffic across many nodes at once — overcoming the single-node throughput limit while being more resilient to node failures. This episode covers how it all works.

#What Is BGP Mode

#The Basic Idea

In BGP mode, the speaker on every node builds a BGP peering session with one or more routers. Every IP allocated by the controller is advertised as a route, usually in the form of an aggregated prefix. The router that receives the route adds the prefix to its routing table and forwards traffic to the nodes advertising it.

#Differences from Layer 2

The key differences between the two modes:

• Layer 2 announces IPs from one leader node; BGP advertises prefixes from all nodes.
• Layer 2 needs no special router; BGP needs a router that supports peering.
• Layer 2 funnels traffic through one node; BGP spreads traffic via ECMP.

That's why BGP mode is the primary choice for networks with real routers and large throughput scaling needs.

#BGPPeer: Defining the Peering Relationship

#Basic Peer Configuration

BGPPeer defines the router that becomes your peering partner. Here's an example peer to an FRR router on your network:

apiVersion: metallb.io/v1beta1
kind: BGPPeer
metadata:
  name: frr-router
  namespace: metallb-system
spec:
  myASN: 64500
  peerASN: 64512
  peerAddress: 192.168.1.254
  holdTime: 90s

myASN is the ASN used by MetalLB, peerASN is the router's ASN, and peerAddress is the router's IP address, which must be reachable from all nodes. holdTime: 90s sets how long a session is considered alive without a keepalive message.

#Verifying the Peering Session

Once the peer is created, make sure the BGP session establishes:

kubectl get bgppeer
kubectl describe bgppeer frr-router

kubectl get bgppeer lists the peers. Detailed status like Established can be seen in the events of kubectl describe bgppeer frr-router or via speaker logs — something we'll dig into more in episodes 13 and 19.

#BGPAdvertisement: Advertising IPs to Routers

#The Resource That Activates Advertisements

Without a BGPAdvertisement, allocated IPs won't be advertised even if the peering session is established. This resource connects pools to the BGP sessions:

apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: bgp-basic
  namespace: metallb-system
spec:
  ipAddressPools:
    - first-pool
  peers:
    - frr-router

With this configuration, all IPs from first-pool will be advertised to the frr-router peer. The peers section is optional — if left empty, the advertisement applies to every defined peer.

#Checking Routes on the Router

To make sure the advertisement is accepted, check from the router side. On a router with a Cisco, Juniper, or Mikrotik CLI, check the routes received from MetalLB:

show ip bgp
show ip route bgp

The show ip bgp command on the router shows the prefixes advertised by MetalLB, and show ip route bgp shows the routes active in the routing table. If the prefix is visible, the advertisement worked.

#ECMP: The Main Power of BGP Mode

#Traffic Spread Across Many Nodes

Because all nodes advertise the same prefix, the router sees many equal-cost paths to that prefix. This triggers ECMP: the router spreads packets across those nodes round-robin or by hash.

kubectl get pods -n metallb-system -o wide
traceroute -n 192.168.1.200

If your network applies ECMP, traceroute -n 192.168.1.200 from several different hosts may show different next-hops — proof that traffic is being spread. Note that the distribution behavior depends on the router's hash algorithm; per-flow traffic generally still goes to a single node.

#Tolerance for Dead Nodes

When a node dies, its BGP session drops, and the router removes the dead path from its table. Traffic then shifts to the other nodes still advertising the prefix — without the ARP failover that Layer 2 needs. This is BGP's high availability advantage, which we'll explore in episode 15.

#Characteristics and Requirements

#Advantages

• Total throughput isn't limited to one node because ECMP spreads the load.
• Node failover is faster and cleaner at the network level.
• Can integrate with enterprise routing, firewalls, and large topologies.

#Requirements and Limitations

• Requires a router that supports BGP (Cisco, Juniper, Mikrotik, or open-source FRR).
• Network configuration is more complex — ASNs, peering, and firewalls must be set up.
• Without proper ECMP, a single node can still become a bottleneck.

#Open-Source Router Options

If your team doesn't have a physical router, FRR (Free Range Routing) can run as a Linux container for simulation. That's the option we use in many labs in the upcoming episodes, especially when covering multi-peer and route reflectors in episode 16.

#Conclusion

Episode 6 completes BGP mode: the speaker peers with routers via BGPPeer, prefixes are advertised via BGPAdvertisement, and ECMP lets traffic spread across many nodes at once — overcoming Layer 2's single-node limit.

Key takeaways:

• BGP mode requires BGPPeer for peering and BGPAdvertisement for route advertisement.
• All nodes advertise the same prefix; routers use ECMP to spread traffic.
• Node failover is cleaner because routers drop dead paths.
• This mode needs a BGP router — Cisco, Juniper, Mikrotik, or open-source FRR.
• An established peering session is an absolute prerequisite for advertisement to work.

In the next episode, episode 7, you'll create your first LoadBalancer Service — deploy an application, expose it via type: LoadBalancer, verify the assigned external IP, test access from outside the cluster, and handle the three most common troubleshooting problems early in your MetalLB usage.