IPV6-Probleme

[chmod007]

Moin,

ich habe seit einiger Zeit ein nerviges Problem mit IPv6-Verbindungen.

Das ganze äußert sich so, dass eine Weile nach Systemstart jede Verbindung auf ein Timeout läuft bzw. irgendwann auf IPv4 zurückfällt.
Mal tritt das Problem nach fünf Minuten auf, mal erst nach Stunden und für mich überhaupt nicht reproduzierbar.

Nach neustarten der Netzwerkdienste (service networking reload) funktionierts dann wieder für ne Weile.

In wesentlich selteneren fällen bricht die Netzwerkerei komplett zusammen, dann geht nichtmal mehr IPv4, auch hier hilt ein Reload der Netzwerkdienste

Infos zum System:

Code: Alles auswählen

OS: Debian stretch (Unter Jessie wars allerdings das gleiche)

[chmod007@debtux ~] lspci | grep -i realtek
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
[chmod007@debtux ~] cat /etc/network/interfaces | grep -v '#'

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto br0
iface br0 inet static
	bridge_ports eth0
	address 192.168.2.2
	netmask 255.255.255.0
	gateway 192.168.2.1
	up route add -net 10.0.0.0 netmask 255.0.0.0 gw 192.168.2.254
	down route del -net 10.0.0.0 netmask 255.0.0.0 gw 192.168.2.254

Mein Notebook zeigt das Verhalten weder unter Windows8.1 noch unter Linux (momentan Fedora23) also würde ich das Problem bei meinem Desktop sehen.

Ich könnt natürlich einfach IPV6 kernelseitig abschalten, aber ich wüsste lieber wo das Problem liegt.
Sachdienliche hinweise werden gern angenommen
Wenn ihr noch irgendwelche Infos benötigt, einfach bescheid sagen.

[Blackbox]

Tritt ins Blaue ...
Wo ist denn deine IPv6 Konfiguration in /etc/network/interfaces ?
Auch die Routen sind IPv4 only, mich wundert dass überhaupt via IPv6 läuft.
Liegt die IPv6 Konfiguration in einem anderen Konfig file, wenn ja, wo, wie sieht es aus ?

Woran machst du den Wechsel IPv6 →IPv4 fest ?

[chmod007]

Danke erstmal für die Antwort, auch Tritte ins Blaue können mal treffen

IPv6 ist autokonfiguriert. Reicht mir auch, da ich intern noch nix mit v6 mache. Mein Kleinrechenzentrum verbirgt sich hinter den 10.0.0.0/8 Routen.
(Wenn ich die Bridge rausnehme und stattdessen eth0 konfiguriere ist der Fehler auch vorhanden)

Nach systemstart hat er jedenfalls IPv6-Adressen an eth0 und br0 anliegen:

Code: Alles auswählen

[chmod007@debtux ~] ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether ... brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether b... brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.2/24 brd 192.168.2.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 2003:xxx:xxxx:xxxx:bla:blub:acdc:acab/64 scope global mngtmpaddr dynamic 
       valid_lft 14392sec preferred_lft 1792sec
    inet6 fe80::bla:blub:acdc:acab/64 scope link 
       valid_lft forever preferred_lft forever
4: virbr2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.101.1/24 brd 192.168.101.255 scope global virbr2
       valid_lft forever preferred_lft forever
5: virbr2-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN group default qlen 500
    link/ether ... brd ff:ff:ff:ff:ff:ff
6: virbr1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.1/24 brd 192.168.100.255 scope global virbr1
       valid_lft forever preferred_lft forever
7: virbr1-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN group default qlen 500
    link/ether ... brd ff:ff:ff:ff:ff:ff

Den Wechsel mache ich damit fest, dass Verbindungen zu Servern die beides können (IPv6 wird da ja bekanntlich bevorzugt) wie z.B. security.debian.org ewig warten und dann auf IPv4 zurückfallen. Merke ich wunderbar beim apt update...

Oder wenn ich meine IPv6-Adresse prüfe mittels 'wget http://ipv6-test.com/api/myip.php -q -O -' kommt normalerweise die öffentliche IPv6 zurück.
Wenn der Fehler auftritt kommt nach ner langen Wartezeit IPv4 als Antwort.

Sobald der Fehler wieder auftritt, werf ich nochmal ein ip address show hier rein.

[mludwig]

Hallo,

vielleicht wird nach dem Starten die Kernel-Variable für Autoconfig von IPv6 geändert? Ich empfehle folgenden Link als Lektüre:

http://strugglers.net/~andy/blog/2011/0 ... orwarding/

Kurz: Wenn Linux als Router läuft, werden Router Advertisments ignoriert, Privacy Extensions werden deaktiviert, da Router nach Möglichkeit feste IPs haben sollten.

Du hast zwar nur eine Netzwerkkarte, aber zusammen mit dieser Bridge wird vielleicht doch Forwarding aktiviert? Zu prüfen wären die Inhalte der Dateien:

Code: Alles auswählen

/proc/sys/net/ipv6/conf/*/forwarding
/proc/sys/net/ipv6/conf/*/accept_ra

Für br0 sollte accept_ra auf 1 bzw 2 stehen, je nachdem ob Forwarding aktiviert ist oder nicht.

viel Erfolg
mludwig

[chmod007]

Hm, das ist ne Idee, ich werd mir den Link mal vorknöpfen.
Ich bin auch grade noch auf diesen Thread hier gestoßen viewtopic.php?f=30&t=155612

Routing ist für IPv4 auf jeden Fall nicht aktiviert (wobei ich dachte ich hätte das mal gemacht, um vom Laptop auf meine VMs zuzugreifen)
Die beiden Dateien für IPv6 gibts gar nicht und 'sysctl -a | grep forwarding' zeigt nur Nullen.

EDIT: grad nochmal die von dir angegebenen Dateien geprüft. Vorhin hatte sich wohl ein Typo eingeschlichen...

Code: Alles auswählen

[rsturm@debtux ~] grep . /proc/sys/net/ipv6/conf/*/forwarding
/proc/sys/net/ipv6/conf/all/forwarding:0
/proc/sys/net/ipv6/conf/br0/forwarding:0
/proc/sys/net/ipv6/conf/default/forwarding:0
/proc/sys/net/ipv6/conf/eth0/forwarding:0
/proc/sys/net/ipv6/conf/lo/forwarding:0
/proc/sys/net/ipv6/conf/virbr1/forwarding:0
/proc/sys/net/ipv6/conf/virbr1-nic/forwarding:0
/proc/sys/net/ipv6/conf/virbr2/forwarding:0
/proc/sys/net/ipv6/conf/virbr2-nic/forwarding:0
[rsturm@debtux ~] grep . /proc/sys/net/ipv6/conf/*/accept_ra
/proc/sys/net/ipv6/conf/all/accept_ra:1
/proc/sys/net/ipv6/conf/br0/accept_ra:1
/proc/sys/net/ipv6/conf/default/accept_ra:1
/proc/sys/net/ipv6/conf/eth0/accept_ra:1
/proc/sys/net/ipv6/conf/lo/accept_ra:1
/proc/sys/net/ipv6/conf/virbr1/accept_ra:0
/proc/sys/net/ipv6/conf/virbr1-nic/accept_ra:1
/proc/sys/net/ipv6/conf/virbr2/accept_ra:0
/proc/sys/net/ipv6/conf/virbr2-nic/accept_ra:1

Interessanterweise ist der Fehler, dass die IPv6-Verbindung wegfliegt, seit gestern nicht mehr aufgetreten. Einzige Änderung war, dass ich eine VM aus dem Autostart genommen habe, die sonst immer im Hintergrund lief (Jessie-Webserver in kvm/qemu).

Dafür kam ein wesenlich älterer Fehler wieder, nämlich, dass die Netzwerkverbindung sporadisch komplett abreißt.
Diesen Fehler hattte ich unter Windows wie Linux, aber seit länger Zeit nicht mehr.

Ergo bin ich jetzt endgültig verwirrt.

[mludwig]

Na, das war es also schonmal nicht.

Wenn es nur zu dem Fehler kommt, wenn eine bestimmte VM läuft, vielleicht gibt es einen Konflikt? Also doppelte Mac-Adressen, oder ist radvd auf der VM eingerichtet?

Vergleichsweise mal

Code: Alles auswählen

ip addr list
route -n

anzeigen lassen, einmal wenn es funktioniert, und einmal wenn es nicht funktioniert. Andere Möglichkeit: vielleicht ein Problem mit der Namensauflösung?

[chmod007]

Die VM ist nichts besonderes, Debian Jessie mit Minimalinstallation, Apache und ein paar Perl-Libs. MAC-Adressen sind einzigartig, IP-Konflikte gibts auch keine, IP's sind fest vergeben und alle außerhalb der DHCP-Range meines Routers.

radvd ist nicht drauf (wußte bis eben gar nicht von der Existenz dieses Pakets)

Namensauflösung mache ich auf dem Host über 8.8.8.8, in der VM ist noch der Speedport (192.168.2.1) drin

Die Ausgaben im funktionierenden Zustand mit hochgefahrener VM hab ich hier mal gepasted: 39293
Falls ich den Fehler heute noch bekomme, pack ich das auch noch in ein Paste.

Edit: Und schon isses soweit... 39294

[mludwig]

Auf den ersten Blick kann ich erstmal keinen Unterschied entdecken, außer das im 1. paste vnet0 fehlt. Beim copy/paste vergessen?

Kann man im Fehlerfahll
- Hosts anpingen (über dns-namen)
- externe IPv6 Adressen anpingen
- den IPv6-Gateway anpingen (wäre fe80::1 ?)
- andere öffentliche IPv6-Adressen im eigenen Netz über ping erreichen?
- die eigene IPv6 Adresse anpingen? (also jeweils die öffentliche und die fe80:xxx)

Das hilft hoffentlich, das weiter einzugrenzen.

[chmod007]

Ja, das vnet0 ist mir wahrscheinlich durch die Lappen gegangen.

Zu deinen Stichpunkten:
- Hosts über Namen pingen funktioniert, allerdings nur reine IPv4-Hosts. Hat der Host auch IPv6, dauerts erstmal ewig und dann kommen Pings von der v4-Adresse. ping -4 auf dualstacked hosts funktioniert wunderbar.
- ping -6 geht nicht, 100% Loss

Den Rest prüfe ich, sobald ich wieder an den Rechner komme, also in rund einer Woche.

bis dahin erstmal Danke für deine Mühen

[rendegast]

Statt systemd-init mal per sysv-init starten?