Docker strips VLAN tag

[ghost]

GNS3 version 1.5.3dev1 on Darwin (64-bit) with Python 3.5.2 Qt 5.6.0, self made GNS3-VM version 1.5.3dev1 on debian stretch (64-bit) with Python 3.5.2

1. VLAN interface within Linux

I'm using a pure alpine container, tcpdump is additionally installed. I've connected eth0 to another alpine container. Then on both sides eth0.100 is configured as a vlan tagged interface.

ip link add link eth0 name eth0.100 type vlan id 100
ip addr add 192.168.100.1/24 brd 192.168.100.255 dev eth0.100
ip link set dev eth0.100 up

Of course alpine-2 uses IP address is 192.168.100.2/24. Pinging 192.168.100.2 from alpine-1 doesn't work. Starting a tcpdump -eX -i eth0 within the alpine container shows the vlan tag 100.

08:56:29.030701 1e:fe:3a:db:32:82 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Request who-has 192.168.100.2 tell 192.168.100.1, length 28
    0x0000:  0064 0806 0001 0800 0604 0001 1efe 3adb  .d............:.
    0x0010:  3282 c0a8 6401 0000 0000 0000 c0a8 6402  2...d.........d.

But a wireshark trace on the link shows this ARP request without the VLAN tag, it's stripped.

2. VLAN interface within docker-IOU

Thanks to Stephen C. Moore for this discovery.

I've created an IOU-L3-router (see GNS3/gns3-gui#1508), but added tcpdump to the iou-base image. Then I added two IOU routers to GNS3, interconnected the eth0 interfaces and configured vlan tagged sub interfaces.

interface Ethernet0/0
 no ip address
!
interface Ethernet0/0.123
 encapsulation dot1Q 123
 ip address 10.1.123.1 255.255.255.0
!

Pinging the partner IOU with IP 10.1.123.2 doesn't work. A tcpdump -eX -i eth0 with the IOU container shows the VLAN tag.

09:00:39.830797 aa:bb:cc:03:42:00 (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 64: vlan 123, p 0, ethertype ARP, Request who-has 10.1.123.2 tell 10.1.123.1, length 46
    0x0000:  007b 0806 0001 0800 0604 0001 aabb cc03  .{..............
    0x0010:  4200 0a01 7b01 0000 0000 0000 0a01 7b02  B...{.........{.
    0x0020:  0000 0000 0000 0000 0000 0000 0000 0000  ................
    0x0030:  0000                                     ..

But again a wireshark trace on the link shows the ARP packet without VLAN tag.

[julien-duponchelle]

Could be complex to solve. I suspect that the kernel strip the info because the VLAN is specific to a network namespace

[julien-duponchelle]

What do you think @grossmj ?

[CapnCheapo]

I believe the following link shows that tagging in docker is an experimental feature right now?
https://github.com/docker/docker/blob/master/experimental/vlan-networks.md

[julien-duponchelle]

The network part for Docker in GNS3 is made by GNS3 not by Docker. The docker network is not flexible, the objective is to provide an interface with an IP they have no reason to offer interface without IP.

But it's true that we do it like docker people by pushing a veth inside the network namespace of the container. And it 's perhaps what we need to change.

From what I understand the macvlan or ipvlan allow to expose a container network interface on the network without the need to use port redirection and stuff like that.

What we need is a dummy interface where we can inject packet to the container from the host os without any modification.

[julien-duponchelle]

Perhaps we could push a tap instead of the VETH

[grossmj]

I don't know if this is possible. The documented way is to use VETH.

[julien-duponchelle]

Test instructions ready to copy/paste

Alpine 1

ip link add link eth0 name eth0.100 type vlan id 100
ip addr add 192.168.100.1/24 brd 192.168.100.255 dev eth0.100
ip link set dev eth0.100 up

Alpine 2

ip link add link eth0 name eth0.100 type vlan id 100
ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth0.100
ip link set dev eth0.100 up
ping 192.168.100.1

[julien-duponchelle]

Good news it seem to work with a tap I will make clean patch for this

[julien-duponchelle]

I pushed the change on 2.0 branch if you can test it.

I have share feeling about backporting it to 1.5. I'm affraid that the change could create side effect.

[ghost]

Great news, I haven't expect it that fast.

I agree, that such a change should not be included in 1.5. Sadly I currently need a stable GNS3, so I can't update to 2.0, maybe when a beta is available.

[julien-duponchelle]

Ok will ship in 2.0.0 alpha 3