I85PREP
⌘ K
Cilium Certified Associate study materials
Cilium Certified Associate study resources

On-prem clients cannot reach a Gateway API LoadBalancer IP

Cilium Certified Associate · Put your knowledge to work in context.

All case studies

On-prem clients cannot reach a Gateway API LoadBalancer IP

A platform team runs Cilium 1.16 with kube-proxy replacement, Gateway API, and the BGP control plane. They expose a Gateway prod-gw in namespace prod with listener hostname app.example.com, and an HTTPRoute in prod for app.example.com to service web. The LoadBalancer IP is 192.0.2.50 from Cilium LB IPAM. Same-VPC clients reach the app. On-prem clients fail; the on-prem router has a BGP session to the cluster's rack=frontend nodes and expects 192.0.2.0/24. cilium bgp peers shows Established on both frontend nodes. kubectl get gateway prod-gw shows Programmed=True. kubectl get httproute web -n prod shows Accepted=True. The Service web has type LoadBalancer, but the CiliumBGPAdvertisement selects services with label advertise=bgp; the Service has no such label. cilium bgp routes advertised shows no route for 192.0.2.50.

1. Why do on-prem clients fail while same-VPC clients succeed, even though the BGP session is Established and the Gateway is Programmed?

Read the worked answer

BGP Established only proves the TCP session and capability negotiation. It does not prove that any prefix is advertised. The CiliumBGPAdvertisement selects Services by label, and the web Service lacks advertise=bgp, so Cilium LB IPAM may have assigned 192.0.2.50 and the Gateway may be Programmed, but no BGP route for 192.0.2.50 is exported. Same-VPC clients can reach the IP through the cluster network or node routing; on-prem clients depend on the BGP advertisement. The missing route in cilium bgp routes advertised is consistent with this.

2. Walk through the full verification chain from Gateway to BGP route, naming the objects and commands you would inspect.

Read the worked answer

Walk the chain:

  • kubectl get gateway prod-gw -n prod -o yaml and kubectl get httproute web -n prod -o yaml for Accepted and Programmed conditions.
  • kubectl get svc web -n prod -o yaml for status.loadBalancer.ingress, the advertise=bgp label, and loadBalancerClass.
  • cilium-dbg service list (or cilium service list) to confirm the frontend and backend state.
  • kubectl get ciliumbgpclusterconfig,ciliumbgpadvertisement -A -o yaml to confirm the node selector and Service selector.
  • cilium-dbg bgp routes advertised and cilium-dbg bgp peers on a selected node to confirm the prefix and session.
  • On the on-prem router, check the received prefix and next hop.

3. After adding the label, the route still does not appear. What are three likely causes, and what would you check for each?

Read the worked answer

Three likely causes: (1) the advertisement's Service selector still does not match because the label key or value differs, or the advertisement is in a different namespace and not selected; compare the Service labels with the selector exactly. (2) The CiliumBGPClusterConfig node selector picks nodes that do not have a working BGP session to the on-prem peer, so the route is advertised from the wrong node set; check cilium bgp peers on each selected node and the node labels. (3) The LoadBalancer IP is not in the LB IPAM pool used by the advertisement, or the Service uses a different loadBalancerClass and Cilium is not the load balancer implementation; inspect the Service status and the IP pool configuration. Also check that the on-prem router's import policy accepts 192.0.2.0/24 and that the next hop is reachable.