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.
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.
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.
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)
- 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.
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
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)
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.
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.
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.
