Das ist der Best Case. Rechne mal aus wieviel kleine Pakete (z.B. 128 Bytes oder 64 Bytes) du bei dieser Geschwindigkeit senden/empfangen kannst. Genau aus diesen Grund ist in allen HighEnd Routern Spezial-Hardware (ASICs…) eingebaut, da die CPUs zu schlapp für große Packet-per-Second (PPS) Raten sind. Wenn Du wissen willst wie leistungsfähig eine HW ist, schaue nicht auf den Durchsatz, sondern auf die zugesicherten PPS.
Du kennst dich aus? IPSEC-VPNs mit Geräten verschiedner Hersteller gebaut und debuggt? Dagegen ist ein Debugging von OpenVPN z.B. wie eine Wellness-Kur.
1 „Gefällt mir“
IPSEC ist ein Standard, so das prinzipiell Geräte verschiedener Hersteller miteinander reden können…
Soweit die Theorie. In der Praxis gibt es einen kleinen Spielraum im Standard, der dazu führt, das es in manchen Fällen nicht klappt.
Beim Debuggen waren für mich eher die unterschiedlichen Debug Tools eine Aufgabe. Das eigentliche Troubleshooting fand und finde ich bei Openvpn schwieriger, ich habe aber auch mit Openvpn weniger Erfahrung als mit IPSEC.
Da IPSEC nicht zu viele Resourcen auf den Geräten braucht, wäre es schon eine Möglichkeit, den Durchsatz im VPN zu erhöhen, wenn die Verschlüsselung ein ‚should have‘ oder ‚nice to have‘ ist.
Ich denke aber auch an die schmalbandigen Anschlüsse, und was man da machen könnte. Es gibt ja immer noch Bereiche in NRW und DE, wo die Infrastruktur nur 1 MBit/s oder weniger liefert. Hier ist nicht die Rechenleistung der Router das Problem, sondern der Anschluss selber.
an könnte mit Datenkomprimierung hier sicherlich einiges erreichen, allderdings schliesst das Verschlüsselung aus, das verschlüsselte Daten per Definition nicht zu komprimieren sind.
Gute Verschlüsselung komprimiert die Daten vorher sowieso um Known Text Attacken vorzubeugen. PGP macht das zum Beispiel so.
Naja, IPSec ist schon etwas komplizierter als so ein OpenVPN Userspaceprozess mit übersichtlichem Konfigfile, den man ggf. die Konfig ändert, beendete, wieder starten, und dann berechtigt hoffen kann dass es (wieder) funktioniert. Der ins Logfile schreibt wenn was nicht past. Bei IPSec muss man zur Laufzeit verstehen was da wie und wo passiert und was man wo nachschaut und wie testet um bei Problemen hinter diese zu kommen. Fehlermeldungen gibst oft keine, wenns nicht geht muss man suchen was nicht so ist wie es sein müsste.
Aber ich muss Dir recht geben, wenn man von Null anfängt ist es eigentlich mit ähnlichem Aufwand erlernbar und dann auch debugbar. Und das Argument, dass es mit Fremdherstellern manchmal nicht funktioniert, hat man ja nicht wenn man beide Seiten selbst in der Hand hat und nur bewährte Kombinationen und Konfigurationen ausrollt.
Das ist durchaus richtig und eigentlich ziemlich humoristisch. Die neue Verschlüsselungswut bringt neue Probleme auf! Nichts ist eben nur gut. Allerdings ist schon noch einiges HTTP, und man könnte hier vielleicht schon ein paar Prozent herausholen… Damit würde mann eine (implizite) Initiative an den entsprechenden Standorten gründen: Für mehr Unsicherheit im Internet! Surft unverschlüsselt und erhaltet mehr Performance! 
Ähm… nein? Mag ja sein dass PGP/GPG das vorher komprimiert, allerdings schützt das weder gegenüber KnowPlaintext nennenswert noch wandelt es die Verschlüsselung von „schlecht“ in „gut“. Findet man auch auf http://en.wikipedia.org/wiki/Known-plaintext_attack: „Modern ciphers such as Advanced Encryption Standard are not currently known to be susceptible to known-plaintext attacks.“
Aber guter Einwand in der Hinsicht, dass HTTP (und somit auch HTTPS) auch die Möglichkeit der Komprimierung bietet, und somit bei entsprechenden Webservern auf der Gegenseite zumindest bei einem Teil des HTTPS Datenverkehrs kaum bis kein Optimierungspotential verloren geht. Mir fällt spontan allerdings kein weiteres wesentliches Protokoll ein, beim dem das sonst noch so ist…
Nach längerem Nachdenken ist mir folgendes eingefallen: Wo Komprimierung einen interessanten Nebeneffekt haben kann ist, wenn ein schlechter Blockverschlüsselungsmodus, insbesondere ECB (siehe Electronic Code Book Mode – Wikipedia), gewählt wurde. Man wird das Bild am ende der Webseite wohl nicht mehr so einfach erzeugen können, wenn es vorher durch gzip geschickt wurde. Allerdings löst man in so einem Fall das Problem durch einen anderen Blockverschlüsselungsmodus, und nicht durch Kompression, die nur bedingt und unvollständig in diesem Sonderfall hilft.
1 „Gefällt mir“
Sorry, ich bin ja ein Spielkind, also habe ich das mal ausprobiert. Ich habe einen i7-Rootserver bei Hetzner, und da ich kein Geld für IPv4-Adressen ausgeben will, die ich eh’ habe, bekommen die VMs dort IPv4-Adressen aus einer OpenVPN-TAP (für IPv6 nutze ich das Hetzner /64):
root@gw05:~# traceroute -m 5 ns.uu.net
traceroute to ns.uu.net (137.39.1.3), 5 hops max, 60 byte packets
1 susan-gw.uu.org (192.251.226.65) 19.663 ms 19.674 ms 19.669 ms
2 xmws-gtso-de12.nw.mediaways.net (192.251.226.203) 19.665 ms 19.648 ms 19.639 ms
3 xmws-gtso-de32-chan-2.nw.mediaways.net (195.71.9.5) 19.622 ms 19.619 ms 19.615 ms
4 xe-4-0-4-0.01.rmwc.99.fra.de.net.telefonica.de (62.53.1.244) 24.943 ms xe-6-1-4-0.01.rmwc.99.fra.de.net.telefonica.de (62.53.1.248) 24.962 ms xe-4-0-4-0.01.rmwc.99.fra.de.net.telefonica.de (62.53.1.244) 24.960 ms
5 213.140.50.124 (213.140.50.124) 36.575 ms 36.590 ms 36.584 ms
19 ms zum first Hop, definitiv nicht lokal. Hingegen der Host:
root@carrot:~# traceroute -m 5 ns.uu.net
traceroute to ns.uu.net (137.39.1.3), 5 hops max, 60 byte packets
1 static.161.67.9.5.clients.your-server.de (5.9.67.161) 1.004 ms 1.154 ms 1.200 ms
2 hos-tr1-juniper3.rz16.hetzner.de (213.239.230.1) 0.261 ms 0.274 ms hos-tr2-juniper3.rz16.hetzner.de (213.239.230.33) 1.293 ms
3 core22.hetzner.de (213.239.245.145) 0.270 ms core21.hetzner.de (213.239.245.105) 1.581 ms core22.hetzner.de (213.239.245.145) 0.266 ms
4 core4.hetzner.de (213.239.245.14) 6.008 ms 6.009 ms core4.hetzner.de (213.239.245.18) 4.840 ms
5 juniper4.ffm.hetzner.de (213.239.245.1) 4.971 ms 4.896 ms 5.995 ms
Anyway. Die These von Markus (@pRiVi) war ja, daß über TUN/TAP keine 100 MBit/sec drüber gingen. Ich werde nun »wget -O /dev/null https://www.kernel.org/pub/linux/kernel/v4.x/testing/linux-4.0-rc5.tar.xz« ausführen, direkt vom Hetzner-Host als auch von der (für IPv4 per OpenVPN angebundenen) VM …
Direkt:
100%[======================================>] 82,290,100 15.0MB/s in 15s
2015-03-28 04:15:11 (5.11 MB/s) - ‘/dev/null’ saved [82290100/82290100]
Via VM:
100%[======================================>] 82,290,100 12.1MB/s in 13s
2015-03-28 04:16:59 (6.03 MB/s) - ‘/dev/null’ saved [82290100/82290100]
Hmm. Sowohl lokal als auch per OpenVPN wurden die 100 MBit/sec übertroffen. Und nu?
3 „Gefällt mir“
Naja, ich würde sagen, daß hier eindeutig das 100mbit Ethernet der begrenzende Faktor war.
Interessant wäre ja noch die CPU-Auslastung und die Load-Werte bei solchen Transferraten über längere Zeit zu ermitteln.
Vielleicht mal mit iperf messen.
Btw. ist das ein netter Speedtest für die eigene Leitung! 
harry@hl-blue:~> wget -O /dev/null https://www.kernel.org/pub/linux/kernel/v4.x/testing/linux-4.0-rc5.tar.xz
--2015-03-28 04:37:11-- https://www.kernel.org/pub/linux/kernel/v4.x/testing/linux-4.0-rc5.tar.xz
Auflösen des Hostnamen »www.kernel.org (www.kernel.org)«... 198.145.20.140, 199.204.44.194, 149.20.4.69, ...
Verbindungsaufbau zu www.kernel.org (www.kernel.org)|198.145.20.140|:443... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 82290100 (78M) [application/x-xz]
In »»/dev/null«« speichern.
100%[===================================================================================>] 82.290.100 4,67MB/s in 29s
2015-03-28 04:37:41 (2,72 MB/s) - »»/dev/null«« gespeichert [82290100/82290100]
harry@hl-blue:~ >
Ginge noch besser, wenn ich nicht gerade „Breaking Bad“ via AmazonPrime schauen würde.
(hat beim Test nichtmal geruckelt!)
Für vergleichende Messungen nicht geeignet:
$ host www.kernel.org
www.kernel.org is an alias for pub.all.kernel.org.
pub.all.kernel.org has address 149.20.4.69
pub.all.kernel.org has address 198.145.20.140
pub.all.kernel.org has address 199.204.44.194
pub.all.kernel.org has IPv6 address 2620:3:c000:a:0:1991:8:25
pub.all.kernel.org has IPv6 address 2001:4f8:1:10:0:1991:8:25
Du weisst nie, gegen welchen Host Du gerade trittst.
Im Übrigen halte ich die Aussage: „>100MBit/s über TUN/TAP nicht möglich“ ebenfalls für Quatsch. Viele der VPN Anbieter (AirVPN,…) benutzen OpenVPN. Ich weiss es nicht, aber ich glaube schon, dass dort mehr als 100MBit/s von der Kundschaft drüber gehen wird.
Spielt in diesem Fall gar keine Rolle.
Jeder einzelne dieser Server kann sicher mehr als die 100mBit, und es ging ja um einen Test und nicht eine korrekte Messung.
Okay, da habe ich mich mit den aktuellen großen CPUs wohl etwas verschätzt, auf bis zu 160 Mbit/sek kann man offensichtlich kommen. Schau dir einmal an wie es selbst bei der Nutzung mehrer CPUs durch Tricks aussieht: Um wegen diesem Problem mehrere CPUs nutzen zu können hat einer mehrere paralelle Tunnel gemacht. Und er hat die gleichen Probleme, über 160Mbit/sek pro CPU kommt er nicht: https://forums.openvpn.net/topic8723.html
Ich bin beim MultipathVPN bei 80 Mbit/sek hängen geblieben, und da ist mein Userspaceantzeil bereits bei etwas unter 50 % auf einem Intel I5 @3,6 Ghz, mit 100 Mbit/sek war ich wohl trotzdem etwas zu pessimistisch. Der fastd, und vermutlich auch openVPN, sind bei unter 20%, darum ist dann natürlich noch etwas mehr für den Kontextwechsel übrig. Beim OpenVPN ist die Grenze laut besagtem Post bei 160 Mbit/sek zu finden. Und natürlich haben diese Probleme auch andere, findet man im Google recht einfach.
Weitere Links mit gleichem Tenor:
MTU erhöhen kann beidseitig lokale (!) tcpverbindungen beschleunigen (klar, dann gibts es pro read/write mehr Daten): http://comments.gmane.org/gmane.network.openvpn.user/32043
Ubiquity systeme: CPU limitiert auf 12 Mbit/sek: http://community.ubnt.com/t5/EdgeMAX/OpenVPN-Performance-Throughput/td-p/567901
…
Es gibt sogar ein ausführliches Paper dazu, das auch auf die „magische“ Wirkung der MTU erhöhung kommt: https://staff.science.uva.nl/c.t.a.m.delaat/rp/2010-2011/p09/report.pdf Diese hilft allerdings beim Forwarden nicht, da die Pakete ja in 1500er Einheiten übers Netzwerk geliefert werden. Mit AES-128-CBC Verschlüsselung liegen die auch nur bei etwa 160 Mbit/sek, siehe Seite 28.
Auf Seite 35 kann man sogar genau euren Anwendungsfall sehen, und hier kommt er nur noch auf unter 120 Mbit/sek. Man sieht auch schön dass diese MTU erhöhung beim Routen nichts bringt, und dass es einen Unterschied macht ob man die Daten geroutet überträgt oder ob diese von lokal kommen. Und warum die MTU Erhöhung nichts bringen kann erklärt er auch.
[quote]CONCLUSION
…
Many different parameters can be used on the first lab setup. In particular the OpenVPN fragmentation options and TUN MTU size.
…
Even though we were unable to exactly pinpoint the exact cause of the
performance loss, we came to interesting results showing differences in performance
loss using different encryption and hashing algorithms. The proposed
future work supplies for enough interesting studies
…[/quote]
Schade, auf die Ursache dafür ist er nicht gekommen.
Die ganzen Werte habe natürlich nur indirekte Relevanz bei den kleinen Kisten mit ARM Prozessor, der teilweise recht anders arbeitet. Wie es läuft mit nur einer CPU, die auch noch ARM ist, sowie wesentlich langsamer taktet, sieht das ganze natürlich entsprechend schlechter aus. Und das wisst Ihr ja schon, deswegen habt Ihr ja diesen Thread begonnen.
Ich hab auf meinen Alixsystemen übrigends mit L2TP im Vergleich zu OpenVPN auch nur etwa 300% mehr Übertragungsraten bekommen im Vergleich zum OpenVPN… Sprich bei 12 Mbit/sek vorher (OpenVPN ohne Verschlüsselung) sind es bei mir auch nur um die 36 Mbit/sek mit L2TP(auch ohne Verschlüsselung) geworden.
ICETA 2024 Hier gibts noch Zahlen AES IPSec vs. AES OpenVPN: 99 Mbit/sek zu 142 Mbit/sek, also ist unter x86 scheinbar wirklich nur ~50% mehr rauszuholen. Da scheint dann die Verschlüsselung im Verhältniss doch mehr zu greifen als erwartet.
1 „Gefällt mir“
Machen die dann Bonding mehrerer TUN Interfaces, oder wie lösen die dieses Problem?
Also, die eine beteiligte CPU war eine von zwei „Intel(R) Xeon™ CPU 3.20GHz“, Single Core, ca. 10 Jahre alt. Ein Odroid U3 (armv7l, Quad-Core 1,7 GHz, 2 GB RAM) schafft immerhin auch schon 90-OpenVPN-MBit/sec.
Mit zwei E5420 QC @ 2.50GHz und OpenVPN mit Standard-Cipher und statischem Key komme ich über GBit zwischen den Kisten ebenfalls an die 150 MBit/sec-Grenze (diesmal, wie gewünscht, mit iperf):
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 182 MBytes 152 Mbits/sec
[ 5] local 193.xxx.xxx.xxx port 5001 connected with 193.xxx.xxx.xxx port 55267
[ 5] 0.0-10.0 sec 1.07 GBytes 921 Mbits/sec
[ 4] local 10.11.12.2 port 5001 connected with 10.11.12.1 port 5001
[ 4] 0.0-10.0 sec 184 MBytes 153 Mbits/sec
AES-NI können die CPUs leider nicht; aber wie aus dem interessanten Link ja auch hervorgeht, ist es im Bereich der Intel-GHz-CPUs nicht Kernel-vs-Userspace, sondern die Ineffizienz von OpenSSL bei Blockgrößen von 1500 Bytes, die hier limitiert. 500 MBit/sec sind mit OpenVPN drin – fährt man mit Paketgrößen von 48.000 statt 1.500 Byte.
»cipher none« bringt bei mir immerhin den Sprung auf 230+ MBit/sec:
[ 4] local 10.11.12.2 port 5001 connected with 10.11.12.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 278 MBytes 233 Mbits/sec
Da ist dann die Frage, warum man OpenVPN nutzt; einfach nur als Tunnel nach Hause, oder aber, z. B. in offenen, fremden WLANs, um sicher nach Hause zu kommen, weil man noch immer zu faul war, seinen VDR-Admin-Zugang auf SSL zu hieven.
Lustigerweise ist auf den beiden Servern (beides DL360G5 mit identischer Ausstattung) aes-256-cbc schneller als der blowfish-Default, obwohl, wie gesagt, die Kisten keine AES-NI-Hardwareunterstützung haben:
[ 4] local 10.11.12.2 port 5001 connected with 10.11.12.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 215 MBytes 180 Mbits/sec
Das würde dann erklären, wie es andere OpenVPN-Anbieter hinbekommen >150 MBit/sec liefern zu können …
Machen die dann Bonding mehrerer TUN Interfaces, oder wie lösen die dieses Problem?
[/quote]
Naja, wenn ich mit alter HW (auch die HP DL360G5 ist ja nicht mehr ganz taufrisch; dafür bekommt man so einen refurbished Server auf dem freien Markt für um 250,–) ohne AES-Hardware-Unterstützung schon 180 MBit/sec schaffe, dürfte da MIT HW-Unterstützung wohl noch deutlich drin sein, selbst mit 1500er Paketen; der Artikel ist ja auch schon wieder 4 Jahre alt …
1 „Gefällt mir“
Scheisse!!!
Du hast mich durchschaut 
10 Jahre alt tut nichts zur Sache. Seitdem hat sich in der Performance pro CPU nichts wesentliches mehr getan.
ja, das ist gut möglich.
- Was den Odroidtest komplett aussen vor läßt ist, dass dieser ohne Crypto gelaufen ist. Wenn Du das an nem aktuellen PC machst, haste da auch flugs 200 oder 300 Mbit/sek mit OpenVPN. Worüber wir allerdings gesprochen hatten war mit Verschlüsselung.
- Mein Ordoid schafft in diesem Senzario (/dev/zero|nc ↔ nc >/dev/null) verschlüsselt (AES-128-CBC) gerade einmal 56 Mbit/sek. Wenn ich 4 parallele OpenVPN Tunnel machen und diese bonde, dann lande ich bei rund 256 Mbit/sek. Aber nur in diesem Bonding und der Nutzung aller CPUs!
- Das längere PDF, das ich verlinkt hatte, hat gezeigt dass lokale Verbindungen etwa 40% weniger Performance benötigen als gerouter Verkehr. Kannste also auch noch abziehen. Der Test ist also für Routing, was wir machen, nicht sehr ausssagekräftig.
- Der Odroid spielt in ganz anderen Regionen als die Kisten die wir so draußen haben, preislich wie bezüglich der Anbindung der Netzwerkkarte, dem Takt und dem RAM. Er hat 4 CPUs und ist das wohl leistungsfähigste ARM CPU Board mit der gigantischten Anbindung des Netzwerkchips an die CPU, das derzeit zu haben ist. Mit rund 40 Euro ist das Board alleine auch nicht grad billig. Ist aber alles egal, denn draußen haben wir TP-Links, die ganz anders ausgestattet sind.Nicht nur ich, sondern auch Ihr, habt doch die Dinger selbst und wisst das Ihr keine 90 Mbit/sek durchbekommt. Wer über 20 Mbit/sek kommt ist ja schon glücklich, nicht?
- Über unverschlüsseltes L2TP bekomme ich aus nem WR-841N für 13,80 sogar 36 Mbit/sek per UDP-VPN raus. Über OpenVPN unverschlüsselt allerdings nur 12 Mbit/sek. Verschlüsselung kostet hier beim OpenVPN gerade einmal um die 2 Mbit/sek. Das zeigt doch dass hier etwas zu holen ist. Und die 90 Mbit/sek finde ich bei dem Hardwareunterschied nicht sooo erstaunlich.
Auf den kleinen Boxen wird es gerade einmal 2 Mbit/sek langsamer (von 12 auf 10 Mbit/sek), wenn ich auf AES-128-CBC von none im OpenVPN umstelle. Ich glaube nicht das AES-NI groß relevant ist.
Das mit den Blockgrößen ist exakt das was ich gesagt habe: Die TUN/TAP Schnittstelle liefert pro read und write nur ein Paket. Wenn das so winzig ist(1500 Byte) braucht man so viele Contextswitche. Die Erhöhung der MTU ermöglicht es pro read/write mehr zu lesen, so daß weniger davon notwendig sind, und somit auch weniger Contextswitche. Natürlich kann das das, wenn man verschlüsselt, auch diesen Aufwand reduzieren.
Der OpenVPN Text von Dir sagt, dass man durch die Erhöhung der MTU am tun Interface mehrere Pakete zusammenfassen lassen kann durch „reassembling“. Ich verstehe noch nicht wie es das macht, aber es ist im Prinzip genau das was wir brauchen: Weniger read und writes, somit weniger Contextswitches, und was ich für den fastd programmieren wollte. Schön dass es das schon gibt. Das ist nen toller Hinweis, den ich noch nicht kannte und wieder etwas dazu gelernt habe. Ich werde das gleich mal ausprobieren und Kernelcode lesen.
Hat das sonst jemand schon einmal ausprobiert?
Komisch finde ich auf jeden Fall noch diesen Hinweis, kann jemand damit etwas anfangen, wenn der Kernel das doch einfach reassemblen kann?
[quote]By increasing the MTU size of the tun adapter and by
disabling OpenVPN’s internal fragmentation routines the throughput can
be increased quite dramatically. The reason behind this is that by
feeding larger packets to the OpenSSL encryption and decryption routines
the performance will go up. The second advantage of not internally
fragmenting packets is that this is left to the operating system and to
the kernel network device drivers. For a LAN-based setup this can work,
but when handling various types of remote users (road warriors, cable
modem users, etc) this is not always a possibility.[/quote]
Korrekt, ohne crypto siehts natürlich besser aus. Aber das war nicht die Frage.
Im Gegenteil, die aktuellen XEON CPUs haben mittlerweile einen langsameren Takt aber dafür mehr CPUs. Was die Hardwarecryptounterstützung bringt weiß ich nicht, ich würden eher davon ausgehen dass die TP-Links sowas nicht haben.
Ne ganz andere Frage in dem Zusammenhang:
Durch die ganzen Broadcasts wird die CPU der kleinen Router auch belastet, was wieder auf die Performance geht.
Bei jedem Broadcast Packet das ankommt, schickt das Interface einen interrupt and die CPU.
Auf meinem 841 macht das ohne clients im netz schon 5-10% CPU-Last aus.
Wenn dann noch die ganzen Arp-Requests der Clients dazu kommen, wird es wahrscheinlich noch schlimmer.
Eine Möglichkeit wäre es die Netzmaske auf 255.255.128 oder 255.255.64 zu ändern, aber das hätte zur Folge, das der lokale Router nicht immer unter 10.XXX.254.254 zu erreichen ist.
Ausserdem müsste erst einmal gemessen werden ,wieviel Performance damit überhaupt gewonnen wird.
Es könnte sein, das sich der ganze Aufwand nicht lohnt.
64er Subnetzmaske wird nicht funktionieren, du meinst sicher 192.
Dann gibt es 4 Subnetze (x.x.x.64,128,192) und im letzten (10.x.254.192/26) ist 10.x.254.254 doch auch erreichbar.
jo, das meinte ich, aber Sonntags morgens Kopfrechnen nach der Zeitumstellung ist nicht meins
Sollte 256-64 = 192 heissen, nicht 64
also 4 subnetze mit je 2048 Adressen/Clients. Das Sollte wohl für doe meisten Netze ausreichen
Das es so ist wie es ist liegt in der Natur der Sache und eine bewusste Designentscheidung. Nämlich die, das Freifunk Netz als flaches Layer2-Netz aufzubauen. Man tat dies im vollen Wissen, dass ein L2-Netz nicht skaliert. Und damit ein L2-Netz funktioniert ist es unumgänglich, dass Broadcast/Multicast an alle Hosts geflutet werden. Da beisst die Maus keinen Faden ab. Stellenweise wird mit Tricks (distributed ARP Table) gearbeitet um das Flooding zu reduzieren, funktional ist es aber zwingend erforderlich. Dagegen zu lamentieren macht ungefähr soviel Sinn, wie sich zu beschweren warum die fundamentalen Wechselwirkungen im Universum so sind wie sie sind.
War keine Beschwerde, sondern eine Bemerkung.
Wenns 'ne bewusste Desingentscheidung war/ist, hat es sich ja schon erledigt.