Learn MetalLB - Advanced BGP (Communities, LocalPref, Aggregation)

#Introduction

In episodes 6 and 8 you already touched basic BGP: peering, advertisement, and some options. Episode 16 takes BGP to the next level — advanced BGP that leverages BGP's built-in mechanisms to control route behavior on large networks: communities for tagging, local preference for priority, prefix aggregation for efficiency, multi-hop peering, and the route reflector topology.

Why does this matter? On large networks, routing policy isn't managed per-route, but per-group of routes. Community is how you group routes; localPref is how you rank them; and route reflectors are how you distribute routes without building countless peering sessions. These three are the language professional network engineers speak.

#Communities: Tagging Routes

#The Community CRD for Human-Friendly Names

A BGP community is a two-part value like 64512:100. These numbers are hard to remember, so MetalLB provides the Community CRD to give those values names:

apiVersion: metallb.io/v1beta1
kind: Community
metadata:
  name: komunitas-perusahaan
  namespace: metallb-system
spec:
  communities:
    - name: PROD_NO_EXPORT
      value: "64512:1"
    - name: INTERNAL_ONLY
      value: "64512:2"

Once the CRD is created, advertisements can reference communities by a readable name:

apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: bgp-prod
  namespace: metallb-system
spec:
  ipAddressPools:
    - prod-pool
  communities:
    - PROD_NO_EXPORT

communities: PROD_NO_EXPORT attaches the community value 64512:1 to all routes from prod-pool. Routers outside your network can use this tag to decide whether a route may be propagated further — for example, refusing to export production routes to an upstream network.

#Why Tagging Is Useful

Tagging lets network policy be applied without touching MetalLB: network engineers just write rules on routers based on the community. This separates responsibilities — the platform team manages what's advertised, the network team manages how routes are treated.

#Local Preference

#Ranking Routes

Local preference is the attribute that determines route priority within an AS. Routes with higher values are preferred. MetalLB can set it per advertisement, so routes from one pool can be prioritized over another:

apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: bgp-primary
  namespace: metallb-system
spec:
  ipAddressPools:
    - primary-pool
  localPref: 200

localPref: 200 makes routes from primary-pool more preferred than routes with the default value of 100. This is useful for directing traffic along the primary path, only falling back to the backup path when the primary is gone.

#Prefix Aggregation

#Shrinking the Routing Table

The more Services you have, the more per-IP routes are advertised — the router's routing table bloats. aggregationLength groups adjacent IPs into shorter prefixes:

apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: bgp-aggregated
  namespace: metallb-system
spec:
  ipAddressPools:
    - prod-pool
  aggregationLength: 24

aggregationLength: 24 advertises a single 192.168.20.0/24 route instead of many /32 routes, as long as all Service IPs fall within the same subnet. The trade-off: traffic to IPs not yet used by a Service still enters the cluster, then gets dropped at the IP level — loading nodes with unnecessary traffic, as we touched on in episode 8.

#When Aggregation Is Worth It

• Worth it if almost all IPs in the subnet will be used by Services.
• Not worth it if small pools are scattered across many subnets.
• Combine with the pool planning in episode 17 for best results.

#Multi-Hop & External Peers

#Peering to Routers Outside the Subnet

BGP's default requires the peer to be on a directly connected network (single-hop). To reach a router outside the subnet — for example, a core router in a data center — enable multiHop:

apiVersion: metallb.io/v1beta1
kind: BGPPeer
metadata:
  name: core-dc
  namespace: metallb-system
spec:
  myASN: 64500
  peerASN: 64550
  peerAddress: 10.0.0.1
  multiHop: true
  holdTime: 180s

multiHop: true allows peering to 10.0.0.1, which isn't on a directly connected network. For multi-hop peering, the BGP TTL is raised from 1 to 255, and a longer holdTime is usually needed because the path is farther.

#Verifying Sessions with External Peers

kubectl get bgppeer
kubectl describe bgppeer core-dc

kubectl describe bgppeer core-dc shows the session condition and details like Established status. Also make sure the TCP path to the peer is open in the firewall (episode 13) — because the peer is on another subnet, there's likely a firewall in between.

#Route Reflector Topology

#Why Route Reflectors Are Needed

With many routers and many nodes, full-mesh peering becomes impractical — the number of sessions grows quadratically. Route reflectors solve this: one router receives routes from clients (nodes), then forwards them to other clients. Each node only needs to peer with one or two route reflectors, not with every router.

show bgp neighbors 192.168.0.10 received-routes

show bgp neighbors 192.168.0.10 received-routes on the router side shows the routes received from that peering session. In a route reflector topology, MetalLB nodes are usually the clients, and the reflector spreads the routes across the whole network.

#Design Practice

• Place route reflectors where they're always available (for example, two reflectors for redundancy).
• Each node peers with two reflectors, not with every router.
• Other routers only receive routes from the reflectors — simplifying policy on the network side.

#Conclusion

Episode 16 completes advanced BGP: communities via the Community CRD, local preference for route priority, prefix aggregation for efficiency, multi-hop peering to external routers, and the route reflector topology for large networks.

Key takeaways:

• The Community CRD gives names to hard-to-remember community values.
• communities in BGPAdvertisement attaches tags for router-side policy.
• localPref ranks routes so the primary path is preferred.
• aggregationLength shrinks the routing table at the cost of precision.
• multiHop: true enables peering to routers outside the subnet.
• Route reflectors reduce the number of peering sessions on large networks.

In the next episode, episode 17, we'll discuss IP planning & network scale — how many Services can be handled, the ARP and BGP limits, large pool strategies, and how to avoid IP exhaustion and allocation fragmentation.