Architect tier · Direct NIC
Supported hardware for Direct NIC
Direct NIC wires a lab device straight to one of your server's real network cards, so the RFC 2544 and Y.1564 testers measure real hardware and whatever's on the cable - not a simulation. This page lists exactly which cards we've proven, which ones should work, and which ones we refuse on purpose. Plain and honest, no hype.
What Direct NIC does
A lab device's port can skip the virtual lab network and be wired straight to a real network card on the server. For containers, the card is moved into the device's own network namespace; for QEMU devices, the card is handed to the VM directly (with the card's own MAC address) using a passthrough adapter. The card leaves the host's control for as long as the device uses it, and is handed back - settings restored - the moment the device stops, crashes, or is cleaned up automatically. Because of that hand-over, the card can never be the one you manage the server through, and it can't carry your server's own IP address. The RFC 2544 / Y.1564 testers, the traffic and multicast tools, and packet capture all work over a Direct NIC port, so a test run over one measures the real card and whatever is connected to it.
The three statuses
Every card falls into one of three buckets. We only ever move a card into "Verified" after running our own full proof on that exact card, on real (non-virtual) hardware - never by reasoning about what "should" work.
| Status | What it means |
|---|---|
| Verified | netplex. ran the full proof on this exact card family on real, non-virtual hardware: attach and detach, a crash-recovery sweep that gets the card back automatically, settings restored exactly, a real frame seen on the far end of a cable, and a real RFC 2544 test run passing through a real device. The row names the driver, the date and the proof. |
| Expected to work | The card uses a standard, in-kernel Linux driver that supports the modes Direct NIC needs (promiscuous mode, MAC passthrough, moving into a namespace). We have not personally tested this exact card yet. Shown in the app as "not yet verified by netplex.". |
| Not supported | Either the card genuinely can't do what's needed, or we refuse it on purpose for safety - the card that manages your server, a card carrying your server's own address, a Wi-Fi adapter, and so on. |
A card that matches none of these tables is shown as Unknown (the same amber as "Expected") and is still allowed if every safety check passes - this list is a promise about what we've personally checked, not a wall that blocks everything else.
Verified - bare metal
Honest state today: this table is empty. Every machine we've tested Direct NIC on so far is itself a virtual machine, not a real physical server - so the only proof we have right now is the nested case below (a virtual network card on a real hypervisor). Getting real, physical hardware verified is active, in-progress work - see the row below and our roadmap. Until then, we don't call Direct NIC "verified on real hardware" anywhere on this site - it's "expected to work", with this page linked.
| NIC family | Driver | Speed | Kernel proven on | Date | Evidence |
|---|---|---|---|---|---|
| No bare-metal cards verified yet - see the note above. | |||||
Verified - nested (a VM on a hypervisor)
This is proof on a virtual card, inside a virtual machine, running on a real hypervisor host - a real, working proof of the mechanism, just not on bare metal.
| Host kind | Adapter | Proven | Evidence |
|---|---|---|---|
| VM on Proxmox / KVM | virtio (virtio_net), bridged on a Linux bridge | 2026-09-13 - attach/detach across Docker, namespace, QEMU passthrough, Dynamips and IOL nodes; automatic recovery after a crash; settings restored exactly; a real RFC 2544 quick test passing through a real device under test | Internal test run npx1048 |
Expected to work - driver families
These are common, standard Linux-driver card families that should work with Direct NIC because nothing in the mechanism is vendor-specific - we just haven't personally run our full proof on each one yet. Listed in the order we plan to verify them, most common first.
| # | NIC family (examples) | Driver | Speed | Note |
|---|---|---|---|---|
| 1 | Intel I210 / I350 (on-board server NICs - most Supermicro/Dell/HP 1GE) | igb | 1 GE | Standard in-kernel driver, supports every mode Direct NIC needs |
| 2 | Intel X520 / X540 / X550 (10GE SFP+/10GBASE-T) | ixgbe | 10 GE | The usual 10GE test-lab card |
| 3 | Realtek RTL8111/8168/8411 (nearly every consumer/mini-PC board) | r8169 | 1 GE | What "netplex. on an ordinary PC" most often has |
| 4 | Intel X710 / XL710 / XXV710 (10/25/40GE) | i40e | 10-40 GE | Firmware/driver pairing matters - the in-app NIC card shows firmware version |
| 5 | Intel E810 (25/100GE) | ice | 25-100 GE | At very high speed the software tester itself becomes the limit before the card does - the report says "tester-limited" when that happens |
| 6 | Mellanox / NVIDIA ConnectX-4/5/6 | mlx5_core | 10-100 GE | On some models, promiscuous mode is a firmware setting worth double-checking |
| 7 | Intel I219 / I225 / I226 (laptop/desktop on-board) | e1000e, igc | 1-2.5 GE | Early I225 revisions have a known link-flap issue at 2.5GE |
| 8 | Broadcom NetXtreme (BCM57xx, BCM5719/5720 on Dell/HP) | tg3, bnxt_en | 1-25 GE | No known caveats |
| 9 | Aquantia / Marvell AQC107/113 (2.5/5/10GBASE-T) | atlantic | 2.5-10 GE | Newer driver - we'll verify this after the first three above |
| 10 | Intel SR-IOV virtual functions (I350 / X710 VFs handed to a VM) | igbvf, iavf | 1-40 GE | Needs the physical card to "trust" the virtual function first (ip link set <pf> vf N trust on) - a separate proof, not yet done |
USB network adapters (r8152, ax88179, and similar) are deliberately left off this list. The mechanism works, but USB NICs can re-enumerate under a new name after a hiccup, which breaks the one-card-one-port tracking Direct NIC relies on. Not recommended until we've tested and documented them properly.
Not supported
| Case | What the app tells you |
|---|---|
| The card you manage the server through | "this is the netplex. management interface - add a second adapter" |
| A card carrying the server's own IP address | "carries a host address - Direct NIC would take the server off the network" |
| A card already in use by a running Gateway node | "in use by Gateway <name> in lab <lab> - stop it first" |
| A hypervisor's NAT / host-only virtual adapter | "VM · hypervisor NAT adapter - real-wire testing isn't reachable through this adapter" |
| Wi-Fi adapters | "wireless adapter - Direct NIC needs a real Ethernet port" |
| A card already attached to another lab device | "attached to <node>/<port> in lab <lab>" |
| A server explicitly marked as shared | "this netplex. host is marked shared - real-network testing is off" |
| Any tier below Architect | "Real-network testing needs Architect tier" |
Running Direct NIC in a virtual machine (nested)
If netplex. itself is running inside a VM, the hypervisor has to be told to let a card's traffic through unchanged, or Direct NIC will only ever see the hypervisor's own gateway. The setting names differ, but the idea is the same everywhere:
- Proxmox / KVM: turn off the adapter's Firewall and any MAC filter on that bridge.
- VirtualBox: Bridged Adapter, Promiscuous Mode set to "Allow All".
- VMware Workstation / ESXi: on the port group, set Promiscuous mode, MAC address changes, and Forged transmits all to "Accept".
- Hyper-V: enable "MAC address spoofing" on the virtual adapter.
Direct NIC checks this for you automatically before a test starts - if the hypervisor setting is wrong, it tells you before sending a single test frame, not after.
How a card gets added to "Verified"
On real, non-virtual hardware, for each card family, in one sitting, covering every case (no shortcuts):
- The card shows up correctly in netplex. with the right driver and speed, before anything is attached.
- Attach it to a Docker node, a namespace node, and a QEMU node in turn - the three ways a tester or capture tool actually uses a card.
- A real frame sent out is seen on the far end of a real cable, and a frame from the far end is seen inside netplex.
- Force-kill the node mid-test: the card is returned automatically within a minute, and every setting is restored exactly as it was.
- A real RFC 2544 quick test through a real device passes cleanly.
- A full-rate test at the card's top speed either hits close to the theoretical maximum, or the report honestly says "tester-limited" with the number it actually reached.
- Only then does the row move from "Expected" to "Verified", with the date and the proof linked.
We'll say "verified on real hardware" on the rest of the site once at least the first three driver families above have gone through this. Until then, every page that mentions Direct NIC's hardware support links back to this one.