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.
I lost an afternoon to a “routing loop” that turned out not to be a loop at all. It was an EVPN all-active multihoming feature quietly not working in a virtual lab — and the packets ping-ponging between two switches were a symptom, not the disease. This post is two things: a refresher on how Arista ESI (Ethernet Segment) multihoming actually forwards traffic, and a write-up of the specific trap you can fall into when you build EVPN designs on vEOS/containerlab instead of real hardware. ...