Packetloss bij belasten verbinding

Hi,

Mijn OPNsense router houdt middels dpinger (gateway monitoring) de kwaliteit van mijn verbinding in de gaten. Die is over het algemeen goed! :slight_smile:

Als ik de verbinding echter wat langer en zwaarder belast loopt het packetloss al snel op tot tussen de 5 en 20%.


Ik gebruik om te testen de bestanden op http://speedtest.tele2.net/. De downloadsnelheid blijft rond de 100 MB/sec, dus dat lijkt mij prima. Iets waar ik mij zorgen over moet maken?

Voor de zekerheid nog de specs van de router, gebrek aan resources is het denk ik niet:
OPNsense 21.7.4-amd64
FreeBSD 12.1-RELEASE-p20-HBSD
LibreSSL 3.3.5
AMD Ryzen 5 3500X 6-Core Processor
16GB RAM

Hier nog wat uitschieters. De reden dat er offline naast staat zijn de signaalwaardes die ik heb ingesteld. De verbinding doet het dus gewoon nog op dat moment.


Iemand suggesties om dit te troubleshooten? Of maak ik me zorgen om niks?

Ik ervaar hetzelfde met mijn pfSense (Netgate 6100). Ik kwam erachter toen ik met traffic shaper aan de slag was.

Met een speedtest is het de bedoeling dat de beschikbare bandbreedte volledig wordt gebruikt. Voorlopig verkoop ik de packetloss dat op dat moment de icmp packets van dpinger geen prioriteit hebben. Waardoor het langer duurt dan verwacht of zelfs verloren gaan. Is dat erg? Ik denk in deze situatie niet. Verder blijft alles prima functioneren.

1 like

zoek eens naar bufferbloat, het zou kunnen zijn dat je hier last van hebt

1 like

Thanks @mcfab! Ik ga eens kijken of ik daar wat mee kan!

Als je zorgt dat je een 5-10% onder het maximum van de uplink capaciteit blijft met traffic shaping beperkt zal alles waarschijnlijk een stuk soepeler lopen. (dat was mijn ervaring in het DSL tijdperk).
En dan met name korte pakketten en ACK etc. prioriteit geven boven bulk data.

1 like

Iemand suggesties voor instellingen op OPNsense? Ik vond dit topic (https://forum.opnsense.org/index.php?topic=7423.0) ? Maar ik heb echt de ballen verstand van tracffic shaping.

Is het niet mogelijk om traffic shaping helemaal uit te zetten?

Ik had geen traffic shaping aan staan, de oplossing is blijkbaar om het juist in te schakelen en dus 5 to 10% onder je maximale capaciteit te gaan zitten.

Heb je voor OPNsense al een voorbeeld gevonden?
Voor pfSense heb ik deze gebruikt. Misschien is deze (eventueel met een kleine aanpassing) ook voor OPNsense bruikbaar.

Ik heb gemerkt dat 5% op basis van het aantal kb/s al prima werkt.

Daarnaast heb ik juist voor de ICMP echo reply/request een extra Queue’s (voor UP en Down) aangemaakt waarbij ik de Weight op 100 heb gezet. (en die uit het voorbeeld op weight: 10). Daarbij heb ik de floating rule voor icmp op de tweede Queue gezet. Daardoor krijgt de ICMP rule, simpel gezegd, voorrang. De limiters heb ik op 100% van mijn bandbreedte gezet. (maar wellicht dat dit overbodig is bij jou)

1 like

Ik heb de link die ik eerder poste gevolgd en die instellingen aangepast aan mijn bandbreedte. Dus de volgende instellingen:

Download pipe

- Bandwidth: 900 Mbit/s
- queue: 2 
- Scheduler type: FlowQueue-CoDel
- Enable (FQ-)CoDel ECN
- FQ-CoDel Quantum: 2700
- FQ-CoDel Limit: 2700

Upload Pipe:

- Bandwidth: 900 Mbit/s
- Scheduler type: FlowQueue-CoDel
- Enable (FQ-)CoDel ECN

Download Queue

- Pipe: Download pipe
- Weight: 100
- Enable (FQ-)CoDel ECN

Upload Queue

- Pipe: Upload pipe
- Weight: 100
- Enable (FQ-)CoDel ECN

Download Rule

- Interface WAN 
- Target: Download Queue
- Protocol: ip
- Destination:  Alle IPv4 en IPv6 subnetten die ik intern gebruik (bijvoorbeeld 10.1.0.0/16)

Upload Rule

- Interface WAN 
- Target: Upload Queue
- Protocol: ip
- Destination:  Alle IPv4 en IPv6 subnetten die ik intern gebruik (bijvoorbeeld 10.1.0.0/16)

Dit lijkt het grootste deel van het probleem opgelost te hebben. Downloadsnelheid zakt ietsjes naar rond de 90 MB/sec, maar packetloss is beperkt tot heel soms 1%, maar meestal 0.

Thanks! Ik ga die ook even doorlezen, misschien valt er nog wat te tweaken. :slight_smile:

vroeger was er het linux router project maar dat is al ergens in 2002 min of meer overleden.
Die hebben wel een erfenis achtergelaten in de vorm van scriptjes en tools… waaronder de traffic-shaper

Hier is wat achtergrond uitleg.
https://www.b1c1l1.com/blog/2020/03/26/linux-home-router-traffic-shaping-with-fq_codel/
https://www.b1c1l1.com/blog/2020/04/19/linux-home-router-download-bufferbloat-analysis/

Gentoo heeft ook een beschrijving
https://wiki.gentoo.org/wiki/Traffic_shaping

Dat is een beschrijving voor Linux systemen, maar het mechaniek is universeel

Begin met 10% onder de bandbreedte en daarna kun je experimenteren met de marges op te schroeven naar 95%… zolang het maar stabiel blijft.

2 likes

disclaimer: Zelf ben ik ook pas een maandje aan het stoeien met de traffic limiter, dus geen expert.

Zo te zien gaat het dus al lekker. Nu de kers op de taart om er meer dan de 90MB/s en dat laatste beetje packet loss weg te halen.

Je kan ook nog zoeken wat de impact is van de Queue length bij de 2 pipes.
Schijnt dat als de Queue te groot is dat er dan ook packets gedropt kunnen wordt. Is de Queue te klein dan kan dat gevolgen hebben voor o.a. de snelheid.

Hier staan bij beide pipes de Queue length op 1000. (200/30Mbps)

1 like

Queue te groot is juist wat bufferbloat veroorzaakt.
een heel klein percentage packet loss is geen ramp, bij geen packetloss zal de tcpstack er steeds meer dooheen proberen te duwen…, packet loss is het mechaniek waardoor stabiliteit op de langere termijn gewaarborgd wordt. (<= 1%)
Het probleem is voornamelijk veroorzaakt door de assymetriche snelheden, met veel te grote buffers.
Maar het wordt goed uitgelegd in de linkjes die ik eerder al poste.

2 likes

De theorie/informatie vind ik inderdaad waardevol.

Hoe bevalt die Netgate 6100 in de praktijk nu we weer een paar maanden verder zijn? Ik word maandag aangesloten op Freedom met gigabit en ben me aan het oriënteren. Initieel had ik de Turris Omnia op het oog maar de nieuwe hardware laat nog wel even op zich wachten en bovendien heb ik altijd prettig met pfSense gewerkt. Een los AP is geen probleem.

Ook de huidige generatie Omnia is nog bij lange na niet ontoereikend voor zo ongeveer ieder denkbaar doeleinde hoor. Laat je daardoor zeker niet weerhouden. Ik heb op die van mij nog nooit een load average hoger dan 0.02 gezien bijvoorbeeld.

root@reykjavik:~# uptime
 13:32:09 up 88 days,  5:28,  load average: 0.00, 0.00, 0.00

Symmetrisch 1Gbps met traffic shaping is ook gewoon te doen. (Niet dat je op symmetrische verbindingen echt traffic hoeft te shapen overigens.)

1 like

Toch spreekt de Netgate 6100 me het meest aan.

Heb ik nog een speciale SPF connector nodig voor Freedom? Ik heb geen GPON maar AON met een Genexis NTU. De monteur zal de NTU verwijderen en glasvezel tijdelijk aan mijn FRITZ!Box 5530 koppelen.

Dit staat bij de specs van de Netgate:

Network Ports: (2) 10 GbE SFP+ Ports, (2) 1 GbE Combo Ports (RJ45/SFP), and (4) discrete, unswitched 2.5 Gbps Ports allow for versatile WAN connectivity.

Ik zie op de site van Freedom het volgende:

SFP specificaties: TX 1310 nm , RX 1490/1550 nm
Type Fiber: singlemode Fiber (9/125) met SC/PC connector (blauw), SC/APC (groen) of LC/APC (groen)

SC connectors worden gebruikt bij de FRITZ!Box 5490
LC connectors worden gebruikt bij de FRITZ!Box 5530

Let op! Sluit nooit verschillende kleuren connectoren op elkaar aan! Hiermee druk je namelijk de glasvezel kapot. Sluit de connectoren alleen blauw-op-blauw en groen-op groen aan.
De glasvezel is erg kwetsbaar. Het is daarom ten sterkste af te raden om een eigen router of firewall direct op de inkomende glasvezelverbinding aan te sluiten. Wil je toch je router of firewall direct op de glasvezel aansluiten, gebruik dan de meegeleverde patchcover of gebruik het juiste koppelblokje.

Ja, je hebt een SFP-module nodig dan, en eventueel een media converter als er geen SFP-module in je router kan / die niet werkt. Zie ook dit topic: Terminologie rondom glasvezel

Persoonlijk zou ik die Genexis lekker laten zitten overigens. Dat is op zich het makkelijkst als je je eigen router wilt gaan gebruiken.

Complimenten voor dat fantastische topic!

Mijn voorkeur gaat uit naar het verwijderen van de NTU. Dan moet ik dus op zoek naar een juiste SFP-module.

De TP-Link TL-SM321B die jij noemt lijkt me een prima optie.