Configure Multi-Homing in Cilium for Multiple Network Interfaces (2026)

Cilium can leverage multiple network interfaces on a node, but it doesn’t automatically distribute traffic across them for pod networking.

Let’s see how this works in practice. Imagine a node with two network interfaces: eth0 and eth1. By default, Cilium will likely bind its agent and allocate IP addresses for pods to eth0. If eth1 is also connected to the network and capable of routing traffic, Cilium won’t inherently know to use it for pod communication unless explicitly told.

Here’s a simplified view of what happens under the hood. Cilium’s agent, cilium-agent, runs on each node. It’s responsible for managing network connectivity for pods, including IP address management (IPAM) and routing. When a pod needs an IP, cilium-agent assigns one from a pre-configured pool. This IP is then routed into the cluster network. If the node has multiple interfaces, cilium-agent needs to be configured to understand which interface(s) should be used for this pod traffic.

Consider this scenario:

# Example cilium-config.yaml on a node
apiVersion: v2
kind: CiliumConfig
metadata:
  name: cilium-node-config
spec:
  ipam:
    mode: "kubernetes"
  tunnel:
    mode: "vxlan"
  devices:
    - eth0
    - eth1 # This line is crucial for multi-homing

In this CiliumConfig, we’ve explicitly listed eth0 and eth1 under the devices field. This tells cilium-agent that both interfaces are available for use. When cilium-agent starts, it will attempt to bind to these interfaces. If eth1 is properly configured on the host (e.g., has an IP address, is up, and connected to the network), Cilium will now consider it for pod networking.

The devices field is the primary lever for multi-homing. When you specify multiple devices, Cilium will:

IP Address Allocation: If using an IPAM mode like kubernetes or eni, Cilium will attempt to allocate IPs from its pool and associate them with the specified devices. This might involve configuring IP address blocks on these interfaces.
Routing: Cilium programs host routes and BGP (if applicable) to ensure that traffic destined for pod CIDRs can be routed correctly through the chosen interfaces. For example, it will add routes to the node’s kernel routing table pointing to the pod CIDRs via the IP addresses assigned to eth0 or eth1.
Agent Binding: The cilium-agent itself might bind to one or more of these interfaces for its own communication or for intercepting and forwarding pod traffic.

Let’s look at a more concrete example of how you might apply this. If you’re using the host-gw mode for CNI, Cilium programs routes on the host. With multi-homing, you’d expect routes to be programmed for the pod CIDR that point out of both eth0 and eth1 (if both are configured and active).

A common setup is to have one interface for management/control plane traffic and another for data plane/pod traffic. For instance, eth0 could be your primary uplink, and eth1 could be a dedicated interface for Kubernetes node-to-node communication or even directly for pod traffic.

The surprising thing about multi-homing in Cilium is that it’s not just about advertising routes for pod CIDRs; it’s also about how Cilium’s internal networking stack and its IP Address Management (IPAM) integrate with the underlying host interfaces. Without explicit configuration in CiliumConfig’s devices field, Cilium might default to using only the primary interface it detects, leaving other potentially active interfaces unused for pod networking.

To verify your configuration, you can check the cilium-agent logs on the node. Look for messages indicating which devices it’s binding to or using for IPAM. You can also inspect the node’s routing table using ip route show and look for routes related to your pod CIDR that are associated with the IP addresses on your multiple interfaces.

# On a node with Cilium running
cilium status --verbose
ip route show | grep <your-pod-cidr>

If eth1 is correctly configured and included in CiliumConfig.spec.devices, you should see routes for your pod CIDR that egress via eth1’s IP address, in addition to any routes via eth0.

The one thing most people don’t know is that Cilium’s device configuration isn’t just for IPAM; it also influences which interfaces are considered for its own internal network services and agent communication, especially when using features like BGP or direct routing modes where the agent needs to establish direct connectivity to other nodes over specific interfaces. This means that even if a network interface is technically up and routable, Cilium might not leverage it for pod traffic unless it’s listed in the devices configuration.

Once you’ve successfully configured multi-homing, the next challenge is often load balancing and ensuring even distribution of traffic across these multiple interfaces for your pods.