IPv6 addresses are lost when an interface is shortly down

Bug #1218442 reported by Thomas Dreibholz
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
ifupdown (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

/etc/network/interfaces has been configured with IPv4 and IPv6 addresses on an interface. There are two networks each:

$ ip -4 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    inet 10.1.1.51/24 brd 10.1.1.255 scope global eth0
    inet 10.2.1.51/24 brd 10.2.1.255 scope global eth0

$ ip -6 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 xxxx:yyyy:zzzz:201::33/64 scope global
       valid_lft forever preferred_lft forever
    inet6 xxxx:yyyy:zzzz:101::33/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::aaaa:aaff:febb:ccdd/64 scope link
       valid_lft forever preferred_lft forever

(Global addresses and MAC address anonymized)

Both are configured within "manual" entries in /etc/network/interfaces.

When I turn down eth0 and bring it up again, the result is:

$ ip -4 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    inet 10.1.1.51/24 brd 10.1.1.255 scope global eth0
    inet 10.2.1.51/24 brd 10.2.1.255 scope global eth0

$ ip -6 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 fe80::aaaa:aaff:febb:ccdd/64 scope link
       valid_lft forever preferred_lft forever

That is, the global IPv6 addresses are lost.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: ifupdown 0.7.5ubuntu2
ProcVersionSignature: Ubuntu 3.8.0-29.42-generic 3.8.13.5
Uname: Linux 3.8.0-29-generic x86_64
ApportVersion: 2.9.2-0ubuntu8.3
Architecture: amd64
Date: Thu Aug 29 16:28:46 2013
InstallationDate: Installed on 2013-08-14 (14 days ago)
InstallationMedia: Kubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
MarkForUpload: True
SourcePackage: ifupdown
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Thomas Dreibholz (dreibh) wrote :
Revision history for this message
Thomas Dreibholz (dreibh) wrote :

There may be a relation to bug #599340 (https://bugs.launchpad.net/ubuntu/+source/netscript-2.4/+bug/599340), but I am using the ifupdown provided with Ubuntu.

Revision history for this message
Thomas Dreibholz (dreibh) wrote :

I have also deinstalled the unnecessary network-manager and avahi-daemon packages, in order to make sure that they do not interfere with ifupdown. But no change.

Revision history for this message
Thomas Dreibholz (dreibh) wrote :

Also, using a "static" or "manual" inet6 entry in /etc/network/interfaces does not matter. The IPv6 address(es) are removed regardless of the entry type while the IPv4 addresses remain.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ifupdown (Ubuntu):
status: New → Confirmed
Revision history for this message
Pedro Morales (pedratan) wrote :

Same happens to me with addresses assigned by the openconnect vpn.
After establishing the connection I manually change the mtu in the vpn adapter and NetworkManager (or at least it says it is him in the logs) reloads the interface and loses all the IPv6 configuration

Revision history for this message
Jan Baranowski (jan-baranowski) wrote :
Download full text (33.1 KiB)

I can also confirm that the issue exists.

I'm the administrator of 2 DNS nameservers (bind9) running Ubuntu 14.04.5 LTS with upgraded kernel (linux-image-generic-lts-xenial which depends on linux-image-4.4.0-81-generic at this time).

root@ns2:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty

root@ns2:~# uname -a
Linux ns2 4.4.0-81-generic #104~14.04.1-Ubuntu SMP Wed Jun 14 12:45:52 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

While one of nameservers behaves as expected, the other experiences the issue described above:

It's dual stack setup, i.e. there is global IPv4 and IPv6 address on a single interface. /etc/network/interfaces on failing machine is as follows (IPs have been obfuscated):

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
        address XXX.XXX.XXX.34
        netmask 255.255.255.224
        network XXX.XXX.XXX.32
        broadcast XXX.XXX.XXX.63
        gateway XXX.XXX.XXX.33
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers XXX.XXX.XXX.35 XXX.XXX.XXX.3
        dns-search XXXXX

iface eth0 inet6 static
        address XXXX:XXXX:XXXX:XXXX:2::1
        netmask 64
        gateway XXXX:XXXX:XXXX:XXXX::1

The problem I'm experiencing is that there is no default IPv6 route set after reboot. Setting it manually temporarily fixes the problem.

Investigation:

1. ifconfig shows eth0 is up with 1 v4, 1 v6 link-local and 1 v6 global IP address (seems OK)
2. route -6 -n shows single v6 default route using link-local address of router's interface as nexthop
3. /etc/init.d/networking stop says: stop: job failed while stopping
4. by examining this initscript i established that it uses ifdown internally, ifdown -a --exclude=lo -v to be exact
5.

root@ns2:~# ifdown -a --exclude=lo -v
run-parts --verbose /etc/network/if-down.d
run-parts: executing /etc/network/if-down.d/bind9
run-parts: executing /etc/network/if-down.d/resolvconf
run-parts: executing /etc/network/if-down.d/upstart
run-parts --verbose /etc/network/if-post-down.d
run-parts: executing /etc/network/if-post-down.d/ip6tasave
run-parts: executing /etc/network/if-post-down.d/iptasave

root@ns2:~# echo $?
0

which is strange because SSH connectivity remains intact

6.
root@ns2:~# ifdown eth0
ifdown: interface eth0 not configured

this makes more sense

7. there is --force switch to ifdown; lets try it

root@ns2:~# ifdown eth0 --force

finally brings eth0 down

moreover, subsequent:

root@ns2:~# ifup eth0

brings interface up and sets v6 gateway correctly

8. at this point I still cannot stop & start "networking" using initscript, but ifdown && ifup work fine

9. soft reboot

10. v6 gateway is set up automatically after reboot (oO)

11. hard reboot

12. v6 gateway is set up automatically after reboot (expected behavior)

13. soft reboot

14. we're back in square one

15.

root@ns2:/run/network# ls -al
razem 12
drw...

Revision history for this message
Jan Baranowski (jan-baranowski) wrote :

One final note: it seems that problem may be overcame by removing contents of /run/network just before reboot/shutdown.

Revision history for this message
stcheng (stcheng) wrote :
Revision history for this message
Midhun P Madhav (midhunpmadhav) wrote :

I am working with 2.6.32 kernel. keep_addr_on_down variable is not available with this version. How to overcome this issue?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.