ctr49
commented
6 years ago Es sind laut Map und Stats nur noch 13 Router ohne v2.4 online, wir haben aber trotzdem noch recht viele MLDv2 Reports (sichtbar an einem Mesh Interface zB mit tcpdump -XXnli <interface> 'ether[90]=0x8f'. Wenn ich die BATMAN Originator Adressen durch uniq laufen lassen (|fgrep 0x0010 |cut -d' ' -f6-8|sort|uniq an o.g. tcpdump angehängt), kommt derzeit folgende Liste heraus:
02ff 0fa5 7a01
06f9 eeaf 66eb
12ff f279 1a73
1ed8 1b28 d103
226e b67c d9ab
2275 9630 8b7b
22af 3509 fd7b
4a6d cda7 b573
4ab7 d227 673b
5608 c9c0 3193
564d 7b2c 33ab
5a05 9381 4b93
5e13 5e77 67c3
667a 826e d2fb
6a76 514c 0758
6e10 4a58 b843
6e51 3c77 ddcb
6e80 2c79 2083
762a d82c 022e
7a8f e9a4 0f2b
7e58 1c9d fb7b
7ebb a866 315b
869d 4362 d750
92eb 616d 0a83
96db c4ed a0b6
aa00 0066 4b61
aa00 00de 8d62
aa0d cd63 cf4b
b291 9eba 0a6b
b827 eb9d aeda
b827 ebe5 a501
be87 daa7 dabb
c65b ef68 ce73
ce21 ffb0 689b
ceb3 1f4e eb30
da8f faf5 8323
ead7 faca f883
eeb8 99e5 c52b
fa1e 6795 b99c
Das sind mehr als 13 und ich vermute, dass sind auch gar keine ffffm-image basierten Nodes (jedenfalls ist keiner davon auf Karte sichtbar, nur die erste Version der Liste probiert).
Einen weiterer Node (04:d6:aa:21:d8:a5) der gestern die ARP Floods verursacht hat, konnte ich über das BATMAN Originator Feld im Dump identifizieren: a6:50:10:27:13:4b Auch dieser ist aber nicht auf der Karte.
Wie können wir herausfinden wer das ist?
Remote BATMAN Gegenstellen: Ist es beabsichtigt dass es Verbindungen "an den Images vorbei" gibt? Haben wir da irgendwelche "acceptable use policies" (im Pico Peering Agreement sehe ich dazu nichts) dafür?
Mind. drei der Adressen: 762a d82c 022e 869d 4362 d750 aa00 0066 4b61 sind unsere eigenen Gateways. D.h. (wie bereits gestern Abend erläutert) scheinen die Traffic den sie auf ihren nativen Interfaces sehen auch mit in das Mesh zu schicken. Dabei müssen die MLDv2 Reports nicht mal von unserer Infrastruktur kommen, es reicht, wenn sie irgendwie beim Gateway ankommen. Hier sollten wir überlegen entweder an den Edge-Nodes mal die {ip|ip6|eb}tables zu überarbeiten und/oder das zumindestens auf den Gateways wegzudrücken, so das es nciht ins Mesh fällt.
Da es (hier?) noch gar keinen Issue dafür gab und vielleicht auch nicht jeder im IRC backlog liest dachte ich mal ich mache hier einen auf.
Problem: Das große Grundrauschen verursacht zu viel Netzwerklast, bis zu dem Punkt an dem kleine Router (zB 841) zu viel Last vom fastd haben und aussteigen.
Was ist "Grundrauschen". Multi- und broadcast Verkehr, der an alle Nodes verteilt wird auch wenn darauf gerade kein Client ist.
Was ist das Problem am Grundrauschen? Für den einzelnen Node könnte es schon zu viel werden, aber noch schlimmer ist es in der Infrastruktur, weil dort das Grundrauschen multipliziert mit Anzahl der Nodes anliegt.
Daher gilt es, das Grundrauschen so weit wie möglich zu reduzieren.
Als mögliche Ursache wurden Ende 2017 ICMPv6 Pakete vom Typ MLDv2 Listener Report (typ143) identifiziert. Das ist kein wirklich neues Problem, siehe Gluon issue 553. Das daraus hervorgehende Paket gluon-ebtables-segment-mld sorgt dafür, das MLDv2 Listener Reports schon am Node weggefiltert werden und somit gar nicht erst im ganzen Netz verteilt werden.
Die automatischen Updates haben in der Nacht vom 03/04.01.2018 angefangen und sind (Stand 05.01.2018) weitestgehend abgeschlossen.