Support LACP bonded network interfaces

[Bowser1704]

Problem

On many GPU training nodes, dual-port NICs (e.g., ConnectX-7 with 2 physical ports) are bonded together using LACP (802.3ad) at the infrastructure level. This is not a vendor-specific setup — CX7 is a single PCIe device with two ports, and in many network environments (e.g., rail-optimized fabrics), the two ports are configured as an LACP bond rather than exposed as two independent interfaces. The bonding happens at the OS/network level, not at the hardware level.

A typical H20 GPU node topology:

PCIe 0000:7f:00.0 (CX7, 2 ports) → bond0 (LACP 802.3ad)
PCIe 0000:c7:00.0 (CX7, 2 ports) → bond1 (LACP 802.3ad)
PCIe 0001:08:00.0 (CX7, 2 ports) → bond2 (LACP 802.3ad)
PCIe 0001:a2:00.0 (CX7, 2 ports) → bond3 (LACP 802.3ad)

dranet discovers these bond interfaces and publishes them in the ResourceSlice. However, when a pod claims one, Prepare fails because bond devices with LACP cannot be moved into a pod network namespace:

• Moving the bond breaks LACP negotiation with the switch
• Moving individual slave ports out of the bond is not supported by the kernel
• The bond must remain in the host namespace to maintain link aggregation

Relationship to #63

#63 proposes using IPvlan to share a single NIC across multiple pods, using allowMultipleAllocations and consumable capacity to model the sharing.

This issue is different. We are not trying to share — the user still wants exclusive use of the NIC. The problem is purely that the bond cannot be moved. IPvlan here is a transport mechanism to work around the LACP constraint, not a sharing mechanism.

From the user's perspective, claiming a bonded NIC should feel the same as claiming a regular NIC — they should not need to know whether the underlying interface is a bond or not.

Proposal

When dranet detects that a network interface is a bond in LACP mode, it should automatically create an IPvlan child interface and move the child into the pod's namespace, instead of attempting to move the bond itself.

Host namespace:                    Pod namespace:
  bond0 (LACP, stays on host)       ipvlan0 ← child of bond0
  bond1 (LACP, stays on host)       ipvlan1 ← child of bond1
  bond2 (LACP, stays on host)       ipvlan2 ← child of bond2
  bond3 (LACP, stays on host)       ipvlan3 ← child of bond3

This should be transparent to the scheduler and to the user:

• The bond is published in the ResourceSlice as a normal device (no allowMultipleAllocations, no capacity)
• The user requests it with a normal allocationMode: All or ExactCount
• The scheduler allocates it exclusively as usual
• During Prepare / RunPodSandbox, dranet detects the bond + LACP and creates an IPvlan child instead of calling ip link set netns

The detection logic could be:

1. Check if the interface is a bond (/sys/class/net/<ifname>/bonding/mode)
2. If the bond mode is 802.3ad (LACP) or other modes where moving is unsafe, create an IPvlan child
3. Move the IPvlan child into the pod namespace and configure it (IP, routes, etc.)

RDMA char devices (/dev/infiniband/uverbs*, rdma_cm) would be injected alongside as in the existing IB-only path.

[Bowser1704]

cc @gauravkghildiyal @ngcxy

[aojea]

The Linux kernel operates on two distinct hierarchical relationships for network interfaces:

• Enslaved (Master/Slave): Managed via MasterIndex. Used for bonds, bridges, and VRFs. The slave interfaces forward traffic to the master.
• Linked (Parent/Child): Managed via ParentIndex. Used for stacked virtual devices like ipvlan, macvlan, and vlan. The child interface relies on the parent's underlying physical link.

The proposal suggests hacking a Linked device (ipvlan) creation into the runtime to bypass an Enslaved device (bond) limitation. By hardcoding this logic (e.g., "if device is bond and LACP, then create ipvlan"), we lose the ability to express these abstractions cleanly.

Now brainstorming with all of you here:

1. Discovery and Inventory Representation

We may expose the Master and Parent relationships in the DRA device attributes during discovery, and export them as standard device attributes (dra.net/master and dra.net/parent). This makes the topology transparent to the control plane and the scheduler.

2. Subinterface creation

Instead of depending on the Shareable devices we add a new field to the API to explicitly request the creation of a linked device.

// InterfaceConfig represents the configuration for a single network interface.
type InterfaceConfig struct {
	// Link specifies that instead of using the allocated interface directly,
	// a virtual linked device should be created on top of it (acting as its parent).
	// This models the kernel's ParentIndex abstraction (e.g. ipvlan, macvlan).
	Link *LinkConfig `json:"link,omitempty"`
}
type LinkConfig struct {
	// Type is the type of the linked device (e.g., "ipvlan", "macvlan", "vlan").
	Type string `json:"type"`
	// Mode is the operation mode for the linked device, if applicable.
	// For example, "l2" or "l3" for ipvlan.
	Mode string `json:"mode,omitempty"`
}

In this example dranet this will work this way:

1. discovers bond0 and its enslaved physical ports (eth0, eth1), exposing their relations via dra.net/master attributes
2. the user/scheduler allocates the bond0 device exclusively,
3. The infrastructure/cloud provider profile returns a NetworkConfig for the pod that specifies:

interface:
  link:
    type: "ipvlan"
    mode: "l2"

4. The dranet driver reads the config, sees the explicit link instruction, creates the ipvlan interface on top of the allocated bond0, and moves the ipvlan into the pod namespace.

I think this will also works for any interface in general and for #63 and also will allow us to remove the dependency on more complex APIs just for the happy case, we will need to use later for bw allocation and more compelx network setups

@gauravkghildiyal WDYT?