Richtig, da hing kein Client dran. Allerdings haben wir trotzdem alle Broadcast-Nachrichten von Knoten bekommen, die auch woanders dran haengen - weil die eben uebers VPN durchs gesamte Mesh verteilt werden. Ein Client fragt per ARP nach der MAC-Adresse des Gateways? Die Anfrage bekommt auch der Knoten in Klingenthal.
Zu dem Punkt von Andre - soweit ich weiss wird der groebste Unfug (Bonjour, SMB, etc) bereits gefiltert. Wie genau weiss ich aber gerade nicht.
In jedem Fall macht ICMPv6 (270 MB) und ARP (130 MB, abzgl UCAST4 wegen DAT ca. 128 MB) zusammen mit 398 MB den Grossteil des Broadcast Traffics (410 MB) aus. Der Rest scheint dann noch IGMP zu sein (12 MB), und dann bleibt da eigentlich nix mehr uebrig. :)
Beim Broadcast koennen wir bzgl. Filtern also: * DAT verbessern um mehr ARPs zu filtern (technisch eher schwierig) * IPv6 weiter einschraenken, z.B. mit Linus' Multicast-Patches experimentieren (ja, das ist experimentell)
Einfacher waer da vielleicht noch, broadcast domains zu splitten (siehe andere Mail).
Viele Gruesse, Simon
On Monday, January 9, 2017 9:16:54 PM CET Michael Gutmann via Freifunk_info wrote:
Glaube nicht. Das ist ja das Ergebnis einer Offline-Messung. Ich verstehe das so, dass da kein Client dran hing.
Am 09.01.2017 um 21:06 schrieb andre.fiedler--- via Freifunk_info:
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 mailto:freifunk_info@freifunk-vogtland.net *Gesendet: *Montag, 9. Januar 2017 20:49 *An: *freifunk_info@freifunk-vogtland.net mailto:freifunk_info@freifunk-vogtland.net; info@freifunk-vogtland.net mailto:info@freifunk-vogtland.net *Cc: *Simon Wunderlich mailto:sw@simonwunderlich.de *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
Freifunk_info mailing list Freifunk_info@freifunk-vogtland.net http://mx.hateotu.de:8025/mailman/listinfo/freifunk_info