[Berlin-wireless] f2a-core-rt GW anscheinend kaputt! Smartgateway Schuld!?

Bastian fly at d00m.org
Sa Mär 5 02:35:07 CET 2016


smartgateway abschalten?

Wir prüfen ja schon auf "richtiges" announcen eines default-route HNA
dank eine reinzigen super special IP.
Aber dank policy-routing(!) und multiple routing tables, iptables und
was sonst noch wird damit keinerlei Corner-Case abgedeckt...

Wie wäre es denn mit prüfen auf working default-route/smartgw-selection?

Smart gateway selection?

On 03/05/2016 12:27 AM, Thomas Arden wrote:
> Moin;
> Habe das gleiche mit einem anderen Router hier im Pberg getestet um auch zu 
> verifizieren ob dies auch tatsächlch ein Issue von f2a-core ist:
> Router: duncker4connect.olsr
> olsrd neustart:
>  ip tun 
> tnl_0a1f3005: ip/ip  remote 10.31.48.5  local any  ttl 64  
> tunl0: ip/ip  remote any  local any  ttl inherit  nopmtudisc
> 
> ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8): 56 data bytes
> 64 bytes from 8.8.8.8: seq=0 ttl=51 time=58.552 ms
> 64 bytes from 8.8.8.8: seq=1 ttl=51 time=11.851 ms
> 64 bytes from 8.8.8.8: seq=2 ttl=51 time=14.035 ms
> ^C
> --- 8.8.8.8 ping statistics ---
> 3 packets transmitted, 3 packets received, 0% packet loss
> 
> Nach einer Weile hat er das Gateway auf
> @duncker4connect:~# ip tun
> tunl0: ip/ip  remote any  local any  ttl inherit  nopmtudisc
> tnl_0a1f022d: ip/ip  remote 10.31.2.45  local any  ttl 64
> 
> gewechselt und es ging Nix mehr.
> 
> t at duncker4connect:~# ping 8.8.8.8
> PING 8.8.8.8 (8.8.8.8): 56 data bytes
> ^C
> --- 8.8.8.8 ping statistics ---
> 7 packets transmitted, 0 packets received, 100% packet loss
> 
> 
> Am Freitag, 4. März 2016, 23:52:42 CET schrieb Thomas Arden:
>> My god;
>> habe hier Stunden damit zu gebracht:
>> habe heute hier im Pberg festgestellt dass die AP's seit einer Woche ohne
>> Gateway waren. Siehe Monitoring. Ein Neustart des olsrd half meistens nur
>> kurz bis das SMARTGAteway das Gateway wechselte. Danach ging nix mehr.
>> Habe mir Hilfe ( Mister P) geholt und mit 4 Augen konnte man sehen zuerst
>> samoa4 als Gateway fungierte und danach zu10.31.2.45 wechselte. Aber durch
>> diesen tunnel kam nix zurück...... NIX...Also gar NIX.
>>  Hier der OUTPUT:
>> #####
>> ip tun
>> tunl0: ip/ip  remote any  local any  ttl inherit  nopmtudisc
>> tnl_0a1f022d: ip/ip  remote 10.31.2.45  local any  ttl 64
>> #####
>> ip r s t olsr-tunnel
>> default dev tnl_0a1f022d  metric 2
>> #####
>> ping 8.8.8.8
>> PING 8.8.8.8 (8.8.8.8): 56 data bytes
>> ^C
>> --- 8.8.8.8 ping statistics ---
>> 7 packets transmitted, 0 packets received, 100% packet loss
>>  PLEASE FAUSTUS SCHAU MAL IN DEN TUNNEL
>>
>> CIAO Tomaggio
>>
>> Am Freitag, 4. März 2016, 01:03:27 CET schrieb Neels Hofmeyr:
>>> 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
>>
>> _______________________________________________
>> Berlin mailing list
>> Berlin at berlin.freifunk.net
>> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
>> Diese Mailingliste besitzt ein ffentlich einsehbares Archiv
> 
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> Diese Mailingliste besitzt ein ffentlich einsehbares Archiv
> 


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


Mehr Informationen über die Mailingliste Berlin