Bug 70151 - redundant GRE tunnel on same interface not brought down when gre link is downed
Summary: redundant GRE tunnel on same interface not brought down when gre link is downed
Status: NEW
Alias: None
Product: Networking
Classification: Unclassified
Component: IPV4 (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Stephen Hemminger
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-06 15:19 UTC by tbeadle
Modified: 2016-02-15 20:37 UTC (History)
2 users (show)

See Also:
Kernel Version: 3.10.0+
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments

Description tbeadle 2014-02-06 15:19:41 UTC
Say I have two IP's assigned to an interface (either a physical interface or an 802.1q sub-interface) and I create two gre interface, using each of the IP addresses assigned above as the local endpoint.  I can send GRE keepalives to either gre interface and a response is received.

Now if I bring one of the gre interfaces down and then send a keepalive to it, a response is still received.  Not until I bring down the other interface also do I stop getting responses.

Prior to the GRE/tunnel refactoring introduced in 3.10.0 (commit c5441932), the keepalives to the downed gre interface would not elicit a response.  I have tested kernels from 3.10.0 up through 3.13.0.

Steps to reproduce:
- Assign 192.168.56.1/24 to eth0 on a machine to be used to send the keepalives (SENDER).

- Assign 192.168.56.3/24 and 192.168.56.4/24 to eth0 on the device under test (DUT).
ip addr add 192.168.56.3/24 dev eth0
ip addr add 192.168.56.4/24 dev eth0

- Bring up the 2 GRE interfaces on DUT.
ip tunnel add gre1 mode gre remote 192.168.56.1 local 192.168.56.3 ttl 255
ip link set gre1 up
sysctl -w net.ipv4.conf.gre1.accept_local=1
sysctl -w net.ipv4.conf.gre1.forwarding=1
sysctl -w net.ipv6.conf.gre1.forwarding=1
ip tunnel add gre2 mode gre remote 192.168.56.1 local 192.168.56.4 ttl 255
ip link set gre2 up
sysctl -w net.ipv4.conf.gre2.accept_local=1
sysctl -w net.ipv4.conf.gre2.forwarding=1
sysctl -w net.ipv6.conf.gre2.forwarding=1

- I used scapy on SENDER to generate a GRE keepalive packet to 192.168.56.3 (08:00:27:53:aa:c1 is the MAC address of eth0 on DUT):
>>> ip = IP(src='192.168.56.1', dst='192.168.56.3')
>>> pkt = Ether(dst='08:00:27:53:aa:c1')/ip/GRE()/IP(src=ip.dst,
>>> dst=ip.src)/GRE()
>>> sendp(pkt, iface='eth0')

- When issuing the sendp command, run "tcpdump -nvi eth0 proto gre" on SENDER.  You should see the following request and reply:

22:24:09.608401 IP (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto GRE (47), length 48)
    192.168.56.1 > 192.168.56.3: GREv0, Flags [none], length 28
        IP (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto GRE (47), length 24)
    192.168.56.3 > 192.168.56.1: GREv0, Flags [none], length 4
        gre-proto-0x0
22:24:09.608879 IP (tos 0x0, ttl 63, id 1, offset 0, flags [none], proto GRE (47), length 24)
    192.168.56.3 > 192.168.56.1: GREv0, Flags [none], length 4
        gre-proto-0x0

- On DUT, run "ip link set gre1 down" and do the sendp command again from SENDER, watching the tcpdump output as well.  With kernels 3.10.0+, you'll still see a response packet.  With earlier kernels, no response is sent, which is the appropriate behavior.

Note that, with 3.10.0+, if you now run "ip link set gre2 down" and do the sendp again, no response is sent.
Comment 1 Alan 2014-02-07 11:29:29 UTC
If you have not already done so then it's worth posting this example and the commit number that introduces the problem to netdev@vger.kernel.org for more immediate discussion
Comment 2 Stephen Hemminger 2014-02-07 16:45:52 UTC
There are several layers that cause what you see:

1. Linux uses weak host model. All IP's are really property of system and are responded to indpependantly of whether link is up or not.

2. It may be that some of the link state is not being propogated correctly.

3. Third IFF_RUNNING is not considered in response to ping's. Related to #1.

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