Ich denke es ist kein Geheimnis, wenn ich sage, dass der OpenVPN Exit eines GWs
immer einen immensen Flaschenhals darstellt.
Ein GW ist idR mit GBits angebunden. Diese können im peak angerufen werden. Die
Provider garantieren zwischen 250 und 500 MBits Dauerlastbandbreite.
Ein VPN Tunnel
Moin!
Schon klar. Was dann für eine Aussagekraft hat?
Mit dem nötigen Abstand könnte man den Eindruck bekommen, daß vlt. die
genutzten GWs nicht so performant (bedingt durch monetäre und
providerspezifische Faktoren) am Start sind, wie sie im Idealfall sein
sollten. Das "think big"-Ding und
> Bei den Gateways gibt es deutliche Unterschiede zwischen FFNord
> (mindestens 2 Promille TX-Drop) und FFHH (nur ein GW hat überhaupt TX-Drop).
> Könnte der Drop im Promille-Bereich, wenn er aus zeitweise höheren
> Dropraten in Spitzenzeiten herrührt, teilweise die, Gerüchten zufolge,
>
Am 06.09.2016 um 23:49 schrieb Allan Wegan:
> Gibt es neben zu schmalen Uplinks und lossy WLAN noch weitere Gründe für
> TX-Drop?
Ich könnte mir vorstellen, dass die CPU einfach nicht mehr hinterher
kommt, sprich das keine Zeit mehr für batman-adv bleibt, alle an das
batman-interface
Gibt es neben zu schmalen Uplinks und lossy WLAN noch weitere Gründe für
TX-Drop?
Gateway gw02 alias de:ad:be:ef:05:05 hat zwei Promille TX-Drop.
In der nodes.json von ffnord haben sogar alle Gateways mindestens 2
Promille TX-Drop (nord-gw8 alias fe:ed:be:ef:ff:08 hat mit 1.6% den
höchsten
Moin,
On 09/06/2016 12:12 PM, Allan Wegan wrote:
> Mir ist aufgefallen, dass in der nodes.json für 1001 von 1246 Nodes
> (80.3%) die gdroppten TX-Pakete > 0 sind.
> 72 (5.8%) haben > 1% gedroppte TX-Pakete.
>
> Die Werte sehen nicht dramatisch aus, aber warum droppen Nodes überhaupt
> ausgehende
