CV8560E in bridging en max aantal connecties

[FredericV]

Ik ben al een tijdje aan het zoeken op een Roon probleem, die random SSL connecties reset volgens de Roon log. Je knalt dan in het midden van een track uit Tidal, of de cover art laadt niet meer.

Aan mijn CV8560E hangt een Mikrotik RB1100AH (x2) in bridging, en deze heeft meerdere VLANS met elk hun eigen firewall rules.

De set met Roon zit in een VLAN wat mijn normaal thuisnetwerk is.

In een aparte VLAN zit een machine die graag veel connecties kort open gooit, zonder daarbij echt traffic te doen.

Het aantal connecties schommelt tussen de 500 en 2000+ en in de netfilter conntrack staan deze op TIME_WAIT, dus voornamelijk idle connecties die geen bandbreedte gebruiken.

Met een netstat zie je dat het aantal werkelijke connecties minder dan 10 is!

Helaas blijven de idle nog af te sluiten connecties ook zichtbaar in de Mikrotik:

Code: Selecteer alles

[admin@MikroTik] /ip firewall connection tracking> print 
                   enabled: auto
      tcp-syn-sent-timeout: 5s
  tcp-syn-received-timeout: 5s
   tcp-established-timeout: 1d
      tcp-fin-wait-timeout: 10s
    tcp-close-wait-timeout: 10s
      tcp-last-ack-timeout: 10s
     tcp-time-wait-timeout: 10s
         tcp-close-timeout: 10s
   tcp-max-retrans-timeout: 5m
       tcp-unacked-timeout: 5m
        loose-tcp-tracking: yes
               udp-timeout: 10s
        udp-stream-timeout: 3m
              icmp-timeout: 10s
           generic-timeout: 10m
               max-entries: 1048576
             total-entries: 634

Maar het totaal is dus een peulschil tov de max entries, en deze idle connecties veroorzaken amper upload.

In de Mikrotik GUI zie je het totaal soms heftig schommelen tussen minder dan duizend en enkele duizenden connecties in een paar seconden.

Dus ik vermoed dat we op een andere plaats tegen een of andere limiet aanlopen. De CV8560E staat in bridging.

Is de bridging een echte layer 2 bridging, of doet deze nog veel meer dan dat?

Toegevoegd na 2 uren 49 minuten 31 seconden:
Ik heb een sterk vermoeden dat Telenet ergens throttling toepast:

1. Roon hangt nu aan z'n eigen Mikrotik L009 series router, met niks anders buiten een phone met wifi om Roon te bedienen. Deze setup is met dubbele NAT helaas - maar alles werkt.

2. De rest van het netwerk hangt aan de RB1100AH, en de doos die veel connecties open gooit daarvan staat de docker applicatie die dit doet uit - alles werkt.

Het gaat dus om 2 gescheiden netwerken met elk een eigen WAN IP.

Van zodra we de docker applicatie aanleggen, die via de RB1100AH aan de modem in bridge hangt , knalt Roon's Tidal er vrijwel direct uit, die aan de L009 hangt.

De conntrack van deze routers horen op geen enkele invloed te hebben op mekaar. Er moet dus ergens door Telenet een cumulatieve policy zijn overheen het totaal van één modem, die beperkt hoeveel connecties een modem mag opbouwen, ongeacht wat aan de modem hangt in bridge staat, of NAT doorheen de modem. Of een andere technische beperking in de CV8560E.

Traffic metingen gedaan en er wordt maar een fractie van de modem snelheid benut, dus dat kan het ook niet zijn.

Ga nu verder testen met de docker volledig uit, en kijken of het Tidal probleem nog triggert. Het is wel al veel minder dan gebruikelijk.

Het is net 2011 ...

viewtopic.php?p=385734

[splinterbyte]

Heb je de modem al eens herstart?

[FredericV]

Modem restarted.

Ter info het piekje wat de docker applicatie even kort trekt, is in de orde van 6500 packets/s via de RB1100AH . En hup, enkele minuten nadien faalt Tidal op Roon weer op de andere router die samen de modem deelt, ondanks de reboot.

Morgen eens bellen met Telenet, dat we vermoeden dat er iets fout is met de modem. Dit soort load zou de connectie niet labiel mogen maken, en al zeker niet het resetten van HTTPS / SSL connecties.

A 50 Mbps upstream connection has a theoretical maximum of roughly 33,300 packets per second, assuming a 1200-byte (including Ethernet headers) packet size, but the actual maximum number will be lower due to variable packet sizes and network overhead. Network performance metrics, such as packets per second (pps), are more reliable for comparisons when using consistent packet sizes.

Het zit er immers ver ver onder ...

Toegevoegd na 10 uren 15 minuten 23 seconden:
Zonder de Docker applicatie actief, heeft Roon een hele nacht een Tidal playlist van 8 uur afgespeeld. Toen ik deze ochtend naar Roon keek, was Tidal nog steeds niet uitgelogd. Het is dus duidelijk dat de modem of iets bij Telenet niet omkan met de transient spikes in packets per second, die de Docker applicatie kortstondig genereert.

[splinterbyte]

Welke docker app is dat of kan je zeggen hoe je dit simuleert dan kan ik dit bij Orange 1000/50 ook eens testen?
Ik heb namelijk ook steeds veel connecties (vooral UDP) lopen en de conntrack count op mijn linux router is momenteel 3807 zonder problemen.

[FredericV]

Nieuwe modem gaan halen, montage was easy. Terug een witte CV8560E.

Docker app terug gestart, kort piekje van 5.7 mbit up en bijna 5000 pps piek, nu weer idle:

Benieuwd of Tidal er weer uit gaat knallen. En ja helaas - Tidal is er uitgeknald ondanks de modem swap.

Het lijkt er dus op dat Telenet netwerkbeheer hier voor iets tussen zit, of een bug die meerdere modems treft, of een hardware beperking.

We weten natuurlijk niet welke rate limiting / packet shaping of andere connection tracking beperking actief is in een modem die in bridge staat.

[devilkin]

Ik heb met regelmaat zeer veel UDP connecties openstaan en heb dit nog nooit voorgehad met de cv8560e.
Kan je eens iets meer details verstrekken dan "docker app"?

[Pho_]

T zou inderdaad handig zijn om te weten wie/wat er zoveel connecties maakt. Ik zou kunnen testen via een eigen modem.

[FredericV]

Net de hele uitleg via een formulier naar TN doorgestuurd, en net telefoon dat er upstream problemen zijn in de wijk, ook gerapporteerd door andere gebruikers.
Het is al sinds 10 september ongoing, en ja al weken krijgen we de Tidal errors.

Ze komen vandaag nog langs.

[FredericV]

Gisteren is er iets foutgelopen en niemand langsgekomen. Vandaag opnieuw gebeld.

Persoon aan de lijn werkt al 17j bij TN en kon direct zeggen dat de upload flappert. Ze zien op één of ander grafiekje dat de lijnkwaliteit flappert.

Er is blijkbaar een probleem met een filter om TV ontvangst te blocken of een vochtprobleem in de 'paddenstoel' die in de voortuin staat, die deze filter doet oxideren.

Dus hopelijk is het coax probleem weldra opgelost, nu ze meer concreet weten waar ze moeten gaan zoeken.

Benieuwd hoe de filter er uit ziet die in de paddenstoel zit. Vond hier 2 voorbeelden van zo'n "TOF":

viewtopic.php?p=641551#p641551
//uploads.tapatalk-cdn.com/201601 ... cd0a94.jpg

Dame aan de lijn vandaag was zeer vriendelijk, en wist veel meer dan de medewerkers met wie ik eerder belde. Bevestigt dat TOF wellicht kapot is.
Dus hopelijk is upload weldra stabiel.

Toegevoegd na 3 uren 58 minuten 27 seconden:
De TOF = TV filter is vervangen. Voordien stonden de lijnwaardes op rood, technieker heeft dit laten zien.

Slecht nieuws:

Van zodra de docker actief is, wordt een deel van nieuwe SSL connecties naar de roon API gereset.

Op de Roon machine draai ik

while sleep 1; do curl https://api.roonlabs.net > /dev/null; done

Als ik deze test opnieuw doe, met m'n eigen domein als test, dan blijft dit gewoon draaien.

Ik zie wel dat de latency soms oploopt tot 8 seconden:

Het kan uiteraard dat de Roon API geen geduld heeft, maar dan nog, een simpele Deluge docker die dan nog idle is, mag niet plots regulier HTTPS zo extreem vertragen.

[FredericV]

Ondertussen heb ik in de Mikrotik als test de docker zijn upload beperkt tot slechts 64 kbit via simple queu's, en in de plot zie je dan de extreme beperking in de toegestane upload.

En hup, van zodra er P2P is, gaat Telenet at random sommige HTTPS connecties met 8 seconden vertragen.

Die 64 kbit stellt niks voor tov de 50 mbit die ik ook meestal haal in mijn 1000/50 profiel.

[TheCeet]

Was den truc niet alles achter VPN te steken? (indien mogelijk)

[FredericV]

@TheCeet VPN schiet niet op.

Als je max 0,128 % van de upload gebruikt voor P2P, (64 kbit tov 50.000 kbit) mag de rest daar niet onder lijden. En dit is nu precies wat Telenet doet.

Dit is geen eerlijke verdeling van de vrije bandbreedte:

"Verdeling bandbreedte
Eerlijke verdeling van vrije bandbreedte.

We verdelen de vrije bandbreedte op ons netwerk zo eerlijk mogelijk over alle gebruikers. Zo profiteren onze klanten van supersnel internet. Op extra drukke momenten beperken we de maximale snelheid van bepaald dataverkeer (bv. downloads, FTP,...) op plaatsen waar ons netwerk dreigt verzadigd te raken. Zo zorgen we ervoor dat onze klanten altijd vlot kunnen blijven streamen, browsen, gamen,..."

[datakiller]

Probeer anders eens die nieuwe F@ST modem? Die heeft ook bridge mode.

[FredericV]

Op aanraden van een ub lid: ben nu de test opnieuw aan het doen met een setje Linux torrents.

https://distrowatch.com/dwres.php?resource=bittorrent


950 mbit down om 22:00 is meer dan OK.
Zie nu wel dat de https test nu veel meer cases met latency heeft, wat te verwachten was. De lijn zit in één richting vol.

Maar het gaat om de case waar https wordt vertraagd of gereset, terwijl de lijn idle is (een TX van 64 kbit is voor mij zo goed als idle, als je 50 mbit hebt).
Dat verwacht je niet.

Ivm de nieuwe modem hoor ik wel dat deze met wifi is. Kan de wifi 100% uitgeschakeld worden?

[datakiller]

Ivm de nieuwe modem hoor ik wel dat deze met wifi is. Kan de wifi 100% uitgeschakeld worden?

Yep, hier recent nieuwe gehaald wegens poging IPv6 werkend te krijgen (werkt nog niet), op de modem zelf wel, in bridge mode ook, maar valt na x aantal tijd uit, met de nieuwe modem voor mij nog geen 24h

Maar latency is redelijk omlaag gegaan, dus misschien helpt dat, is broadcom ipv intel puma chipset. (1 a 2ms minder met ICMP op een 24h avg)

[FredericV]

@TheCeet dat is inderdaad de truuk, maar netjes is het niet.

Telenet is duidelijk in gebreke ivm net neutrality.

Van zodra we de traffic van de Deluge docker door onze eigen VPN trekken (geen grote fan van gezien verspilling van bandwidth, en extra rules moeten opzetten voor deze test, want onze VPN is voor beheer van onze toestellen in the field, en niet voor P2P), dan blijft de curl test die direct via Telenet loopt, gewoon instant antwoorden.

Dus ja, als je P2P traffic door een tunnel gooit, dan moeit Telenet zich niet met normale traffic zoals HTTPS.

Nog ter info: de gratis vpnbook openvpn profielen werken dus niet met P2P, dus dat was geen manier om dit correct vast te stellen.