A MACVLAN can be thought of a Layer-2 abstraction that is done on a physical interface based on the MAC address. Since a unique MAC address is assigned for every MACVLAN sub-interface, packets arriving with that MAC address get easily classified into the appropriate MACVLAN. Since there is no normal Layer-2 forwarding happening, there is no need for having a MAC table or running spanning tree instances on the MACVLAN. So it is faster compared to the traditional Linux bridge.

MACVLAN can operate in 4 different modes,

  • Private
  • VEPA
  • Bridge
  • Passthru

For more information on MACVLAN modes and how they operate, refer here. The lucid contents there do not warrant a repetition.

As you can notice only in the Bridge mode, the packets are traversing from one MACVLAN to another within the same switch. If you are wondering why there is no need for a MAC table in this scenario, note that the MAC addresses to each of the sub-interfaces is actually assigned by the kernel and hence the information is already implicitly known to it.

Container networking use MACVLAN mode when they want isolation of containers and at the same time also require them to be reachable via an external switch where appropriate policies are applied to the packets.


IPVLAN is used to address some disadvantages with the MACVLAN wherein creating unique MAC address can cause security issue with the network switch policies. Refer to the same link to know more about IPVLAN.

IPVLAN can operate in two modes,

  • Layer-2 mode
  • Layer-3 mode

In Layer-2 mode, packets between interfaces belonging to the same subnet are routed within the box itself by the parent interface. This is equivalent to the behavior displayed by a MACVLAN bridge. In this case, since the IP addresses on each of the virtual interfaces are known the kernel, it doesn’t need a MAC table to switch them. For any Layer-3 forwarding, the packets will need to traverse an external switch. The difference between this and the traditional Linux bridge is that there is no MAC learning happening and hence if the external networks need to be contacted, those MAC addresses will be unknown and will hence be flooded.

In the Layer-3 mode, the parent interface acts as a Layer-3 router and can forward packets directed towards other IPVLANs in the same box internally within the box itself. The same limitation with respect to Layer-2 flooding for unknown external MAC will exist for IPVLAN as well. But consider a container use-case where unique Layer-3 subnet is assigned for each POD. For the Layer-3 subnets that are not present in the box, the routes will be advertised via some mechanism into the box and will take the default gateway on the physical interface. For the PODs in the same box, the packets will be locally forwarded. We will explore more of these in container networking scenarios later.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s