![macvtap passthrough mac address macvtap passthrough mac address](https://image.slidesharecdn.com/20190613sreconasia-190613143037/85/software-networking-and-interfaces-on-linux-60-320.jpg)
Or using a recent version of brctl: # brctl hairpin br0 eth0 on However it's worth mentioning that Linux's own internal bridge implementation does support hairpin mode in recent versions assuming eth0 is a port of br0, hairpin mode can be anabled by doing # echo 1 > /sys/class/net/br0/brif/eth0/hairpin_mode Since there are few switches supporting hairpin mode, VEPA mode isn't used all that much yet. This feature (the so-called "hairpin mode" or "reflective relay") isn't widely supported yet, which means that if using VEPA mode with an ordinary switch, inter-VM traffic leaves the hypervisor but never comes back (unless it's sent back at the IP level by a router somewhere, but then there's nothing special about that, it has always worked that way). However, at the same time this implies that, for VMs to be able to communicate, the external switch should send back inter-VM traffic to the hypervisor out of the same interface it was received from, something that is normally prevented from happening by STP. Since macvlans are almost always assigned to virtual machines or containers, this makes it possible to see and manage inter-VM traffic on a real external switch (whereas with normal bridging it would not leave the hypervisor), with all the features provided by a "real" switch. If the lower device receives data from a macvlan in VEPA mode, this data is always sent "out" to the upstream switch or bridge, even if it's destined for another macvlan in the same lower device. VEPA (Virtual Ethernet Port Aggregator) is the default mode.The main use of macvlan seems to be container virtualization (for example LXC guests can be configured to use a macvlan for their networking and the macvlan interface is moved to the container's namespace), but there are other scenarios, mostly very specific cases, like using virtual MAC addresses (see for example this keepalived feature).Ī macvlan interface can work in one of four modes, defined at creation time. The physical interface to which the macvlan is attached is often referred to as "the lower device" or "the upper device" here we'll use the term "lower device". Applications can then bind specifically to the IP address assigned to a macvlan interface, for example. So with this it's possible to have multiple IP addresses, each with its own MAC address, on the same physical interface. Each macvlan interface has its own MAC address (different from that of the main interface) and can be assigned IP addresses just like a normal interface. Macvlan interfaces can be seen as subinterfaces of a main ethernet interface. Surely there's more to it (corrections and/or more information welcome). Here are some notes to summarize what I've been able to gather so far. There's not a lot of documentation about these interfaces.