[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