[Berlin-wireless] f2a-core-rt GW anscheinend kaputt! Smartgateway Schuld!?
Bastian
fly at d00m.org
Sa Mär 12 13:55:06 CET 2016
*bump*
f2a-core-rt ist momentan wieder blackhole.
Nicht nur Internet, sondern auch reiner Mesh-Traffic im BBB (F'hain
<->Pankow)
root at Zwingli-Core:~# traceroute 10.31.13.1
traceroute to 10.31.13.1 (10.31.13.1), 30 hops max, 38 byte packets
1 mid7.f2a-core-rt.olsr (10.31.2.37) 0.938 ms 1.309 ms 3.381 ms
2 mid7.f2a-core-rt.olsr (10.31.2.37) 0.878 ms 1.005 ms 0.852 ms
root at JUP-core:~# traceroute 10.31.10.1
traceroute to 10.31.10.1 (10.31.10.1), 30 hops max, 38 byte packets
1 mid1.JUP-beam.olsr (10.31.13.4) 0.337 ms 0.282 ms 0.200 ms
2 mid3.segen-core.olsr (10.31.6.33) 30.690 ms 1.422 ms 3.222 ms
3 f2a-core-rt.olsr (10.31.2.45) 2.564 ms 2.717 ms 3.074 ms
4 f2a-core-rt.olsr (10.31.2.45) 4.328 ms 3.194 ms 2.076 ms
Cheers, Bastian
On 03/08/2016 08:06 PM, Faustus wrote:
> Tja - dass ein reboot selten Probleme löst ist klar. Aber dass
> es nun nichtmal 24h gehalten hat, erstaunt mich nun schon - heute
> wieder das selbe Problem.
>
> Ein init.d/olsrd restart reicht nicht aus! Erst nach einem reboot
> rollt der Tunnel wieder.
>
> Ideen? Ggf. wechsel ich mal die Firmware/OLSR Version auf blöd.
>
> Wer sich das Problem vorort ansehen möchte ist natürlich dazu
> eingeladen -> einfach SSH Key mitteilen.
>
> Lg
> Faustus
>
>
> On Sun, Mar 06, 2016 at 02:40:27AM +0100, Faustus wrote:
>> Ja, SmartGW war schuld... :-(
>>
>> Ich hab letzte Nacht den f2a-core-rt neugestartet, zumindest von
>> d81-sued-2ghz läuft der Tunnel nun wieder.
>>
>> @Neels: sorry, ich hatte in meiner ersten Mail nur von Standorten
>> gecheckt bei den SmartGW schon abgeschaltet war. Hab ich erst
>> danach gemerkt.
>>
>> Es ist schon seltsam, mein Core ist relativ einfach konfiguriert:
>> keine Firewall, kein Policyrouting, statische IP+Gateway auf dem
>> "WAN"-Interface. Den Gateway hat er hin und wieder vergessen,
>> warum auch immer. Das hab ich aber mittlerweile in Griff bekommen
>> mit einem Hotplug-Script in /etc/hotplug.d/iface/ das bei
>> ifdown/ifup den GW nochmal setzt.
>>
>> Keine Ahnung also warum der Tunnel plötzlich aussetzte. Hier
>> läuft Kathleen 0.2.0 mit OLSR 0.9.0.3... werd mir das nächste mal
>> mehr Zeit nehmen für die Fehlersuche...
>>
>> Und ja - ich fände es super genial, wenn es eine simple
>> Möglichkeit gäbe einen Satz von SmartGWs/ipip-Tunnel einfach im
>> Frontend zu "pinnen", die dann nach Verfügbarkeit und Priorität
>> vorzugsweise benutzt werden. Auf meinem
>> "produktiv-bastel-Debian-DSL-Router" klappt das ja prima, wenn
>> auch etwas gefrickelt: kleiner Cronjob checkt sehr regelmäßig
>> mehrere Tunnel/Gateways (ping $remote+8.8.8.8). Funzt das, wird
>> neben dem default DSL-Gateway (metric 1) der Tunnel als weiterer,
>> Fallback-Gateway (metric >1) angelegt, in meinem Fall also zu
>> l9-core, wg1337...
>>
>> Und da bspw. L9 in Pberg mit 100/12 MBits nen super Uplink bietet
>> und mein Freifunk dorthin richtig performant ist, macht es schon
>> fast Spass wenn Telekom VDSL 50/10 in Fhain mal wieder aussetzt
>> -> Internet ist dann schneller. :-P
>>
>> Deswegen kann Freifunka auch SmartGW mögen... ;-)
>>
>> Lg
>> Faustus
>>
>>
>> On Sat, Mar 05, 2016 at 02:35:07AM +0100, Bastian wrote:
>>> 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
>>>>>
-------------- 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/20160312/8e36e7ab/attachment.sig>
Mehr Informationen über die Mailingliste Berlin