Docker Macvlan Demystify
In this article, we are going to disucss a little bit about Macvlan and setup a Macvlan lab environment under Hyper-V host with 3 Ubuntu 16.04 VMs.
0 What is Macvlan
Refer to Macvlan Driver
The
Macvlandriver provides operators the ability to integrate Docker networking in a simple and lightweight fashion into the underlying network.Macvlanis supported by the Linux kernel and is a well known Linux network type. The Macvlan built-in driver does not require any port mapping and supports VLAN trunking (Virtual Local Area Network). VLANs are a traditional method of network virtualization and layer 2 datapath isolation that is prevalent in some form or fashion in most data centers.
Refer to Use Macvlan networks
Some applications, especially legacy applications or applications which monitor network traffic, expect to be directly connected to the physical network. In this type of situation, you can use the
macvlannetwork driver to assign a MAC address to each container’s virtual network interface, making it appear to be a physical network interface directly connected to the physical network. In this case, you need to designate a physical interface on your Docker host to use for the Macvlan, as well as the subnet and gateway of the Macvlan.
1 Macvlan Lab Environment
To illustrate how Macvlan works, we will use 3 VMs to demostrate Macvlan, one VM is master VM which will severs as gateway to route VLAN traffics between VLAN's sub-interfaces, other 2 VMs are docker nodes, node0 and node1. Those VMs will be created under Hyper-V environment.
1.1 Network Diagram
Refer to above diagram, each VM will have two network interfaces, eth0 is for management, eth1 is the interface to create Macvlan
1.2 Hyper-V network & VM's configuration
Before creating those VMs, we need to create two virtual switches under Hyper-V. One is for management, eth0's network (has internet connectivity to download/install docker, able to SSH etc.), Another is for Macvlan, eth1's network.
From Powershell window, add two virtual switches
# eth0
New-VMSwitch -SwitchName "NAT" -SwitchType Internal
# eth1
New-VMSwitch -SwitchName "VLAN" -SwitchType Internal
Configure virtual switch 'NAT' in NAT mode. We need ifIndex to associate it with NAT network
Get-NetAdapter
vEthernet(NAT)'s ifIndex is 11
Name InterfaceDescription ifIndex Status MacAddress LinkSpeed
---- -------------------- ------- ------ ---------- ---------
vEthernet (VLAN) Hyper-V Virtual Ethernet Adapter #4 35 Up 00-15-5D-10-31-10 10 Gbps
vEthernet (NAT) Hyper-V Virtual Ethernet Adapter #3 11 Up 00-15-5D-10-31-0F 10 Gbps
Create NAT network and associate it with 'NAT' virtual switch
New-NetIPAddress -IPAddress 172.16.0.1 -PrefixLength 16 -InterfaceIndex 11
New-NetNat -Name NATNetwork -InternalIPInterfaceAddressPrefix 172.16.0.0/16
Now, from Hyper-V management console, create three VMs with name "master", "node0" and "node1", assign fist 'Network Adatper" to 'NAT' virtual switch.
After VMs are created, we will add second 'Network Adapter' to them. Before that, let's talk a little bit about Hyper-V virtual switch mode.
Hyper-V virtual switch works in either Access mode or Trunk mode, the default mode is Access mode.
Trunk Mode, virtual switch will listen to all the network traffic and forward the traffic to all the ports. In other words, network packets are sent to all the virtual machines connected to it. Which means the virtual switch receives all network packets and forwards them to all the virtual machines connected to it.
Access Mode, virtual switch receives network packets in which it first checks the VLAN ID tagged in the network packet. If the VLAN ID tagged in the network packet matches the one configured on the virtual switch, then the network packet is accepted by the virtual switch. Any incoming network packet that is not tagged with the same VLAN ID will be discarded by the virtual switch.
Since Macvlan is implemented in guest OS, that means Hyper-V virtual switch needs to forward VLAN traffics to guest OS, which also means we need to configure trunk mode for second network adapter connect to virtual switch 'VLAN'. Follow below steps to add network adapter into each VM and configure them in trunk mode
Add-VMNetworkAdapter -SwitchName VLAN -VMName "node0" -Name "VLAN-Nic"
Set-VMNetworkAdapterVlan -Trunk -AllowedVlanIdList "10,20,30,40,50,60" -VMName "node0" -V
MNetworkAdapterName "VLAN-NIC" -NativeVlanId 100
Add-VMNetworkAdapter -SwitchName VLAN -VMName "node1" -Name "VLAN-Nic"
Set-VMNetworkAdapterVlan -Trunk -AllowedVlanIdList "10,20,30,40,50,60" -VMName "node1" -V
MNetworkAdapterName "VLAN-NIC" -NativeVlanId 100
Add-VMNetworkAdapter -SwitchName VLAN -VMName "master" -Name "VLAN-Nic"
Set-VMNetworkAdapterVlan -Trunk -AllowedVlanIdList "10,20,30,40,50,60" -VMName "master" -
VMNetworkAdapterName "VLAN-NIC" -NativeVlanId 100
Macvlan uses a unique MAC address per ethernet interface, by default, Hyper-V only allows traffics with MAC address sticks to the virutal switch port, we need to "Enable MAC address spoofing" to prevent virtual switch dropping VLAN's traffic.
1.3 Install Ubuntu
Install Ubuntu 16.04 on master, node0 and node1, manually configure eth0 with IP addresses below
1.3.1 master
auto eth0
iface eth0 inet static
address 172.16.0.3
netmask 255.255.0.0
gateway 172.16.0.1
dns-nameservers 10.50.50.50 10.50.10.50
auto eth1
iface eth1 inet manual
1.3.2 node0
auto eth0
iface eth0 inet static
address 172.16.0.4
netmask 255.255.0.0
gateway 172.16.0.1
dns-nameservers 10.50.50.50 10.50.10.50
auto eth1
iface eth1 inet manual
1.3.3 node1
auto eth0
iface eth0 inet static
address 172.16.0.5
netmask 255.255.0.0
gateway 172.16.0.1
dns-nameservers 10.50.50.50 10.50.10.50
auto eth1
iface eth1 inet manual
On 3 VMs, run
sudo -i
apt update
apt install docker.io
2 Configure Macvlan
We are going to configure eth1 interface as an IEEE 802.1Q VLAN trunk interface.
There are two ways to connect a ethernet interface to a switch that carries 802.1Q VLANs:
- Via a untagged port, where VLAN support is handled by the switch (so the attached machine sees ordinary Ethernet frames);
Or - Via a tagged (trunk) port, where VLAN support is handled by the attached ethernet interface (which sees 802.1Q-encapsulated Ethernet frames).
The advantage of a tagged port is that it allows multiple VLANs to be carried by a single physical bearer. The disadvantage is that the ethernet interface in question must support 801.q and be configured to use it.
VLAN requies 802.1Q kernel module, to load 802.1Q kernel module, from master, node0 and node1, run below commands
sudo -i
apt install vlan
modprobe 8021q
From node0 and node1, create 2 VLANs with VLAN ID 10 and 20, we will configure VLAN on master later(to show how VLAN routing works).
vconfig add eth1 10
vconfig add eth1 20
ifconfig eth1.10 up
ifconfig eth1.20 up
If we run ifconfig -a on node0 and node1, we would see below result
node0
docker0 Link encap:Ethernet HWaddr 02:42:5d:2e:ef:f3
inet addr:172.17.0.1 Bcast:0.0.0.0 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth0 Link encap:Ethernet HWaddr 00:15:5d:10:31:07
inet addr:172.16.0.4 Bcast:172.16.255.255 Mask:255.255.0.0
inet6 addr: fe80::215:5dff:fe10:3107/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:90852 errors:0 dropped:0 overruns:0 frame:0
TX packets:32235 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:68965196 (68.9 MB) TX bytes:4056047 (4.0 MB)
eth1 Link encap:Ethernet HWaddr 00:15:5d:10:31:15
inet6 addr: fe80::215:5dff:fe10:3115/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:68364 errors:0 dropped:0 overruns:0 frame:0
TX packets:40843 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:15163085 (15.1 MB) TX bytes:1860806 (1.8 MB)
eth1.10 Link encap:Ethernet HWaddr 00:15:5d:10:31:15
inet6 addr: fe80::215:5dff:fe10:3115/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:882 errors:0 dropped:0 overruns:0 frame:0
TX packets:40712 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:66664 (66.6 KB) TX bytes:1849808 (1.8 MB)
eth1.20 Link encap:Ethernet HWaddr 00:15:5d:10:31:15
inet6 addr: fe80::215:5dff:fe10:3115/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:145 errors:0 dropped:0 overruns:0 frame:0
TX packets:121 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9512 (9.5 KB) TX bytes:10178 (10.1 KB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:160 errors:0 dropped:0 overruns:0 frame:0
TX packets:160 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:11840 (11.8 KB) TX bytes:11840 (11.8 KB)
node1
docker0 Link encap:Ethernet HWaddr 02:42:b2:6b:03:e5
inet addr:172.17.0.1 Bcast:0.0.0.0 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth0 Link encap:Ethernet HWaddr 00:15:5d:10:31:08
inet addr:172.16.0.5 Bcast:172.16.255.255 Mask:255.255.0.0
inet6 addr: fe80::215:5dff:fe10:3108/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:87256 errors:0 dropped:0 overruns:0 frame:0
TX packets:27809 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:69339085 (69.3 MB) TX bytes:2333610 (2.3 MB)
eth1 Link encap:Ethernet HWaddr 00:15:5d:10:31:16
inet6 addr: fe80::215:5dff:fe10:3116/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:106266 errors:0 dropped:0 overruns:0 frame:0
TX packets:1140 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16748384 (16.7 MB) TX bytes:86416 (86.4 KB)
eth1.10 Link encap:Ethernet HWaddr 00:15:5d:10:31:16
inet6 addr: fe80::215:5dff:fe10:3116/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:38604 errors:0 dropped:0 overruns:0 frame:0
TX packets:856 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1106876 (1.1 MB) TX bytes:60624 (60.6 KB)
eth1.20 Link encap:Ethernet HWaddr 00:15:5d:10:31:16
inet6 addr: fe80::215:5dff:fe10:3116/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:322 errors:0 dropped:0 overruns:0 frame:0
TX packets:274 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:23148 (23.1 KB) TX bytes:24972 (24.9 KB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:522 errors:0 dropped:0 overruns:0 frame:0
TX packets:522 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:52384 (52.3 KB) TX bytes:52384 (52.3 KB)
Note: eth1, eth1.10 and eth1.20's HWaddr, they are all same
From node0, create 2 Macvlan netowrks, each Macvlan will have 2 containers running under that VLAN, VLAN eth1.10's IP range is 192.168.2.0/24 and VLAN eth1.20's IP range is 192.169.2.0/24
# First Macvlan network on VLAN eth1.10
docker network create -d macvlan --subnet=192.168.0.0/16 --ip-range=192.168.2.0/24 -o macvlan_mode=bridge -o parent=eth1.10 macvlan10
docker run --net=macvlan10 -itd --name macvlan10_1 busybox
docker run --net=macvlan10 -itd --name macvlan10_2 busybox
# Second Macvlan network on eth1.20
docker network create -d macvlan --subnet=192.169.0.0/16 --ip-range=192.169.2.0/24 -o macvlan_mode=bridge -o parent=eth1.20 macvlan20
docker run --net=macvlan20 -itd --name macvlan20_1 busybox
docker run --net=macvlan20 -itd --name macvlan20_2 busybox
From node1, create 2 Macvlan netowrks, each Macvlan will have 2 containers running under that VLAN, VLAN eth1.10's IP range is 192.168.3.0/24 and VLAN eth1.20's IP range is 192.169.3.0/24
# First Macvlan network on VLAN eth1.10
docker network create -d macvlan --subnet=192.168.0.0/16 --ip-range=192.168.3.0/24 -o macvlan_mode=bridge -o parent=eth1.10 macvlan10
docker run --net=macvlan10 -itd --name macvlan10_3 busybox
docker run --net=macvlan10 -itd --name macvlan10_4 busybox
# Second Macvlan network on VLAN eth1.20
docker network create -d macvlan --subnet=192.169.0.0/16 --ip-range=192.169.3.0/24 -o macvlan_mode=bridge -o parent=eth1.20 macvlan20
docker run --net=macvlan20 -itd --name macvlan20_3 busybox
docker run --net=macvlan20 -itd --name macvlan20_4 busybox
Now, we have finished Macvlan setup and we are going to test the network connectivity in next section.
3 Test Macvlan's Network Connectivity
We now have 2 Macvlan networks, and 8 containers are running on 2 nodes
| Node | Macvlan | Container | IP Address |
|---|---|---|---|
| node0 | macvlan10 | macvlan10_1 | 192.168.2.1 |
| node0 | macvlan10 | macvlan10_2 | 192.168.2.2 |
| node0 | macvlan20 | macvlan20_1 | 192.169.2.1 |
| node0 | macvlan20 | macvlan20_2 | 192.169.2.2 |
| node1 | macvlan10 | macvlan10_3 | 192.168.3.1 |
| node1 | macvlan10 | macvlan10_4 | 192.168.3.2 |
| node1 | macvlan20 | macvlan20_3 | 192.169.3.1 |
| node1 | macvlan20 | macvlan20_4 | 192.169.3.2 |
We are going to show how Macvlan works by running simple ICMP ping commands.
From node0, run docker ps, it shows we have 4 containers are running right now
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ec5fad3905b3 busybox "sh" 2 weeks ago Up 2 weeks macvlan20_2
4a790e26281b busybox "sh" 2 weeks ago Up 13 days macvlan20_1
ec71a1c389dc busybox "sh" 2 weeks ago Up 2 weeks macvlan10_2
77e6188d79ff busybox "sh" 2 weeks ago Up 13 days macvlan10_1
We are going to attach container macvlan10_1 to do some ICMP test
docker attach macvlan10_1
From bash shell inside of container macvlan10_1, run ifconfig -a to list network interfaces and IPs
/ # ifconfig -a
eth0 Link encap:Ethernet HWaddr 02:42:C0:A8:02:01
inet addr:192.168.2.1 Bcast:0.0.0.0 Mask:255.255.0.0
inet6 addr: fe80::42:c0ff:fea8:201/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:381 errors:0 dropped:0 overruns:0 frame:0
TX packets:2342 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:33358 (32.5 KiB) TX bytes:212848 (207.8 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:215 errors:0 dropped:0 overruns:0 frame:0
TX packets:215 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:24080 (23.5 KiB) TX bytes:24080 (23.5 KiB)
Note the HWaddr 02:42:C0:A8:02:01, it is a different MAC address than the attached interface eth1.10. This is becasuse in Macvlan, each container's interface will have its own MAC address.
Run route -n to list routing information, the default gateway is 192.168.2.0
/ # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.2.0 0.0.0.0 UG 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
Notice ping container macvlan10_2 (IP address 192.168.2.2) in same VM works, also ping container macvlan10_4(IP address 192.169.3.2) in different VM also works, this is because those containers are in the same VLAN 10.
/ # ping 192.168.2.2
PING 192.168.2.2 (192.168.2.2): 56 data bytes
64 bytes from 192.168.2.2: seq=0 ttl=64 time=0.056 ms
64 bytes from 192.168.2.2: seq=1 ttl=64 time=0.063 ms
^C
--- 192.168.2.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.056/0.059/0.063 ms
/ # ping 192.168.3.2
PING 192.168.3.2 (192.168.3.2): 56 data bytes
64 bytes from 192.168.3.2: seq=0 ttl=64 time=0.440 ms
64 bytes from 192.168.3.2: seq=1 ttl=64 time=0.320 ms
^C
--- 192.168.3.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.320/0.364/0.440 ms
When ping 192.169.3.2, An ARP request is broadcasted to all hosts on same VLAN.
If we capture a network trace from node1's eth1 interface
tcpdump -i eth1 -n -e
We could see and ARP request sent from node0's eth1 to ask MAC address of 192.168.3.2, this packet is broadcasted to all interfaces in same VLAN, that's reason why node1's eth1 interface can receive it.
20:22:41.028839 02:42:c0:a8:02:01 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP, Request who-has 192.168.3.2 tell 192.168.2.1, length 28
20:22:41.028933 02:42:c0:a8:03:02 > 02:42:c0:a8:02:01, ethertype 802.1Q (0x8100), length 46: vlan 10, p 0, ethertype ARP, Reply 192.168.3.2 is-at 02:42:c0:a8:03:02, length 28
Node1 eth1 replied ARP request, after getting the MAC address of 192.168.3.2, the ICMP packet then send out and it get received from node1 eth1's interface eventually.
20:22:41.029129 02:42:c0:a8:02:01 > 02:42:c0:a8:03:02, ethertype 802.1Q (0x8100), length 102: vlan 10, p 0, ethertype IPv4, 192.168.2.1 > 192.168.3.2: ICMP echo request, id 2304, seq 0, length 64
20:22:41.029162 02:42:c0:a8:03:02 > 02:42:c0:a8:02:01, ethertype 802.1Q (0x8100), length 102: vlan 10, p 0, ethertype IPv4, 192.168.3.2 > 192.168.2.1: ICMP echo reply, id 2304, seq 0, length 64
The network trace is captured from eth1 so we can see it contains 802.1Q header and it has 'vlan 10' included. If we capture network trace on eth1.10, then 802.1Q header will be stripped out. Also, in above network trace, the MAC address being used is 02:42:c0:a8:02:01, the MAC address of container macvlan10_1.
Below network trace captured on node1's eth1.10 interface show there is no VLAN tag.
tcpdump -i eth1.10 -n -e "arp or icmp"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1.10, link-type EN10MB (Ethernet), capture size 262144 bytes
09:36:43.482579 02:42:c0:a8:02:01 > 02:42:c0:a8:03:02, ethertype IPv4 (0x0800), length 98: 192.168.2.1 > 192.168.3.2: ICMP echo request, id 4352, seq 102, length 64
09:36:43.482616 02:42:c0:a8:03:02 > 02:42:c0:a8:02:01, ethertype IPv4 (0x0800), length 98: 192.168.3.2 > 192.168.2.1: ICMP echo reply, id 4352, seq 102, length 64
Let's try to ping VLAN 20's IP 192.169.2.1
/ # ping 192.169.2.1
PING 192.169.2.1 (192.169.2.1): 56 data bytes
^C
--- 192.169.2.1 ping statistics ---
11 packets transmitted, 0 packets received, 100% packet loss
You can see it's failed, this is because even VLAN 10 and VLAN 20 are attached to same physical network interface eth1 from node0, packets still won't be forwarded between different VLANs.
Later, we will discuss how to use master as a gateway to route traffics between different VLANs.
4 Route Traffics Between VLANs
Here is the solution to route traffics between different VLANs. We will use master as a gateway to route VLAN traffics
Enable IP forwarding on master
sysctl -w net.ipv4.ip_forward=1
Append below configurations to /etc/network/interfaces to create VLAN subinterfaces under eth1
vi /etc/network/interfaces
auto eth1
iface eth1 inet manual
auto eth1.10
iface eth1.10 inet manual
vlan-raw-device eth1
aut0 eth1.20
iface eth1.20 inet manual
vlan-raw-device eth1
Reboot master and bring up eth1.10 and eth1.20 subinterfaces
modprobe 8021q
ifup eth1.10
ifup eth1.20
Verfiy VLANs are created and up.
cat /proc/net/vlan/config
VLAN Dev name | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
eth1.10 | 10 | eth1
eth1.20 | 20 | eth1
Configure IP addresses on eth1.10 and eth1.20, those IP addresses will be gateway IP addresses for network 192.168.2.0/24, 192.169.2.0/24, 192.168.3.0/24 and 192.169.3.0/24.
ifconfig eth1.10 192.168.2.0 netmask 255.255.255.0 up
ifconfig eth1.20 192.169.2.0 netmask 255.255.255.0 up
ip address add 192.168.3.0/24 dev eth1.10
ip address add 192.169.3.0/24 dev eth1.20
The last step is to configure iptables, so that eth1.10(VLAN 10) and eth1.20(VLAN 20) can forward traffics to each other.
iptables -A FORWARD -i eth1.10 -o eth1.20 -j ACCEPT
iptables -A FORWARD -i eth1.20 -o eth1.10 -j ACCEPT
Let's ping 192.169.2.1 again, this time it works
/ # ping 192.169.2.1
PING 192.169.2.1 (192.169.2.1): 56 data bytes
64 bytes from 192.169.2.1: seq=0 ttl=63 time=0.710 ms
64 bytes from 192.169.2.1: seq=1 ttl=63 time=0.539 ms
64 bytes from 192.169.2.1: seq=2 ttl=63 time=0.546 ms
^C
--- 192.169.2.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.539/0.598/0.710 ms
Even ping 192.169.3.2, it still works
/ # ping 192.169.3.2
PING 192.169.3.2 (192.169.3.2): 56 data bytes
64 bytes from 192.169.3.2: seq=0 ttl=63 time=0.676 ms
64 bytes from 192.169.3.2: seq=1 ttl=63 time=0.525 ms
64 bytes from 192.169.3.2: seq=2 ttl=63 time=0.697 ms
^C
--- 192.169.3.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.525/0.632/0.697 ms
This is because master begins to forward traffics between differnt VLANs, if we capture network trace from master's eth1 interface, we can see traffics in below
21:10:20.668524 02:42:c0:a8:02:01 > 00:15:5d:10:31:14, ethertype 802.1Q (0x8100), length 102: vlan 10, p 0, ethertype IPv4, 192.168.2.1 > 192.169.3.2: ICMP echo request, id 3072, seq 0, length 64
21:10:20.668551 00:15:5d:10:31:14 > 02:42:c0:a9:03:02, ethertype 802.1Q (0x8100), length 102: vlan 20, p 0, ethertype IPv4, 192.168.2.1 > 192.169.3.2: ICMP echo request, id 3072, seq 0, length 64
21:10:20.668821 02:42:c0:a9:03:02 > 00:15:5d:10:31:14, ethertype 802.1Q (0x8100), length 102: vlan 20, p 0, ethertype IPv4, 192.169.3.2 > 192.168.2.1: ICMP echo reply, id 3072, seq 0, length 64
21:10:20.668840 00:15:5d:10:31:14 > 02:42:c0:a8:02:01, ethertype 802.1Q (0x8100), length 102: vlan 10, p 0, ethertype IPv4, 192.169.3.2 > 192.168.2.1: ICMP echo reply, id 3072, seq 0, length 64
5 Summary
Macvlan allows creation of multiple virtual network interfaces behind the host’s single physical interface Each virtual interface has unique MAC and IP addresses assigned with restriction: the IP address needs to be in the same broadcast domain as the physical interface eliminates the need for the Linux bridge, NAT and port- mapping allowing you to connect directly to physical interface.