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
Overview This document outlines the security policies and dynamic routing configurations for the network gateway, including firewall rules via nftables and BGP peering via BIRD. How Zones are Defined and Connected In this architecture, zones (zone_blue, zone_green, zone_red, and wan) directly correspond to network interfaces (either physical NICs, VLAN tags, or bridge interfaces) on the Gateway Server. Chain Structure (nftables): The firewall strictly controls traffic flow by matching the input interface (iif) and output interface (oif). For example, iif zone_blue oif zone_green tcp dport 22 accept explicitly states: If a packet enters the server via the zone_blue interface and is destined to leave via the zone_green interface on TCP Port 22, allow it. ...
Overview This document describes a method for simulating multiple servers belonging to different network domains on a single Linux host. Each simulated server runs inside its own Linux network namespace and is connected to a dedicated VLAN. Training and demonstration environments Each namespace behaves as an independent server with: Its own IP address Its own MAC address An SSH service A simple HTTP server Network Topology The Linux host uses the following interfaces: ...
We run multiple teams on the same OpenStack platform, one project per team. Traffic between two projects always hairpins through the gateway nodes, even with DVR enabled. This is expected behavior, not a misconfiguration. Below is the technical summary of why. What DVR distributes East-west between networks on the same router: routed locally on the ingress chassis, tunneled to the destination chassis. Fully distributed. North-south with a floating IP: the chassis hosting the VM performs the 1:1 NAT and answers ARP for the FIP on the external network. Distributed, but requires the provider network to be attached to every compute node and distributed FIP to be enabled. North-south with SNAT: centralized. The router’s external address is shared by all VMs behind it; it can be ARP-owned at only one point of the external segment, and the NAT state must live in a single conntrack table. It is pinned to a gateway chassis by design. DVR distributes only what it can bind 1:1 to a single chassis. Everything based on a shared, stateful address is centralized. ...