Introduction Hi. In this video we’re going to explore a feature called Layer 2 announcements. This was introduced in Cilium 1.14, and it enables you to advertise Kubernetes Service IPs locally on your network. You may already have seen examples where Cilium uses BGP to advertise Kubernetes Services beyond the cluster into the rest of the network. That works really well and has become very popular. But there are cases where you don’t want to use BGP, maybe because you don’t have BGP-capable devices or you just want something simpler for the local network. That’s what this feature is about. Instead of using BGP, we advertise Service IPs locally at Layer 2 using ARP. In the past, you would typically need MetalLB for this use case, but with Cilium you can now do it natively. Demo time In this demo I’m going to deploy a couple of pods and a Service in front of them. Then I’ll use a client outside the cluster and show how Layer 2 announcements advertise that Service to the local network. We’re sticking with the Star Wars theme, so I’m deploying a couple of Death Star pods and a Service in front of them. If I look at the Service, it currently has an internal cluster IP and a label that will matter later, but it does not yet have an external IP. What I’m going to do now is set an external IP on that Service. I’m using 12.0.0.100, and that is the address we want to advertise to the local network. At this point, if I go into a local client container on the same network and try to connect, there is still no connectivity because Layer 2 announcement has not been activated yet. Deployment Let’s look at the configuration. When we deployed Cilium, we enabled the Layer 2 announcement feature and set some basic timing parameters. But enabling the feature itself is not enough. We now need to apply a Layer 2 announcement policy. This is a custom resource called CiliumL2AnnouncementPolicy. In this policy, we specify which IP addresses we want to advertise, from which interfaces, and on which nodes. In this example, we are only advertising external IPs. We are not advertising LoadBalancer IPs in this demo. We are also only advertising Services that carry a specific label, and we are restricting the advertisement to worker nodes rather than the control plane. At the moment, my Service still has the wrong label, so even after applying the policy, connectivity still won’t work. I’m showing that deliberately because it demonstrates how granular the feature is. Now I patch the Service and change the label from red to blue so it matches the policy. As soon as I do that, connectivity starts working. Configuration Now that we have working connectivity, I want to show what’s actually happening in the background. I deploy a second Service and identify which Cilium node is currently responsible for the Layer 2 lease. I then log into the corresponding Cilium pod, install tcpdump and termshark, and start capturing traffic. From the local client, I make another request to the externally advertised Service IP. If we inspect the capture, we can see the key packet exchange. The client sends an ARP request asking who owns the IP address we advertised. The Cilium-managed node responds with the MAC address associated with that IP. That ARP response is what allows the local client to establish connectivity to the Service. So the important point here is that Cilium is responding locally to ARP on behalf of the Service IP, which is exactly what enables Layer 2 service advertisement. Conclusion This feature gives you a native way to advertise Kubernetes Service IPs on the local network without needing MetalLB. It’s especially useful when BGP is too heavy or unnecessary for your environment. I hope you found this useful. Thank you very much for watching.