Understanding lightweight direct-attached networking in OpenShift Virtualization, and when to choose MACVLAN or IPVLAN over Linux Bridge, OVN, and SR-IOV.
By this point in the series, you know two very different answers to "how do I get a workload directly onto my network." Linux Bridge (Part 1) works, but it still builds a small internal topology — a TAP device, a bridge, a veth pair — before the frame ever reaches the NIC. SR-IOV (Part 5) removes all of that, but demands SR-IOV-capable hardware, IOMMU support, and a Virtual Function allocation strategy.
Sometimes neither answer fits. You don't need overlay isolation. You don't have specialized NICs. You just need a pod or VM to have its own address directly on the physical network, with the least possible machinery in between.
That's exactly the gap MACVLAN and IPVLAN fill: native Ethernet connectivity, with no bridge and no special hardware — just a kernel driver standing directly between the workload and the NIC.
A MACVLAN interface creates another virtual network interface directly on top of a physical one — with its own, genuinely unique MAC address. No bridge sits between them. No OVS. No overlay.
To the physical switch, each MACVLAN interface looks exactly like a separate physical host plugged into the network — because as far as MAC learning is concerned, it is one.
IPVLAN takes the opposite approach to addressing. Instead of giving every interface its own MAC, every IPVLAN interface shares the parent NIC's single MAC address — and instead uses IP addressing to tell traffic apart.
This is the comparison the entire article builds toward.
| MACVLAN | IPVLAN |
|---|---|
| Multiple MAC addresses | One shared MAC |
| Switch learns every VM's MAC | Switch learns only one MAC |
| Better isolation between VMs | Better scalability at large VM counts |
| L2 | L2 or L3 |
| Normal broadcast behavior | Reduced broadcast / CAM table pressure |
Placed next to Linux Bridge, the simplification is immediately visible.
Both paths terminate at the same physical NIC. The difference is entirely in what happens above it: Linux Bridge builds a small software switch inside the kernel; MACVLAN's driver just multiplexes frames to the correct virtual interface based on destination MAC, with no switching logic in between.
The guest at 192.168.1.10 sends a frame from its virtual NIC, tagged with its own unique MAC address aa:bb:cc:...:01.
The kernel's macvlan driver receives the frame on this VM's dedicated sub-interface — no bridge lookup occurs.
The macvlan driver hands the frame directly to the physical NIC's driver for transmission.
The frame is transmitted exactly as-is — the physical NIC has no idea a macvlan driver was even involved.
The switch learns a brand-new MAC address on this port — from its perspective, a new device has appeared on the network.
Same hardware, genuinely different addressing model.
The guest at 10.0.0.10 sends a frame — but its source MAC is the same MAC as the parent NIC and every other ipvlan sibling.
The kernel's ipvlan driver demultiplexes traffic by IP address rather than MAC — it knows which VM sent what based on source address, not hardware identity.
The frame passes to the physical NIC's driver exactly as with macvlan — no bridge, no switching logic.
Transmission proceeds using the single shared MAC address for every VM behind this interface.
The switch's MAC table gains nothing new — it already knows this MAC. Multiple VMs are invisible to it as distinct L2 identities.
Both drivers support multiple operating modes — a detail most articles skip entirely.
MACVLAN modes: Bridge mode allows sibling interfaces to talk to each other directly; Private mode fully isolates them from one another; VEPA mode reflects all traffic through the upstream switch, even between siblings; Passthru mode dedicates the entire physical interface to a single macvlan endpoint.
IPVLAN modes: L2 mode behaves like a switch at Layer 2; L3 mode routes between endpoints without ARP, purely by IP; L3S adds connection tracking on top of L3 mode, which matters if you need stateful firewalling.
The same pattern from every earlier article in this series — a familiar shape by now.
A NetworkAttachmentDefinition declares the interface type — macvlan or ipvlan — along with the parent physical interface and any addressing configuration. Multus reads it and invokes the appropriate CNI plugin at pod or VM creation time, which creates the actual kernel interface and attaches it.
The complete version of the series' running comparison — all six articles, one table.
| Network | Wire Format |
|---|---|
| Linux Bridge | Native Ethernet |
| OVN | Geneve |
| Localnet | Native Ethernet |
| UDN | Geneve |
| SR-IOV | Native Ethernet |
| MACVLAN | Native Ethernet |
| IPVLAN | Native Ethernet |
Six articles, one lookup table.
| Requirement | Best Choice |
|---|---|
| General VM networking | Linux Bridge |
| Kubernetes-native SDN | OVN-Kubernetes |
| Enterprise VLAN integration | Localnet |
| Tenant isolation | UDN / CUDN |
| Maximum performance | SR-IOV |
| Native Ethernet, no special hardware | MACVLAN |
| Large-scale L2 with many VMs | IPVLAN |
Every network type covered in this series, side by side. Bookmark this table — it's the one you'll come back to.
| Feature | Bridge | OVN | Localnet | UDN | SR-IOV | MACVLAN | IPVLAN |
|---|---|---|---|---|---|---|---|
| Overlay | No | Yes | No | Yes | No | No | No |
| Bridge / OVS | Bridge | OVS | OVS | OVS | No | No | No |
| Hardware VF | No | No | No | No | Yes | No | No |
| Native Ethernet | Yes | No | Yes | No | Yes | Yes | Yes |
| Performance | Good | Good | Better | Good | Excellent | Very Good | Very Good |
| Flexibility | High | High | Medium | High | Lower | Medium | Medium |
| Best Use | General VMs | Cloud-native | VLAN integration | Multi-tenancy | Telco / NFV | Lightweight native L2 | Large-scale L2/L3 |