Skip to content

Connecting Cilium Clusters with External Networks: CCA practice questions

Making workloads reachable from outside a Cilium cluster usually combines three pieces: something that assigns addresses to Services, something that tells the network where those addresses live, and the datapath that actually forwards packets.

By Ibrahim Yesilay · Published · Updated

Independent community practice, not affiliated with or endorsed by CNCF or The Linux Foundation.

What Connecting Cilium Clusters with External Networks covers in CCA

Making workloads reachable from outside a Cilium cluster usually combines three pieces: something that assigns addresses to Services, something that tells the network where those addresses live, and the datapath that actually forwards packets.

LB IPAM covers the first piece where no cloud load balancer exists. It assigns IPs to Services of type LoadBalancer from CiliumLoadBalancerIPPool resources. The feature is always present but dormant until the first pool is created. Pools can be limited to certain Services with a serviceSelector, and allowFirstLastIPs set to No keeps network and broadcast addresses out of CIDR blocks.

For announcing addresses, BGP Control Plane peers with external routers, such as the top-of-rack peers in the docs' examples. It is enabled with bgpControlPlane.enabled=true and configured with custom resources. A CiliumBGPClusterConfig selects nodes and defines BGP instances with a localASN and peers. A CiliumBGPPeerConfig holds shared session settings: timers, an authSecretRef for a TCP MD5 password, eBGP multihop, graceful restart and address families. CiliumBGPAdvertisement resources, chosen by a label selector in each family, decide what is announced: PodCIDR, CiliumPodIPPool, Service addresses or interface IPs. Without a matching advertisement nothing is announced. Instances do not listen for incoming sessions unless localPort is set. Because the speaker lives in the agent, graceful restart keeps routes in the peer during agent restarts. Service advertisements respect externalTrafficPolicy: Local by advertising only from nodes with a local endpoint. BGP Control Plane does not program the datapath and must not be used for reachability inside the cluster; troubleshooting uses cilium bgp peers and cilium bgp routes.

Where the network has no BGP, such as an office or campus LAN, L2 announcements (beta) answer ARP or NDP queries for LoadBalancer or external IPs. One elected node per Service replies and load-balances the traffic, and the address moves if that node fails. The feature is selected through CiliumL2AnnouncementPolicy, requires the kube-proxy replacement, and does not work with externalTrafficPolicy: Local.

Pods themselves can also be reached directly. Advertising pod CIDRs over BGP lets routers send traffic to pods without NAT or load balancers, while native routing between nodes relies on the network routing pod CIDRs or on routes installed per node. Outbound traffic is handled separately by masquerading and the egress gateway.

Key points

  • LB IPAM assigns LoadBalancer IPs; BGP or L2 announcements make them reachable.
  • CiliumBGPClusterConfig, CiliumBGPPeerConfig and CiliumBGPAdvertisement split instances, session settings and prefixes.
  • A BGP instance initiates sessions only unless localPort is configured.
  • L2 announcements need kube-proxy replacement and cannot be combined with externalTrafficPolicy: Local.

Three sample questions

13 CCA questions on Connecting Cilium Clusters with External Networks, 13 with explanations. How practice works

Question 1

In the current Cilium BGP Control Plane, which resource selects nodes with a nodeSelector and defines BGP instances with a localASN and a list of peers?
  1. A.CiliumBGPClusterConfig
  2. B.CiliumBGPPeeringPolicy
  3. C.CiliumBGPRouter
  4. D.CiliumBGPAdvertisement

Correct answer: A

CiliumBGPClusterConfig defines BGP instances for the nodes matched by its nodeSelector; each instance has a name, a localASN and peers with peerASN, peerAddress and a peerConfigRef. Why the other options are wrong. CiliumBGPPeeringPolicy is the older v1 resource and is no longer part of the documented resources. CiliumBGPRouter does not exist. CiliumBGPAdvertisement defines which prefixes are advertised, not the instances and peers.

Sources: Cilium docs: BGP Control Plane Resources, Cilium docs: BGP Control Plane

Question 2

What does Cilium's BGP implementation enable?
  1. A.Replacing internal Kubernetes CNI functionality
  2. B.Exposing Kubernetes services to external networks without cloud load balancers
  3. C.Direct connection between pods across multiple clusters
  4. D.Automatic service mesh capability

Correct answer: B

Cilium's BGP implementation enables exposing Kubernetes services to external networks without cloud load balancers by advertising service IPs via BGP to external routers.

Question 3

Which command would you use to check the status of BGP peers in Cilium?
  1. A.cilium bgp peers
  2. B.cilium status bgp
  3. C.kubectl get ciliumbgppeers
  4. D.kubectl describe bgp

Correct answer: A

The "cilium bgp peers" command is used to check the status of BGP peers in Cilium, showing information about peering sessions and their state.

Practice this topic

Focus mode keeps every question on Connecting Cilium Clusters with External Networks until you leave it. 10 free guest answers, then a free account; no credit card.

Or open CCA practice across all topics.

Sources

The explanation above was checked against these official documents.

Frequently asked questions

Why do peers show established sessions but receive no routes?

Prefixes are only announced when a CiliumBGPAdvertisement matches the advertisements selector of the peer config address family; by default nothing is advertised.