Bug 437410 - ip tunnel can't be bound to another device
ip tunnel can't be bound to another device
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.6
All Linux
high Severity high
: rc
: 4.8
Assigned To: Michal Schmidt
Martin Jenner
:
Depends On: 419671
Blocks: 391511 447953 458123 461297 494835
  Show dependency treegraph
 
Reported: 2008-03-13 17:48 EDT by Vince Worthington
Modified: 2010-10-22 19:14 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-18 15:21:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
rebinding of IPIP, GRE, SIT tunnels (9.36 KB, patch)
2008-06-13 08:18 EDT, Michal Schmidt
no flags Details | Diff
testing script (525 bytes, application/x-shellscript)
2008-06-13 08:22 EDT, Michal Schmidt
no flags Details

  None (edit)
Description Vince Worthington 2008-03-13 17:48:59 EDT
Cloning for RHEL4 since we have a customer looking for this solution.

+++ This bug was initially created as a clone of Bug #419671 +++

Description of problem:
ip tunnel can't be bound to another device

Version-Release number of selected component (if applicable):
kernel-2.6.23.8-63.fc8 with latest iproute-2.6.22

How reproducible:
always

Steps to Reproduce:
1. create tunnel
# ip tunnel add tunneltest0 mode ipip remote 10.0.0.1 dev eth0
2. try to change the bounding device from eth0 to eth1
# ip tunnel change tunneltest0 dev eth1
3. show the result
# ip tunnel show tunneltest0
# tunneltest0: ip/ip  remote 10.0.0.1  local any  dev eth0  ttl inherit

Actual results:
The tunnel bounding can't be change on the other device.

Expected results:
The tunnel bounding can be change on the other device.

-- Additional comment from tjanouse@redhat.com on 2007-12-11 08:05 EST --
Our short investigation showed that the SIOCCHGTUNNEL case in
net/ipv6/sit.c:ipip6_tunnel_ioctl does not care about the p->link at all. And
it's probably the same for ipip and gre.

-- Additional comment from mschmidt@redhat.com on 2007-12-12 09:44 EST --
I took a look at net/ipv4/ipip.c (this one is relevant for the provided
testcase). Tomas, you're right that the handler for SIOCCHGTUNNEL ioctl ignores
p.link completely.

I have a patch to allow re-binding the tunnel to another device. It also
recalculates the MTU of the tunnel from the known MTU of the newly bound device.
I believe it's the right thing to do in this case. I'll send the patch to netdev
and if it's accepted, I'll make similar changes to gre and sit.

(Assigning the bug to myself.)

-- Additional comment from mschmidt@redhat.com on 2007-12-12 09:45 EST --
Created an attachment (id=285761)
allow rebinding of ipip tunnels


-- Additional comment from mschmidt@redhat.com on 2007-12-14 07:18 EST --
The patch was sent to netdev (http://www.spinics.net/lists/netdev/msg49844.html). 
It was accepted with a small modification.

I submitted similar patches for GRE and SIT
(http://www.spinics.net/lists/netdev/msg49983.html).

Dave Miller applied all three patches to his git tree. They will be in Linux 2.6.25.


-- Additional comment from tjanouse@redhat.com on 2007-12-14 16:00 EST --
Thanks, Michal.
If I'm not mistaken, no further modification to iproute should be needed.

-- Additional comment from mschmidt@redhat.com on 2007-12-14 17:46 EST --
Tomas,
correct, no change is needed in iproute.
Comment 3 RHEL Product and Program Management 2008-05-14 09:25:30 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 4 Michal Schmidt 2008-06-13 08:18:48 EDT
Created attachment 309199 [details]
rebinding of IPIP, GRE, SIT tunnels

This is a backported patch for RHEL4. I'm testing it.
Comment 5 Michal Schmidt 2008-06-13 08:22:24 EDT
Created attachment 309200 [details]
testing script

A script to test rebinding of IPIP, GRE and SIT tunnels. "Before" and "After"
must differ for each type. "After" must show the new bound device and MTU.
Comment 6 Michal Schmidt 2008-06-16 10:42:49 EDT
I uploaded a test kernel with the patch applied to my personal Jabber disk:

http://disk.jabbim.cz/michich@jabber.cz/kernel-2.6.9-72.mschmidt1.EL.src.rpm
http://disk.jabbim.cz/michich@jabber.cz/kernel-2.6.9-72.mschmidt1.EL.i686.rpm
http://disk.jabbim.cz/michich@jabber.cz/kernel-2.6.9-72.mschmidt1.EL.x86_64.rpm
http://disk.jabbim.cz/michich@jabber.cz/kernel-smp-2.6.9-72.mschmidt1.EL.i686.rpm
http://disk.jabbim.cz/michich@jabber.cz/kernel-smp-2.6.9-72.mschmidt1.EL.x86_64.rpm

Changing the bound device should work with this kernel for IPIP, GRE and SIT
tunnels. Could you please test one of these kernels to verify the fix works as
you expect? You do not have to test all three types of tunnels, just the types
you use.

Note: This kernel build is for testing only and it did not go through proper QA.
Comment 7 Issue Tracker 2008-06-17 07:34:35 EDT
Sorr, Janne was not on notification list, fixed.

So onece again, Janne Karhunen to please test packages linked at
https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=139309&gid=836&view_type=lifoall#eid_2115835


This event sent from IssueTracker by pernzer 
 issue 139309
Comment 8 Issue Tracker 2008-06-19 04:36:20 EDT
Works as expected. Tested on i386. 

Internal Status set to 'Waiting on Support'
Status set to: Waiting on Tech

This event sent from IssueTracker by sprabhu 
 issue 139309
Comment 10 RHEL Product and Program Management 2008-09-03 08:51:31 EDT
Updating PM score.
Comment 11 Vivek Goyal 2009-01-26 10:10:44 EST
Committed in 80.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
Comment 13 J.H.M. Dassen (Ray) 2009-02-16 08:55:01 EST
Partner has confirmed that the tunnels can be bound to another device when running the test kernel supplied to them.
Comment 14 J.H.M. Dassen (Ray) 2009-02-16 09:59:59 EST
For completeness, here's the partner's response:
Seems to work. Thank you.


[root@carpet ~]# uname -a
Linux carpet 2.6.9-80.ELsmp #1 SMP Fri Jan 23 16:30:12 EST 2009 i686 i686 i386 GNU/Linux

[root@carpet ~]# ip a
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
   link/ether 00:90:27:8e:09:52 brd ff:ff:ff:ff:ff:ff
   inet 10.144.71.126/22 brd 10.144.71.255 scope global eth0
   inet6 fe80::290:27ff:fe8e:952/64 scope link
      valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
   link/ether 00:06:29:89:6b:d5 brd ff:ff:ff:ff:ff:ff
   inet 192.168.0.2/24 brd 192.168.0.255 scope global eth1
4: sit0: <NOARP> mtu 1480 qdisc noop
   link/sit 0.0.0.0 brd 0.0.0.0
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]# ip tunnel add tunneltest0 mode ipip remote 10.0.0.1 dev eth0
[root@carpet ~]#
[root@carpet ~]# ip a
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
   link/ether 00:90:27:8e:09:52 brd ff:ff:ff:ff:ff:ff
   inet 10.144.71.126/22 brd 10.144.71.255 scope global eth0
   inet6 fe80::290:27ff:fe8e:952/64 scope link
      valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
   link/ether 00:06:29:89:6b:d5 brd ff:ff:ff:ff:ff:ff
   inet 192.168.0.2/24 brd 192.168.0.255 scope global eth1
4: sit0: <NOARP> mtu 1480 qdisc noop
   link/sit 0.0.0.0 brd 0.0.0.0
5: tunl0: <NOARP> mtu 1480 qdisc noop
   link/ipip 0.0.0.0 brd 0.0.0.0
6: tunneltest0@eth0: <POINTOPOINT,NOARP> mtu 1480 qdisc noop
   link/ipip 0.0.0.0 peer 10.0.0.1
[root@carpet ~]#
[root@carpet ~]# ip tunnel show tunneltest0
tunneltest0: ip/ip  remote 10.0.0.1  local any  dev eth0  ttl inherit
[root@carpet ~]#  ip link show tunneltest0
6: tunneltest0@eth0: <POINTOPOINT,NOARP> mtu 1480 qdisc noop
   link/ipip 0.0.0.0 peer 10.0.0.1
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]# ip tunnel change tunneltest0 dev eth1
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]# ip tunnel show tunneltest0
tunneltest0: ip/ip  remote 10.0.0.1  local any  dev eth1  ttl inherit
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]#  ip link show tunneltest0
6: tunneltest0@eth1: <POINTOPOINT,NOARP> mtu 1480 qdisc noop
   link/ipip 0.0.0.0 peer 10.0.0.1
Comment 16 Chris Ward 2009-03-27 10:18:55 EDT
~~ Attention Partners! Snap 1 Released ~~
RHEL 4.8 Snapshot 1 has been released on partners.redhat.com. There should
be a fix present, which addresses this bug. NOTE: there is only a short time
left to test, please test and report back results on this bug
at your earliest convenience.

If you encounter any issues, please set the bug back to the ASSIGNED state and
describe the issues you encountered. If you have found a NEW bug, clone this
bug and describe the issues you encountered. Further questions can be
directed to your Red Hat Partner Manager.

If you have VERIFIED the bug fix. Please select your PartnerID from the
Verified field above. Please leave a comment with your test results details.
Include which arches tested, package version and any applicable logs.

 - Red Hat QE Partner Management
Comment 17 Chris Ward 2009-04-14 12:11:53 EDT
Verified that the patch is the same as tested in .80. See comment #14.
Comment 19 errata-xmlrpc 2009-05-18 15:21:40 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-1024.html

Note You need to log in before you can comment on or make changes to this bug.