I started working with VLAN kernel capabilities only recently and found a pretty challenging domain.

I thought I had almost everything in control but then found a problem which I am apparently unable to solve.

I have some automatic scripts taking care of creating and destroying some network namespaces which must isolate a user domain from one another.

In one of my servers, this script has been properly working for 2 months now, but suddenly today it started misbehaving in a very odd way. Kernel version is 3.13.0-24-generic running within Ubuntu 14.04 LTS.

This is the current situation:

cat /proc/net/vlan/config

VLAN Dev name    | VLAN ID

So nothing there.

ip netns ls


That is my namespace is still there.

ip netns exec TEST cat /proc/net/vlan/config

VLAN Dev name    | VLAN ID
tap0.105       | 105  | tap0

I have defined a virtual tagged interface in this domain, which is properly configured and correctly running.

ip netns exec TEST ip addr

1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default 
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
92: tap0.105@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc 
      noqueue state UP group default 
    link/ether 5a:ff:b5:98:6f:c2 brd ff:ff:ff:ff:ff:ff
    inet scope global tap0.105
      valid_lft forever preferred_lft forever
    inet6 fe80::58ff:b5ff:fe98:6fc2/64 scope link 
      valid_lft forever preferred_lft forever

Then the problem:

vconfig add eth1 10

ERROR: trying to add VLAN #10 to IF -:eth1:-  error: File exists

and, of course:

vconfig rem eth1.10

ERROR: trying to remove VLAN -:eth1.10:- error: No such device

I tried to look on the internet for similar error cases but with no success. Some other outputs:

ip netns pids TEST

gives no result.

This is an STRACE of the command:

root@d-intfw1:~# strace vconfig add eth1 10 execve("/sbin/vconfig", ["vconfig", "add", "eth1", "10"], [/* 17 vars */]) = 0 brk(0) = 0x1a2a000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f361112c000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=24418, ...}) = 0 mmap(NULL, 24418, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f3611126000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\37\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1845024, ...}) = 0 mmap(NULL, 3953344, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3610b46000 mprotect(0x7f3610d02000, 2093056, PROT_NONE) = 0 mmap(0x7f3610f01000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1bb000) = 0x7f3610f01000 mmap(0x7f3610f07000, 17088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f3610f07000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3611125000 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3611123000 arch_prctl(ARCH_SET_FS, 0x7f3611123740) = 0 mprotect(0x7f3610f01000, 16384, PROT_READ) = 0 mprotect(0x601000, 4096, PROT_READ) = 0 mprotect(0x7f361112e000, 4096, PROT_READ) = 0 munmap(0x7f3611126000, 24418) = 0 open("/proc/net/vlan/config", O_RDONLY) = 3 close(3) = 0 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3 ioctl(3, SIOCSIFVLAN, 0x7fffeead1420) = -1 EEXIST (File exists) write(2, "ERROR: trying to add VLAN #10 to"..., 65ERROR: trying to add VLAN #10 to IF -:eth1:- error: File exists ) = 65 exit_group(3) = ? +++ exited with 3 +++

Does anyone know what the cause might be for such a behaviour? Thanks a lot.

  • strace vconfig rem eth1.10.? – Green Tree Nov 15 '18 at 11:57
  • Did you ever resolve this issue and how? Could you share if you did? – Lifeboy Jun 20 at 14:06
  • Hi @Lifeboy, I finally understood that whenever this happens, there's likely a process having "something to do" (likely an open file descriptor) with that namespace which is still hanging there (in a non-well defined environment, since the namespace does not exist anymore). Terminating the culprit should be enough, but discovering its identity may not be the simplest quest ever (I once had a strongswan daemon running bound to that netns, which I forgot to stop before deleting the netns). – Blazor Aug 9 at 15:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.