pi@raspberrypi:~ $ traceroute heise.de
traceroute to heise.de (193.99.144.80), 30 hops max, 60 byte packets
1 10.234.144.4 (10.234.144.4) 11.961 ms 12.138 ms 12.334 ms
2 bgp-ber01.4830.org (193.26.120.86) 12.416 ms 14.227 ms 14.446 ms
3 bgp-gut02.4830.org (193.26.120.83) 31.587 ms 31.895 ms 32.103 ms
4 bgp-ber01.4830.org (193.26.120.86) 30.321 ms 30.889 ms 31.741 ms
5 bgp-gut02.4830.org (193.26.120.83) 47.070 ms 47.296 ms 47.349 ms
6 * * bgp-ber01.4830.org (193.26.120.86) 42.941 ms
7 bgp-gut02.4830.org (193.26.120.83) 58.960 ms * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * bgp-gut02.4830.org (193.26.120.83) 105.136 ms 105.310 ms
14 bgp-ber01.4830.org (193.26.120.86) 104.054 ms 105.382 ms 105.347 ms
15 bgp-gut02.4830.org (193.26.120.83) 120.967 ms 121.064 ms 120.721 ms
16 bgp-ber01.4830.org (193.26.120.86) 120.171 ms 120.656 ms *^C
pi@raspberrypi:~ $ traceroute ex.knaup-nrw.de
traceroute to ex.knaup-nrw.de (87.130.118.242), 30 hops max, 60 byte packets
1 10.234.144.4 (10.234.144.4) 11.678 ms 11.791 ms 11.839 ms
2 bgp-ber01.4830.org (193.26.120.86) 12.111 ms 12.356 ms 12.483 ms
3 dtag.l105.community-ix.de (185.1.74.27) 27.721 ms 27.906 ms 27.879 ms
4 87.137.220.109 (87.137.220.109) 28.771 ms 29.105 ms 87.137.214.213 (87.137.214.213) 29.227 ms
5 * * *
6 87.130.118.242 (87.130.118.242) 32.832 ms 32.785 ms 32.756 ms
pi@raspberrypi:~ $ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 10.234.144.4 (10.234.144.4) 11.850 ms 12.049 ms 12.090 ms
2 bgp-ber01.4830.org (193.26.120.86) 12.309 ms 12.467 ms 12.530 ms
3 google.bcix.de (193.178.185.100) 28.223 ms 28.531 ms 28.479 ms
4 108.170.241.193 (108.170.241.193) 26.943 ms 108.170.241.161 (108.170.241.161) 28.613 ms 108.170.241.193 (108.170.241.193) 27.503 ms
5 108.170.237.45 (108.170.237.45) 27.034 ms 108.170.236.227 (108.170.236.227) 28.580 ms 172.253.66.185 (172.253.66.185) 29.020 ms
6 dns.google (8.8.8.8) 28.618 ms 26.246 ms 25.314 ms
Kann sein, sorry for that. Das Netz wird umgebaut (von BGP-Fullmesh auf Routerreflektoren in HAM und BER), in GUT spinnt hier zeitweise was (gut02 bekommt dann Routen per OSPF von gw10 o. ä., die falsch sind und für Schleifen sorgen ), kann also noch rumpeln über’s Wochenende. Feiertag bringt da zum Glück etwas Zeit …
Ist in Ordnung. Mir ist es gestern abend schon aufgefallen. Dort war es aber nur zeitweise. Wollte nur sicher gehen, dass sich dort nicht verselbständigt hat.
Tja, FTR: “ip route flush table main” ist keine gute Idee. Trotz laufenden (und gen Upstream verbundenen) Routing-Daemons (bird) bleibt die Routingtabelle leer. Läuft das Routing auf der Hardware, ist ein Reboot zwingend; ist die Hardware auch ein Hypervisor, ist der Spaß doppelt so hoch. Seit 13:10 sollte das meiste wieder tun (IPv4; IPv6 ist andere Baustelle).
Hmm, also auf 10.234.144.2 der ja verteilt wird sagt mein Android Handy Timeout bei der Auflösung. Ping geht. Mein Raspberrypi läuft aber im selben Netz mit dem selben Server sauber. (Ich habe in beiden Fällen mit einem Tool der Server getestet.)
Aktuell funktionieren alle Clients. Mein Bruder hat aber von änlichen sachen bei ihm zu Hause auch gesprochen. Er kann es aber nicht so genau beschreiben. DOrt heißt es dann nur immer geht nicht. Wenn ich da bin funktionieren meine Standardseiten aber immer direkt. Scheinbar weil dort mein Handy die Auflösung im Cache hat.
Ich werde das mal weiter beobachten und ein Augenmerk drauf haben.
Interessant finde ich, dass ich einmal einen Timeout bekommen habe und in selben Moment von einen anderen Client aus eine Rückmeldung. Und das über mehrere Minuten reproduzierbar im selben WLAN direkt an einem 841als Client. Ohne jegliche andere Infrastruktur dazwischen.
Habe es im Produktiv Netz gerade auch sehen können. Hier wollte Laptop (Windows 10) und Handy nicht. Habe anbei einmal einen Screenshot von Wireshark. Evtl hilft der ja weiter.