Keine Neighbor Cache Einträge - ULA Netz - für Hosts mit OpenBSD und manchen Linux Distros

[OnkelThomas]

1900UF - Firmware 10.92.0018-Rel

Seitdem ich vor 2,5 Jahren auf ULAs (mit NPTv6) umgestiegen bin, habe ich das Problem, das meine OpenBSD-Server nach kurzer Zeit ihre IPv6-Konnektivität verlieren. Nach einem Systemstart funktioniert zunächst alles, bis von der Privacy Extensions eine neue Adresse ausgewürfelt wird. Dann ist es vorbei. Erzwinge ich den Verkehr über die veraltete, aber noch nicht entfernte Adresse, fleißt er. Ich habe das Thema hier auch schon mal in der OpenBSD Mailingliste diskutiert https://www.mail-archive.com/misc@openb ... 90460.html, wo ich auf den NDP Cache aufmerksam gemacht wurde. Und ja, führe ich auf dem LANCOM "show ipv6-neighbor-cache" aus, fehlt der Eintrag für die Maschinen.

Aber es geht noch weiter. Meine Windows- und Ubuntu-Systeme haben das Problem nicht. Da ich langsam Plane mich von OpenBSD in Richtung Linux zu verabschieden, wollte ich das Thema ignorieren. Jetzt setzte ich hier aber Alpine Linux auf und muss feststellen, dass ich damit dasselbe Problem habe! Und Alpine verwendet standardmäßig nicht mal Privacy Extensions! Die Host-Adresse verschwindet irgendwann aus dem LANCOM ipv6-neighbor-cache und bleibt dann bis zu einem Neustart des Hosts fern. (Der Kernel 6.12.31 ist sogar neue wie bei Ubuntu (6.8.0).)

Ich bin für alle Vorschläge offen. Es muss ja irgendwie am NDP liegen.


Trace von einem ping - Alpine

Code: Alles auswählen

~ # ping6 google.de
PING google.de (2a00:1450:4016:80a::2003): 56 data bytes
^C
--- google.de ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss

LANCOM 1900UF - trace + IPv6-Router @ 2a004016:80a::2003 - Man sieht eindeutig wie der Verkehr ins Internet und zurück geht. (Ein tcpdump auf dem Host zeigt, dass das Reply nicht eintrifft.)

Code: Alles auswählen

[IPv6-Router] 2025/06/17 14:23:32,277  Devicetime: 2025/06/17 14:23:31,394 [BENUTZER (2)]
IP packet, scope global, routing tag 172:
  IPv6: fd00:172:17:2:be24:11ff:fe59:6c23 -> 2a00:1450:4016:80a::2003, Payload-Len: 64
  ICMP: Echo (ping) request (128), ID: 4128, Seq: 0
--> Creating destination cache entry of type firewall forwarding
--> Creating firewall mirror destination cache entry of type firewall forwarding for address 2a02:810d:5f80:5100:6120:11ff:fe59:6c23 on interface INTERNET (17)
--> Firewall: accepted, forwarded unicast via INTERNET (17) to next hop fe80::1212:ff:fe00:6598

[IPv6-Router] 2025/06/17 14:23:32,324  Devicetime: 2025/06/17 14:23:31,411 [INTERNET (17)]
IP packet, scope global, routing tag 0:
  IPv6: 2a00:1450:4016:80a::2003 -> 2a02:810d:5f80:5100:6120:11ff:fe59:6c23, Payload-Len: 64
  ICMP: Echo (ping) reply (129), ID: 4128, Seq: 0
--> Firewall: accepted, forwarded unicast via BENUTZER (2)

[IPv6-Router] 2025/06/17 14:23:33,277  Devicetime: 2025/06/17 14:23:32,394 [BENUTZER (2)]
IP packet, scope global, routing tag 172:
  IPv6: fd00:172:17:2:be24:11ff:fe59:6c23 -> 2a00:1450:4016:80a::2003, Payload-Len: 64
  ICMP: Echo (ping) request (128), ID: 4128, Seq: 1
--> Firewall: accepted, forwarded unicast via INTERNET (17) to next hop fe80::1212:ff:fe00:6598

[IPv6-Router] 2025/06/17 14:23:33,324  Devicetime: 2025/06/17 14:23:32,407 [INTERNET (17)]
IP packet, scope global, routing tag 0:
  IPv6: 2a00:1450:4016:80a::2003 -> 2a02:810d:5f80:5100:6120:11ff:fe59:6c23, Payload-Len: 64
  ICMP: Echo (ping) reply (129), ID: 4128, Seq: 1
--> Firewall: accepted, forwarded unicast via BENUTZER (2)

[IPv6-Router] 2025/06/17 14:23:34,277  Devicetime: 2025/06/17 14:23:33,395 [BENUTZER (2)]
IP packet, scope global, routing tag 172:
  IPv6: fd00:172:17:2:be24:11ff:fe59:6c23 -> 2a00:1450:4016:80a::2003, Payload-Len: 64
  ICMP: Echo (ping) request (128), ID: 4128, Seq: 2
--> Firewall: accepted, forwarded unicast via INTERNET (17) to next hop fe80::1212:ff:fe00:6598

[IPv6-Router] 2025/06/17 14:23:34,324  Devicetime: 2025/06/17 14:23:33,411 [INTERNET (17)]
IP packet, scope global, routing tag 0:
  IPv6: 2a00:1450:4016:80a::2003 -> 2a02:810d:5f80:5100:6120:11ff:fe59:6c23, Payload-Len: 64
  ICMP: Echo (ping) reply (129), ID: 4128, Seq: 2
--> Firewall: accepted, forwarded unicast via BENUTZER (2)

[IPv6-Router] 2025/06/17 14:23:35,277  Devicetime: 2025/06/17 14:23:34,395 [BENUTZER (2)]
IP packet, scope global, routing tag 172:
  IPv6: fd00:172:17:2:be24:11ff:fe59:6c23 -> 2a00:1450:4016:80a::2003, Payload-Len: 64
  ICMP: Echo (ping) request (128), ID: 4128, Seq: 3
--> Firewall: accepted, forwarded unicast via INTERNET (17) to next hop fe80::1212:ff:fe00:6598

[IPv6-Router] 2025/06/17 14:23:35,324  Devicetime: 2025/06/17 14:23:34,409 [INTERNET (17)]
IP packet, scope global, routing tag 0:
  IPv6: 2a00:1450:4016:80a::2003 -> 2a02:810d:5f80:5100:6120:11ff:fe59:6c23, Payload-Len: 64
  ICMP: Echo (ping) reply (129), ID: 4128, Seq: 3
--> Firewall: accepted, forwarded unicast via BENUTZER (2)

LANCOM 1900UF - trace + ND-CACHE @ BENUTZER

Code: Alles auswählen

[ND-CACHE] 2025/06/17 14:47:41,490  Devicetime: 2025/06/17 14:47:40,567[info] : outgoing packet on BENUTZER
target: fd00:172:17:2:be24:11ff:fe59:6c23, source: fe80::2a0:57ff:fe3a:ac77
fd00:172:17:2:be24:11ff:fe59:6c23 iface BENUTZER lladdr xx:xx:xx:xx:xx:xx host INIT src fe80::2a0:57ff:fe3a:ac77

[ND-CACHE] 2025/06/17 14:47:41,490  Devicetime: 2025/06/17 14:47:40,567[info] : ND cache entry (3235/1) state on interface BENUTZER changed
fd00:172:17:2:be24:11ff:fe59:6c23 iface BENUTZER lladdr xx:xx:xx:xx:xx:xx host INCOMPLETE src fe80::2a0:57ff:fe3a:ac77

[ND-CACHE] 2025/06/17 14:47:44,490  Devicetime: 2025/06/17 14:47:43,567[info] : ND cache entry (3235/1) state on interface BENUTZER changed
fd00:172:17:2:be24:11ff:fe59:6c23 iface BENUTZER lladdr xx:xx:xx:xx:xx:xx host UNREACHABLE src fe80::2a0:57ff:fe3a:ac77

[ND-CACHE] 2025/06/17 14:47:45,474  Devicetime: 2025/06/17 14:47:44,565[info] : outgoing packet on BENUTZER
target: fd00:172:17:2:be24:11ff:fe59:6c23, source: fe80::2a0:57ff:fe3a:ac77
fd00:172:17:2:be24:11ff:fe59:6c23 iface BENUTZER lladdr xx:xx:xx:xx:xx:xx host INIT src fe80::2a0:57ff:fe3a:ac77

[ND-CACHE] 2025/06/17 14:47:45,474  Devicetime: 2025/06/17 14:47:44,565[info] : ND cache entry (3236/1) state on interface BENUTZER changed
fd00:172:17:2:be24:11ff:fe59:6c23 iface BENUTZER lladdr xx:xx:xx:xx:xx:xx host INCOMPLETE src fe80::2a0:57ff:fe3a:ac77

[ND-CACHE] 2025/06/17 14:47:46,521  Devicetime: 2025/06/17 14:47:45,608[info] : received neighbor solicitation on BENUTZER
target: fe80::2a0:57ff:fe3a:ac77, source: fe80::be24:11ff:fe59:6c23, link-layer-address: bc:24:11:59:6c:23 (BUNDLE-1,3)

[ND-CACHE] 2025/06/17 14:47:46,521  Devicetime: 2025/06/17 14:47:45,608[info] : found cache entry for target fe80::be24:11ff:fe59:6c23
fe80::be24:11ff:fe59:6c23 iface BENUTZER lladdr bc:24:11:59:6c:23 (BUNDLE-1,3) host STALE src fe80::2a0:57ff:fe3a:ac77

[ND-CACHE] 2025/06/17 14:47:48,474  Devicetime: 2025/06/17 14:47:47,565[info] : ND cache entry (3236/1) state on interface BENUTZER changed
fd00:172:17:2:be24:11ff:fe59:6c23 iface BENUTZER lladdr xx:xx:xx:xx:xx:xx host UNREACHABLE src fe80::2a0:57ff:fe3a:ac77

[ND-CACHE] 2025/06/17 14:47:49,474  Devicetime: 2025/06/17 14:47:48,565[info] : outgoing packet on BENUTZER
target: fd00:172:17:2:be24:11ff:fe59:6c23, source: fe80::2a0:57ff:fe3a:ac77
fd00:172:17:2:be24:11ff:fe59:6c23 iface BENUTZER lladdr xx:xx:xx:xx:xx:xx host INIT src fe80::2a0:57ff:fe3a:ac77

[ND-CACHE] 2025/06/17 14:47:49,474  Devicetime: 2025/06/17 14:47:48,565[info] : ND cache entry (3237/1) state on interface BENUTZER changed
fd00:172:17:2:be24:11ff:fe59:6c23 iface BENUTZER lladdr xx:xx:xx:xx:xx:xx host INCOMPLETE src fe80::2a0:57ff:fe3a:ac77

lladdr xx:xx:xx:xx:xx:xx ist keine Anonymisierung von mir, sondern ist die original Trace-Ausgabe.

[backslash]

Hi OnkelThomas,

offenbar antowrtet da dein Server nuicht auf Neighbor-Solicitations... zu sehen daran, daß der State des Neighborcache-Eintrags für fd00:172:17:2:be24fe59:6c23 immer zwischen INIT, INCOMPLETE und UNREACHABLE wechselt..
INIT: Der Eintrag wird angelegt
INCOMPLETE: die Neighbor-Solicitaion wurde gesendet
UNREACHABLE: nach dem Timeout von 3 Sekunden gibt das LANCOM auf

lladdr xx:xx:xx:xx:xx:xx bedeutet i.Ü. daß die Linklayer-Adresse nicht bekannt ist

Da mußt du schon bei deinem Server untersuchen, warum der schweigt...

Gruß
Backslash

[GrandDixence]

Das hört sich an, als ob die Linux- und OpenBSD-Firewall wegen Fehlkonfiguration von deren Firewallregeln die eingehenden ICMPv6-Pakete verwirft (DROP).

Hier als Beispiel eine nftables-Fehlkonfiguration unter einer modernen Linux-Distribution.
https://bbs.archlinux.org/viewtopic.php?id=260707

Und hier ein Beispiel für die PF von FreeBSD:
https://forums.freebsd.org/threads/pf-n ... fic.91045/

Auf Grund fehlender Kenntnisse von IPv6 kann ich hier nicht weiterhelfen, welches NDP-Paket genau verworfen wird.
https://de.wikipedia.org/wiki/Neighbor_ ... y_Protocol

Einfach mit Packet Capture und Wireshark den NDP-Datenverkehr abhorchen und untersuchen.

Wie man eine Linux-Firewall mit iptables korrekt für IPv4 als SPI-Firewall konfiguriert, ist unter anderem unter:
fragen-zum-thema-firewall-f15/bandbreit ... ml#p106507
beschrieben (firewall_rules_ipv4.txt). Den IPv6-Kram muss man sich (leider) selber zurechtbröseln...

Wenn iptables unter Linux zum Einsatz kommt, sollte mit:

# conntrack -E |grep -i <irgendetwas Schlaues zum Filtern>

kontrolliert werden, ob die Linux-Firewall den NDP-Datenverkehr durchlässt.
https://www.systutorials.com/docs/linux ... conntrack/

[OnkelThomas]

Danke fürs damit beschäftigen.

offenbar antowrtet da dein Server nuicht auf Neighbor-Solicitations... zu sehen daran, daß der State des Neighborcache-Eintrags für fd00:172:17:2:be24fe59:6c23 immer zwischen INIT, INCOMPLETE und UNREACHABLE wechselt..

Sehe ich mir den Trace (ND-CACHE) einer Neighbor-Solicitation für eine funktionierende Maschine an, dann sieht das so aus:

Code: Alles auswählen

[ND-CACHE] 2025/06/17 18:28:52,099  Devicetime: 2025/06/17 18:28:52,020[info] : ND cache entry (1940/2) state on interface BENUTZER changed
fd00:172:17:2:8d68:b229:69d6:e25 iface BENUTZER lladdr 3c:8c:f8:60:fb:79 (BUNDLE-1,2) host STALE src fd00:172:17:2:2a0:57ff:fe3a:ac77

[ND-CACHE] 2025/06/17 18:29:01,412  Devicetime: 2025/06/17 18:29:01,335[info] : ND cache entry (1940/2) state on interface BENUTZER changed
fd00:172:17:2:8d68:b229:69d6:e25 iface BENUTZER lladdr 3c:8c:f8:60:fb:79 (BUNDLE-1,2) host DELAY src fd00:172:17:2:2a0:57ff:fe3a:ac77

[ND-CACHE] 2025/06/17 18:29:06,412  Devicetime: 2025/06/17 18:29:06,335[info] : ND cache entry (1940/2) state on interface BENUTZER changed
fd00:172:17:2:8d68:b229:69d6:e25 iface BENUTZER lladdr 3c:8c:f8:60:fb:79 (BUNDLE-1,2) host PROBE src fd00:172:17:2:2a0:57ff:fe3a:ac77

[ND-CACHE] 2025/06/17 18:29:06,412  Devicetime: 2025/06/17 18:29:06,335[info] : received neighbor advertisement on BENUTZER
target: fd00:172:17:2:8d68:b229:69d6:e25, source: fd00:172:17:2:8d68:b229:69d6:e25
  Flags: 0x40
    0... .... = Not router
    .1.. .... = Solicited
    ..0. .... = Not override

[ND-CACHE] 2025/06/17 18:29:06,412  Devicetime: 2025/06/17 18:29:06,335[info] : ND cache entry (1940/2) state on interface BENUTZER changed
fd00:172:17:2:8d68:b229:69d6:e25 iface BENUTZER lladdr 3c:8c:f8:60:fb:79 (BUNDLE-1,2) host REACHABLE src fd00:172:17:2:2a0:57ff:fe3a:ac77

STALE, DELAY, PROBE. Das PROBE ist (vermutlich) das Neighbor Solicitation Paket, welches auch sofort per tcpdump auf der entsprechenden Maschine zu sehen ist:

Code: Alles auswählen

18:29:06.416448 IP6 fd00:172:17:2:2a0:57ff:fe3a:ac77 > fd00:172:17:2:8d68:b229:69d6:e25: ICMP6, neighbor solicitation, who has fd00:172:17:2:8d68:b229:69d6:e25, length 32
18:29:06.416472 IP6 fd00:172:17:2:8d68:b229:69d6:e25 > fd00:172:17:2:2a0:57ff:fe3a:ac77: ICMP6, neighbor advertisement, tgt is fd00:172:17:2:8d68:b229:69d6:e25, length 24

Es taucht kein Trace-Eintrag mit "outgoing packet on...INIT" auf. Dafür habe ich bei den problematischen Maschinen ständig "outgoing packet on...INIT", aber kein PROBE. Ist PROBE und INIT beides der Start einer Neighbor Solicitaion? Einmal fürs Auffrischen und einmal wenn gar nichts bekannt ist? Oder was könnte der Unterschied sein?
Manchmal kommt das PROBE für die Link Local Adresse:

Code: Alles auswählen

[ND-CACHE] 2025/06/17 18:25:41,815  Devicetime: 2025/06/17 18:25:41,741[info] : ND cache entry (3531/1) state on interface KELLER changed
fd00:172:23:20::1 iface KELLER lladdr xx:xx:xx:xx:xx:xx host UNREACHABLE src fe80::2a0:57ff:fe3a:ac77

[ND-CACHE] 2025/06/17 18:25:41,878  Devicetime: 2025/06/17 18:25:41,779[info] : outgoing packet on KELLER
target: fd00:172:23:20::1, source: fe80::2a0:57ff:fe3a:ac77
fd00:172:23:20::1 iface KELLER lladdr xx:xx:xx:xx:xx:xx host INIT src fe80::2a0:57ff:fe3a:ac77

[ND-CACHE] 2025/06/17 18:25:41,878  Devicetime: 2025/06/17 18:25:41,779[info] : ND cache entry (3532/1) state on interface KELLER changed
fd00:172:23:20::1 iface KELLER lladdr xx:xx:xx:xx:xx:xx host INCOMPLETE src fe80::2a0:57ff:fe3a:ac77

[ND-CACHE] 2025/06/17 18:25:43,784  Devicetime: 2025/06/17 18:25:43,707[info] : ND cache entry (2/2) state on interface KELLER changed
fe80::6245:cbff:fe80:c8cb iface KELLER lladdr 60:45:cb:80:c8:cb (BUNDLE-1,3) host PROBE src fe80::2a0:57ff:fe3a:ac77

[ND-CACHE] 2025/06/17 18:25:43,846  Devicetime: 2025/06/17 18:25:43,728[info] : received neighbor advertisement on KELLER
target: fe80::6245:cbff:fe80:c8cb, source: fe80::6245:cbff:fe80:c8cb
  Flags: 0x40
    0... .... = Not router
    .1.. .... = Solicited
    ..0. .... = Not override

[ND-CACHE] 2025/06/17 18:25:43,846  Devicetime: 2025/06/17 18:25:43,728[info] : ND cache entry (2/2) state on interface KELLER changed
fe80::6245:cbff:fe80:c8cb iface KELLER lladdr 60:45:cb:80:c8:cb (BUNDLE-1,3) host REACHABLE src fe80::2a0:57ff:fe3a:ac77

Die Problemlos empfangen und beantwortet wird:

Code: Alles auswählen

# tcpdump -i re0 -n "icmp6"
tcpdump: listening on re0, link-type EN10MB
18:25:42.801984 fd00:172:23:20::1 > 2a00:1450:4016:80a::2003: icmp6: echo request
18:25:43.796885 fe80::2a0:57ff:fe3a:ac77 > fe80::6245:cbff:fe80:c8cb: icmp6: neighbor sol: who has fe80::6245:cbff:fe80:c8cb
18:25:43.796995 fe80::6245:cbff:fe80:c8cb > fe80::2a0:57ff:fe3a:ac77: icmp6: neighbor adv: tgt is fe80::6245:cbff:fe80:c8cb
18:25:43.801722 fd00:172:23:20::1 > 2a00:1450:4016:80a::2003: icmp6: echo request

Aber eben keine Anfrage für die ULA Adresse.

Es ist auch keine Anfrage per trace + IPv6-LAN-Packet zu sehen!

[OnkelThomas]

Das hört sich an, als ob die Linux- und OpenBSD-Firewall wegen Fehlkonfiguration von deren Firewallregeln die eingehenden ICMPv6-Pakete verwirft (DROP).

Alpine Linux:

Code: Alles auswählen

~ # ip6tables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

OpenBSD:

Code: Alles auswählen

# pfctl -s rules
block return all
pass all flags S/SA
block return in on ! lo0 proto tcp from any to any port 6000:6010
block return out log proto tcp all user = 55
block return out log proto udp all user = 55

Standard, Out of the Box, leere unangefasste Regeln. Die selben Maschinen haben mit globalen Adressen keine Probleme.

[GrandDixence]

Bitte mal noch einige Lektüre zum "Thema Firewallregeln konfigurieren" konsumieren. So wird das nichts...
https://wiki.archlinux.org/title/Simple ... l_firewall

https://medium.com/opsops/nd-for-ipv6-i ... a287fa1da4

Iptables für nur-Loopback-Netzwerkverkehr mit IPv6, TCP und UDP per SPI:
https://emanuelduss.ch/posts/eine-einfa ... -iptables/

Code: Alles auswählen

# ip6tables -L -n -v -t filter
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    3   372 ACCEPT     all      *      *       ::/0                 ::/0                 ctstate RELATED,ESTABLISHED
    0     0 DROP       all      *      *       ::/0                 ::/0                 ctstate INVALID
    0     0 ACCEPT     tcp      lo     *       ::1                  ::1                  ctstate NEW
    3   228 ACCEPT     udp      lo     *       ::1                  ::1                  ctstate NEW

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all      *      *       ::/0                 ::/0                 ctstate RELATED,ESTABLISHED
    0     0 DROP       all      *      *       ::/0                 ::/0                 ctstate INVALID

Chain OUTPUT (policy DROP 61 packets, 3472 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    3   372 ACCEPT     all      *      *       ::/0                 ::/0                 ctstate RELATED,ESTABLISHED
    0     0 DROP       all      *      *       ::/0                 ::/0                 ctstate INVALID
    0     0 ACCEPT     tcp      *      lo      ::1                  ::1                  ctstate NEW
    3   228 ACCEPT     udp      *      lo      ::1                  ::1                  ctstate NEW

[OnkelThomas]

Bitte mal noch einige Lektüre zum "Thema Firewallregeln konfigurieren" konsumieren. So wird das nichts...

So können Sie vielleicht mit Ihren Kindern reden, aber nicht mit mir. Ich habe bald 25 Jahre Erfahrung mit iptables.

Ausgeführt auf problemfreien Maschinen sehen weder tcpdump noch Wireshark Neighbor Solicitation Broadcasts für die "problematischen" Maschinen. Das die überhaupt eine Zeitlang IPv6 Konnektivität haben, liegt daran, das sie beim starten ihres Interfaces ein Neighbor Advertisement machen, welches LCOS problemlos verarbeitet.

Mutmaßung: Wenn von Seiten eines Linux Hosts sehr lange kein IPv6 Traffic fleißt, scheint der Eintrag aus dem Cache zu fallen. Bei OpenBSD ist schon nach dem Auswürfeln einer neuen Adresse (Privacy Extension) Schluss, da diese offensichtlich nicht beworben wird. Warum für manche Maschinen von LCOS Neighbor Solicitations gesendet werden und für andere nicht? Keine Ahnung.

Ich habe jetzt für mich einen Workaround gefunden: Proaktiv vom betroffenen Host, per Cronjob, ein Unsolicited Neighbor Advertisement senden.

[Dr.Einstein]

Hast du mal auf dem Lancom Router einen Wireshark auf dem LAN-x Interface gestartet und geschaut, ob das Paket wirklich rausgeschickt wird? Am Client kommt es nicht an laut deiner Aussage, am Router wirds laut Trace rausgeschickt, steht also unentschieden. https://www.lancom-systems.de/docs/LCOS ... uring.html // https://www.lancom-systems.de/docs/LCOS ... uring.html

Kann es sein, dass der Switch zwischen Client und Server die Multicast-Frames wieso auch immer verwirft, von Quelle Router zum Zielport des Clients? Komisch, dass der Lancom unterschiedliche Quell-IPs nimmt (Link Local vs Unique Local)

[OnkelThomas]

Danke fürs damit beschäftigen.

Hast du mal auf dem Lancom Router einen Wireshark auf dem LAN-x Interface gestartet und geschaut, ob das Paket wirklich rausgeschickt wird?

Jetzt schon, hab ich ein Mitschnitt erstellt.

ksnip_20250618-124700.png

Ich habe das für eine Minute laufen lassen und dabei von meinem Mailserver fd00:172:17:170:8fd4:f5e9:bfe5:8b72 google.de angepingt. (fe80::2a0:57ff:fe3a:ac77 ist lediglich die Link Local vom LANCOM.)

ksnip_20250618-125451.png

Ich kann hier keine Neighbor Solicitation für fd00:172:17:170:8fd4:f5e9:bfe5:8b72 finden.

ksnip_20250618-125922.png

CAP-Datei: https://aloof.de/f/tempfile-Rathaus1900 ... icmpv6.cap (Lies sich nicht im Forum anhängen.)

[backslash]

Hi OnkelThomas,

STALE, DELAY, PROBE. Das PROBE ist (vermutlich) das Neighbor Solicitation Paket, welches auch sofort per tcpdump auf der entsprechenden Maschine zu sehen ist:

ja PROBE ist das Senden einer (gerichteten) Neighbor-Solicitation

Es taucht kein Trace-Eintrag mit "outgoing packet on...INIT" auf.

weil der Eintrag schon bekannt war und sich vor dem STALE im Zustand REACHABLE bafand

Dafür habe ich bei den problematischen Maschinen ständig "outgoing packet on...INIT", aber kein PROBE. Ist PROBE und INIT beides der Start einer Neighbor Solicitaion? Einmal fürs Auffrischen und einmal wenn gar nichts bekannt ist

fast korrekt...

funktionierende Zustände: <unknown> -> (empfange Datenpaket) INIT -> INCOMPLETE (sende Neigbor-Solicitation als Multicast) -> (empfange Neighbor-Advertisement) REACHABLE -> (30s Timeout) STALE -> (empfange Datenpaket) DELAY -> (0..10s Timeout) PROBE (sende Neigbor-Solicitation als Unicast) -> (empfange Neighbor-Advertisement) REACHABLE
nicht funktionierend: <unknown> -> (empfange Datenpaket) INIT -> INCOMPLETE (sende Neigbor-Solicitation als Multicast) -> (3s Timeout) UNREACHABLE


vor dem jeweiligen Zustand steht in Klammern das Event, das den Zustandwechsel auslöst und hinter dem Zustand die Aktion, die durch den Zustandswechsel getriggert wird.

Gruß
Backlash