[Berlin-wireless] f2a-core-rt GW anscheinend kaputt

Neels Hofmeyr neels at hofmeyr.de
Fr Mär 4 01:03:27 CET 2016


On Thu, Mar 03, 2016 at 08:10:22PM +0100, Faustus wrote:
> Eigenartig. Die 10.31.2.45 ist das Interface in Richtung
> Segenskirche auf f2a-core - von der Segen aus betrachtet sieht
> aber alles prima aus:
> 
> root at segen-core:~# mtr -r -c1 8.8.8.8
> Start: Thu Mar  3 19:53:24 2016
> HOST: segen-core                  Loss%   Snt   Last   Avg  Best  Wrst StDev
>   1.|-- 10.31.2.45                 0.0%     1    1.0   1.0   1.0   1.0   0.0
>   2.|-- 10.31.2.2                  0.0%     1    1.6   1.6   1.6   1.6   0.0
>   3.|-- 217.5.98.18                0.0%     1   22.5  22.5  22.5  22.5   0.0
>   4.|-- 217.237.153.6              0.0%     1   21.9  21.9  21.9  21.9   0.0
>   5.|-- 80.150.170.98              0.0%     1   35.3  35.3  35.3  35.3   0.0
>   6.|-- 72.14.233.114              0.0%     1   27.9  27.9  27.9  27.9   0.0
>   7.|-- google-public-dns-a.googl  0.0%     1   27.6  27.6  27.6  27.6   0.0
> root at segen-core:~# 
> 
> Auch das Rathaus Neukölln und Martin Luther werfen hier gerade
> Traffic ab - die letzten Tage waren das immer ~150 GB/Tag.
> 
> Vielleicht ein temporärer Schluckauf?


Hmm. Das geht jetzt schon seit ca. einer Woche so, und ich habe 6 router
die dasselbe Problem unabhängig voneinander zeigen.

Zwei von denen sind mit M5 am rhnk angebunden, und vier via emma.

Ich bin ziemlich sicher dass ich nicht auf allen sechs was kaputtgemacht hab,
und da die verschieden funken und alle dasselbe Problem zeigen rätselt es mich
dass es von woanders geht...

Einer davon ist ein ArcherC5 und die anderen sind alles WR841N; alle
laufen mit backbone image, die WR841Ns mit dem 4mb-backbone image.

Wenn ich die tunnel route lösche und das netz geht, dann geht der traffic
interessanterweise trotzdem durch f2a (siehe traceroute unten) aber halt nicht
durch den tunnel.

Also der f2a traffic geht, nur der tunnel failt. Weiß jemand warum der tunnel
failen könnte?? Wie kann ich eigentlich den tunnel analysieren, gibts da kluge
methoden?

Das Netz durch den tunnel geht problemlos sobald der smartgw irgendein anderes
gw außer eben 10.31.2.45 auswählt. Scheint also doch irgendwie mit dem f2a
tunnel "ausgang" zu tun zu haben.

(v6 ist von alldem natürlich gänzlich unbeeindruckt und läuft einfach.)

Ein paar details...
Wenn f2a als smartgw ausgewählt ist sieht's so aus:


root at archie:~# ip r show table olsr-tunnel
default dev tnl_0a1f022d  metric 2 

root at archie:~# traceroute 10.31.2.45
traceroute to 10.31.2.45 (10.31.2.45), 30 hops max, 38 byte packets
 1  mid13.rhnk-core.olsr (10.230.3.10)  1.130 ms  0.871 ms  1.054 ms
 2  f2a-core-rt.olsr (10.31.2.45)  8.346 ms  5.325 ms  5.012 ms

root at archie:~# traceroute freifunk.net
traceroute to freifunk.net (176.28.11.93), 30 hops max, 38 byte packets
 1  *  *  *
 2  *  *  *
 3  *  *  *
 4^C

root at archie:~# ping freifunk.net
PING freifunk.net (176.28.11.93): 56 data bytes
<idle idle idle>
^C
--- freifunk.net ping statistics ---
29 packets transmitted, 0 packets received, 100% packet loss




Wenn ich dann die route lösche siehts so aus:


root at archie:~# ip r del default dev tnl_0a1f022d metric 2 table olsr-tunnel
root at archie:~# ip r show table olsr-tunnel
<nix>

root at archie:~# traceroute 10.31.2.45
traceroute to 10.31.2.45 (10.31.2.45), 30 hops max, 38 byte packets
 1  mid13.rhnk-core.olsr (10.230.3.10)  1.257 ms  1.824 ms  1.873 ms
 2  f2a-core-rt.olsr (10.31.2.45)  2.488 ms  2.505 ms  3.761 ms

root at archie:~# traceroute freifunk.net
traceroute to freifunk.net (176.28.11.93), 30 hops max, 38 byte packets
 1  mid13.rhnk-core.olsr (10.230.3.10)  0.926 ms  1.693 ms  1.104 ms
 2  mid4.f2a-core-rt.olsr (10.31.2.33)  6.303 ms  6.583 ms  4.607 ms
 3  10.31.2.2 (10.31.2.2)  7.036 ms  8.824 ms  6.968 ms
 4  217.5.98.18 (217.5.98.18)  25.047 ms  26.685 ms  26.094 ms
 5  217.237.153.6 (217.237.153.6)  30.791 ms  29.298 ms  30.614 ms
 6  d-ed1-i.D.DE.NET.DTAG.DE (62.154.15.230)  30.985 ms  217.239.50.86 (217.239.50.86)  31.488 ms  d-ed1-i.D.DE.NET.DTAG.DE (62.154.15.226)  31.304 ms
 7  62.157.250.114 (62.157.250.114)  32.677 ms  42.532 ms  35.534 ms
 8  xe-0-3-0.dr-master.r2.cgn3.he-core.de (176.28.4.54)  33.736 ms  39.165 ms  86.440 ms
 9  *  *  *
10  lvps176-28-11-93.dedicated.hosteurope.de (176.28.11.93)  50.358 ms  37.433 ms  37.115 ms

root at archie:~# ping freifunk.net
PING freifunk.net (176.28.11.93): 56 data bytes
64 bytes from 176.28.11.93: seq=0 ttl=55 time=41.508 ms
64 bytes from 176.28.11.93: seq=1 ttl=55 time=42.981 ms
64 bytes from 176.28.11.93: seq=2 ttl=55 time=31.535 ms
64 bytes from 176.28.11.93: seq=3 ttl=55 time=29.499 ms
64 bytes from 176.28.11.93: seq=4 ttl=55 time=35.311 ms
64 bytes from 176.28.11.93: seq=5 ttl=55 time=32.603 ms
64 bytes from 176.28.11.93: seq=6 ttl=55 time=40.650 ms
64 bytes from 176.28.11.93: seq=7 ttl=55 time=36.346 ms
^C
--- freifunk.net ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max = 29.499/36.304/42.981 ms


Wenn ich noch irgendwelche commands oder logs checken kann immer her mit
den kommandozeilen...

~Neels

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: Digital signature
URL         : <https://lists.berlin.freifunk.net/pipermail/berlin/attachments/20160304/a8e6abbe/attachment.sig>


Mehr Informationen über die Mailingliste Berlin