IPv4 Traffic sporadisch gestört, WTF?!

Moin,

folgendes Setup: 4 Gateway-VMs bei einem Hoster, aufgesetzt nach Münsteraner Art, GW 1 und 2 beherrbergen die L2TP-Domänen 1 und 2 parallel, GW 3 und 4 sind dementsprechend für die Domänen 3 und 4 zuständig. Sprich: 2 v15 batman-Interfaces je GW.

Symptom: Nutzer melden, daß „gar nix mehr geht“, heißt nach eigenen Tests: IPv4 in einer Domäne tut plötzlich nicht/nur sporadisch, obwohl IPv6 geht. Die andere Domäne auf den gleichen GWs ist davon nach aktuellem Kenntnisstand nicht betroffen.

Zum Debuggen haben wir nun (bei einem anderen Hoster) 4 VMs aufgesetzt, jeweils ein Gluon-x86 vor einer Linux-VM, Gluon-VM geht per virbr0 & NAT zu den Gateways, Linux-VM hängt in privater Bridge mit dem „LAN“ des Gluon-VM:

br-tst1         8000.fe00c5e342fb       no              one-305-0
                                                        one-306-1
br-tst2         8000.fe009eaff856       no              one-307-0
                                                        one-308-1

virbr0          8000.5254003b6c4d       yes             one-305-1
                                                        one-306-0
                                                        one-307-1
                                                        one-308-0
                                                        virbr0-nic

Pärchen 1 (VM one-305 & one-306) ist in Domäne 3, der mit den Problemen, Pärchen 2 (VM one-307 & one-308) in Domäne 1. Und so stellt sich das Problem dar (v6-IPs auf Doku-Prefix „anonymisiert“).

root@testvm01:~# ip route | grep defa
default via 10.15.32.4 dev ens4 

root@testvm01:~# (LANG=C date ; ((ping -c 5 10.15.32.4)&) ; ((ping -6 -c 5 2001:db8:2004:333::4)&) ; echo) 
Mi 12. Feb 18:31:15 CET 2020

PING 2001:db8:2004:333::4(2001:db8:2004:333::4) 56 data bytes
64 bytes from 2001:db8:2004:333::4: icmp_seq=1 ttl=64 time=2.85 ms
64 bytes from 2001:db8:2004:333::4: icmp_seq=2 ttl=64 time=2.82 ms
64 bytes from 2001:db8:2004:333::4: icmp_seq=3 ttl=64 time=3.19 ms
64 bytes from 2001:db8:2004:333::4: icmp_seq=4 ttl=64 time=2.84 ms
64 bytes from 2001:db8:2004:333::4: icmp_seq=5 ttl=64 time=3.11 ms

--- 2001:db8:2004:333::4 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 2.828/2.967/3.196/0.155 ms
PING 10.15.32.4 (10.15.32.4) 56(84) bytes of data.

--- 10.15.32.4 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4102ms

 

root@gw03 ~ # ip -4 addr show bat03
3: bat03: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 10.15.32.4/20 brd 10.15.47.255 scope global bat03
       valid_lft forever preferred_lft forever
root@gw03 ~ # (LANG=C date ; ((ping -c 5 10.15.36.95)&) ; ((ping6 -c 5 2001:db8:2004:333:0:c5ff:fee3:42fc)&) ; echo) 
Mi 12. Feb 18:31:15 CET 2020

PING 2001:db8:2004:333:0:c5ff:fee3:42fc(2001:db8:2004:333:0:c5ff:fee3:42fc) 56 data bytes
64 bytes from 2001:db8:2004:333:0:c5ff:fee3:42fc: icmp_seq=1 ttl=64 time=2.94 ms
64 bytes from 2001:db8:2004:333:0:c5ff:fee3:42fc: icmp_seq=2 ttl=64 time=3.02 ms
64 bytes from 2001:db8:2004:333:0:c5ff:fee3:42fc: icmp_seq=3 ttl=64 time=3.10 ms
64 bytes from 2001:db8:2004:333:0:c5ff:fee3:42fc: icmp_seq=4 ttl=64 time=3.00 ms
64 bytes from 2001:db8:2004:333:0:c5ff:fee3:42fc: icmp_seq=5 ttl=64 time=2.92 ms

--- 2001:db8:2004:333:0:c5ff:fee3:42fc ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 2.929/3.001/3.106/0.063 ms
PING 10.15.36.95 (10.15.36.95) 56(84) bytes of data.

--- 10.15.36.95 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4101ms

Ich. Versteh’s. Nicht. Habe ich so auch noch nicht gesehen, und daß v6 tut und v4 nicht spricht auch gegen karpottes batman? Anyway, any ideas?

Laut gedacht: Geht vielleicht ARP nicht, NDP aber schon? Daher v4 broken, v6 geht.

Hmm. Oder doch Routing?

root@testvm01:~# ip addr add 203.0.113.2/24 dev ens4
root@gw03 ~ # ip addr add 203.0.113.1/24 dev bat03

 

root@testvm01:~# ip route | grep defa
default via 10.15.32.4 dev ens4 
root@testvm01:~# ((ping -q -c 5 203.0.113.1)&) ; ping -q -c 5 10.15.32.4
PING 203.0.113.1 (203.0.113.1) 56(84) bytes of data.
PING 10.15.32.4 (10.15.32.4) 56(84) bytes of data.

--- 203.0.113.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 3.007/3.135/3.383/0.144 ms

--- 10.15.32.4 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4062ms

 

root@gw03 ~ # ping -c 5 203.0.113.2
PING 203.0.113.2 (203.0.113.2) 56(84) bytes of data.
64 bytes from 203.0.113.2: icmp_seq=1 ttl=64 time=3.35 ms
64 bytes from 203.0.113.2: icmp_seq=2 ttl=64 time=3.56 ms
64 bytes from 203.0.113.2: icmp_seq=3 ttl=64 time=3.11 ms
64 bytes from 203.0.113.2: icmp_seq=4 ttl=64 time=3.23 ms
64 bytes from 203.0.113.2: icmp_seq=5 ttl=64 time=3.21 ms

--- 203.0.113.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 3.116/3.299/3.569/0.154 ms

kopfkratz

hast Du evtl. ein uralt-Gluon (2015) oder eine TestVM mit manuell installiertem batman-adv. Also ohne den ebtables-foo vom Gluon?

Will sagen: Evtl. rennt da irgendwas in einen ARP-Limiter.

Ist es „nur“ die IPv4-GW-IP oder fehlen andere lokale IPv4-Dienste evtl auch, die auf anderen Knoten liegen (evtl. NTP, fw-server, map… whatever). Also nur um zu sehen, ob es „nur“ an der einen IPv4-Adresse liegt oder ob IPv4 komplett in der domain gestört ist.

Danke der Nachfrage, aber nein, das ist es nicht, es ist ein x86-Build der normalen Firmware, IIRC basierend auf Gluon v2018.2.x:

root@gluon01:~# cat /etc/openwrt_release 
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='18.06-SNAPSHOT'
DISTRIB_REVISION='r7835+25-89808e211c'
DISTRIB_TARGET='x86/64'
DISTRIB_ARCH='x86_64'
DISTRIB_DESCRIPTION='OpenWrt 18.06-SNAPSHOT r7835+25-89808e211c'
DISTRIB_TAINTS='busybox'

Jenes Setup ist auch nur dazu da, das (einfach) selbst verifizieren zu können — die Meldung kommt von den Nutzern, die seit vorgestern, und nur in dieser Domäne, von den Problemen berichten. Aber 'n echten Router und dahinter 'n RPi oder was auch immer als Linux-Testclient ist halt deutlich komplizierter aufzubauen :wink:

Ich verstehe wirklich nicht, was da passiert: wenn ich von der Linux-VM pinge, dann sehe ich „ping“ und „pong“ auf dem Batman-Interface des Gateways, dazwischen aber nur die ausgehenden Pakete:

root@testvm01:~# ping -c 3 193.26.120.42
PING 193.26.120.42 (193.26.120.42) 56(84) bytes of data.

--- 193.26.120.42 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2025ms

 
Auf dem Interface von der Linux- zur Gluon-VM sieht man die Pakete nur rausgehen:

root@testvm01:~# tcpdump -n -i ens4 host 193.26.120.42
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens4, link-type EN10MB (Ethernet), capture size 262144 bytes
03:11:08.865344 IP 10.15.36.95 > 193.26.120.42: ICMP echo request, id 2429, seq 1, length 64
03:11:09.866949 IP 10.15.36.95 > 193.26.120.42: ICMP echo request, id 2429, seq 2, length 64
03:11:10.890943 IP 10.15.36.95 > 193.26.120.42: ICMP echo request, id 2429, seq 3, length 64

 
Auch auf der Gluon-VM ist nur der ausgehende Traffic sichtbar:

root@gluon01:~# tcpdump -n -i bat0 host 193.26.120.42
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bat0, link-type EN10MB (Ethernet), capture size 262144 bytes
03:11:08.868974 IP 10.15.36.95 > 193.26.120.42: ICMP echo request, id 2429, seq 1, length 64
03:11:09.870568 IP 10.15.36.95 > 193.26.120.42: ICMP echo request, id 2429, seq 2, length 64
03:11:10.894533 IP 10.15.36.95 > 193.26.120.42: ICMP echo request, id 2429, seq 3, length 64

 
Auf dem Gateway allerdings gehen die Anfragen raus und kommen die Antworten an:

root@gw03 ~ # tcpdump -n -i bat03 host 193.26.120.42
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bat03, link-type EN10MB (Ethernet), capture size 262144 bytes
03:11:08.869326 IP 10.15.36.95 > 193.26.120.42: ICMP echo request, id 2429, seq 1, length 64
03:11:08.915079 IP 193.26.120.42 > 10.15.36.95: ICMP echo reply, id 2429, seq 1, length 64
03:11:09.870794 IP 10.15.36.95 > 193.26.120.42: ICMP echo request, id 2429, seq 2, length 64
03:11:09.909963 IP 193.26.120.42 > 10.15.36.95: ICMP echo reply, id 2429, seq 2, length 64
03:11:10.895731 IP 10.15.36.95 > 193.26.120.42: ICMP echo request, id 2429, seq 3, length 64
03:11:10.934797 IP 193.26.120.42 > 10.15.36.95: ICMP echo reply, id 2429, seq 3, length 64

 
Selten, aber eben doch manchmal, tut es auch …

root@testvm01:~# ping 193.26.120.42
PING 193.26.120.42 (193.26.120.42) 56(84) bytes of data.
64 bytes from 193.26.120.42: icmp_seq=1 ttl=59 time=301 ms
64 bytes from 193.26.120.42: icmp_seq=2 ttl=59 time=42.3 ms
64 bytes from 193.26.120.42: icmp_seq=3 ttl=59 time=42.5 ms
64 bytes from 193.26.120.42: icmp_seq=4 ttl=59 time=59.3 ms
64 bytes from 193.26.120.42: icmp_seq=5 ttl=59 time=45.2 ms
^C
--- 193.26.120.42 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 42.394/98.241/301.680/101.910 ms

… und dann sieht man natürlich auch auf der Gluon-VM beide Richtungen:

root@gluon01:~# tcpdump -n -i bat0 host 193.26.120.42
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bat0, link-type EN10MB (Ethernet), capture size 262144 bytes
03:18:43.680146 IP 10.15.36.95 > 193.26.120.42: ICMP echo request, id 2452, seq 1, length 64
03:18:43.981632 IP 193.26.120.42 > 10.15.36.95: ICMP echo reply, id 2452, seq 1, length 64
03:18:44.681082 IP 10.15.36.95 > 193.26.120.42: ICMP echo request, id 2452, seq 2, length 64
03:18:44.723268 IP 193.26.120.42 > 10.15.36.95: ICMP echo reply, id 2452, seq 2, length 64
03:18:45.682813 IP 10.15.36.95 > 193.26.120.42: ICMP echo request, id 2452, seq 3, length 64
03:18:45.725209 IP 193.26.120.42 > 10.15.36.95: ICMP echo reply, id 2452, seq 3, length 64
03:18:46.684696 IP 10.15.36.95 > 193.26.120.42: ICMP echo request, id 2452, seq 4, length 64
03:18:46.743818 IP 193.26.120.42 > 10.15.36.95: ICMP echo reply, id 2452, seq 4, length 64
03:18:47.686323 IP 10.15.36.95 > 193.26.120.42: ICMP echo request, id 2452, seq 5, length 64
03:18:47.731329 IP 193.26.120.42 > 10.15.36.95: ICMP echo reply, id 2452, seq 5, length 64

Bin so langsam mit meinem Latein am Ende, Spanisch ist schon durch :rage:

Ich habe mal Batman-TL-Fehler in alten Batman-Versionen gejagt.
Da sich Batman meinem Gefühl nach auch oberhalb von Layer2 noch dazwischenhängt, um Arp-Stürme zu vermindern etc… wäre auch die einzige Erklärung, warum v4 failed während v6 funktioniert.

Versuche doch wirklich mal, von der TestVM parallel andere RFC1918er (an anderen Nodes) anzupingen. Ob das ebenfalls ausfällt oder ob es „nur“ das Gateway ist, auf dem die IPv4 abgehängt ist?
(Ich kenne den Effekt, dass das Gateway nur einige der IPv4s in der Domain nicht mehr zu kennen scheint in seinem lokalen ARP-cache, d.h. die andere Hälfte der clients „dürfen“ dann noch. Supernode reboot, alles weg… bis zum nächsten mal…)

Ich erreiche das IPv4-GW, also quasi die andere Seite des magischen Wurmlochs zwischen ens4, dem Netzwerkinterface der VM, und br03 auf dem GW, dem Tunneldigger für Domäne 3, ja schon nicht. Und, wie gezeigt, versacken die Antworten zwischen bat03 und bat0 auf der Gluon-VM, also irgendwo im L2TP-Batman-Advance-Feenstaub.

Ich kann meine Frage nur wiederholen: Bitte pinge von der TestVM aus

  • parallel zur IPv4 des GW
  • eine IPv4 des lokalen Subnetzes, die an einem anderen Batman-Knoten hängt, idealerweise an einer dortigen Clientbridge.

Je nachdem wie das Resultat ausfällt solltest Du an verschiedenen Stellen weitersuchen.

Zweite Frage: Geht IPv4 „zum/auf das IPv4 gateway“ für „überhaupt keine Router/clients“ mehr in der Domain. Oder nur für „einen Teil/einzelne Router&deren Clients“ nicht?

PS: einen der effektivesten „Angriffe“ auf eine Gluon-Domain ist es, Mac-Adressen (z.B. des Gateways) mehrfach in eine Domain zu hängen. Wird hier nicht der Fall sein, denn das würde auch IPv6 ruinieren.
Batman-NodeIDs doppelt ist ein anderes Szenario, was aber meist schneller auffliegt, weil der Routinggraph auf der Nodemap dann total hinüber ist.

Tagsüber hatte ich 'n mtr ins Internet laufen lassen:

testvm01 (10.15.36.95)                                               2020-02-12T18:21:18+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                     Packets               Pings
 Host                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 10.15.32.4                                     32.8%   857    2.9   3.3   2.8 135.0   5.7
 2. 185.66.194.0                                   32.7%   856    6.5   7.5   6.3 264.4  15.2
 3. 193.26.120.85                                  32.9%   856   14.3  14.8  14.0  97.1   5.2
 4. 193.26.120.91                                  33.0%   856   14.5  15.8  13.8 106.7   8.1
 5. 193.26.120.33                                  33.0%   856   42.4  46.2  41.6 184.8  14.8
 6. 193.26.120.42                                  33.1%   856   41.9  46.1  40.7 301.9  16.2

Aktuell laufen welche zu 10.15.32.5 (GW04, Domäne 3) und 1.1.1.1 — gerade tut’s mal wieder :frowning:

GW-Reboot haben wir auch probiert, keine wirkliche Änderung.

Das ist eine gute Frage, die ich nicht beantworten kann; es melden sich typisch ja nur Leute, bei denen es nicht geht, und bei einem gezielten Test gestern, bevor die Gluon+Linux-VM-Reihen standen, meldete der Nutzer „tut nicht“ zurück.

Richtig, und der Graph sieht ok-ish aus:

Oh, das ist … interessant. Aktuell hängt der mtr zu 1.1.1.1, schon die 10.15.32.4, per DHCP gelerntes Default-GW (auf GW03) ist nicht erreichbar. Parallel war die 10.15.32.5 (GW04) aber noch erreichbar, die GW-IP des aktuellen batman-GWs:

root@gluon01:~# batctl gwl
[B.A.T.M.A.N. adv openwrt-2018.1-8, MainIF/MAC: primary0/16:f1:a2:ab:4e:eb (bat0/02:00:c0:a8:7a:08 BATMAN_IV)]
  Router            ( TQ) Next Hop          [outgoingIf]  Bandwidth
  02:ca:ff:ee:03:04 (225) 02:ca:ff:ee:03:05 [  mesh-vpn]: 1024.0/1024.0 MBit
* 02:ca:ff:ee:03:05 (255) 02:ca:ff:ee:03:05 [  mesh-vpn]: 1024.0/1024.0 MBit

Nun sind aber seit mehreren Minuten beide mtrs tot … was ja fast nach ARP-Timeout klingt, allerdings:

root@testvm01:~# arp -an
? (192.168.122.1) at 52:54:00:3b:6c:4d [ether] on ens3
? (10.15.32.5) at ee:b6:56:e4:08:fc [ether] on ens4
? (192.168.122.8) at 16:f1:a2:ab:4e:e8 [ether] on ens3
? (10.15.32.4) at 0e:79:ce:82:e0:92 [ether] on ens4
root@testvm01:~# ping -c 3 10.15.32.5 ; ping -c 3 10.15.32.4
PING 10.15.32.5 (10.15.32.5) 56(84) bytes of data.

--- 10.15.32.5 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2025ms

PING 10.15.32.4 (10.15.32.4) 56(84) bytes of data.

--- 10.15.32.4 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2030ms

root@testvm01:~# 

­

root@gluon01:~# batctl tr ee:b6:56:e4:08:fc
traceroute to ee:b6:56:e4:08:fc (02:ca:ff:ee:03:05), 50 hops max, 20 byte packets
 1: 02:ca:ff:ee:03:04  2.892 ms  2.997 ms  2.754 ms
 2: 02:ca:ff:ee:03:05  3.119 ms  3.271 ms  4.805 ms
root@fflip-gluon01:~# batctl tr 0e:79:ce:82:e0:92
traceroute to 0e:79:ce:82:e0:92 (02:ca:ff:ee:03:04), 50 hops max, 20 byte packets
 1: 02:ca:ff:ee:03:04  2.941 ms  2.916 ms  3.043 ms

Altes Problem, nicht zu lösen, dass die Leute Fehler so unspezifisch beschreiben.

aber anyhow. Versuche von der TestVM mehrere IPv4-Adressen zu pingen innerhalb der L2-Domain, an verschiedenen Nodes.
Meine Vermutung ist wirklich „Batman-Arpcache-Foo auf dem ipv4GW“.
Testweise mal Batmanadv-downgrade?

PS: Batman hängt irgendwie auf layer 2.5 zwischen arp-layer und dem ipv4. Daher musst Du schon mit batctl auf Testknoten (an dem die Test-VM hängt) und batctl auf dem GW schauen, was die so meinen zu verschiedenen mac-adressen… die arp-request aus dem Client-Netz werden ja nicht zwangsläufig in der ganzen Domain herumgereicht, sondern aus dem lokalen datcache beantwortet… und wenn da tabellen-inkonsistenzen auftreten, dann hilft nach meiner Erfahrung nur Reboot.

Strategie ist also: Was passiert im Fehlerfall bei GW-Reboot? oder muss Testknoten gebootet werden? Oder beide?

Daher nochmal: Bitte versuche im Fehlerfall mal eine andere IPv4 im L2-netz zu pingen, ob auch das failed.

Isch 'ab da nix. Die GWs sind .4 und .5, beide teilen die gleiche Problematik. Reboot der GW-VMs löst das Problem nicht spürbar dauerhaft.

Ja, das failed auch, siehe oben. Ich werd’ morgen noch 'n 841 oder so reinhängen und 'n RPi oder ESP dahinter, um eine Test-IP „quer durch’s Mesh“ zu haben. Was mich aber der Lösung auch nicht weiterbringt, oder?

Wenn das durchgehend läuft während das GW failed: Batmanversion auf dem gw ändern, hoch (wenn verfügbar) oder runter.

root@gw04 ~ # modinfo batman-adv
filename:       /lib/modules/4.4.0-173-generic/updates/dkms/batman-adv.ko
alias:          net-pf-16-proto-16-family-batadv
alias:          rtnl-link-batadv
version:        2017.4
description:    B.A.T.M.A.N. advanced
author:         Marek Lindner <mareklindner@neomailbox.ch>, Simon Wunderlich <sw@simonwunderlich.de>
license:        GPL
srcversion:     10420B3AFED5BDE0BC8A13E
depends:        libcrc32c,bridge
retpoline:      Y
vermagic:       4.4.0-173-generic SMP mod_unload modversions 

­

root@gw03 ~ # modinfo batman-adv
filename:       /lib/modules/4.15.0-76-generic/kernel/net/batman-adv/batman-adv.ko
alias:          net-pf-16-proto-16-family-batadv
alias:          rtnl-link-batadv
version:        2017.4
description:    B.A.T.M.A.N. advanced
author:         Marek Lindner <mareklindner@neomailbox.ch>, Simon Wunderlich <sw@simonwunderlich.de>
license:        GPL
srcversion:     30C417E65EBD2930F839782
depends:        libcrc32c,bridge
retpoline:      Y
intree:         Y
name:           batman_adv
vermagic:       4.15.0-76-generic SMP mod_unload 
signat:         PKCS#7
signer:         
sig_key:        
sig_hashalgo:   md4

das müffelt aber schon ein wenig… würde mich nicht wundern, wenn sich das hier und da mal mit aktuellen Gluons beisst.

Ubuntu 18.04.4 (gw03), 16.04.6 (gw04). Wieviel Diversität hätten’s denn gerne? :wink:

Nochmal: 4 „Domänen“ laufen auf den 4 GWs, D1 & D2 auf GW01, D1 & D2 auf GW02, D3 & D4 auf GW03, D3 & D4 auf GW04. Nur D3 macht Probleme — die sich mit D4 aber ja die GWs und damit auch die batman-Module teilt. GW01, GW02, GW04 sind Ubuntu 16.04.6. Wenn Du meinst, da beißt sich was, würde ich ja GW03 abschalten und gucken, ob sich das D3-Verhalten bessert?

Firmware im Einsatz ist überwiegend 2018.2.x und 2019.1.x.

Es reicht doch ein einzelner Knoten in einer Domain der irgendwelche Race-Conditions in den Tabellen erzeugt. Daher würde ich wirklich erstmal das Batman updaten auf den Gateways.
(Mir würde es gar nicht einfallen, irgendwo nicht mindestens „irgendein“ 2019er zu nutzen.)

seufz Na gut, dann probieren wir das mal …

FTR: Batman 2019.5 hat – wie vermutet – die Situation nicht verändert. Da ja auch auf den Knoten ein batman-adv.ko läuft, was älter als 2019.x ist, zudem IPv6 von dem Phänomen ausgenommen, hatte ich keine große Hoffnung in „neu ist besser“ gesetzt.

Es läuft nun ein Smokeping auf einem RPi hinter einem realen Knoten — just in case:

FPing4 zum Default-GW:

FPing6 zum Default-GW:

Weitere Vorschläge zu den Gründen sind willkommen.

ich bleibe dabei.