[Berlin-wireless] f2a-core-rt GW anscheinend kaputt! Smartgateway Schuld!?
Faustus
freifunk at faust2k.net
So Mär 6 02:40:27 CET 2016
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
> >>
> >> _______________________________________________
> >> 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
> >
>
>
> _______________________________________________
> 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
--
Freifunk ist politisch.
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : signature.asc
Dateityp : application/pgp-signature
Dateigröße : 181 bytes
Beschreibung: Digital signature
URL : <https://lists.berlin.freifunk.net/pipermail/berlin/attachments/20160306/3ac69acf/attachment.sig>
Mehr Informationen über die Mailingliste Berlin