Legacy Netz - Fastd Server Verbindung zum Netz verloren?

**Thomas** · 17. Oktober 2020 um 07:19

Hallo,

seit dem 15.10.2020, 0:16:36 ist der Knoten 33397-H-Knaup Offline. (Für den ich zuständig bin). Ich habe erst an einem Konfigurationsfehler in der Firewall gedacht. Scheint aber nicht der Fall zu sein. Ich habe gestern einmal den Traffic auf zwei unterschiedlichen Internetanschlüssen heraus geschickt und per Wireshark anlysiert. Der Knoten schickt Pakete, und es kommen auch welche vom Fastd Server zurück. Trtozdem ist das Netz Offline. (Keine IP; ich kann leider aktuell nicht Lokal auf den Knoten zugreifen).
Auf der Firewall bei uns ist folgende Verbindung offen, und wird nach dem Kappen auch immer wieder aufgebaut.
xxx.xxx.xxx.190:39791 --.>; 193.26.120.101:10000

Allerdings ist mir folgendes aufgefallen.
Folgende Knoten sind zu selben Zeit Offline gegangen.

letzte Nachricht vor 2 Tagen (15.10.2020, 0:18:32) - 33829-SBR1 offline
letzte Nachricht vor 2 Tagen (15.10.2020, 0:18:35) - 33829-Stadt-Borgholzhausen-FUH4 offline
letzte Nachricht vor 2 Tagen (15.10.2020, 0:18:36) - 33829-SpielgruppeFamZ offline
letzte Nachricht vor 2 Tagen (15.10.2020, 0:18:00) - 33790-Bokel-ESX offline
letzte Nachricht vor 2 Tagen (15.10.2020, 0:18:02) - 33415-d46e0e79c0bc offline
letzte Nachricht vor 2 Tagen (15.10.2020, 0:18:02) - 33790-Bokel offline
letzte Nachricht vor 2 Tagen (15.10.2020, 0:18:02) - 33803-CheckPoint-967b offline
letzte Nachricht vor 2 Tagen (15.10.2020, 0:18:02) - 33824-Haus-Werther-18e8 offline
letzte Nachricht vor 2 Tagen (15.10.2020, 0:16:36) - 33397-H-Knaup offline

Die Zeiten sind schon etwas aufällig. Kann es sein, das dort eine Verbindung vom fastd Server zum Netz gekappt ist?

**flohoff** · 17. Oktober 2020 um 12:46

Moin,

Hallo,

seit dem 15.10.2020, 0:16:36 ist der Knoten 33397-H-Knaup Offline. (Für den ich zuständig bin). Ich habe erst an einem Konfigurationsfehler in der Firewall gedacht. Scheint aber nicht der Fall zu sein. Ich habe gestern einmal den Traffic auf zwei unterschiedlichen Internetanschlüssen heraus geschickt und per Wireshark anlysiert. Der Knoten schickt Pakete, und es kommen auch welche vom Fastd Server zurück. Trtozdem ist das Netz Offline. (Keine IP; ich kann leider aktuell nicht Lokal auf den Knoten zugreifen).
Auf der Firewall bei uns ist folgende Verbindung offen, und wird nach dem Kappen auch immer wieder aufgebaut.
xxx.xxx.xxx.190:39791 --.>; 193.26.120.101:10000

Allerdings ist mir folgendes aufgefallen.
Folgende Knoten sind zu selben Zeit Offline gegangen.

letzte Nachricht vor 2 Tagen (15.10.2020, 0:18:32) - 33829-SBR1 offline
letzte Nachricht vor 2 Tagen (15.10.2020, 0:18:35) - 33829-Stadt-Borgholzhausen-FUH4 offline
letzte Nachricht vor 2 Tagen (15.10.2020, 0:18:36) - 33829-SpielgruppeFamZ offline
letzte Nachricht vor 2 Tagen (15.10.2020, 0:18:00) - 33790-Bokel-ESX offline
letzte Nachricht vor 2 Tagen (15.10.2020, 0:18:02) - 33415-d46e0e79c0bc offline
letzte Nachricht vor 2 Tagen (15.10.2020, 0:18:02) - 33790-Bokel offline
letzte Nachricht vor 2 Tagen (15.10.2020, 0:18:02) - 33803-CheckPoint-967b offline
letzte Nachricht vor 2 Tagen (15.10.2020, 0:18:02) - 33824-Haus-Werther-18e8 offline
letzte Nachricht vor 2 Tagen (15.10.2020, 0:16:36) - 33397-H-Knaup offline

Die Zeiten sind schon etwas aufällig. Kann es sein, das dort eine Verbindung vom fastd Server zum Netz gekappt ist?

Ich hatte eine Fritz!Box 4020 die mit einem mal offline war und auch
durch reboot nicht zu fixen war. Auch durch die config oberfläche
nach reset war nichts zu wollen. Ich hab dann auf die testing firmware
geupgraded und das ging dann.

Ich hab keine Ahnung was das war oder was es repariert hat. Alles
undurchsichtig.

Flo

**Thomas** · 17. Oktober 2020 um 14:00

Das es nun funktioniert wird daran liegen, das die Testing Firmware schon auf das neue L2TP basierende Netz drauf zugreift.

**wusel** · 17. Oktober 2020 um 15:21

Nur der tng-Zweig (http://firmware.4830.org/tng/) nutzt L2TP.

Aber zwischen den Versionen haben sich die Gateways geändert, vermutlich liegt es daran.

Wobei: welchen ISP nutzt 33397-H-Knaup, gibt es ggf. da einen Zusammenhang (sprich: haben die alle den gleichen Anbieter)?

**Thomas** · 17. Oktober 2020 um 15:30

Telekom, einmal über einen DCIPvmit statischer IP oder über VDSL mit dynamischer. Die Routen sind aber identisch. Ich starte gleich Mal am Travel sobald ich zu Hause bin.

**wusel** · 17. Oktober 2020 um 15:57

Von einer IP .190, Port 39791, sehe ich auf der .101 keine Einträge im Log heute.

Telekom-Routing sieht OK aus:

traceroute to 193.26.120.101 (193.26.120.101), 30 hops max, 60 byte packets
 1  fritz.box (192.168.177.1)  0.826 ms  0.962 ms  1.199 ms
 2  p3e9bf2e7.dip0.t-ipconnect.de (62.155.242.231)  14.722 ms  14.774 ms  14.981 ms
 3  pd9ef371a.dip0.t-ipconnect.de (217.239.55.26)  19.550 ms  24.311 ms  24.368 ms
 4  pd9ef371a.dip0.t-ipconnect.de (217.239.55.26)  24.433 ms  24.501 ms  24.712 ms
 5  bgp-ber01.4830.org (193.26.120.86)  24.828 ms  31.218 ms  31.271 ms
 6  legacy-ber01.4830.org (193.26.120.101)  31.335 ms  17.204 ms  20.737 ms

Rückweg ebenso:

root@legacy-ber01 ~ # traceroute $home
traceroute to $home ($homeip), 30 hops max, 60 byte packets
 1  blackstar.4830.org (193.26.120.97)  0.322 ms  0.302 ms  0.288 ms
 2  dtag.l105.community-ix.de (185.1.74.27)  1.510 ms  1.486 ms  1.591 ms
 3  87.137.220.105 (87.137.220.105)  5.728 ms  5.738 ms  5.726 ms
 4  p578e2ef1.dip0.t-ipconnect.de (87.142.46.241)  13.255 ms  13.405 ms  14.212 ms
 5  p578e2ef1.dip0.t-ipconnect.de (87.142.46.241)  13.660 ms  13.872 ms  14.355 ms

Verbunden sind derzeit gut 230 Knoten, aber nicht jener:

root@legacy-ber01 ~ # ./status.pl /run/fastd-00/fastd.sock | jq '.peers[].address' | wc -l
232
root@legacy-ber01 ~ # ./status.pl /run/fastd-00/fastd.sock | jq '.peers[].address' | grep \.190:
root@legacy-ber01 ~ #

Ideen?

**Thomas** · 17. Oktober 2020 um 16:13

Die Nat IP ist aber 87.130.118.242 oder 84.179.114.218

Der Firewall Eintrag war für dich nicht hilfreich sorry

**Thomas** · 17. Oktober 2020 um 18:26

Der Knoten 33397-H-Knaup hat sich jetzt auf 192.251.226.202:10000 verbunden. Hier hat er eine Verbindung zum Netz. Es gehen auch Daten über die Verbindung.

Hier der Traceroute

tracert 192.251.226.202

Routenverfolgung zu l2tp-test-v15.4830.org [192.251.226.202]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms XXX.XXX.XXX.XXX
2 1 ms 1 ms 1 ms XXX.XXX.XXX:XXX
3 4 ms 6 ms 3 ms 87.130.118.241
4 54 ms 4 ms 4 ms 10.49.46.53
5 11 ms 14 ms 11 ms f-ee5-i.f.de.net.dtag.de [62.154.14.206]
6 11 ms 11 ms 12 ms 193.158.36.214
7 22 ms 22 ms 22 ms ae1.cr2.gut1.plusserver.com [85.119.200.54]
8 22 ms 22 ms 22 ms te1-5.xmws-gtso-de12.gut1.plusserver.com [85.119.200.234]
9 27 ms 26 ms 26 ms de0.as206946.net [193.26.120.92]
10 25 ms 25 ms 25 ms bgp-gut01.4830.org [193.26.120.82]
11 25 ms 25 ms 25 ms bgp-fra01.4830.org [193.26.120.81]
12 26 ms 26 ms 27 ms l2tp-test-v15.4830.org [192.251.226.202]

**Thomas** · 18. Oktober 2020 um 07:15

@wusel hast du schon eine Idee? Wird da irgendwo was gefitert oder gedrosselt? Weil die Routen sehen ja in beiden Richtungen identisch aus. Oder ist da etwas mit dem Server?

**wusel** · 23. Oktober 2020 um 00:47

Zwischenstand:

Auf blackstar, unserem Server in Berlin, laufen nun 2 fastd-Prozesse (“fastd176” und “fastd177”) auf dem Host, die Interfaces reingebridged in die VM, legacy-ber01, wie vorher in GUT.

Die Legacy-Gateway-Adressen “fastd178” und “fastd179” ziehen entsprechend auf brick, unseren Server in Frankfurt, werden reingebridged in die VM legacy-fra01.

Alleine: wenn ich den fastd in legacy-ber01 abschalte, kommen auf den anderen fastd-Adresse eben nicht mehr Anfragen an — die Clients kleben irgendwie auf der IP. Obwohl gestern schon der DNS-Eintrag geändert wurde und der nur eine Lebensdauer von 1 Stunde hat.

Ich bin gerde etwas ratlos

**Thomas** · 24. Oktober 2020 um 19:09

Soll ich etwas testen? Oder einfach nur den normalen Betrieb beobachten?

**wusel** · 25. Oktober 2020 um 03:51

Momentan scheint’s zu tun, leider ist nun die Karte hin. Irgendwas ist ja immer …

root@blackstar ~ # FASTD_SOCKET=/var/run/fastd176-status.ffgt.sock /usr/local/bin/fastd-query connections
51
root@blackstar ~ # FASTD_SOCKET=/var/run/fastd177-status.ffgt.sock /usr/local/bin/fastd-query connections
127
root@brick:~# FASTD_SOCKET=/var/run/fastd178-status.ffgt.sock /usr/local/bin/fastd-query connections
30
root@brick:~# FASTD_SOCKET=/var/run/fastd179-status.ffgt.sock /usr/local/bin/fastd-query connections
194

Insofern: wenn man einen Legacy-Knoten hat/sieht, einfach mal v6.de aufrufen, ggf. auch 'nen Speedtest machen, danke.

**Thomas** · 25. Oktober 2020 um 09:07

Kann es sein das wir Paketloss haben? Zumindest bei IPv6?

Wollte gerade aus dem Telekom Netz auf einen RaspberryPI im Legacy Netz für einen Speedtest, leider scheitere ich kläglich.

**Thomas** · 25. Oktober 2020 um 09:24

bzgl. Paketloss hatte ich gestern auch schon einmal gedacht das es nicht genau passt, da ich in Icinga Ping Probleme gesheen habe. Habe mir aber noch nichts gedacht gehabt.

(Der Raspberry Antwortet wenn man im passenden Moment per SSH anspricht, die Verbindung bricht aber immer wieder zusammen)

**Thomas** · 26. Oktober 2020 um 16:27

Ipv4 scheint sauber zu funktionieren. Auf jeden Fall von innen nach außen. Werde morgen noch einmal genauer schauen.

**Thomas** · 26. Oktober 2020 um 19:38

Die beiden Screenshots zeigen, dass aus den Netz von FF GT nach Extern auch Pakete verloren gehen. Sowohl über v4 als auch über v6.

Ein Speedtest den nochmals ausgeführt habe zeigt, das aber wohl Daten fließen können, wenn es scheinbar unkritische Daten sind.

thomas@ff-icinage-knaup:~ $ speedtest
Retrieving speedtest.net configuration…
Testing from Kai Siering (192.251.226.202)…
Retrieving speedtest.net server list…
Selecting best server based on ping…
Hosted by Previder BV (Hengelo) [115.96 km]: 84.156 ms
Testing download speed…
Download: 11.59 Mbit/s
Testing upload speed…
Upload: 1.52 Mbit/s

**wusel** · 26. Oktober 2020 um 20:01

Moin,

ich hab’ zwecks Test ja vier Gluon- und eine Linux-VM in Falkenstein aufgesetzt. Die Gluon-VMs sollen jeweils nur ein GW erreichen (löse ich durch iptables auf dem Host) und die Linux-VM hat das LAN der Gluon-VMs jeweils als Interface. Das tut auch soweit:

root@legacy-mon:~# ip route show
default via 192.168.122.1 dev ens11 onlink 
10.255.128.0/17 dev ens6 proto kernel scope link src 10.255.220.18 
10.255.128.0/17 dev ens7 proto kernel scope link src 10.255.251.30 
10.255.128.0/17 dev ens5 proto kernel scope link src 10.255.249.1 
10.255.128.0/17 dev ens4 proto kernel scope link src 10.255.242.23 
192.168.122.0/24 dev ens11 proto kernel scope link src 192.168.122.11 
root@legacy-mon:~# ip -6 route show
::1 dev lo proto kernel metric 256 pref medium
2001:bf7:1310:ba14::/64 dev ens5 proto kernel metric 256 expires 86399sec pref medium
2001:bf7:1310:ba14::/64 dev ens6 proto kernel metric 256 expires 86399sec pref medium
2001:bf7:1310:ba14::/64 dev ens4 proto kernel metric 256 expires 86399sec pref medium
2001:bf7:1310:ba14::/64 dev ens7 proto kernel metric 256 expires 86399sec pref medium
2a01:4f8:211:132a::/64 dev ens3 proto kernel metric 256 pref medium
fd10:ca1::/64 dev ens5 proto kernel metric 256 expires 86340sec pref medium
fd10:ca1::/64 dev ens6 proto kernel metric 256 expires 86215sec pref medium
fd10:ca1::/64 dev ens4 proto kernel metric 256 expires 86191sec pref medium
fd10:ca1::/64 dev ens7 proto kernel metric 256 expires 86008sec pref medium
fe80::/64 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev ens11 proto kernel metric 256 pref medium
fe80::/64 dev ens4 proto kernel metric 256 pref medium
fe80::/64 dev ens5 proto kernel metric 256 pref medium
fe80::/64 dev ens6 proto kernel metric 256 pref medium
fe80::/64 dev ens7 proto kernel metric 256 pref medium
default via 2001:db8:211:132a::2 dev ens3 metric 1024 onlink pref medium
default via fe80::f0be:efff:fe00:21 dev ens6 proto ra metric 1024 expires 57sec hoplimit 64 pref medium
default via fe80::f0be:efff:fe00:23 dev ens5 proto ra metric 1024 expires 59sec hoplimit 64 pref medium
default via fe80::f0be:efff:fe00:23 dev ens6 proto ra metric 1024 expires 59sec hoplimit 64 pref medium
default via fe80::f0be:efff:fe00:23 dev ens7 proto ra metric 1024 expires 59sec hoplimit 64 pref medium
default via fe80::f0be:efff:fe00:23 dev ens4 proto ra metric 1024 expires 59sec hoplimit 64 pref medium
default via fe80::f0be:efff:fe00:21 dev ens5 proto ra metric 1024 expires 57sec hoplimit 64 pref medium
default via fe80::f0be:efff:fe00:21 dev ens4 proto ra metric 1024 expires 57sec hoplimit 64 pref medium
default via fe80::f0be:efff:fe00:21 dev ens7 proto ra metric 1024 expires 57sec hoplimit 64 pref medium
default via fe80::f0be:efff:fe00:22 dev ens5 proto ra metric 1024 expires 59sec hoplimit 64 pref medium
default via fe80::f0be:efff:fe00:22 dev ens4 proto ra metric 1024 expires 59sec hoplimit 64 pref medium
default via fe80::f0be:efff:fe00:22 dev ens6 proto ra metric 1024 expires 59sec hoplimit 64 pref medium
default via fe80::f0be:efff:fe00:22 dev ens7 proto ra metric 1024 expires 59sec hoplimit 64 pref medium
default via fe80::f0be:efff:fe00:20 dev ens6 proto ra metric 1024 expires 57sec hoplimit 64 pref medium
default via fe80::f0be:efff:fe00:20 dev ens5 proto ra metric 1024 expires 57sec hoplimit 64 pref medium
default via fe80::f0be:efff:fe00:20 dev ens4 proto ra metric 1024 expires 57sec hoplimit 64 pref medium
default via fe80::f0be:efff:fe00:20 dev ens7 proto ra metric 1024 expires 57sec hoplimit 64 pref medium

Was ich jetzt brauche ist eine Möglichkeit, daß sowohl der DHCP-Client als auch der Kernel (der die Rouing Advertisements verarbeitet) Routen, die er via ens4 lernt, in Routingtabelle 4 packt, via ens5 in Tabelle 5 und so weiter. DANN könnte man die “User-Experience” über alle Gateways von einem Ort aus messen.

Irgend eine Idee, wie das funktionieren könnte?

**jarl** · 26. Oktober 2020 um 20:12

Du könntest jedes Interface in ein eigenes VRF packen, dann hast du alle Routingtabellen sauber separiert.

**wusel** · 26. Oktober 2020 um 21:07

Danke, gute Idee; ich hatte initial an Network Namespaces gedacht, VRF scheint aber einfacher.

Aber leider wird keine v4 Defaultroute vom dhclient gesetzt, damit ist das eher zweckfrei

root@legacy-mon:~# ip addr show vrf ffgw01
3: ens4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc fq_codel master ffgw01 state UP group default qlen 1000
    link/ether 02:00:c5:e3:42:fc brd ff:ff:ff:ff:ff:ff
    inet 10.255.242.23/17 brd 10.255.255.255 scope global ens4
       valid_lft forever preferred_lft forever
    inet6 fd10:ca1::c5ff:fee3:42fc/64 scope global dynamic mngtmpaddr 
       valid_lft 86375sec preferred_lft 14375sec
    inet6 2001:bf7:1310:ba14:0:c5ff:fee3:42fc/64 scope global dynamic mngtmpaddr 
       valid_lft 86398sec preferred_lft 14398sec
    inet6 fe80::c5ff:fee3:42fc/64 scope link 
       valid_lft forever preferred_lft forever
root@legacy-mon:~# ip route show table 101
broadcast 10.255.128.0 dev ens4 proto kernel scope link src 10.255.242.23 
10.255.128.0/17 dev ens4 proto kernel scope link src 10.255.242.23 
local 10.255.242.23 dev ens4 proto kernel scope host src 10.255.242.23 
broadcast 10.255.255.255 dev ens4 proto kernel scope link src 10.255.242.23 
root@legacy-mon:~#

Hmm. Warum kann nicht einmal was tun wie’s soll?

**jarl** · 26. Oktober 2020 um 22:09

Damit dhclient in VRFs default Routen setzt musst du das dhclient-script anpassen. Welche Distribution nutzt du in der Linux-VM?