Advertisement configuration

By default, BGP mode advertises each allocated IP to the configured
peers with no additional BGP attributes. The peer router(s) will
receive one /32 route for each service IP, with the BGP localpref
set to zero and no BGP communities.

You can configure more elaborate advertisements by adding a
bgp-advertisements section that lists one or more custom
advertisements.

In addition to specifying localpref and communities, you can use this
to advertise aggregate routes. The aggregation-length advertisement
option lets you “roll up” the /32s into a larger prefix. Combined with
multiple advertisement configurations, this lets you create elaborate
advertisements that interoperate with the rest of your BGP network.

For example, let’s say you have a leased /24 of public IP space, and
you’ve allocated it to MetalLB. By default, MetalLB will advertise
each IP as a /32, but your transit provider rejects routes more
specific than /24. So, you need to somehow advertise a /24 to your
transit provider, but still have the ability to do per-IP routing
internally.

With this configuration, if we create a service with IP 198.51.100.10,
the BGP peer(s) will receive two routes:

198.51.100.10/32, with localpref=100 and the no-advertise
community, which tells the peer router(s) that they can use this
route, but they shouldn’t tell anyone else about it.

198.51.100.0/24, with no custom attributes.

With this configuration, the peer(s) will propagate the
198.51.100.0/24 route to your transit provider, but once traffic
shows up locally, the 198.51.100.10/32 route will be used to forward
into your cluster.

As you define more services, the router will receive one “local” /32
for each of them, as well as the covering /24. Each service you
define “generates” the /24 route, but MetalLB deduplicates them all
down to one BGP advertisement before talking to its peers.

The above configuration also showcases the bgp-communities
configuration section, which lets you define readable names for BGP
communities that you can reuse in your advertisement
configurations. This is completely optional, you could just specify
65535:65281 directly in the configuration of the /24 if you
prefer.

Limiting peers to certain nodes

By default, every node in the cluster connects to all the peers listed
in the configuration. In more advanced cluster topologies, you may
want each node to connect to different routers. For example, if you
have a “rack and spine” network topology, you likely want each machine
to peer with its top-of-rack router, but not the routers in other
racks.

You can limit peers to certain nodes by using the node-selectors
attribute of peers in the configuration. The semantics of these
selectors are the same as those used elsewhere in Kubernetes, so refer
to
the
labels documentation on
the Kubernetes website.

For example, this is a (somewhat contrived) definition for a peer that
will only be used by machines:

With hostname hostA or hostB, or

That have the rack=frontend label, but not the label network-speed=slow: