> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # LoadBalancer IPAM > Explains Cilium LoadBalancer IPAM, configuring IP pools, allocating external IPs for LoadBalancer Services, and methods to advertise or route those IPs to the cluster In this lesson we cover Cilium's LoadBalancer IPAM: how Cilium can allocate external IP addresses for Kubernetes LoadBalancer Services and how to make those IPs reachable from your network. Why this matters * In cloud providers (for example, EKS on AWS) creating a Service of type LoadBalancer usually triggers the cloud provider to provision a load balancer and return an external IP or DNS name (for example, an [AWS ELB](https://aws.amazon.com/elasticloadbalancing/) DNS entry). * On-premise clusters typically use components like [MetalLB](https://metallb.universe.tf/) to provide external IPs. * Cilium’s LoadBalancer IPAM eliminates the need for separate tooling by allocating external IPs directly from configured pools and exposing them as the Service EXTERNAL-IP. How it looks in Kubernetes When Cilium assigns an external IP to a Service, it appears in the Service listing: ```bash theme={null} user1@control-plane:~$ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 443/TCP 36d myapp-service LoadBalancer 10.98.13.153 10.0.10.1 80:30699/TCP 170m ``` Traffic sent to that EXTERNAL-IP will be routed to the Service and then to the pods backing it, provided the network fabric advertises or forwards that IP to the cluster. How to configure LoadBalancer IPAM (CiliumLoadBalancerIPPool) Create a Cilium custom resource of kind CiliumLoadBalancerIPPool describing the address ranges Cilium can use and optional selectors that control which Services may receive external IPs. Example manifest: ```yaml theme={null} apiVersion: cilium.io/v2alpha1 kind: CiliumLoadBalancerIPPool metadata: name: blue-pool spec: blocks: - cidr: "10.0.10.0/24" - cidr: "2004::0/64" - start: "20.0.20.100" stop: "20.0.20.200" - start: "1.2.3.4" serviceSelector: matchLabels: color: red ``` Spec fields explained * apiVersion / kind / metadata.name: standard Kubernetes CR metadata. * spec.blocks: one or more blocks from which external IPs are allocated. * spec.serviceSelector: (optional) restricts allocation to Services matching the provided labels. Types of blocks supported | Block type | Description | Example | | ---------------- | --------------------------------------------------------------- | --------------------------------------------- | | CIDR | A CIDR range (IPv4 or IPv6) from which Cilium will allocate IPs | `cidr: "10.0.10.0/24"` | | Start/Stop range | An explicit sequential range between two addresses | `start: "20.0.20.100"`, `stop: "20.0.20.200"` | | Single IP | A start-only entry to represent a single IP | `start: "1.2.3.4"` | Service selector behavior * If you include spec.serviceSelector, only Services that match those labels will be eligible for external IP allocation from this pool. * In the example above, only Services labeled `color: red` will be assigned IPs from `blue-pool`. Making the allocated external IPs reachable Allocating an IP on the Service resource is only half the job — you must ensure external routing/forwarding directs traffic for those IPs to the cluster nodes. Common methods: | Mechanism | When to use | Notes | | ------------------------------- | -------------------------------------------------- | -------------------------------------------------------------------- | | BGP advertisements | Data center or network fabric supports BGP peering | Use a BGP speaker to advertise pool prefixes to upstream routers | | L2 announcements (ARP/NDP) | Simple L2 networks or when BGP is not available | Cluster nodes respond to neighbor discovery for allocated IPs | | Static routing (network config) | Small deployments or lab environments | Add static routes pointing to cluster nodes or load balancer devices | Verification and troubleshooting * Verify the pool CR exists: * kubectl get ciliumloadbalancerippool -A * kubectl describe ciliumloadbalancerippool blue-pool * Check Service allocation: * kubectl get svc myapp-service -o wide * kubectl describe svc myapp-service * Confirm network reachability: * From outside the cluster, ping or curl the EXTERNAL-IP. * Use network tools on upstream routers to verify routes or BGP advertisements. * Logs and Cilium status: * Check Cilium agent logs on nodes for IPAM-related messages. * Inspect Cilium control plane status (see Cilium documentation for cluster-specific commands). Best practices * Only include pool ranges that your network fabric can route to the cluster. * Use selectors to separate pools by environment (prod/staging) or by tenant. * Prefer advertising the entire pool prefix via BGP when possible — it simplifies routing and scales better than per-IP static routes. Links and references * [Cilium LoadBalancer IPAM documentation](https://docs.cilium.io/en/stable/loadbalancer_ipam/) * [Kubernetes Service types](https://kubernetes.io/docs/concepts/services-networking/service/) * [MetalLB project](https://metallb.universe.tf/) * [AWS Elastic Load Balancing (ELB)](https://aws.amazon.com/elasticloadbalancing/) * [BGP overview](https://en.wikipedia.org/wiki/Border_Gateway_Protocol) Important: you must ensure that external routing/forwarding is configured so traffic destined to those allocated external IPs actually reaches your cluster. Common ways to advertise or make those routes reachable include: * BGP advertisements from the cluster (peering with a router or BGP speaker). * L2 (ARP/NDP) announcements so the cluster responds to neighbor discovery for the IPs. BGP and other advertisement mechanisms are commonly used to advertise those allocated external IPs to the wider network so they become reachable. When creating pools, include only ranges that your network fabric can actually route to the cluster. Otherwise external traffic won't reach the assigned IPs even though Services will show the EXTERNAL-IP.