Post

topics for subsequent posts: - IPv6 address planning to run #cilium in native routing with cluster pool vs. multi-pool ipam. - Cilium BGP control plane with LB IPAM and GatewayAPI for ingress - Predictable egress IP without using an egress gateway (aka no SNAT/masquerading) Stay tuned ;)

Also cover BGP ECMP/Anycast of pods + seperate GUA addressing for unique unicast per node to eliminate the need for GENEVE or other host-to-host tunnelling. Would love to see a single blog post or blog post that covers this end-to-end.

I’m planning to cover just that in part4. Still working on part 3 this week😅 but yes I do have a working architecture/config with #cilium that uses native routing i.e no tunneling or masquerading. Each namespace gets a clean /64 using multi-pool ipam. POD addresses announced via BGP.

pod to pod and pod to wan is Unicast. Ingress has to be a virtual IP. It’s basically a load balancer for your Pods. Albeit, since Cilium uses Envoy proxy as L7 proxy underneath it preserves the original source IP. So when user traffic reaches pod it sees real source IP

Envoy uses a feature within the Linux Kernel called TPROXY (transparent proxy). So technically your application sees the original client IP and not the reverse proxy IP, if that helps. Now granted I have never worked with SIP so I could be mistaken.

Quick research suggests TPROXY is ossified and limited only to TCP/UDP. This leaves out all other standardised layer 3/4 protocols (including native IPSec in IPv6 without UDP encap hack).

0 reposts0 likes

I am not K8s pro, but in Docker this is easily achieved: Use different subnets for Anycast/unicast, container is exposed to WAN on both subnets natively, no reverse proxy. As long as container app talks SIP/Other protocols, it should work. BGP handles routing with the leave switches.