Netzinstabilitäten

wusel · 3. Dezember 2018 um 15:48

Orginaler Blog-Post: https://freifunk-kreisgt.de/netzinstabilitaeten/

Info aus dem Maschinenraum: aktuell sehen wir Instabilitäten im Gütersloher Freifunknetz, Knoten kommen und gehen Wir sind dran, haben aber noch keine Erklärung, was da schiefgeht. Updates via Forum.

wusel · 6. Dezember 2018 um 11:03

Ein Teil der Probleme wurde lokalisiert, an der Lösung wird gearbeitet.

(Details: die virtuellen Verbindungen der Gateways zum DHCP-Server waren nicht mehr funktional (‘links’ alter Kernel, session_id 1, ‘rechts’ neuer Kernel und eindeutige session_id => nix geht durch). Nun werden DHCP-Requests zwar wieder beantwortet — aber diese Antwort kommt nicht beim Client an. Das Gateway als DHCP-Relay bekommt die Antwort und setzt sie auch um, wie im tcpdump zu sehen — aber die Antwort kommt nicht beim Client an, wie man dort per tcpdump sieht )

Thomas · 10. Dezember 2018 um 21:50

Hi Kai,

hier wie versprochen etwas Futter für dich. Bin über folgenden Knoten rein gegangen.
33378-freifunk-a42bb0f43a87

nslookup
Standardserver: UnKnown
Address: 10.255.0.11

heise.de
Server: UnKnown
Address: 10.255.0.11

Nicht autorisierende Antwort:
Name: heise.de
Addresses: 2a02:2e0:3fe:1001:302::
193.99.144.80

google.de
Server: UnKnown
Address: 10.255.0.11

DNS request timed out.
timeout was 2 seconds.
Name: google.de
Address: 2a00:1450:4003:80b::2003

heise.de
Server: UnKnown
Address: 10.255.0.11

Nicht autorisierende Antwort:
Name: heise.de
Addresses: 2a02:2e0:3fe:1001:302::
193.99.144.80

google.de
Server: UnKnown
Address: 10.255.0.11

DNS request timed out.
timeout was 2 seconds.
Nicht autorisierende Antwort:
Name: google.de
Addresses: 2a00:1450:4003:80b::2003
172.217.168.163

google.de
Server: UnKnown
Address: 10.255.0.11

Nicht autorisierende Antwort:
Name: google.de
Addresses: 2a00:1450:4003:80b::2003
172.217.168.163

t-online.de
Server: UnKnown
Address: 10.255.0.11

Nicht autorisierende Antwort:
Name: t-online.de
Addresses: 2a02:cbf7::62:138:238:100
2a02:cbf7:1:0:62:138:239:100
62.138.239.100
62.138.238.100

ping t-online.de

Ping wird ausgeführt für t-online.de [62.138.239.100] mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 62.138.239.100:
Pakete: Gesendet = 2, Empfangen = 0, Verloren = 2
(100% Verlust),
STRG-C
^C

ping 8.8.8.8

Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
STRG-C
^C

ping 10.255.0.1

Ping wird ausgeführt für 10.255.0.1 mit 32 Bytes Daten:
Antwort von 10.255.0.1: Bytes=32 Zeit=9ms TTL=64
Antwort von 10.255.0.1: Bytes=32 Zeit=3ms TTL=64

Ping-Statistik für 10.255.0.1:
Pakete: Gesendet = 2, Empfangen = 2, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 3ms, Maximum = 9ms, Mittelwert = 6ms
STRG-C
^C

ping 10.255.0.11

Ping wird ausgeführt für 10.255.0.11 mit 32 Bytes Daten:
Antwort von 10.255.0.11: Bytes=32 Zeit=36ms TTL=64
Antwort von 10.255.0.11: Bytes=32 Zeit=34ms TTL=64
Antwort von 10.255.0.11: Bytes=32 Zeit=20ms TTL=64
Antwort von 10.255.0.11: Bytes=32 Zeit=34ms TTL=64

Ping-Statistik für 10.255.0.11:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 20ms, Maximum = 36ms, Mittelwert = 31ms

ping 9.9.9.9

Ping wird ausgeführt für 9.9.9.9 mit 32 Bytes Daten:
Antwort von 10.255.0.11: Zielnetz nicht erreichbar.
Zeitüberschreitung der Anforderung.
Antwort von 10.255.0.11: Zielnetz nicht erreichbar.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 9.9.9.9:
Pakete: Gesendet = 4, Empfangen = 2, Verloren = 2
(50% Verlust),

Also der DNS sieht bis auf vereinzelte Paketverluste hier etst mal garnicht so schlecht aus.

Thomas · 11. Dezember 2018 um 19:54

Hmm, interessant

heute Mittag über Lu-Hollenbeck-1 klappte alles ohne Probleme

Gerade aktuell über 33378-freifunk-a42bb0f43a87 nur DNS aber kein Routing nach Extern

ping 9.9.9.9

Ping wird ausgeführt für 9.9.9.9 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Antwort von 10.255.0.53: Zielnetz nicht erreichbar.
Zeitüberschreitung der Anforderung.
Antwort von 10.255.0.53: Zielnetz nicht erreichbar.

Ping-Statistik für 9.9.9.9:
Pakete: Gesendet = 4, Empfangen = 2, Verloren = 2
(50% Verlust),

ping 9.9.9.9

Ping wird ausgeführt für 9.9.9.9 mit 32 Bytes Daten:
Antwort von 10.255.0.53: Zielnetz nicht erreichbar.
Antwort von 10.255.0.53: Zielnetz nicht erreichbar.
Antwort von 10.255.0.53: Zielnetz nicht erreichbar.
Antwort von 10.255.0.53: Zielnetz nicht erreichbar.

Ping-Statistik für 9.9.9.9:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),

ping 9.9.9.9

Ping wird ausgeführt für 9.9.9.9 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 10.255.0.53: Zielnetz nicht erreichbar.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 9.9.9.9:
Pakete: Gesendet = 4, Empfangen = 1, Verloren = 3
(75% Verlust),

ping 10.255.0.53

Ping wird ausgeführt für 10.255.0.53 mit 32 Bytes Daten:
Antwort von 10.255.0.53: Bytes=32 Zeit=29ms TTL=64
Antwort von 10.255.0.53: Bytes=32 Zeit=41ms TTL=64
Antwort von 10.255.0.53: Bytes=32 Zeit=72ms TTL=64
Antwort von 10.255.0.53: Bytes=32 Zeit=56ms TTL=64

Ping-Statistik für 10.255.0.53:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 29ms, Maximum = 72ms, Mittelwert = 49ms

ping 8.8.8.8

Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.

Ping-Statistik für 8.8.8.8:
Pakete: Gesendet = 1, Empfangen = 0, Verloren = 1
(100% Verlust),
STRG-C
^C

tracert 9.9.9.9

Routenverfolgung zu dns.quad9.net [9.9.9.9]
über maximal 30 Hops:

1 * * 10.255.0.53 meldet: Zielnetz nicht erreichbar.

Ablaufverfolgung beendet.

wusel · 11. Dezember 2018 um 20:21

Da warst Du auf dem neuen Gateway gw-test01, welches zu dem Zeitpunkt ggf. auch noch nicht vollkommen fertig aufgesetzt war. Außerdem existieren derzeit noch Querverbindungen (über Test-Knoten mit 1.x-Firmware an Knoten mit 0.7er FW), was auch dazu führt, daß (auch) Dein Knoten noch zwei v6-Prefixe hat:

2001:bf7:1310:10:a62b:b0ff:fef4:3a87
2001:bf7:1315:10:a62b:b0ff:fef4:3a87
fd42:ffee:ff12:aff:a62b:b0ff:fef4:3a87
fe80::a62b:b0ff:fef4:3a87

Das sollte sich im Laufe des Abends dann auch in Wohlgefallen auflösen.

FYI: Die neuen VMs stehen in Hamburg, dementsprechend sehen Traces etwas anders aus:

# traceroute -m 10 -s 10.255.0.53 -4 -T www.ripe.net
traceroute to www.ripe.net (193.0.6.139), 10 hops max, 60 byte packets
 1  bgp-ham02.4830.org (193.26.120.85)  9.734 ms  9.697 ms  9.677 ms
 2  bgp-ber01.4830.org (193.26.120.86)  9.708 ms  9.690 ms  9.671 ms
 3  strato.a36.community-ix.de (185.1.74.6)  19.155 ms  19.155 ms  19.142 ms
 4  ae1.0.core-b30.as6724.net (85.214.0.66)  19.156 ms  19.499 ms  19.492 ms
 5  xe-0-0-0.0.core-ams14.as6724.net (85.214.0.62)  24.838 ms  24.824 ms  24.806 ms
 6  gw.amsix.eqix3rtr.ripe.net (80.249.208.68)  20.825 ms gw.amsix.telrtr.ripe.net (80.249.208.71)  17.442 ms gw.amsix.eqix3rtr.ripe.net (80.249.208.68)  17.680 ms
 7  www.ripe.net (193.0.6.139)  17.639 ms  18.299 ms  18.233 ms
 8  www.ripe.net (193.0.6.139)  18.197 ms  35.027 ms  34.856 ms

Ab Ende der Woche hat die Kiste weitere Internet-Zugänge, sodaß wir hoffentlich nicht mehr alles von und nach Berlin karren müssen

wusel · 21. Dezember 2018 um 20:21

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