When would you attach containers to a physical LAN using Docker's `macvlan` or `ipvlan` driver instead of a bridge, and what problems do those drivers introduce?

seniornice to knowfreq 24%

answer

own MAC (macvlan) vs shared MAC (ipvlan)
no NAT, no -p, LAN IP direct
host <-> container blocked by default
promiscuous mode / cloud + Wi-Fi refuse it
reserve --ip-range against DHCP

basics

~20 s

Use them when a container must appear as a first-class device on the physical LAN - its own IP (and, for macvlan, its own MAC), reachable inbound with no NAT or port publishing. Costs: the host usually cannot talk to its own macvlan containers, the parent NIC must accept extra MAC addresses (blocked on most clouds and Wi-Fi), and IP allocation must be coordinated with the LAN.

solid answer

~1 min

macvlan creates a virtual interface with its own MAC address on a parent NIC, so the container looks like a separate physical machine on the LAN: it gets a LAN IP, is reachable inbound directly, and no NAT or -p is involved. ipvlan does the same at the IP level but shares the parent's MAC (L2 mode) or routes for the container (L3 mode) - which is what you use when the environment forbids extra MACs.

Good reasons: legacy applications that must sit on a specific VLAN or need real layer-2 presence; appliances expecting DHCP on the corporate network; monitoring tools; protocols where NAT breaks addressing.

Problems to raise unprompted:

Host to container is blocked by default on macvlan - the host cannot reach its own containers unless you add a macvlan sub-interface on the host.
Extra MAC addresses / promiscuous mode on the parent NIC: cloud VMs, most Wi-Fi adapters, and switches with port security reject this. ipvlan is the workaround.
IPAM coordination: Docker allocates from a subnet you declare; overlap with DHCP causes conflicts, so reserve a range.
Weaker isolation - the container sits on the corporate LAN with no NAT boundary in front of it.

**macvlan** creates a virtual interface with its **own MAC address** on a parent NIC, so the container looks like a separate physical machine on the LAN: it gets a LAN IP, is reachable inbound directly, and no NAT or `-p` is involved. **ipvlan** does the same at the IP level but **shares the parent's MAC** (L2 mode) or routes for the container (L3 mode) - which is what you use when the environment forbids extra MACs. Good reasons: legacy applications that must sit on a specific VLAN or need real layer-2 presence; appliances expecting DHCP on the corporate network; monitoring tools; protocols where NAT breaks addressing. Problems to raise unprompted: - **Host to container is blocked by default** on macvlan - the host cannot reach its own containers unless you add a macvlan sub-interface on the host. - **Extra MAC addresses / promiscuous mode** on the parent NIC: cloud VMs, most Wi-Fi adapters, and switches with port security reject this. ipvlan is the workaround. - **IPAM coordination**: Docker allocates from a subnet you declare; overlap with DHCP causes conflicts, so reserve a range. - **Weaker isolation** - the container sits on the corporate LAN with no NAT boundary in front of it.

code

bash · 8 lines

bash

docker network create -d macvlan \
  --subnet 192.168.20.0/24 \
  --gateway 192.168.20.1 \
  --ip-range 192.168.20.192/27 \
  --aux-address 'printer=192.168.20.200' \
  -o parent=eth0.20 lan20

docker run -d --network lan20 --ip 192.168.20.194 nginx:alpine

go deeper

for a junior

Know that these drivers put a container directly on the physical network with its own IP instead of behind the host's NAT.

for a middle

Explain the parent-interface model, the macvlan-versus-ipvlan MAC difference, and that no NAT or port publishing is involved.

for a senior

Lead with the operational traps - host-to-container isolation, MAC/promiscuous-mode constraints, IPAM coordination - and justify the driver against a bridge alternative.

for a principal

Judge whether layer-2 presence is a genuine requirement or an accommodation of legacy design, and price in non-interchangeable hosts and LAN-level troubleshooting before standardising on it.

What these drivers actually do

Bridge networking hides containers behind the host: outbound is masqueraded, inbound needs a published port. macvlan and ipvlan remove that indirection by giving a container an interface derived from a parent physical NIC (or a VLAN sub-interface such as eth0.20).

macvlan allocates a fresh MAC address for each container interface. To the switch it is another host on the segment; it gets an address in the LAN's subnet and answers ARP for itself.
ipvlan attaches by IP while reusing the parent's MAC. In L2 mode containers share the parent's broadcast domain; in L3 mode the host routes for them and there is no broadcast or multicast, which scales better and avoids ARP churn.

In both cases there is no NAT, no port publishing and no bridge hop: the container is addressed directly by other machines.

Legitimate use cases

Legacy or appliance software that must own a LAN IP, be discovered by broadcast, or sit on a specific VLAN.
Network services where NAT is fatal: DHCP servers, some media stacks, monitoring probes that must see the segment.
Existing IP-based policy: firewall rules, allowlists or audit systems keyed to per-service IPs rather than host-plus-port.
Very high inbound throughput where even NAT and connection tracking are unwanted, and host mode is unacceptable because you need per-container addresses.

The problems, in the order they bite

1. The host cannot reach its own containers. With macvlan, the parent interface and its macvlan children are deliberately isolated from each other. Your health check from the host, or a monitoring agent on the host, fails while every other machine on the LAN succeeds. The remedy is to create a macvlan sub-interface on the host itself, give it an address in the same subnet, and route container addresses through it - extra host configuration that must survive reboots.

2. The environment may forbid extra MAC addresses. The parent NIC must accept frames for many MAC addresses (promiscuous mode). Cloud provider virtual NICs commonly reject unknown source MACs outright; switch port security may shut the port; most Wi-Fi adapters cannot do it at all. This is the single most common reason a macvlan plan dies. ipvlan exists precisely for this: one MAC, several IPs. Confirm your hypervisor or cloud allows the extra addresses before committing.

3. Address management becomes a shared concern. You declare the LAN subnet and gateway when creating the network, and Docker's IPAM hands out addresses from it. Nothing coordinates with the LAN's DHCP server, so you must carve out a reserved range (--ip-range) and exclude addresses already in use (--aux-address), or assign static container IPs. Duplicate addresses on a corporate LAN are a painful outage to debug.

4. Isolation is reduced. The container is directly reachable from anything on the segment; there is no NAT boundary implicitly protecting it. Everything it listens on is exposed unless the LAN's own controls prevent it. Treat it like putting a bare server on the network.

5. Portability and operability. These setups are tied to a specific NIC name, VLAN and subnet, which makes hosts non-interchangeable and complicates automation. Troubleshooting also shifts to LAN tooling - switch ARP tables, VLAN tagging - rather than docker network inspect.

Choosing between them

Prefer macvlan when you need each container to be a distinct layer-2 device (DHCP, MAC-based policy) and the infrastructure allows extra MACs. Prefer ipvlan L2 when MAC restrictions block macvlan but you still want LAN addresses; prefer ipvlan L3 for large deployments where you control routing and want to avoid broadcast domains entirely. And prefer neither if a bridge with published ports would do - these drivers buy layer-2 presence at a real cost in host integration, environment constraints and address management.

## What these drivers actually do Bridge networking hides containers behind the host: outbound is masqueraded, inbound needs a published port. macvlan and ipvlan remove that indirection by giving a container an interface derived from a **parent** physical NIC (or a VLAN sub-interface such as `eth0.20`). - **macvlan** allocates a fresh **MAC address** for each container interface. To the switch it is another host on the segment; it gets an address in the LAN's subnet and answers ARP for itself. - **ipvlan** attaches by IP while **reusing the parent's MAC**. In **L2 mode** containers share the parent's broadcast domain; in **L3 mode** the host routes for them and there is no broadcast or multicast, which scales better and avoids ARP churn. In both cases there is no NAT, no port publishing and no bridge hop: the container is addressed directly by other machines. ## Legitimate use cases - **Legacy or appliance software** that must own a LAN IP, be discovered by broadcast, or sit on a specific VLAN. - **Network services** where NAT is fatal: DHCP servers, some media stacks, monitoring probes that must see the segment. - **Existing IP-based policy**: firewall rules, allowlists or audit systems keyed to per-service IPs rather than host-plus-port. - **Very high inbound throughput** where even NAT and connection tracking are unwanted, and host mode is unacceptable because you need per-container addresses. ## The problems, in the order they bite **1. The host cannot reach its own containers.** With macvlan, the parent interface and its macvlan children are deliberately isolated from each other. Your health check from the host, or a monitoring agent on the host, fails while every other machine on the LAN succeeds. The remedy is to create a macvlan sub-interface on the host itself, give it an address in the same subnet, and route container addresses through it - extra host configuration that must survive reboots. **2. The environment may forbid extra MAC addresses.** The parent NIC must accept frames for many MAC addresses (promiscuous mode). Cloud provider virtual NICs commonly reject unknown source MACs outright; switch port security may shut the port; most Wi-Fi adapters cannot do it at all. This is the single most common reason a macvlan plan dies. **ipvlan** exists precisely for this: one MAC, several IPs. Confirm your hypervisor or cloud allows the extra addresses before committing. **3. Address management becomes a shared concern.** You declare the LAN subnet and gateway when creating the network, and Docker's IPAM hands out addresses from it. Nothing coordinates with the LAN's DHCP server, so you must carve out a reserved range (`--ip-range`) and exclude addresses already in use (`--aux-address`), or assign static container IPs. Duplicate addresses on a corporate LAN are a painful outage to debug. **4. Isolation is reduced.** The container is directly reachable from anything on the segment; there is no NAT boundary implicitly protecting it. Everything it listens on is exposed unless the LAN's own controls prevent it. Treat it like putting a bare server on the network. **5. Portability and operability.** These setups are tied to a specific NIC name, VLAN and subnet, which makes hosts non-interchangeable and complicates automation. Troubleshooting also shifts to LAN tooling - switch ARP tables, VLAN tagging - rather than `docker network inspect`. ## Choosing between them Prefer **macvlan** when you need each container to be a distinct layer-2 device (DHCP, MAC-based policy) and the infrastructure allows extra MACs. Prefer **ipvlan L2** when MAC restrictions block macvlan but you still want LAN addresses; prefer **ipvlan L3** for large deployments where you control routing and want to avoid broadcast domains entirely. And prefer neither if a bridge with published ports would do - these drivers buy layer-2 presence at a real cost in host integration, environment constraints and address management.

Every machine on the LAN can reach a macvlan container, but the Docker host itself cannot. Why, and how do you fix it?
macvlan child interfaces are isolated from their parent by design, so traffic between the host's own stack and its containers is not forwarded. The fix is to create a macvlan sub-interface on the host in the same subnet, give it an address, bring it up and route the container range through it - and persist that configuration so it survives reboots.
A macvlan network works on bare metal but the same configuration fails on a cloud VM. What is the usual reason, and what is the alternative?
Cloud virtual NICs typically drop frames with MAC addresses not registered to the interface, and the extra MACs macvlan generates are exactly that; some platforms also require MAC/IP anti-spoofing to be disabled explicitly. The usual alternative is ipvlan, which shares the parent's MAC and only adds IP addresses - though the platform may still require those addresses to be assigned to the interface.

saying these in an interview costs you the question

Expecting the Docker host to reach its own macvlan containers without extra interface configuration
Assuming macvlan will work on a cloud VM or a Wi-Fi adapter
Letting Docker's IPAM range overlap the LAN's DHCP pool
Thinking published ports (`-p`) are still needed or meaningful on macvlan
Treating macvlan and ipvlan as interchangeable without mentioning the MAC difference

When would you attach containers to a physical LAN using Docker's `macvlan` or `ipvlan` driver instead of a bridge, and what problems do those drivers introduce?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

What these drivers actually do

Legitimate use cases

The problems, in the order they bite

Choosing between them

▾common follow-ups2 questions

▾red flags5 flags

§ context

▾related questions6 questions

▾related topics3 topics

What these drivers actually do

Legitimate use cases

The problems, in the order they bite

Choosing between them

answer

go deeper

context