Moin. Moin.
Hier haben wir heute ein instabiles Netz.
Mal ist „Internet“ mal ist kein „Internet“.
IP-Adressen werden aus meiner Sicht aber verteilt.
Gruß
Matthias
Moin,
[m.bitterlich] m.bitterlich https://forum.freifunk-kreisgt.de/u/m.bitterlich Matthias Bitterlich
13. JuliMoin. Moin.
Hier haben wir heute ein instabiles Netz.Mal ist „Internet“ mal ist kein „Internet“.
IP-Adressen werden aus meiner Sicht aber verteilt.
Schneller Blick auf die üblichen Verdächtigen zeigt Probleme auf unserem Server in Berlin:
»Außenrum« (OOB-Zugang):
My traceroute [v0.92]
luggage (10.0.118.141) 2022-07-13T14:11:34+0200
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
[…]
7. de-bfe18a-rt01-lag-1.aorta.net 0.1% 4417 15.4 18.2 11.0 135.5 8.4
8. 145.254.2.51 68.9% 4417 33.4 32.6 23.7 114.3 10.6
9. 145.254.2.51 68.1% 4417 32.3 31.7 23.4 130.6 10.8
10. bcix.gw-ak-1.in-berlin.de 0.0% 4417 31.1 32.4 25.1 83.7 6.4
11. blackstar.in-berlin.de 0.4% 4417 32.1 30.7 23.8 162.0 6.6
»Normal« (AS206813):
My traceroute [v0.92]
luggage (10.0.118.141) 2022-07-13T14:11:36+0200
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
[…]
5. de-bfe18a-rd04-ae-0-0.aorta.net 0.0% 4420 19.2 18.8 10.5 94.9 7.5
6. de-fra01b-rc2-ae-65-0.aorta.net 0.1% 4420 21.1 18.6 11.2 69.8 5.7
7. 84.116.190.134 0.0% 4420 17.1 18.0 10.6 156.8 7.7
8. de-cix1.rt.act.fkt.de.retn.net 0.0% 4420 16.9 19.9 10.7 82.7 8.0
9. ae0-5.RT.IPB.BER.DE.retn.net 0.1% 4420 25.9 27.3 18.6 104.9 8.2
10. blackstar.4830.org 15.3% 4419 105.1 93.4 20.9 287.5 21.6
Grafisch auch »schön« zu sehen im Smokeping aus Berlin (http://transit.blackstar.4830.org/smokeping/?target=CIX.rs2_w19_community-ix_de):
Seit Montag »spinnt« schein’s unsere 10G-Anbindung bzw. der Treiber der 10G-Karte wieder. Ersatz ist schon in Berlin, der Hardwareumbau muß aber noch erfolgen.
Ich habe jetzt l2tp-ber01.4830.org ausgeschaltet, die Knoten sollten sich auf die verbliebenen Gateways verteilen. Heute abend ggf. Reboot des Servers/Routers.
HTH,
-kai
ich klemm mich hier mal mit ran:
in feldberg läuft es seit vorgestern auch nicht so rund. verbindungen laufen jetzt über l2tp-fra01.4830.org, aber brechen scheinbar zwischendurch immer wieder ab. (ich weiß nicht wie aussagekräftig der TQ wert auf der web.statusseite der clients ist: für 02:ca:ff:ee:06:10 sind hier vor ort die werte zw 7-14%)
Hrm, das ist jetzt nicht so schön zu hören. Eigentlich sollte seit Donnerstag morgen das Problem weg sein, für Berlin wie auch Frankfurt:
Der Reboot hat das Problem in BER nicht gelöst — allerdings verschwanden schon in der Vorbereitung – shutdown der VMs vor dem Reboot – die Netzwerkprobleme:
In der Folge konnte ich feststellen, daß der Start der neuen 4 GWs (auf Basis Debian 10 mit Kernel 5.10.0-0.bpo.12-cloud-amd64) diese Probleme hervorruft, der Stopp dieses Problem wieder behebt. Duh.
l2tp-ber01 und -ber02 wurden dann auf die neuen IP-Adressen umgezogen und diese Änderung auch im DNS hinterlegt — allerdings, Untersuchung steht noch aus, scheint der Tunneldigger-Client auf den Knoten nicht allzuhäufig nach dem Start den DNS neu zu befragen 
Sprich: einige Knoten, die auf diesen Gateways hingen, blieben offline, faktisch hat sich bislang kein Knoten z. B. zu l2tp-ber01 unter der neuen IP verirrt
root@l2tp-ber01 ~ # brctl show
bridge name bridge id STP enabled interfaces
br01 8000.02caffee0104 no
br02 8000.02caffee0204 no
br03 8000.02caffee0304 no
br04 8000.02caffee0404 no
br05 8000.02caffee0504 no
br06 8000.02caffee0604 no
br09 8000.02caffee0904 no
Checkskript sagt aber alles ok:
OK - All Bridges and Tunneldiggers found
OK - All Bridges and Tunneldiggers found
OK - All Bridges and Tunneldiggers found
OK - All Bridges and Tunneldiggers found
OK - All Bridges and Tunneldiggers found
OK - All Bridges and Tunneldiggers found
OK - All Bridges and Tunneldiggers found
Alles etwas mysteriös, aber das ist ein anderes Thema.
Hmm, l2tp-fra01 ist eigentlich eher unterlastet:
root@l2tp-fra01 ~ # brctl show
bridge name bridge id STP enabled interfaces
br01 8000.02caffee0110 no l2tp2968-2968
l2tp2970-2970
br02 8000.02caffee0210 no l2tp34-34
l2tp61-61
br03 8000.02caffee0310 no
br04 8000.02caffee0410 no l2tp4128-4128
l2tp4129-4129
br05 8000.02caffee0510 no l2tp5295-5295
l2tp5296-5296
br06 8000.02caffee0610 no l2tp3610-3610
l2tp3633-3633
l2tp3634-3634
l2tp3635-3635
l2tp3636-3636
l2tp3637-3637
Ich guck’ mir das am Wochenende aber eh’ alles nochmal genauer an …
noch ein paar logs vom router hier neben mir (17258-Gutshof)
➜ ~ traceroute g01m06.4830.org
traceroute to g01m06.4830.org (193.26.120.227), 30 hops max, 60 byte packets
1 _gateway (192.168.178.1) 0.355 ms 0.403 ms 0.504 ms
2 p3e9bf098.dip0.t-ipconnect.de (62.155.240.152) 9.631 ms 9.620 ms 10.277 ms
3 b-eh2-i.B.DE.NET.DTAG.DE (217.5.87.126) 13.763 ms 14.030 ms 14.021 ms
4 b-eh2-i.B.DE.NET.DTAG.DE (217.5.87.126) 13.328 ms 13.065 ms 13.308 ms
5 bgp-ber01.4830.org (193.26.120.86) 12.405 ms 12.129 ms 12.387 ms
6 bgp-ham02.4830.org (193.26.120.85) 22.091 ms 21.918 ms 21.886 ms
7 bgp-fra01.4830.org (193.26.120.81) 21.241 ms 19.552 ms 20.173 ms
8 l2tp-fra01.4830.org (193.26.120.227) 20.971 ms 20.738 ms 21.243 ms
➜ ~ traceroute g02m06.4830.org
traceroute to g02m06.4830.org (194.113.54.71), 30 hops max, 60 byte packets
1 _gateway (192.168.178.1) 0.281 ms 0.531 ms 0.521 ms
2 p3e9bf098.dip0.t-ipconnect.de (62.155.240.152) 9.102 ms 9.257 ms 9.240 ms
3 pd900cd12.dip0.t-ipconnect.de (217.0.205.18) 12.862 ms 12.845 ms 12.828 ms
4 fflip-ber01.freifunk-lippe.de (194.113.54.1) 11.938 ms 11.919 ms 12.461 ms
5 bgp-ber01.4830.org (193.26.120.86) 12.156 ms 12.139 ms 12.122 ms
6 bgp-ber01.4830.org (193.26.120.86) 2889.418 ms !H 2889.142 ms !H 2889.213 ms !H
logread:
Danke!
Ja, das sollte demnächst der Vergangenheit angehören durch das direkte Netz in FRA:
root@smoke-td:~# traceroute 193.26.120.227
traceroute to 193.26.120.227 (193.26.120.227), 30 hops max, 60 byte packets
1 fritz.box (192.168.177.1) 0.567 ms 0.649 ms 0.688 ms
2 p3e9bf2e7.dip0.t-ipconnect.de (62.155.242.231) 8.966 ms 8.913 ms 8.870 ms
3 pd900cd66.dip0.t-ipconnect.de (217.0.205.102) 1430.212 ms 1430.393 ms 1430.364 ms
4 bgp-ber01.4830.org (193.26.120.86) 13.744 ms 14.117 ms 14.061 ms
5 bgp-ham02.4830.org (193.26.120.85) 24.712 ms 24.891 ms 24.858 ms
6 bgp-fra01.4830.org (193.26.120.81) 28.011 ms 24.295 ms 24.928 ms
7 l2tp-fra01.4830.org (193.26.120.227) 26.410 ms 24.410 ms 25.281 ms
root@smoke-td:~# traceroute 194.113.55.65
traceroute to 194.113.55.65 (194.113.55.65), 30 hops max, 60 byte packets
1 fritz.box (192.168.177.1) 0.913 ms 1.001 ms 1.434 ms
2 p3e9bf2e7.dip0.t-ipconnect.de (62.155.242.231) 13.000 ms 12.937 ms 13.083 ms
3 217.5.116.86 (217.5.116.86) 818.395 ms 818.375 ms 818.339 ms
4 80.156.161.186 (80.156.161.186) 19.481 ms 19.454 ms 19.519 ms
5 194.113.55.65 (194.113.55.65) 22.943 ms 23.510 ms 23.484 ms
Allerdings sollte es auch nicht BER01-HAM02-FRA01 laufen … Autsch!
root@blackstar ~ # birdc show proto | egrep 'BGP|OSPF' | grep i_
i_dus01 BGP ffnet start 2022-07-14 Active Socket: Connection closed
i_fra01 BGP ffnet start 2022-07-14 Active Socket: Connection reset by peer
i_ham02 BGP ffnet up 2022-07-14 Established
i_ham03 BGP ffnet up 2022-07-14 Established
i_ham04 BGP ffnet up 2022-07-14 Established
WTF‽ Mist, da fehlte der Link BER01-FRA01, sowohl im iBGP als auch im OSPF; war irgendwie auskommentiert in Frankfurt
Fixed:
root@smoke-td:~# traceroute 193.26.120.227
traceroute to 193.26.120.227 (193.26.120.227), 30 hops max, 60 byte packets
1 fritz.box (192.168.177.1) 0.759 ms 1.030 ms 1.100 ms
2 p3e9bf2e7.dip0.t-ipconnect.de (62.155.242.231) 10.320 ms 10.305 ms 10.268 ms
3 pd900cd66.dip0.t-ipconnect.de (217.0.205.102) 18.495 ms 18.476 ms 18.438 ms
4 bgp-ber01.4830.org (193.26.120.86) 15.348 ms 15.333 ms 15.391 ms
5 bgp-fra01.4830.org (193.26.120.81) 25.513 ms 25.597 ms 25.577 ms
6 l2tp-fra01.4830.org (193.26.120.227) 26.497 ms 22.550 ms 23.118 ms
Sollte aber nur bedingt zu Performanceproblemen geführt haben; vorher (BER01-HAM02-FRA01):
root@smoke-td:~# iperf3 -c 193.26.120.227
Connecting to host 193.26.120.227, port 5201
[ 4] local 192.168.177.10 port 47062 connected to 193.26.120.227 port 5201
[…]
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 49.7 MBytes 41.7 Mbits/sec 52 sender
[ 4] 0.00-10.00 sec 46.5 MBytes 39.0 Mbits/sec receiver
iperf Done.
root@smoke-td:~# iperf3 -c 193.26.120.227 -R
Connecting to host 193.26.120.227, port 5201
Reverse mode, remote host 193.26.120.227 is sending
[ 4] local 192.168.177.10 port 47066 connected to 193.26.120.227 port 5201
[…]
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 123 MBytes 103 Mbits/sec 91 sender
[ 4] 0.00-10.00 sec 121 MBytes 102 Mbits/sec receiver
iperf Done.
Nachher (BER01-FRA01):
root@smoke-td:~# iperf3 -c 193.26.120.227
Connecting to host 193.26.120.227, port 5201
[ 4] local 192.168.177.10 port 47190 connected to 193.26.120.227 port 5201
[…]
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 48.4 MBytes 40.6 Mbits/sec 50 sender
[ 4] 0.00-10.00 sec 45.6 MBytes 38.2 Mbits/sec receiver
iperf Done.
root@smoke-td:~# iperf3 -c 193.26.120.227 -R
Connecting to host 193.26.120.227, port 5201
Reverse mode, remote host 193.26.120.227 is sending
[ 4] local 192.168.177.10 port 47198 connected to 193.26.120.227 port 5201
[…]
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 124 MBytes 104 Mbits/sec 108 sender
[ 4] 0.00-10.00 sec 122 MBytes 102 Mbits/sec receiver
iperf Done.
Gut, tagsüber kann das anders sein, wenn der Link in Hamburg auch mehr belastet ist … Anyway, should be fixed, danke!
Das ist soweit korrekt, als daß ich l2tp-ber01 und 02 runtergefahren hatte und vorhin wieder mit der alten IP neu gestartet:
Sollte jetzt wieder unter der alten Adresse erreichbar sein und benutzt werden:
wusel@cohen:~$ host g02m06.4830.org
g02m06.4830.org is an alias for l2tp-ber01.4830.org.
l2tp-ber01.4830.org has address 193.26.120.99
Merkwürdig finde ich die Meldungen in Deinem Paste:
Sun Jul 17 20:37:21 2022 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Sun Jul 17 20:37:27 2022 daemon.info td-client: Performing broker selection...
Sun Jul 17 20:37:28 2022 daemon.err td-client: Failed to connect to remote endpoint - check WAN connectivity!
Sun Jul 17 20:37:28 2022 daemon.err td-client: Failed to connect to remote endpoint - check WAN connectivity!
Sun Jul 17 20:37:28 2022 daemon.info td-client: Reinitializing tunnel context.
Sun Jul 17 20:37:28 2022 daemon.debug td-client: Broker usage of g01m06.4830.org:10006: 192
Ah, ok, für Mesh 06 sind aktuell nur 2 GWs deployed:
wusel@cohen:~$ host g01m06.4830.org
g01m06.4830.org is an alias for l2tp-fra01.4830.org.
l2tp-fra01.4830.org has address 193.26.120.227
l2tp-fra01.4830.org has IPv6 address 2a06:e881:1707:1:400:c1ff:fe1a:78e3
wusel@cohen:~$ host g02m06.4830.org
g02m06.4830.org is an alias for l2tp-ber01.4830.org.
l2tp-ber01.4830.org has address 193.26.120.99
l2tp-ber01.4830.org has IPv6 address 2a06:e881:1706:1:400:c1ff:fe1a:7863
wusel@cohen:~$ host g03m06.4830.org
g03m06.4830.org is an alias for no-gw-yet.4830.org.
no-gw-yet.4830.org has address 127.0.0.1
wusel@cohen:~$ host g04m06.4830.org
g04m06.4830.org is an alias for no-gw-yet.4830.org.
no-gw-yet.4830.org has address 127.0.0.1
Dennoch hättest Du g01m06 aka l2tp-fra01 doch erreichen können müssen? Aber das Tunneldigger-Thema bekommt einen separaten Threads, das hat wenig/nichts mit Routing/Performance zu tun.
ich hatte zwischendurch g01m06 testweise aus den gateways für tunneldigger entfernt, um eine verbindung zu g02m06 / l2tp-ber zu erzwingen: dann wurde aber leider gar keine verbindung aufgebaut
Ah, dumm gelaufen, ich hatte l2tp-ber01 ja deaktiviert, Du l2tp-fra01 aus der Verteilung genommen, und Feldberg hat aktuell nur 2 GWs konfiguriert => damit ist das geklärt.
via ipv4 ja, aber nicht ipv6.
root@17258-Gutshof:~# ping l2tp-ber01.4830.org
PING l2tp-ber01.4830.org (2a06:e881:1706:1:400:c1ff:fe1a:7863): 56 data bytes
^C
--- l2tp-ber01.4830.org ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
root@17258-Gutshof:~# ping -4 l2tp-ber01.4830.org
PING l2tp-ber01.4830.org (193.26.120.99): 56 data bytes
64 bytes from 193.26.120.99: seq=0 ttl=60 time=11.436 ms
64 bytes from 193.26.120.99: seq=1 ttl=60 time=11.122 ms
^C
--- l2tp-ber01.4830.org ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 11.122/11.279/11.436 ms
und die knoten wollen scheinbar (auch mit biegen&brechen) keine verbindung zu l2tp-ber01 / g02m06.4830.org aufbauen
Falsches /64 bei ber01 im DNS, fixed. Aber für Tunneldigger irrelevant.