The multi-homed node from the previous post has two equal-cost layer 3 uplinks. The kernel’s multipath hash never sees the flow — Cilium’s bpf_fib_lookup carries L3 only. Feeding it the flow label and the L4 ports makes ECMP real, on the default hash policy. With the help of AI coding with my stupid ideas, cilium distributes traffic to both uplinks.
Two L3 uplinks per node, address on dummy0, BGP unnumbered to the fabric, and Cilium peering with the node’s own FRR over a single ::1 session that carries both address families — so no Kubernetes manifest ever contains a TOR address.
How L3VPN affects Kubernetes and when it is meaningful?
An alternative Cilium Egress Gateway that removes state synchronization and conntrack overhead in active-active multi-gateway setups from the gateway
Dual-homed servers use IP-unnumbered physical interfaces. A dedicated dummy interface (not lo) is assigned to each server as its IPv4 node address. FRR runs between the servers and the ToR switches to provide node-level connectivity, advertising the server’s node IP (dummy interface address) and receiving the default route from the ToRs. Using a bond interface between ToRs can also be used for redundancy and failover for server connectivity. You may also configure Layer 3 interfaces. The main issue is about node identity and service continuity during the failure of a single link. Using a bond interface or a dummy interface seems like a more usable approach. ...