Deel glasvezelklanten Solcon heeft sinds dinsdagochtend geen internet - update

Een deel van de klanten van Nederlandse provider Solcon heeft sinds dinsdagochtend nauwelijks of geen internet door een storing op het glasvezelnetwerk. Er treedt veel packetloss op, waardoor de verbinding wegvalt. Solcon weet niet wanneer het probleem kan worden opgelost.

Op zijn statuspagina maakte Solcon dinsdagochtend om 7.30 uur voor het eerst melding van de storing. Tweakers ontving van meerdere klanten klachten over de storing. Het betreft een landelijke storing op het ftth-netwerk van de provider. De storing heeft invloed op internet, tv en e-mail.

Een tweaker die klant is bij de provider, stelt dat met name clouddiensten last hebben van de storing. Rdp, ftp en webuploads zouden daardoor niet werken. De provider wist hem te vertellen dat de problemen zijn ontstaan na een update van een access switch.

In de loop van dinsdag heeft Solcon de oorzaak van het probleem niet kunnen lokaliseren. De provider zei samen met de leverancier te zoeken naar de oorzaak. Woensdag om twaalf uur 's middags heeft Solcon een update op zijn statuspagina geplaatst. Daarin zegt de provider dat bij 'een aantal' verbindingen minder packetloss is te zien, maar het probleem blijft aanwezig.

Ook meldt Solcon dat er glasvezelverbindingen zijn die geen packetloss ervaren, maar ook geen verbinding op kunnen zetten. Dat neemt de provider mee in het lopende onderzoek. Een oplostijd kan Solcon nog niet geven.

Een maand geleden had Solcon ook een storing waardoor klanten last hadden van een wegvallende verbinding door packetloss. Destijds zei een woordvoerder dat er ongeveer honderd klanten problemen ondervonden. De provider heeft in totaal 25.000 glasvezelklanten.

Update 16.15: Solcon heeft gereageerd op vragen gesteld door Tweakers. De provider stelt dat er zo'n duizend klanten zijn die last hebben van packetloss. Verder zegt de provider de problemen geïsoleerd te hebben tot twee gebieden: omgeving Putten, Ermelo en Nunspeet en de omgeving Deventer. Door aanpassingen aan de zijde van Solcon zou de packetloss inmiddels gedaald zijn van 50 naar 10 tot 15 procent.

Solcon ontkent dat er aan de zijde van Solcon netwerkaanpassingen hebben plaatsgevonden. De oplossing van het probleem ligt volgens de provider aan de zijde van de netwerkleverancier. Die heeft de storing sinds gisteravond in onderzoek en vandaag de storing opgeschaald naar een expertteam. Solcon zegt intensief te overleggen met de leverancier om de storing zo snel mogelijk te verhelpen. Een verwachte eindtijd kan de provider echter nog niet geven.

Update 2, donderdag 14.08: Solcon meldt dat de problemen met packetloss donderdag rond 5.30 uur 's morgens zijn opgelost.

Door Julian Huijbregts

Nieuwsredacteur

21-06-2017 • 13:41

50

Reacties (50)

50
47
25
5
1
11
Wijzig sortering
Ik vind het - als Solcon gebruiker - erg jammer dat Tweakers Solcon binnen een maand weer op de frontpage zet met een storing, terwijl de oorzaak gezocht moet worden bij één van de vele toeleveranciers van netwerkdiensten waar Solcon gebruik van maakt. Ja, Solcon moet in staat geacht worden om snel een oorzaak analyse te verrichten. Maar ik vind het wat makkelijk om gewoon blunt te posten dat Solcon weer een storing heeft zonder verder onderzoek. Tweakers, dat kan beter!
Vraag 1 voor Tweakers-journalisten: heeft Solcon die expertise?.
Vraag 2: welke netwerk faalde een maand geleden? KPN?
Vraag 3: wat netwerk faalt er nu?

In het Rekam gebied werkt de FTTH verbinding gewoon. Alleen Solcon TV werkt niet.

Wijziging reactie: typo's

[Reactie gewijzigd door MOmax op 22 juli 2024 15:10]

Het is natuurlijk een feit dat een afnemer niets te maken heeft met een andere leverancier. Als jij een ISP begint en een enkele lijn afneemt bij KPN en die gaat plat kan ik KPN ook niet de schuld geven maar dan is het toch echt Solcon die een fout heeft gemaakt. (Zeg trouwens niet dat het zo is)

Alle netwerken maken gebruik van andere leveranciers maar de afnemer heeft maar met 1 partij te maken, degene waar je een contract mee hebt. Het is juist van belang om designs zelf te testen en te valideren in een gedegen testopstelling, iets wat helaas niet altijd maar gebeurd en dan maar op de blauwe ogen van een leverancier wordt vertrouwd.
(ook Solcon gebruiker) Dat ze nu vaker in korte tijd grotere storingen hebben, is voor mij wel nieuwswaarde. Storingen met deze tijdsduur zijn bijzonder en geeft mij het gevoel dat ze de controle over techniek en proces misschien wel beetje verloren zijn of ten minste aan het verliezen zijn.

En je kunt lastig zeggen dat de partij erachter verantwoordelijk is. Wij nemen bij Solcon een dienst af. Dat Solcon vervolgens die dienst uitbesteedt, of het onderhoud, of welk onderdeel van hun proces ook, is waar Solcon voor gekozen heeft en waarvan de klant mag verwachten dat ze dat goed gedaan hebben, conform contract.

Ook ik ben wel van de kleine, lokale, partijen. Maar buiten deze storing, heb ik al lange tijd instabiel internet, waarbij de helpdesk geen storing wilde aanmelden en mij de dienst zelf wilde laten testen. Pas bij aangeven dat ik wil opzeggen, gaan ze op onderzoek uit en vinden ze dat mijn genexis kastje fouten geeft.

Dit was 5 jaar geleden bij Solcon anders. Toen belden ze je zelfs terug na het opgelost te hebben om te vragen of het weer werkte! Ik heb destijds perplex gestaan. Een helpdesk die uit zichzelf terugbelt. Ook degene aan de telefoon had kennis.

Helaas heeft Solcon kennelijk een aantal keuzes gemaakt, of moeten maken, waardoor het nu een stuk minder is (zie ook laatste consumentengids isp onderzoek 1e kwartaal 2017). Ik ben groot voorstander van dit soort kleinere bedrijven die de grote isp's scherp kunnen houden doordat ze innovatiever moeten zijn. Het lijkt er echter op dat Solcon het niet meer lukt om de beste te zijn. Misschien omdat de innovatie er wel uit is, ze ingehaald zijn, schaalgrootte missen,.... en dus kosten belangrijker worden, met alle gevolgen van dien.

Ik stond al op het punt over te stappen vanwege langlopende discussie met de helpdesk over wegvallen internet (op glasvezel). Ik heb inmiddels mij maar voor XS4ALL aangemeld. KPN dus eigenlijk. Ik gun Solcon het beste, maar mijzelf gun ik ook een stabiele internetverbinding, zodat ik na maanden weer kan bellen via whatsapp en de Sonos er niet tenminste 1x per avond minuten lang eruit klapt (spotify).
Zit zelf ook bij Solcon (en gun als lokaal bedrijf heel veel ten opzichte van de grote jongens). De eerste jaren was de stabiliteit echt hoog, jaren geen storing gehad. Sinds ze vorig jaar iedereen verplicht hebben overgezet naar Solcon TV zijn er bijna maandelijks problemen. Om te beginnen was de server niet stabiel, daarna een verkeerde instelling in de Genixs glasbix (4 maanden onderzoek) waardoor het beeld niet stabiel was. En nu ook af en toe haperingen op internet. En dit allemaal op het eigen Solcon netwerk in Dronten. Gelukkig hebben nu nog DVB C als uitwijk voor Solcon TV, vanaf augustus is dat ook voorbij en moet het echt weer stabiel worden anders wordt het echt een andere isp, hoeveel ik ze ook gun als lokale partij!
Een tweaker die klant is bij de provider stelt dat met name clouddiensten last hebben van de storing. Rdp, ftp en webuploads zouden daardoor niet werken.
'Clouddiensten'... wordt daarmee het afnemen van diensten van partijen die werken via CDN's bedoeld (CloudFlare, etc.), of is het probleem echt beperkt tot RDP (waarom gebruik je puur RDP over het Internet?!), FTP en HTTP uploads?

Dat lijkt mij onwaarschijnlijk dankzij netneutraliteit. Het lijkt mij eerder dat alles waarbij het uploaden van gegevens in grote hoeveelheden en/of met een korte latency problemen oplevert. Hier zouden dus ook bijvoorbeeld VPN's last van kunnen hebben.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:10]

Om even te reageren op het RDP gedeelte; wat is het probleem met RDP via internet? Kan prima en is daarmee ook niet onveiliger dan bijv. een HTTPS verbinding. Met of zonder VPN zou ook niets uitmaken. want een VPN z'n verbinding is ook niet veiliger dan een RDP verbinding (met ssl aan natuurlijk, wat het standaard is). Enige waar je voor moet zorgen is dat de verbinding alleen mogelijk is vanaf de clients die je daarvoor wil toestaan en specifiek toegewezen gebruikers een RDP sessie laten maken welke een sterk ww hebben.
Anoniem: 1322 @mrdemc21 juni 2017 19:35
Wanneer je iets aan het internet hangt dien je zo min mogelijk poorten open te zetten. Wanneer iemand RDP zonder VPN open zet aan het internet schop ik hem de zaak uit. Exploitatie van RDP (via bijvoorbeeld een zeroday exploit) zou direct betekenen dat de machine volledig compromised is wat weer betekent dat deze volledig opnieuw opgebouwd moet worden (lees: format c:).
En dan mag je nog blij zijn als het daarbij is gebleven. Alles wat vanaf die machine benaderbaar is moet ook als verdacht worden beschouwt.

RDP is daarnaast nog voornamelijk username/password waardoor het zeer geschikt is voor bruteforce hackpogingen. Het leuke daar weer aan is dat je enkel een waarschuwing krijgt in de Windows security eventlog. Daar kijkt nooit iemand in. Combineer dat met het feit dat 'administrator' geen user-lockout policy heeft en je hebt de mooiste target om eens goed te bruteforcen.

Microsoft best practice is ook duidelijk. Alleen RDP waar het echt nodig is en dan via een firewall alleen benaderbaar via je management netwerk.

Ik zou zeggen, kijk eens op die machine naar de security logs en trek zelf je conclusie of het een goed idee is.
Met een losse firewall ervoor zou je dat probleem dus kunnen oplossen. daarnaast is dat ook nog steeds de standaard methode om een Windows server in de Azure omgeving te beheren. Gelukkig heb je ook meer logging tools dan alleen de eventlog die je daarvoor kunt gebruiken :)
Anoniem: 1322 @mrdemc21 juni 2017 20:03
Inderdaad, een firewall geeft je een eerste laag beveiliging. Bij azure hangt Microsoft ook nooit de VMs zomaar aan het internet maar worden ze beschermt door firewalls (specifiek, hun network virtualisation product).

When VMs are exposed to the Internet, it is important that you control network traffic flow with network security groups (NSGs). Because NSGs can be applied to subnets, you can minimize the number of NSGs by grouping your resources by subnet and then applying NSGs to the subnets. The intent is to create a layer of network isolation, which you can do by properly configuring the network security capabilities in Azure.
You can also use the just-in-time (JIT) VM-access feature from Azure Security Center to control who has remote access to a specific VM, and for how long.


Daarnaast geven ze aan nooit de machine direct aan het internet te hangen:
Organizations that don't enforce network-access restrictions to Internet-facing VMs are exposed to security risks, such as a Remote Desktop Protocol (RDP) Brute Force attack.
https://docs.microsoft.co...curity-best-practices-vms

Uiteindelijk draait het allemaal om security lagen die je inbouwt. Meer lagen = meer security. Vooral voor azure zou ik altijd voor een Azure VPN Gateway gaan. Deze is zo uitgerold.
Een VPN zijn verbinding is over het algemeen wel degelijk veiliger dan direct rdp.

Zo gebruik ik een VPN met wachtwoord en shared secret om vervolgens via screensharing naar een ander subnet te verbinden alvorens ik daar een ARD kan launchen om packets te deployen. Op die manier is het iets trager, maar wel vele malen veiliger dan alleen de rdp verbinding. Meestal ben ik namelijk on site en kan het dan direct en voor die ene keer dat het wel echt remote remote moet zet ik de VPN wel aan. Zodoende kan ik veel beter bijhouden welke externe verbindingen er in gaan. Iemand die namelijk de VPN verbinding kraakt kan nog steeds niet aanrichten.
Ik snap er niks van. Hoe kunnen gebruikers hier dan mee werken?
Of is dit een tweaker omgeving zonder betalende klanten?

[Reactie gewijzigd door pe0mot op 22 juli 2024 15:10]

Niet. De gebruikers is mijn familie die geen externe toegang nodig hebben. Het is voor mij zodat ik makkelijk software kan deployen.

En zelfs al zouden er wel betalende klanten aan kunnen dan nog zou ik er wel een vpn tussen hangen zodat ook het externe netwerkverkeer via een vertrouwde server loopt. De machine met de RDP sessies wordt dan wel intern gekloned naar een machine in het andere subnet als de sessie gesloten wordt. Zodoende kan er eerst gekeken worden of cryptolockers afwezig zijn.
Buiten dat is het altijd prettiger om meer dan één drempel te hebben. Een VPN laag is een meer dan uitstekende eerste laag, waar je vervolgens RDP bovenop kan kleien of wat je ook maar wilt. Robuust, overzichtelijk, simpel en standaard uit te rollen voor zowat elke locatie. En ik gebruik dan ook nog eens filtering op source- en destination adres waar mogelijk en als dat niet kan port knocking om tijdelijk een poort in mijn netwerk open te zetten om binnen te komen in de eerste ring.

Mijn model is een drielaags model:
* Eerst mijn eigen opstapserver bereiken en beveiligd/encrypted op inloggen
* Daarvandaan een VPN opzetten naar het doelnetwerk
* En dan vanuit dat netwerk de RDP sessie starten met de lokale PC daar

Inderdaad wat trager, maar om in het doelnetwerk terecht te komen heb je kennis nodig uit alle lagen. En het werkt immens stabiel en goed met een configuratie die ook uiterst overzichtelijk is. Alleen jammer als je opstapserver even niet thuis geeft :)

Supersnathan94 snapt het wel :)
Precies! Plus alle bijkomstige passwords en accounts. Voor mij zijn dat al 8 verschillende units die je moet weten. Mis je er 1 dan kom je nergens. Dus zelfs als je alle lagen gaat bruteforcen heb je voor alleen de VPN al een supercluster nodig.
malware op de client kan nog steeds alle keystrokes loggen. Of gebruik je ook een persoonlijk certificaat bijv.?
Klopt idd. Maar ook dan heeft mn VPN inderdaad een profiel met account en pre shared secret daar al ingezet (die deploy ik zelf). Daarnaast is die VPN ook Mac Only en check ik die mac ook omdat ie vaak in mijn beheer staat (malwarebytes erover).

Al met al is het lastig om de eerste laag door te komen met alleen keylogging en zijn overige lagen ook niet per se bedoelt voor externe gebruikers. Die VPN is leuk, maar alle admin tools staan weer twee lagen verder.
Hoe kan je als ISP zijnde, je storingen niet vinden?
Als ze niet zeker weten of het door de update op de access switch komt, roll de update terug (dus naar de vorige versie waar het wel werkt) en kijk dan of het effect heeft. Simpelweg Trial and Error.

Heeft Solcon dan zelf geen stappenplan en/of een logboek waarin ze elke verandering vermelden?
Qua eerlijkheid vind ik het wel goed, ze zeggen dat zij het niet weten waardoor het komt.

Zit zelf bij Ziggo (Voormalig UPC gebied), heb tot nu toe nog geen problemen ondervonden.

Voor de mensen die bij Solcon zitten, sterkte... Het is lastig als je niet weet wanneer je weer gebruik van de diensten kan maken...
Dat het moeilijk is de oorzaak van een storing te achterhalen komt door de vele factoren die meespelen. Het kan een bug in de router software zijn (ondanks dat die dingen een vermogen kosten zijn ze niet bug-vrij), een kapotte SFP module om een fiber aan te sturen, leveranciers van verbindingen kunnen intern een probleem hebben waardoor de provider het niet kan debuggen en afhankelijk is van de leverancier, etc etc etc.

Ik doe zelf vaker dit soort debug-werk, en het kan een enorme puzzel zijn om er achter te komen wat het daadwerkelijke probleem is, waar het zit, hoe het op te lossen is, en door wie. Het is heel vervelend, ook voor de provider. Het internet is complexer dan het soms lijkt...
Anoniem: 392841 @sjmsteffann21 juni 2017 16:42
Hm... Kan je geen koppeling op bepaalde plekken zetten waar dan metingen plaatsvinden, zodat je vlugger kan bepalen op welk gedeelte je specifieker moet gaan zoeken?

Zelf ben ik niet bekend met dat soort architectuur, dus als ik het mis heb zeg het maar....
Anoniem: 40104 @gamezfreak21 juni 2017 16:23
Het probleem is vaak dat dergelijke providers, zeker die met maar 25.000 klanten vaak hun hele netwerk operations hebben geoutsourced om een paar centen te besparen. De beheerder heeft vaak totaal geen praktische kennis van het netwerk en gebruikt wat volk uit India om op de knoppen te drukken. Allemaal mooi zolang het goed gaat maar als mijn provider een storing van uren of dagen heeft dan gaat er per direct een opzegging op de post.
Grappig dat je over Ziggo begint. Die hadden gisteren 24 uur storing in mijn postcode gebied. Alles lag er uit en niemand weet nog waarom. Alleen dat het om acht uur vanmorgen weer werkte. Ook dit duurde langer dan verwacht (2 maal deadline verplaatst).
Ik zit ook bij Ziggo (Voormalig UPC gebied) en ik moet zeggen dat recent de kwaliteit van de dienstverlening hard achteruit is gegaan. Constant verstoringen, ook herkenbaar van wat @supersnathan94 daar over zegt. Vaak lang eruit op tijdstippen dat je de verbinding als consument juist wil gebruiken en als het wel werkt upstream/backbone problemen vergelijkbaar met het Solcon probleem.
Anoniem: 855731 @gamezfreak21 juni 2017 19:59
Bij welke ISP of netwerk provider werk jij en weet jij altijd direct waar de storing zit?
Bij welke ISP of netwerk provider werk jij en weet jij altijd direct waar de storing zit?
Off
Ehh, ik werk bij geen een ISP, zit in mijn laaste jaar van MBO-4 ICT. Waar ik tot nu toe stage heb gelopen, heb ik veel ervaring opgedaan. Als je een update toepast en de volgende dag klagen er mensen erover, verwijder de update en kijk dan of het is opgelost. Kwestie van alles gedocumenteerd hebben, dan weet je ook waar je moet zoeken.

Laatst een probleem gehad dat Outlook niet wou starten, kwam door een van de updates van Patch Tuesday. Zolang je documentatie niet op orde is, kan het nog wel eens chaotisch zijn (ik spreek uit eigen ervaring)
Dat zijn twee belangrijke zaken, die je nooit moet vergeten en een club als Solcon past vast ook een soortgelijke methode toe. Alleen is het wat complex dan het terugdraaien van een Outlook-update na Patch Tuesday ;)

Wanneer iets absoluut niet doet heb je vaak wat meer ruimte, maar er is hier sprake van packetloss. Zover ik kan zien betekend dat niet dat in de drie genoemde plaatsen niks doet, maar dat zegt niet direct alles. Netwerken zijn vaak (minimaal) dubbel uitgevoerd, maar dat wil ook wel eens voor 'problemen' zorgen.

Lees maar een incidentrapporten van providers of datacenters https://www.bit.nl/news/1189/91/Disruption-BIT-network
Dat en het feit dat je natuurlijk eerst wil weten of eea met elkaar te maken heeft. Ja, het kán die patch zijn, maar dat hoeft niet. Soms is het gewoon stom toeval. Infrastructuren zijn soms dermate complex dat je er inderdaad lang over kunt doen om een probleem te vinden. En het stomste dat je kunt doen is wilde acties uitvoeren zonder dat je weet wat de oorzaak/bron van je probleem is.
Dit is al de 4 storing die ik bij Solcon heb in 6 weken tijd. Maak iedere keer een ticket bij ze aan en krijg alleen te horen "we hebben een storing" en meer niet, heb vandaag XS4ALL aangevraagd omdat ik het zat ben.
De storing van nu veroorzaakt een hele instabiele verbinding, heb wel internet connectie maar door de packet loss kan je bijna niets doen.

[Reactie gewijzigd door BoLCoM op 22 juli 2024 15:10]

Dit hebben wij dus ook gedaan. Duurt iedere keer weer dagen voordat een storing is verholpen, waar we in het begin nooit storingen hadden. En wanneer je belt krijg je het standaard antwoord. Van een super provider naar een hele slechte provider.
Ben sinds vandaag over naar XS4ALL. Sinds het nieuwe tv pakket van vorig jaar was ik niet meer gelukkig met Solcon en n.a.v. de 3 daagse storing van vorige maand heb ik de knoop doorgehakt.
Er was gisteren een storing bij Signet die melde dat Amsterdam Exchange en Provider "Interconnect" problemen had.

https://signet.nl/content/customer-services?rf=icon
Melding op Signet website staat er niet meer op.
Signet: 21-jun, 09:05: De oorzaak van de verstoring bij de AMS-IX is inmiddels bekend: "We localized issue with one of our members which configured proxy-arp on the interface faced production LAN. Customer fixed an issue and we moved it back into production LAN." [JS]status: opgelost

Zie ook https://www.interconnect....te-storing-vanuit-ams-ix/
Het kan zijn dat u gisteren bemerkt heeft dat uw site of mail minder goed bereikbaar was, er bleek sprake te zijn van een probleem bij de AMS-IX (Nederlands grootste internetknooppunt). Op AMS-IX kunnen aangesloten partijen netwerkverkeer met elkaar uitwisselen. Deze problemen zorgden dus niet alleen bij Interconnect voor hinder, maar bij meerdere hostingpartijen en toegangsproviders in Nederland. Wij hebben vrijwel direct de verbinding afgesloten en het verkeer omgeleid om de bereikbaarheid te waarborgen. De capaciteit van ons netwerk is groot genoeg om te allen tijde de uitval van een of meerdere knooppunten op te kunnen vallen. De storing is inmiddels verholpen door technici van AMS-IX.

[Reactie gewijzigd door peddler op 22 juli 2024 15:10]

Het regent ook klachten bij Caiway op CIF, wellicht dat dit dus van bovenaf mis gaat.
Ik hou een 3-tal solcon verbindingen in de gaten d.m.v. smokeping, allen gaan over CIF glasvezel.
2 daarvan zijn buren van elkaar, IP adressen zijn ook .44 en .45 :) De 3e verbinding is in een andere gemeente.

Het merkwaardige is dat 1 van die buren nergens last van leeft. De andere wel, maar het valt op dat op het moment het daar weer even goed gaat, de verbinding bij de 3e verbinding ineens wel last krijgt.
Zie http://corky.wurtel.net/~paul/solcon-20170621.html voor de grafiekjes.

Ik zou haast zeggen het gaat ergens mis bij een load-balanced verbinding.
Ik ben één van de gelukkige klanten die alle recente Packet-loss storingen bij Solcon heeft meegemaakt.
- 17 mei tot 20 mei
- 8 juni tot 11 juni
- 20 juni tot ......

In de update staat: "Verder zegt de provider de problemen geïsoleerd te hebben tot twee gebieden: omgeving Putten, Ermelo en Nunspeet en de omgeving Deventer."
Ik woon niet in de genoemde regio's en hier is het probleem helaas weer/nog steeds actueel :'(
Wat schering en inslag lijkt te zijn, is dat providers dit soort kennis hebben ge-outsourced. Dat hoeft overigens niet per definitie slecht te zijn, maar de reden is toch vaak dat het goedkoper moet. Daardoor staan SLA afspraken onder druk en je bent 100% overgeleverd aan je leverancier en je hebt zelf geen kennis meer.

Vervolgens gebeurt er wat en wordt pas de volgende dag een expertteam opgeschakeld. Tja, dan heb je jezelf in een lastig parket gemanoeuvreerd. Geen kennis in huis, waarschijnlijk een best effort contract met je leverancier en klagende klanten met - zoals blijkt - voldoende media aandacht. Er zijn bedrijven die er failliet aan gaan.

De klant wil niet meer betalen dan 20-30 euro voor zijn internet en daar moet alles in passen qua kosten. Heb je geen schaalgrootte, dan geeft outsourcen een voorspelbaar kostenpatroon en lage personeelskosten aan jouw kant. Maar dan moet je niet teveel van dit soort dingen hebben.

Kortom: Lastig voor Solcon, die lijken keuzes te hebben gemaakt om de boel bestuurbaar te houden, maar zitten daarmee in een lastig parket met een storing als deze. Sterkte!

PS: Ik neem aan dat de laag 2 verbinding blijft staan, maar je laag 3 verbinding onderuit gaat door die veelheid van packetloss. Technisch gezien gaat je verbinding dan niet onderuit (want laag 2), maar je TCP connecties geven het op. 't Resultaat blijft natuurlijk om te huilen ...

[Reactie gewijzigd door Houtenklaas op 22 juli 2024 15:10]

Maandelijks probleem van Solcon? In Mei hadden ze immers ook problemen rond deze tijd.
staat zelfs nog bij mij onder Lees meer: problemen in mei

Op dit item kan niet meer gereageerd worden.