Hm, Freifunk sollte ja generell nicht filtern. Aber so Broadcasts ala „ist ein Drucker im Netz“ oder „Apple TV bitte melde dich“ könnten wir doch filtern, oder? Können wir das und würde das etwas bringen?

 

VG,

Abdré

 

Gesendet von meinem Windows 10 Phone

 

Von: Simon Wunderlich via Freifunk_info
Gesendet: Montag, 9. Januar 2017 20:49
An: freifunk_info@freifunk-vogtland.net; info@freifunk-vogtland.net
Cc: Simon Wunderlich
Betreff: Re: [Freifunk_info] Stnadby-Traffic eines FFV-APs sehr hoch

 

Hi Denis,

 

nein, hat damit leider nix zu tun - das Datenaufkommen kommt ja "vom Kabel"

bzw. vom VPN, das wird nicht weniger bloss weil wir es langsamer (mit

niedrigerer Modulation) uebers WLAN senden. Das verbraet dann nur mehr

airtime.

 

Der Broadcast Traffic ist prinzipiell von unseren Clients generierte Pakete,

d.h. die Clients machen ARP-Requests, IPv6 MLDs, etc - und die muessen eben

ausgeliefert werden. Das kriegen wir nicht langsamer, wir koennen bestenfalls

filtern.

 

Viele Gruesse,

     Simon

 

On Monday, January 9, 2017 7:31:01 PM CET Denis Mitlacher via Freifunk_info

wrote:

> Vllt hilft es die Geschwindigkeit des Broadcast zu drosseln?  :)

>

> Bitrate used for multicast/broadcast packets.

> mesh_mcast_rate

>

> Oder wird dann alles langsamer?

>

> Am 09.01.2017 um 17:47 schrieb Simon Wunderlich via Freifunk_info:

> > Hi,

> >

> > wie zum letzten Treffen mal besprochen haben wir eine Analyse

> > durchgefuehrt. Unten [1] gibts das Ergebnis. Wir hatten einen einzelnen

> > AP isoliert, einen PC dazwischen gehaengt und saemtlichen Traffic uebers

> > Wochenende gedumpt und offline analysiert.

> >

> > Wie man sieht haben wir knapp 1 Gigabyte Grundrausch-Traffic pro Tag (bei

> > unser derzeitigen Netzgroesse von ca. 200 online APs), wobei die zwei

> > groessten Posten OGMs (Protokoll) und Broadcast Traffic sind. Broadcast

> > teilt sich dann weiter auf in ARP Traffic (der schon durch DAT reduziert

> > ist) und IPv6 Traffic. Dieser wiederum besteht wieder aus verschiedenen

> > Komponenten, wobei MLD (Multicast Listenery Discovery) der groesste

> > Posten ist.

> >

> > Low Hanging fruits um das ganze merklich einzudaempfen sehe ich gerade

> > nicht (ausser domains splitten), aber ich wuerd das erstmal sacken lassen

> > ... :)

> >

> > Viele Gruesse,

> >

> >      Simon

> >

> > [1]

> >

> > UDP(TOTAL)              917.264 MByte/day

> > OGM                     498.585 MByte/day

> > ICMP                    0.529 MByte/day

> > UCAST                   3.701 MByte/day

> > UCAST4                  2.200 MByte/day

> > BCAST                   410.491 MByte/day

> >

> >     ARPREQUEST          129.582 MByte/day (includes UCAST4)

> >     ARPREPLY            1.118 MByte/day (includes UCAST4)

> >     IGMP                12.055 MByte/day

> >     ICMPv6              270.635 MByte/day

> >    

> >         IPv6-allnodes   9.641 MByte/day

> >         IPv6-RS         5.298 MByte/day

> >         IPv6-RA         6.928 MByte/day

> >         IPv6-NS         75.624 MByte/day

> >         IPv6-NA         0.918 MByte/day

> >         MLDQ            1.099 MByte/day

> >         MLDR            171.521 MByte/day

> >         MLDD            0.970 MByte/day

> >         MLD2R           8.273 MByte/day

> >

> > On Monday, January 2, 2017 12:11:02 PM CET Simon Wunderlich via

> > Freifunk_info>

> > wrote:

> >> Hallo Ihrs,

> >>

> >> das ist systembedingt, da das Mesh uebers VPN gefahren wird. D.h. es gibt

> >> regelmaessig Routingprotokoll-Overhead (alle paar Sekunden ein Paket von

> >> jedem Knoten) und Broadcasts aus dem gesamten Netz (groesstenteils die

> >> Clients - DHCP Requests, ARP requests, etc). Das ist nicht so viel, aber

> >> stetig, und in der Summe (pro Tag) schon eine Menge. Das steigt

> >> natuerlich

> >> auch mit der Anzahl der aktiven Knoten und (Gesamt)Clients.

> >>

> >> Das Problem ist durchaus bekannt, einfach mal nach "Gluon Grundrauschen"

> >> googlen.

> >>

> >> Spontan habe ich leider keine Alternative fuer den LTE Uplink - eventuell

> >> koennen wir einen anderen fastd Server schalten wo "wenig" Nutzer drauf

> >> sind. Ich muss da mal drueber nachdenken ... Falls Ihr etwas seht, sagt

> >> Bescheid.

> >>

> >> Viele Gruesse,

> >>

> >>      Simon

> >>

> >> On Monday, January 2, 2017 11:09:07 AM CET Alexander Heidenreich via

> >>

> >> Freifunk_info wrote:

> >>> Hi,

> >>>

> >>> ich hab mal das Trafficaccounting für diesen Client im Netz

> >>> angeschalten.

> >>> Da geht tatsächlich eine ganze Menge sinnloser Traffic übers Netz. Ob

> >>> das

> >>> jetzt 1GB/Tag ist, kann ich noch nicht abschätzen, aber aus der

> >>> Hochrechnung der letzten Stunde würde ich sagen mindestens 500MB,

> >>> Tendenz

> >>> ist eher höher. Ich rechne da mal lieber vorsichtiger, weil bei mir sind

> >>> tatsächlich Clients verbunden.

> >>>

> >>> Völlig inakzeptabel, imho.

> >>>

> >>> Grüße

> >>> Alex

> >>>

> >>> On Wednesday, 28 December 2016 11:30:00 CET Carsten Weber via

> >>> Freifunk_info

> >>>

> >>> wrote:

> >>>> Hi,

> >>>>

> >>>> im Zuge des Projekts, entlang der Kammloipe an den GK-Kamera-Standorten

> >>>> Freifunk-APs aufzustellen, wurden LTE-Router mit Vertrag über 30GB

> >>>> Datenvolumen beschafft.

> >>>>

> >>>> Leider scheint der AP nur fürs Existieren schon sehr viel Datenvolumen

> >>>> zu verbrauchen, ich komme auf ein knappes Gigabyte pro Tag - und da

> >>>> sind noch keine Clients eingebucht gewesen. Mache ich was falsch? Kann

> >>>> man das ändern? Alleine fürs Betreiben ist der Vertrag damit ja schon

> >>>> fast ausgelastet.

> >>>>

> >>>> Carsten

> >>>> _______________________________________________

> >>>> Freifunk_info mailing list

> >>>> Freifunk_info@freifunk-vogtland.net

> >>>> http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info

> >

> > _______________________________________________

> > Freifunk_info mailing list

> > Freifunk_info@freifunk-vogtland.net

> > http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info