Vertragen HTTPS en TCP connection resets bij idle P2P

[FredericV]

Ik heb een CV8560E in bridging, met een Mikrotik RB1100AH (x2). Omwille van upstream problemen is vorige week de modem alsook een TV filter (TOF) in de paddenstoel vervangen. De oude TOF was verouderd en de technieker toonde lijnwaarden die in het rood gingen. Nadien leek alles OK.

Helaas heeft dit het probleem niet verholpen.

Ik heb een Deluge docker draaien met daarin een aantal officiële Linux torrents.

De lijn trekt 990 mbit via fast.com en haalt quasi de volle 50 mbit upstream, dus het 1000/50 profiel wordt hier vlotjes gehaald.
En gisteren bij het downloaden van een berg Linux torrents rond 22u, deed de lijn 950 mbit. Netjes!

De problemen stellen zich echter niet bij belastig van de verbinding, maar bij normaal gebruik en idle P2P.

Van zodra Telenet idle P2P verkeer detecteert (dus geen enkele torrent is aan het up- of downloaden, maar er is wel idle protocol verkeer die in de orde ligt van jaren 90 inbelmodems), dan worden op eender welke host in mijn thuisnetwerk HTTPS connecties ofwel vertraagt, of zelfs gereset.

Het maakt niet uit of die hosts dan achter de Mikrotik hangen, of achter de modem, zelfs traffic wat met een ander IPv4 naar buiten gaat wordt beïnvloed.

Sommige applicaties kunnen hier niet mee overweg. Zo verliest een applicatie als Roon zijn connectie met Tidal door deze resets, en stopt een flac stream die in meerdere delen wordt ingeladen. Roon's coverart hapert ook. Ook curl testen naar userbase.be tonen deze resets.

Helaas krijg ik van Telenet hierover geen degelijk antwoord, buiten dan een snelle opvolging van het modemprobleem.

Op userbase loopt hier ook een topic over:

https://userbase.be/forum/viewtopic.php?t=67585

Het meest bizarre dan nog, is het feit dat het niet uitmaakt waar de Deluge doos achter de modem hangt: als we deze achter de Mikrotik hangen die een public IPv4 krijgt, gaat P2P verkeer naar buiten met een ander IPv4 als hosts die direct aan de modem hangen (die gaan naar buiten met het WAN ip van de modem): HTTPS wordt vertraagd van zodra er idle P2P verkeer door de modem gaat. Ook het omgekeerde geldt: Deluge direct achter modem, en curl test via de Mikrotik -> HTTPS vertraagt of wordt gereset.

Ik heb een verleden in networking en traffic shaping, en wat hier gebeurt lijkt mij geen normaal netwerkbeheer. Immers de lijn wordt niet gesatureerd, en zelfs als P2P hard wordt afgeknipt in de Mikrotik (bvb 64 kbit upstream via een simple queu, dus een fractie van de 50 mbps upload) dan nog steeds wordt HTTPS vertraagd of gereset.

Deze ochtend draaide ik een test met enkel P2P protocol verkeer, en de invloed op HTTPS:

Een gelijkaardige curl naar userbase.be of de Roon api url, zorgt zelfs voor resets:

$ while sleep 1; do curl https://userbase.be/api >/dev/null; done
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 274 0 274 0 0 1053 0 --:--:-- --:--:-- --:--:-- 1053
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:04 --:--:-- 0
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to userbase.be:443
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 274 0 274 0 0 2283 0 --:--:-- --:--:-- --:--:-- 2283

[Janneke_Dust]

welk privé subnet gebruikt uw router en welk subnet gebruikt de modem voor de direct aangesloten toestellen.

[FredericV]

Ik gebruik al bijna 20 jaar meerdere /24 vlans binnen de 172.16.0.0/12 range.
De machine waarop de docker draait, zit in een eigen VLAN.

Deze machine direct op de modem en dus een 192.168.0.X adres: probleem blijft, dus met de interne ranges heeft het normaal niks te maken.

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