LFCE 29 🐧 Virtual Networking — MACVLAN and IPVLAN
MACVLAN and IPVLAN are two virtual network drivers that solve a problem veth pairs and bridges cannot: they allow a single physical interface to present multiple distinct network identities without creating a bridge. A MACVLAN interface gets its own MAC address, so the external switch sees it as a separate physical host. An IPVLAN interface shares the parent’s MAC address and is demultiplexed by IP address instead, which conserves MAC table entries on the switch and works in environments where the network enforces one MAC per port . Both drivers attach virtual interfaces directly to a physical parent, bypassing the host’s bridge and routing stack for the data path.
This chapter covers the two drivers, their operating modes, and the trade-offs that determine which one to use. The previous chapters covered veth pairs and TUN/TAP; MACVLAN and IPVLAN are the alternatives that trade the bridge’s flexibility for lower overhead and a different set of constraints.
Key point: MACVLAN gives each virtual interface its own MAC address, so the switch treats each one as a distinct physical device. IPVLAN shares the parent’s MAC across all virtual interfaces and uses the IP address to decide which interface receives an incoming packet. The choice between them is usually determined by the network’s MAC address policy and whether the virtual interface needs to receive broadcast traffic .
Why MACVLAN and IPVLAN exist
The bridge overhead problem.
A bridge connects virtual interfaces by forwarding frames between ports in the host’s kernel. This works, but it adds a Layer 2 processing step and a bridge device that must be managed. MACVLAN and IPVLAN bypass the bridge entirely. The virtual interface is attached directly to the physical parent, and the kernel’s driver handles the multiplexing. For container networking at scale, this removes a layer from the data path and reduces the configuration surface.
The MAC address exhaustion problem.
Some network environments enforce a strict policy of one MAC address per switch port. A host running fifty containers with a bridge would present fifty MAC addresses on the physical port, which the switch may reject or penalize. IPVLAN solves this by sharing the parent’s MAC address across all virtual interfaces. The switch sees only one MAC, and the host’s IPVLAN driver uses the destination IP address to route incoming packets to the correct virtual interface . MACVLAN does not solve this problem; it creates a new MAC for each interface, which is the correct choice when the switch permits multiple MACs and the virtual interfaces need full Layer 2 independence.
The host-to-virtual-interface communication problem.
Both drivers have a known limitation: the host cannot communicate with its own MACVLAN or IPVLAN interfaces through the parent physical interface. The kernel’s design prevents the host from sending packets to a MACVLAN child through the parent, and IPVLAN interfaces cannot reach the host through the IPVLAN link at all . This is not a bug; it is a consequence of the direct attachment model. The workaround is to create a separate MACVLAN or IPVLAN interface on the host and use it for host-to-container communication, or to use a bridge for the management path.
a. MACVLAN modes and configuration
MACVLAN creates virtual interfaces with distinct MAC addresses. The driver supports several modes, each defining how the virtual interfaces communicate with each other and with the outside world.
# Create a MACVLAN interface in bridge mode
# The parent is eth0; the virtual interface is macvlan0
ip link add link eth0 name macvlan0 type macvlan mode bridge
# Assign an address and bring it up
ip addr add 192.168.1.101/24 dev macvlan0
ip link set macvlan0 up
# Verify the interface has its own MAC address
ip link show macvlan0
# Output includes: link/ether <different-from-eth0>The bridge mode allows the MACVLAN interfaces on the same parent to communicate with each other directly, in addition to communicating with the external network. The private mode prevents communication between MACVLAN interfaces on the same parent; they can only reach the external network. The vepa mode sends all traffic between virtual interfaces out through the external switch, which requires a switch that supports hairpin mode. The passthru mode gives a single virtual interface exclusive access to the parent, allowing it to change its MAC address and enter promiscuous mode .
For container networking, bridge mode is the most common choice. Each container gets a MACVLAN interface with its own MAC and IP address. The containers can communicate with each other through the parent’s driver, and they can reach the external network as if they were physical hosts on the same switch.
b. IPVLAN modes and configuration
IPVLAN creates virtual interfaces that share the parent’s MAC address. The driver uses the IP address in incoming packets to decide which virtual interface receives the packet. IPVLAN has two primary modes: L2 and L3.
# Create an IPVLAN interface in L2 mode
ip link add link eth0 name ipvlan0 type ipvlan mode l2
# Assign an address
ip addr add 192.168.1.102/24 dev ipvlan0
ip link set ipvlan0 up
# Verify the interface shares the parent's MAC address
ip link show ipvlan0
# Output: link/ether <same-as-eth0>In L2 mode, the IPVLAN interface behaves like a MACVLAN interface in bridge mode, except that it shares the parent’s MAC. The virtual interfaces can communicate with each other and with the external network, and they receive broadcast and multicast traffic. In L3 mode, the virtual interfaces do not receive broadcast or multicast traffic, and the host’s routing stack controls the path. L3 mode is more restrictive but can be useful when the host is acting as a router for the virtual interfaces .
There is also an l3s mode, which is similar to L3 but enables connection tracking for iptables. This mode has slightly lower performance but is necessary when firewall rules need to track connections to the virtual interfaces .
The mode flags bridge, private, and vepa apply to IPVLAN as well, with the same meanings as in MACVLAN. The bridge flag is the default and allows cross-communication between virtual interfaces on the same parent.
c. Choosing between MACVLAN and IPVLAN
The kernel documentation explicitly lists the conditions under which IPVLAN is the correct choice over MACVLAN :
Use IPVLAN when the external switch or router allows only one MAC address per port. The host’s physical port presents a single MAC, and the switch does not need to learn multiple addresses.
Use IPVLAN when the number of virtual interfaces exceeds the switch’s MAC address table capacity, or when the NIC would be forced into promiscuous mode to handle the multiple MACs, degrading performance.
Use IPVLAN when the virtual interface is placed in an untrusted network namespace where the Layer 2 address could be changed or misused. Because IPVLAN interfaces share the parent’s MAC, the namespace cannot spoof a different MAC at Layer 2.
MACVLAN remains the correct choice when the virtual interfaces need full Layer 2 independence, when they must receive broadcast and multicast traffic, or when the network environment permits multiple MAC addresses and the simplicity of the MACVLAN model is preferred.
Both drivers have the same limitation: the host cannot reach the virtual interfaces through the parent. For host-to-container management traffic, a separate interface is required.
Complete Example Session
# ============================================
# PART 1: CREATE A MACVLAN INTERFACE
# ============================================
ip link add link eth0 name mv0 type macvlan mode bridge
ip link set mv0 up
ip link show mv0
# Output confirms a distinct MAC address
# ============================================
# PART 2: MOVE THE MACVLAN INTO A NAMESPACE
# ============================================
ip netns add ns-mv
ip link set mv0 netns ns-mv
ip netns exec ns-mv ip addr add 192.168.1.101/24 dev mv0
ip netns exec ns-mv ip link set lo up
ip netns exec ns-mv ip link set mv0 up
# ============================================
# PART 3: CREATE AN IPVLAN INTERFACE
# ============================================
ip link add link eth0 name iv0 type ipvlan mode l2
ip link set iv0 up
ip link show iv0
# Output confirms the MAC matches eth0
# ============================================
# PART 4: MOVE THE IPVLAN INTO A NAMESPACE
# ============================================
ip netns add ns-iv
ip link set iv0 netns ns-iv
ip netns exec ns-iv ip addr add 192.168.1.102/24 dev iv0
ip netns exec ns-iv ip link set lo up
ip netns exec ns-iv ip link set iv0 up
# ============================================
# PART 5: VERIFY CONNECTIVITY
# ============================================
# From the MACVLAN namespace to the IPVLAN namespace
ip netns exec ns-mv ping -c 2 192.168.1.102
# From the IPVLAN namespace to the MACVLAN namespace
ip netns exec ns-iv ping -c 2 192.168.1.101
# ============================================
# PART 6: VERIFY HOST LIMITATION
# ============================================
# The host cannot reach either namespace through eth0
ping -c 1 -W 1 192.168.1.101
# Expected: fails or times out
# This is the documented limitation of both drivers
# ============================================
# PART 7: CLEAN UP
# ============================================
ip netns pids ns-mv | xargs -r kill
ip netns pids ns-iv | xargs -r kill
ip netns delete ns-mv
ip netns delete ns-ivThe seven parts demonstrate the parallel configuration of both drivers, the namespace migration, the connectivity between them, and the host limitation. The critical verification is Part 6, which confirms that the host cannot reach the virtual interfaces through the parent.
Quick Reference
Driver Comparison
| Property | MACVLAN | IPVLAN |
|---|---|---|
| MAC address | Unique per interface | Shared with parent |
| Switch MAC table | Multiple entries | Single entry |
| Broadcast/multicast | Received | L2: received; L3: not received |
| Host-to-interface | Blocked | Blocked |
| Configuration | type macvlan mode <mode> | type ipvlan mode <mode> |
MACVLAN Modes
| Mode | Behavior |
|---|---|
bridge | Virtual interfaces communicate with each other |
private | Virtual interfaces cannot communicate |
vepa | Traffic goes through external switch |
passthru | Single interface, exclusive access |
IPVLAN Modes
| Mode | Behavior |
|---|---|
l2 | Layer 2 multiplexing, broadcast received |
l3 | Layer 3 multiplexing, no broadcast |
l3s | L3 with connection tracking |
Best Practices
✅ Do This:
# Use MACVLAN bridge mode for container networking
ip link add link eth0 name mv0 type macvlan mode bridge # ✅
# Use IPVLAN when the switch allows only one MAC
ip link add link eth0 name iv0 type ipvlan mode l2 # ✅
# Move the interface into the namespace before configuring
ip link set mv0 netns ns1 # ✅
# Bring up loopback inside the namespace
ip netns exec ns1 ip link set lo up # ✅
# Create a separate management interface for host access
# Both drivers block host-to-interface through the parent # ✅❌ Don’t Do This:
# Expect the host to reach the virtual interface through eth0
ping 192.168.1.101 # Fails by design # ❌
# Use MACVLAN when the switch enforces one MAC per port
# The switch may block or penalize the extra MACs # ❌
# Use IPVLAN L3 mode when broadcast is required
# L3 mode does not receive broadcast # ❌
# Mix MACVLAN and IPVLAN on the same parent
# The kernel refuses this combination # ❌
# Forget to bring up the parent interface
ip link set eth0 up # Required before virtual interfaces # ❌Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
| Host cannot ping virtual interface | Both drivers block host-to-interface via parent | Use a separate interface for host access |
| Switch rejects traffic | MACVLAN creates multiple MACs | Use IPVLAN if one-MAC-per-port is enforced |
| No broadcast in IPVLAN | L3 mode disables broadcast | Use L2 mode if broadcast is needed |
| Parent not up | Virtual interfaces inherit link state | ip link set eth0 up |
| MACVLAN and IPVLAN conflict | Kernel refuses mixed use on same parent | Use one driver per parent |
Real-World Examples
1. MACVLAN bridge mode
ip link add link eth0 name mv0 type macvlan mode bridge2. MACVLAN private mode
ip link add link eth0 name mv0 type macvlan mode private3. IPVLAN L2 mode
ip link add link eth0 name iv0 type ipvlan mode l24. IPVLAN L3 mode
ip link add link eth0 name iv0 type ipvlan mode l35. Move into namespace
ip link set mv0 netns ns16. Assign address
ip netns exec ns1 ip addr add 192.168.1.101/24 dev mv07. Verify MAC difference
ip link show mv0 | grep ether8. Verify MAC sharing
ip link show iv0 | grep ether9. Clean up namespace
ip netns delete ns110. Delete virtual interface
ip link delete mv0Visual
MACVLAN vs IPVLAN
┌──────────────────────────────────────────────────────────────┐
│ MACVLAN: UNIQUE MAC PER INTERFACE │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Physical Network (Switch) │ │
│ │ sees: MAC-A, MAC-B, MAC-C │ │
│ └──────────────────────────┬─────────────────────────────┘ │
│ │ │
│ │ eth0 (MAC-A) │
│ ┌──────────────────────────▼─────────────────────────────┐ │
│ │ Host │ │
│ │ │ │
│ │ mv0 (MAC-B) mv1 (MAC-C) │ │
│ │ ┌─────────┐ ┌─────────┐ │ │
│ │ │ ns1 │ │ ns2 │ │ │
│ │ └─────────┘ └─────────┘ │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ Each interface has its own MAC. │
│ Switch sees multiple hosts. │
│ │
│ ───────────────────────────────────────────────────────── │
│ │
│ IPVLAN: SHARED MAC, IP-BASED DEMUX │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Physical Network (Switch) │ │
│ │ sees: MAC-A only │ │
│ └──────────────────────────┬─────────────────────────────┘ │
│ │ │
│ │ eth0 (MAC-A) │
│ ┌──────────────────────────▼─────────────────────────────┐ │
│ │ Host │ │
│ │ │ │
│ │ iv0 (MAC-A) iv1 (MAC-A) │ │
│ │ ┌─────────┐ ┌─────────┐ │ │
│ │ │ ns1 │ │ ns2 │ │ │
│ │ └─────────┘ └─────────┘ │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ All interfaces share one MAC. │
│ Driver uses IP to demux incoming packets. │
└──────────────────────────────────────────────────────────────┘Host Limitation
┌──────────────────────────────────────────────────────────────┐
│ HOST CANNOT REACH VIRTUAL INTERFACES VIA PARENT │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Host │ │
│ │ │ │
│ │ eth0 (192.168.1.10) │ │
│ │ │ │ │
│ │ ├── mv0 (192.168.1.101) → ns1 │ │
│ │ └── mv1 (192.168.1.102) → ns2 │ │
│ │ │ │
│ │ ping 192.168.1.101 from host: │ │
│ │ → FAILS (kernel cannot loop back through parent) │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ Workaround: create a separate MACVLAN/IPVLAN interface │
│ on the host and use it for host-to-container traffic. │
└──────────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| MACVLAN | Unique MAC per virtual interface |
| IPVLAN | Shared MAC, IP-based demultiplexing |
| MACVLAN modes | bridge, private, vepa, passthru |
| IPVLAN modes | l2, l3, l3s |
| Host-to-interface | Blocked in both drivers |
| IPVLAN advantage | Saves switch MAC table entries |
| MACVLAN advantage | Full Layer 2 independence |
| Mixed use | Not allowed on same parent |
Key takeaways:
- MACVLAN gives each virtual interface its own MAC address. The external switch sees each interface as a distinct physical host. This is the correct choice when the network permits multiple MACs and the virtual interfaces need full Layer 2 independence .
- IPVLAN shares the parent’s MAC address. The driver uses the destination IP address to route incoming packets to the correct virtual interface. This is the correct choice when the switch enforces one MAC per port or when the MAC table capacity is a concern .
- IPVLAN L3 mode does not receive broadcast. L2 mode receives broadcast and multicast; L3 mode does not. The choice depends on whether the virtual interface needs to participate in broadcast-based protocols .
- The host cannot reach its own virtual interfaces through the parent. This is a documented limitation of both drivers. A separate interface or a bridge is required for host-to-container management traffic .
- MACVLAN and IPVLAN cannot be mixed on the same parent. The kernel refuses to create an IPVLAN interface on a device that is already a MACVLAN port, and vice versa .
- Both drivers bypass the bridge. The virtual interface is attached directly to the physical parent. There is no bridge device to configure, and the data path does not traverse the host’s Layer 2 forwarding logic.
Remember: MACVLAN and IPVLAN are two answers to the same question: how do I give a namespace or container a direct presence on the physical network without a bridge? MACVLAN answers with a new MAC address per interface. IPVLAN answers with a shared MAC and IP-based demultiplexing. The choice is usually made by the network’s MAC policy: if the switch allows multiple MACs, MACVLAN is simpler; if it does not, IPVLAN is required. Both drivers block host-to-interface communication through the parent, so a separate management path is always necessary.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!