Notes: When a tool loads some of the network device modules into the kernel, they create one interface ending with 0. This can typically be fixed by using a module option.

I'm getting the following with RHEL 6 and upstream:

# ip tunnel add zxcv mode gre
add tunnel "gre0" failed: File exists

And with RHEL 6, I see only gre0 in the "ip tunnel show" after adding a tunnel with a different name output, so I'm getting a wrong result, albeit a different one than described in the original bug report.

Hi Pavel,

I tested it on rhel6 and rhel7 and bellow are my results.

rhel6:

# ip l show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: usb0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether e6:1f:13:1b:f0:93 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether e4:1f:13:1a:f0:90 brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether e4:1f:13:1a:f0:92 brd ff:ff:ff:ff:ff:ff

# lsmod|grep ip_

# ip tunnel add TestIface mode gre && echo ok
ok

# ip l show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: usb0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether e6:1f:13:1b:f0:93 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether e4:1f:13:1a:f0:90 brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether e4:1f:13:1a:f0:92 brd ff:ff:ff:ff:ff:ff
12: gre0: <NOARP> mtu 1476 qdisc noop state DOWN 
    link/gre 0.0.0.0 brd 0.0.0.0
13: gretap0: <BROADCAST,MULTICAST> mtu 1476 qdisc noop state DOWN qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

# lsmod|grep ip_
ip_gre                  9575  0 
ip_tunnel              12693  1 ip_gre
ipv6                  334932  63 ip_tunnel

You can see that ip route did nothing useful, at least not created TestIface, and returned 0. It just loaded kernel module ip_gre a ip_tunnel. These modules created two interfaces grep0 and grepta0.

Creating gre tunnel without destination ip address does not make sense. If I add remote option, it will work as I expect.

# ip tunnel add TestIface mode gre remote 192.168.1.1 && echo ok
ok

# ip l show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: usb0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether e6:1f:13:1b:f0:93 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether e4:1f:13:1a:f0:90 brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether e4:1f:13:1a:f0:92 brd ff:ff:ff:ff:ff:ff
12: gre0: <NOARP> mtu 1476 qdisc noop state DOWN 
    link/gre 0.0.0.0 brd 192.168.1.1
13: gretap0: <BROADCAST,MULTICAST> mtu 1476 qdisc noop state DOWN qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
14: TestIface@NONE: <POINTOPOINT,NOARP> mtu 1476 qdisc noop state DOWN 
    link/gre 0.0.0.0 peer 192.168.1.1

# ip tunnel show
gre0: gre/ip  remote any  local any  ttl inherit 
TestIface: gre/ip  remote 192.168.1.1  local any  ttl inherit 

Results: gre0 is default iface which is created by loading kernel module. The problem is that ip tunnel does not create requested interface and return 0, which means success.

rhel7:

# ip l show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 28:d2:44:55:5a:fd brd ff:ff:ff:ff:ff:ff
3: wwp0s20u4i6: <BROADCAST,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 12:39:a2:6d:3b:46 brd ff:ff:ff:ff:ff:ff
4: wlp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT qlen 1000
    link/ether 5c:51:4f:e8:d8:0c brd ff:ff:ff:ff:ff:ff
5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT 
    link/ether 52:54:00:0c:bb:d0 brd ff:ff:ff:ff:ff:ff
6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN mode DEFAULT qlen 500
    link/ether 52:54:00:0c:bb:d0 brd ff:ff:ff:ff:ff:ff
# lsmod|grep ip_
ip_tables              27239  5 iptable_security,iptable_filter,iptable_mangle,iptable_nat,iptable_raw

# ip tunnel add TestIface mode gre && echo ok
add tunnel "gre0" failed: File exists

# ip l show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 28:d2:44:55:5a:fd brd ff:ff:ff:ff:ff:ff
3: wwp0s20u4i6: <BROADCAST,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 12:39:a2:6d:3b:46 brd ff:ff:ff:ff:ff:ff
4: wlp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT qlen 1000
    link/ether 5c:51:4f:e8:d8:0c brd ff:ff:ff:ff:ff:ff
5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT 
    link/ether 52:54:00:0c:bb:d0 brd ff:ff:ff:ff:ff:ff
6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN mode DEFAULT qlen 500
    link/ether 52:54:00:0c:bb:d0 brd ff:ff:ff:ff:ff:ff
11: gre0: <NOARP> mtu 1476 qdisc noop state DOWN mode DEFAULT 
    link/gre 0.0.0.0 brd 0.0.0.0
12: gretap0: <BROADCAST,MULTICAST> mtu 1476 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

# ip tunnel add TestIface mode gre remote 192.168.1.1 && echo ok
ok

# ip l show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 28:d2:44:55:5a:fd brd ff:ff:ff:ff:ff:ff
3: wwp0s20u4i6: <BROADCAST,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 12:39:a2:6d:3b:46 brd ff:ff:ff:ff:ff:ff
4: wlp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DORMANT qlen 1000
    link/ether 5c:51:4f:e8:d8:0c brd ff:ff:ff:ff:ff:ff
5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT 
    link/ether 52:54:00:0c:bb:d0 brd ff:ff:ff:ff:ff:ff
6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN mode DEFAULT qlen 500
    link/ether 52:54:00:0c:bb:d0 brd ff:ff:ff:ff:ff:ff
11: gre0: <NOARP> mtu 1476 qdisc noop state DOWN mode DEFAULT 
    link/gre 0.0.0.0 brd 0.0.0.0
12: gretap0: <BROADCAST,MULTICAST> mtu 1476 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
13: TestIface@NONE: <POINTOPOINT,NOARP> mtu 1476 qdisc noop state DOWN mode DEFAULT 
    link/gre 0.0.0.0 peer 192.168.1.1

# ip tunnel show
TestIface: gre/ip  remote 192.168.1.1  local any  ttl inherit 
gre0: gre/ip  remote any  local any  ttl inherit  nopmtudisc

There is a difference between rhel6 and rhel7. Rhel7 reports error and returns non zero value, but still there is a problem, because ip tunnel tries to create grep0 interface instead of TestIface.

It seems to me, that if there is no option remote, ip tunnel ignores requested name of tunnel interface and use grep0 as a default.  Then, on rhel6, do nothing, because gre0 exists and, on rhel7, reports error because gre0 exists. Both are mistakes.

rhel6: iproute-2.6.32-45.el6.x86_64
rhel7: iproute-3.10.0-21.el7.x86_64

We could not reproduce the originally reported issue, please retry with current RHEL6 kernel and iproute. On the other hand, we found issues with "ip tunnel" in both RHEL6 and RHEL7 and we are going to further investiage those.

My intention is to eventually close this bug and and start new bugs for Fedora/RHEL7 and work with upstream on fixing the issues we found. Once you retry with current packages, you will probably find slightly different issues than originally reported and the best way to handle those is to file new bugzilla ticket(s).

I also investigated the possibility of getting rid of automatically creating gre0 and gretap0. But I found out that iproute2 doesn't generally load modules and leaves it up to the kernel to load them and I have no indication that upstream was going to change that. I also found out that there is no module option to suppress that like 'max_bonds=0' which suppresses similar behavior in 'bonding' module.

# modinfo ip_gre
filename:       /lib/modules/3.10.0-229.el7.x86_64/kernel/net/ipv4/ip_gre.ko
alias:          netdev-gretap0
alias:          netdev-gre0
alias:          rtnl-link-gretap
alias:          rtnl-link-gre
license:        GPL
rhelversion:    7.1
srcversion:     9EF4BA6E37B09845120B3AF
depends:        ip_tunnel,gre
intree:         Y
vermagic:       3.10.0-229.el7.x86_64 SMP mod_unload modversions 
signer:         Red Hat Enterprise Linux kernel signing key
sig_key:        A3:CB:8C:C3:19:50:4A:B5:2C:FB:76:BA:F8:D8:A2:A7:39:68:9C:56
sig_hashalgo:   sha256
parm:           log_ecn_error:Log packets received with corrupted ECN (bool)

(the above command was run on RHEL 7)

Another thing is that "ip tunnel" (even in upstream) appears to use ioctl instead of netlink to my surprise.

(In reply to Pavel Šimerda (pavlix) from comment #7)
> We could not reproduce the originally reported issue, please retry with
> current RHEL6 kernel and iproute. On the other hand, we found issues with
> "ip tunnel" in both RHEL6 and RHEL7 and we are going to further investiage
> those.
> 
> My intention is to eventually close this bug and and start new bugs for
> Fedora/RHEL7 and work with upstream on fixing the issues we found. Once you
> retry with current packages, you will probably find slightly different
> issues than originally reported and the best way to handle those is to file
> new bugzilla ticket(s).

I tried with latest RHEL6 and also could not reproduce now. So I agree we can close this bug now.

Thanks
Hangbin

(In reply to Hangbin Liu from comment #9)
> I tried with latest RHEL6 and also could not reproduce now. So I agree we
> can close this bug now.

Thank you and looking forward to the next chance of cooperation.

Pavel