[Berlin-wireless] conntrack auf icvpn02 voll
Philipp Borgers
borgers at mi.fu-berlin.de
So Feb 21 23:01:27 CET 2016
nf_conntrack_ipv4 in /etc/modules ist ev. sauberer. Wollte ich demnächst mal bei
den VPN03s umbauen. Mit erfunden hats der Lars [1].
Gruß Philipp
[1] https://forum.freifunk.net/t/admin-tagebuch-moehne/7292/52?u=booo
On Sun, Feb 21, 2016 at 10:55:17PM +0100, Bastian wrote:
> Danke! steht jetzt in der /etc/rc.local
>
> On 02/21/2016 10:49 PM, Philipp Borgers wrote:
> > Entweder rufst du nach dem Booten nochmal sysctl --system auf oder du lädst die
> > entsprechenden Kernel-Module vor dem Start des Init-Scripts.
> >
> > On Sun, Feb 21, 2016 at 10:38:00PM +0100, Bastian wrote:
> >> Nachtrag:
> >>
> >> icvpn02:~$ cat /etc/sysctl.d/20-better-NAT-performance.conf
> >> net.netfilter.nf_conntrack_generic_timeout = 120
> >> net.netfilter.nf_conntrack_max = 131072
> >> net.netfilter.nf_conntrack_tcp_timeout_established = 120
> >> net.nf_conntrack_max = 131072
> >>
> >> Das sind die Settings, die eigentlich bisher aktiv sein sollten.
> >> icvpn02:~$ uptime
> >> 22:36:14 up 5 days, 3:34, 3 users, load average: 0.17, 0.16, 0.16
> >>
> >> Wenn ich mir den RRD-Graphen dazu so angucke scheinen die sysctl file
> >> beim reboot nicht sauber eingesetzt zu werden :/
> >>
> >> On 02/21/2016 10:29 PM, Bastian wrote:
> >>> Hallo,
> >>>
> >>> da hat wohl wieder die conntrack table auf icvpn02 zugeschlagen:
> >>> http://monitor.berlin.freifunk.net/detail.php?p=conntrack&t=conntrack&h=icvpn02.berlin.freifunk.net&s=604800&x=800&y=350
> >>>
> >>> Ich hab die limits weiter angehoben und jetzt tut das erstmal wieder.
> >>> Auf Dauer muss da aber eine saubere Loesung her.
> >>>
> >>> @VPN03 Admins:
> >>>
> >>> Sind eure conntrack settings irgendwo public? Ihr hab da doch sicher
> >>> reichlich Erfahrung.
> >>>
> >>> Cheers, Bastian
> >>>
> >>> On 02/21/2016 09:57 PM, Fischkeks wrote:
> >>>> Guten Abend.
> >>>>
> >>>> Augenblicklich ist das Internet über das Freifunknetz von meinem Router
> >>>> aus fast nicht mehr benutzbar. Es braucht Minuten, bis eine angeforderte
> >>>> Webseite sich aufbaut. Gleiches Setup funktionierte vorher Monate
> >>>> tadellos. Nichts verändert und mit verschiedenen Geräten das selbe
> >>>> Phänomen. Testdownload von 2001:bf7:830:1102::1 sehr gut.
> >>>>
> >>>> traceroute to 2001:67c:1562::14 (2001:67c:1562::14) from
> >>>> 2001:bf7:830:201:5456:fc3a:fc3b:12bb, 30 hops max, 24 byte packets
> >>>> 1 2001:bf7:830:201::1 (2001:bf7:830:201::1) 0.419 ms 0.539 ms 0.369 ms
> >>>> 2 2001:bf7:830:1102::1 (2001:bf7:830:1102::1) 1.403 ms 1.209 ms
> >>>> 1.105 ms
> >>>> 3 icvpn02.olsr (2001:bf7:750:1530::2) 5.03 ms 3.867 ms 2.332 ms
> >>>> 4 2001:bf7:b201::1 (2001:bf7:b201::1) 2.312 ms 3.778 ms 2.559 ms
> >>>> 5 * 2001:7f8:19:1::aca2:2 (2001:7f8:19:1::aca2:2) 28.664 ms *
> >>>> 6 * 2a00:13c8:2:1:: (2a00:13c8:2:1::) 4.729 ms 50.1 ms
> >>>> 7 * 2a00:13c8:10:b:: (2a00:13c8:10:b::) 93.204 ms *
> >>>> 8 * * *
> >>>> 9 * * 2001:1900:107:1::8 (2001:1900:107:1::8) 14.903 ms
> >>>> 10 2001:1900:5:1::22d (2001:1900:5:1::22d) 24.348 ms * 155.899 ms
> >>>> 11 2001:1900:5:1::211 (2001:1900:5:1::211) 20.787 ms 20.79 ms 18.997 ms
> >>>> 12 2001:1900:104:8::a (2001:1900:104:8::a) 21.355 ms 21.322 ms 19.605 ms
> >>>> 13 2001:978:3::161 (2001:978:3::161) 21.552 ms 22.375 ms 21.481 ms
> >>>> 14 2001:550:0:1000::8275:d (2001:550:0:1000::8275:d) 20.168 ms 20.545
> >>>> ms 20.856 ms
> >>>> 15 * * *
> >>>> 16 * * *
> >>>> 17 2001:550:0:1000::9a36:3a45 (2001:550:0:1000::9a36:3a45) 38.725 ms
> >>>> 39.2 ms 44.576 ms
> >>>> 18 2001:550:0:1000::9a36:2ca5 (2001:550:0:1000::9a36:2ca5) 119.444 ms
> >>>> 102.128 ms 102.896 ms
> >>>> 19 2001:550:2:2c::15:2 (2001:550:2:2c::15:2) 103.228 ms 103.436 ms
> >>>> 101.798 ms
> >>>> 20 orobas.canonical.com (2001:67c:1562::14) 101.372 ms 101.809 ms
> >>>> 102.294 ms
> >>>>
> >>>>
> >>>> traceroute spiegel.de
> >>>> spiegel.de: Der Name oder der Dienst ist nicht bekannt
> >>>> Cannot handle "host" cmdline arg `spiegel.de' on position 1 (argc 1)
> >>>>
> >>>> traceroute spiegel.de
> >>>> traceroute to spiegel.de (62.138.116.3), 30 hops max, 60 byte packets
> >>>> 1 Desmond.olsr (10.230.109.65) 0.298 ms 0.329 ms 0.374 ms
> >>>> 2 mid11.rhxb-rt1.olsr (10.31.1.42) 1.870 ms 1.905 ms 2.481 ms
> >>>> 3 * * *
> >>>> 4 * * *
> >>>> 5 * * *
> >>>> 6 * * *
> >>>> 7 * * *
> >>>> 8 * * *
> >>>> 9 * * *
> >>>> 10 * * *
> >>>> 11 * * *
> >>>> 12 * * *
> >>>> 13 * * *
> >>>> 14 * * *
> >>>> 15 * * *
> >>>> 16 * * *
> >>>> 17 * * *
> >>>> 18 * * *
> >>>> 19 * * *
> >>>> 20 * * *
> >>>> 21 * * *
> >>>> 22 * * *
> >>>> 23 * * *
> >>>> 24 * * *
> >>>> 25 * * *
> >>>> 26 * * *
> >>>> 27 * * *
> >>>> 28 * * *
> >>>> 29 * * *
> >>>> 30 * * *
> >>>>
> >>>>
> >>>> Ich hoffe die Mail geht über Freifunk überhaupt raus.
> >>>> Gruß Fischkeks
> >>>>
> >>>>
> >>>>
> >>>> Am 21.02.2016 um 09:54 schrieb Bastian:
> >>>>> Hallo Fischkeks,
> >>>>>
> >>>>> IPv6 ist bei uns immer faul, das ist nichts neues. Aber zumindest das
> >>>>> von dir genannte Ziel funktioniert von der Zwingli aus...
> >>>>>
> >>>>> root at Zwingli-Core:~# ping6 2001:67c:1562::14
> >>>>> PING 2001:67c:1562::14 (2001:67c:1562::14): 56 data bytes
> >>>>> 64 bytes from 2001:67c:1562::14: seq=0 ttl=49 time=119.672 ms
> >>>>> 64 bytes from 2001:67c:1562::14: seq=1 ttl=49 time=119.552 ms
> >>>>>
> >>>>> Kannst du mal einen traceroute6/mtr von deiner workstation aus posten?
> >>>>>
> >>>>>
> >>>>> Was du vorhin beschrieben hast war kein konkretes "Problem mit 104er
> >>>>> IPs". Wir beziehen inzwischen auch Upstream vom FFRL, der wiederum
> >>>>> bilaterales Transit-Peering mit Hamburg hat. Hamburg hat uns aber in der
> >>>>> Kette vergessen, und deswegen gab es da eine Lücke im Internet...
> >>>>>
> >>>>> Cheers,
> >>>>> Bastian
> >>>>>
> >>>>> On 02/20/2016 03:28 PM, 100.78090 at germanynet.de wrote:
> >>>>>> Vielen Dank, dass Windows und Apple Updates wieder gehen, allerdings scheint zudem noch etwas mit ipv6 faul zu sein.
> >>>>>>
> >>>>>> Von meinem Freifunkrechner bekomme ich keine Antwort auf einen traceroute to 2001:67c:1562::14
> >>>>>> Vom http://www.subnetonline.com/pages/ipv6-network-tools/online-ipv6-traceroute.php geht das ganz hervorragend. Hängt das mit dem anderen Problem zusammen? Hey Basti, was genau war nun eigentlich das Problem mit den 104er-Adressen?
> >>>>>>
> >>>>>> Beste Grüße
> >>>>>> Fischkeks
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ----- Original Nachricht ----
> >>>>>> Von: Bastian <fly at d00m.org>
> >>>>>> An: berlin at berlin.freifunk.net
> >>>>>> Datum: 19.02.2016 11:04
> >>>>>> Betreff: Re: [Berlin-wireless] 104er Adressen machens mir schwer
> >>>>>>
> >>>>>>> Dank Leo in Hamburg sollten routen via FFHH nun sauber funktionieren!
> >>>>>>>
> >>>>>>>
> >>>>>>> On 02/19/2016 10:16 AM, Bastian wrote:
> >>>>>>>> Hallo,
> >>>>>>>>
> >>>>>>>> das scheint kein Problem im OLSR zu sein:
> >>>>>>>>
> >>>>>>>> 1. bgp02.berlin.freifunk.net <- wir (IPB)
> >>>>>>>> 2. freifunk-a36s.bcix.de <- wir (Speedbone)
> >>>>>>>> 3. freifunk.ber.ecix.net <- Freifunk Rheinland
> >>>>>>>> 4. ecix.iphh.hamburg.freifunk.net<- Freifunk Hamburg
> >>>>>>>> 5. ???
> >>>>>>>>
> >>>>>>>> Wir beziehen inzwischen auch Upstream vom FFRL, der wiederum bilaterales
> >>>>>>>> Transit-Peering mit Hamburg hat.
> >>>>>>>>
> >>>>>>>> Mal bei den Hamburgern nachfragen...
> >>>>>>>>
> >>>>>>>> Cheers, Bastian
> >>>>>>>>
> >>>>>>>> On 02/19/2016 08:58 AM, Stefan Sperling wrote:
> >>>>>>>>> On Fri, Feb 19, 2016 at 04:00:04AM +0100, 100.78090 at germanynet.de wrote:
> >>>>>>>>>> a176.g1.akamai.net [104.96.2.137], über
> >>>>>>>>>> configuration.apple.com
> >>>>>>>>>> e5153.a.akamaiedge.net [104.102.21.172] mit 32 Bytes Daten:
> >>>>>>>>>
> >>>>>>>>>> 104.102.18.110
> >>>>>>>>>> 104.102.35.246 (support.microsoft.com / e3843.g.akamaiedge.net)
> >>>>>>>>>> [2a02:26f0:10b:186::e59]
> >>>>>>>>>>
> >>>>>>>>>> Kann da mal bitte jemand nachsehen warum die Adressen nicht zu erreichen
> >>>>>>> sind?
> >>>>>>>>>
> >>>>>>>>> Könnte man in der Freifunk Firmware den olsrd anweisen 104/8 routen aus
> >>>>>>>>> dem OLSR Mesh zu ignorieren? Per patch oder config option (falls es dazu
> >>>>>>>>> eine gibt)?
> >>>>>>>>>
> >>>>>>>>> Wer bis jetzt noch nicht renumbered hat wirds wohl vergessen haben und
> >>>>>>>>> auch nicht mehr dazu kommen.
> >>>>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >
> >
> >
> > _______________________________________________
> > 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 : 819 bytes
Beschreibung: nicht verfügbar
URL : <https://lists.berlin.freifunk.net/pipermail/berlin/attachments/20160221/d9df99dc/attachment.sig>
Mehr Informationen über die Mailingliste Berlin