Plötzlich Probleme mit IPv6

Traceroute teste ich gleich, war gerade im Rettungssystem und auch da geht's nicht - ich erhalte ebenfalls die komische Adresse wie im ersten Post anstatt der 2a03:...

Zitat von eripek

Wo versandet es bei Dir im traceroute6/mtr?

Einmal vom Server zu Google:

traceroute to ipv6.google.com (2a00:1450:4001:81d::200e), 30 hops max, 80 byte p                                            ackets
 1  2a03:4000:21::3 (2a03:4000:21::3)  0.628 ms  0.778 ms  0.739 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  *^C

Und einmal von mir zu Hause zum Server:

Routenverfolgung zu hub.jeffsrv.de [2a03:4000:21:3dd::1]
über maximal 30 Hops:

  1     1 ms     1 ms     1 ms  2a02:908:d70:51a0:362c:c4ff:fe39:8528
  2    13 ms    12 ms     9 ms  2a02:908:d00:7::1
  3    11 ms    10 ms    22 ms  7113a-mx960-01-ae10-1310.dar.unity-media.net [2a02:908:0:1eb::1]
  4    14 ms    13 ms    15 ms  de-fra01b-rc1-lo0-0.v6.aorta.net [2001:730:2d00::5474:8065]
  5    22 ms    19 ms    13 ms  2001:7300:2d00::5474:80f8
  6     *     2032 ms     *     2001:730:2d01:21::2
  7     *        *        *     Zeitüberschreitung der Anforderung.
  8     *        *        *     Zeitüberschreitung der Anforderung.
  9     *        *        *     Zeitüberschreitung der Anforderung.
 10     *        *     ^C

Zitat von eripek

ip -6 r s sollte jedenfalls nur ein einziges default gateway zeigen.

Dem ist auch so:

fe80::/64 dev ens3 proto kernel metric 256  pref medium
fe80::/64 dev ens6 proto kernel metric 256  pref medium
default via fe80::1 dev ens3 proto ra metric 1024  expires 1737sec hoplimit 64 pref medium

Zitat von eripek

Dein Server blockt doch nichts?

Habe Firewall per ufw konfiguriert; aber wie gesagt ging es auch im Rettungssystem nicht

EDIT: Teilweise kann ich netcup-intern meine anderen Server anpingen. 2a03:4000:21:80d::1 geht, 2a03:4000:2a:151::1 hingegen nicht.

Zitat von eripek

Dann ist es recht klar. Schick die gesammelten Traceroutes an den Support. Ausgehend landest Du an einem Netcup-Gateway, eingehend hängt es bei Anexia fest. Da kündigt ein Router bei Netcup den Präfix nicht an.

Danke, ich werd auf diesen Thread hier verweisen. Hast du meinen Edit im letzten Post gesehen?

Vielen Dank eripek ! Dann darf sich jetzt der Support damit rumschlagen; immerhin hab ich eins gelernt: IPv6 gehört mit ins Monitoring - hatte bisher nur IPv4 im Nagios gecheckt

Laut Support gab es seitens netcup kein Problem. Ich habe dann wie von eripek vorgeschlagen die zweite iface-Deklaration durch die up und down Befehle ersetzt, jetzt geht alles.

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens3
iface ens3 inet static
        address $IPV4/22
        gateway $IPV4GATEWAY
        dns-nameservers 46.38.225.230 46.38.252.230 2a03:4000:0:1::e1e6 2a03:4000:8000::fce6
        up ip -6 a a $IPV6/64 dev ens3
        up ip -6 r a default via fe80::1 dev ens3
        down ip -6 r d default via fe80::1 dev ens3
        down ip -6 a d $IPV6/64 dev ens3

# VLAN
allow-hotplug ens6
iface ens6 inet static
        address $VLANIP
        netmask 255.255.255.0

Was mich dennoch verwundert, ist, dass die Config wie im ersten Post erwähnt monatelang funktioniert hatte und auch auf all meinen anderen Servern identisch war. Ich werde die Config jetzt überall ändern, damit das nicht nochmal passiert

Danke an alle Beteiligten!

Zitat von eripek

Wenn Du das machst, achte darauf, dass zu jedem up-Kommando auch ein spiegelverkehrtes down-Kommando existiert.

ifupdown ist diesbezüglich etwas empfindlich. Teste das mit sinngemäß "ifdown --force ens3; sleep 1; ifup ens3". Wenn das nicht passt, hast Du beim Booten und Herunterfahren eventuell Zeitverzögerungen wegen der Fehler.

Der betroffene Server meckert wegen sendmail:

/etc/network/if-up.d/sendmail: 44: .: Can't open /usr/share/sendmail/dynamic
run-parts: /etc/network/if-up.d/sendmail exited with return code 2
ifup: failed to bring up ens3

Auf den anderen klappt es ohne Fehlermeldung.

Weiterhin ist mir aber noch aufgefallen, dass der Problemserver beim Hochfahren noch "Failed to start Raise network interfaces" meckert. Das scheint ebenfalls an sendmail zu liegen:

● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2019-12-11 14:11:14 CET; 2min 54s ago
     Docs: man:interfaces(5)
  Process: 676 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
  Process: 661 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-environment --list --exclude=lo)" ] && udevadm
 Main PID: 676 (code=exited, status=1/FAILURE)

Dec 11 14:11:14 hub ifup[676]: /etc/network/if-up.d/sendmail: 44: .: Can't open /usr/share/sendmail/dynamic
Dec 11 14:11:14 hub ifup[676]: run-parts: /etc/network/if-up.d/sendmail exited with return code 2
Dec 11 14:11:14 hub ifup[676]: ifup: failed to bring up lo
Dec 11 14:11:14 hub ifup[676]: /etc/network/if-up.d/sendmail: 44: .: Can't open /usr/share/sendmail/dynamic
Dec 11 14:11:14 hub ifup[676]: run-parts: /etc/network/if-up.d/sendmail exited with return code 2
Dec 11 14:11:14 hub systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Dec 11 14:11:14 hub ifup[676]: ifup: post-up script failed
Dec 11 14:11:14 hub systemd[1]: Failed to start Raise network interfaces.
Dec 11 14:11:14 hub systemd[1]: networking.service: Unit entered failed state.
Dec 11 14:11:14 hub systemd[1]: networking.service: Failed with result 'exit-code'.

Darum kann ich mich aber frühestens heute abend kümmern. Wahrscheinlich einfach ein Überbleibsel von sendmail, das nutze ich schon länger nicht mehr.

Zitat von H6G

Wenn dort ein expires drinne steht, dann ist das kein gutes Zeichen.

Das heißt, dass diese Route dynamisch gesetzt wurde und nicht statisch.

Bei ordnungsgemäßer Funktion darf die Default Route nicht ablaufen.

Hier sollte unbedingt überprüft werden, wer diese Route setzt.

Alles anzeigen

Danke für den Hinweis, aber mit der neuen Config passt's:

2a03:4000:21:3dd::/64 dev ens3 proto kernel metric 256  pref medium
fe80::/64 dev ens6 proto kernel metric 256  pref medium
fe80::/64 dev ens3 proto kernel metric 256  pref medium
default via fe80::1 dev ens3 metric 1024  pref medium