TNG Routing Probleme

(Thomas Hollenbeck) #1

Guten Morgen,

kann es sein, dass es im TNG Netz Routing Probleme gibt?
Siehe hier:
pi@raspberrypi:~ $ traceroute strato.de

traceroute to strato.de (192.67.198.33), 30 hops max, 60 byte packets
1 10.234.144.4 (10.234.144.4) 11.421 ms 11.717 ms 11.948 ms
2 bgp-ber01.4830.org (193.26.120.86) 12.391 ms 13.141 ms 13.205 ms
3 strato.a36.community-ix.de (185.1.74.6) 12.742 ms 13.389 ms 13.597 ms
4 ae2.0.morla.as6724.net (85.214.0.65) 27.211 ms 27.680 ms 27.740 ms
5 vl482.fiddlersriddle.as6724.net (81.169.144.34) 29.337 ms 30.038 ms 30.247 ms
6 web4.webmailer.de (192.67.198.33) 29.662 ms 28.294 ms 28.291 ms

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

Scheinbar spinnt
bgp-gut02.4830.org

0 Likes

(Kai 'wusel' Siering) #2

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 :frowning:), kann also noch rumpeln über’s Wochenende. Feiertag bringt da zum Glück etwas Zeit …

0 Likes

(Thomas Hollenbeck) #3

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.

0 Likes

(Kai 'wusel' Siering) #4

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).

0 Likes

(Thomas Hollenbeck) #5

Ich habe aktuell im TNG noch ein Problem mit der DNS Auflösung. Die läuft in einen Timeout. Teste es gerade mit verschiedenen Clients.

0 Likes

(Thomas Hollenbeck) #6

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.)

0 Likes

(Thomas Hollenbeck) #7

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.

0 Likes

(Kai 'wusel' Siering) #8

Hmm, evtl. wäre es sinnig, auch weitere Resolver zu übergeben? So ist das in der Tat ein SPOF:

0 Likes

(Thomas Hollenbeck) #9

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.

0 Likes

(Kai 'wusel' Siering) #10

Sprich: Du vermutest keine generelle Fehlfunktion des DNS-Resolvers sondern Netzprobleme (DNS ist, noch, meist UDP)?

0 Likes

(Thomas Hollenbeck) #11

Irgendwie so, nur das es irgendetwas mit den Client zu tun hat. Mal schauen ob ich beim nächsten mal etwas mit Wireshark mit schnippeln kann

0 Likes

(Thomas Hollenbeck) #12

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.

(Rohdaten habe ich auch noch wenn bedarf da ist.)

0 Likes

(system) geschlossen, #13

Dieses Thema wurde automatisch 10 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Nachrichten mehr erlaubt.

0 Likes