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?
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.
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.
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:
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.
@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?
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.
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)
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
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.
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:~#
