Over FredericV

Ondertussen heb ik nog een bijkomende test gedaan, waaruit blijkt dat Telenet legitiem HTTPS verkeer lijkt te vertragen of reset, van zodra er P2P over de lijn gaat, ongeacht de snelheid van dit P2P verkeer. Wanneer dit verkeer doorheen een VPN tunnel gaat, wordt direct HTTPS verkeer op een andere machine noch vertraagd noch gereset. Op de machine met de Deluge docker, die een Linux ISO download, werd de traffic geroute doorheen de VPN server van mijn zaak, om te kijken wat er dan gebeurt met de curl test. Ik ben daar geen fan van, gezien de VPN dient voor ondersteuning van onze klanten, en niet om P2P te verstoppen. Het gaat om een 4GB Linux ISO die ongeveer aan 100 a 200 kbyte/s binnenkomt.  Tijdens deze test staat de curl nooit in wacht, en ik zie instant antwoorden. Van zodra ik de default gateway terug verzet naar de lokale Mikrotik, en dus alle P2P terug lokaal naar buiten gaat ipv geroute doorheen de VPN, zie ik vertragingen in de curl test tot wel 8 seconden. Ik hoop dat Telenet hun packet shaping policies naziet op fouten, want dit is nog mijn job geweest bij telecom vendors om zulke configs op te zetten en te testen. Het ging dan over IP over sat, waarbij de upstream extreem beperkt was. Maar de tests in deze post, satureren nooit de upstream, en het lijkt alsof de shaper veel te hard en vooral veel te snel ingrijpt. Van zodra we de default gateway niet meer door de VPN trekken, zien we heel snel terug de curl test vertraging oplopen. ... Meer weergeven