Telenet herstart dhcp-servers na storing in geheel Vlaanderen

Telenet heeft laten weten dat zijn klanten in de loop van zondagmiddag weer kunnen internetten nadat de Belgische kabelaar kampte met een landelijke storing. Ook interactieve tv en voip kampten met storingen. De problemen zouden veroorzaakt zijn door een falende dhcp-server.

De problemen bij Telenet ontstonden zondagochtend. Klanten in geheel Vlaanderen konden niet langer gebruik maken van voip-telefonie, terwijl ook internetverbindingen en interactieve tv niet langer werkten. Digitale en analoge televisie bleven wel werken.

Oorzaak van de storing zouden falende dhcp-servers zijn, zo meldt De Standaard. Volgens Telenet-woordvoerder Stefan Coenjaerts deelden de servers niet langer ip-adressen uit waardoor alle toepassingen die gebruik maken van een kabelmodem niet langer verbinding konden maken.

Telenet zou vrij snel de oorzaak van de verbindingsproblemen hebben gevonden, maar de provider zou enige tijd nodig hebben gehad om tests uit te voeren. Een ploeg van honderd man zou bezig zijn geweest om de problemen op te lossen. Inmiddels zouden de dhcp-servers weer functioneren. Telenet verwacht dat alle klanten vanaf circa 14:00 uur weer gebruik kunnen maken van internet, voip en interactieve tv.

Reacties (114)

[egnappahz]

misschien heeft dit er iets mee te maken:

Meld je veilig aan op Mijn Telenet
Mijn Telenet is niet beschikbaar van zaterdag 2/02 van 18u tot zondag 3/02 18u wegens verbeteringswerken. Onze excuses voor het ongemak.

Stond er al zeker van gisteren op. toen telenet vannacht later uitviel dan maar ff getethert....

en nog een coole glitch meegemaakt met homespot nét voor de uitval:

60 mbit download en 5.6 mbit upload gehaald. ik snapte er helemaal niets van.

nu al wat meer....

[Tokkes]

Grappig... Ze doen bijna elke paar weken "verbeteringswerken", maar totnogtoe heb ik enkel meer redenen kunnen vinden om geen internet bij hun te nemen: Geen lokaal instelbare modem/router (alles moet via de webinterface vn Mijn Telenet... die dan de configuratie naar je modem pushed van over het internet), er veranderd voor de klant bitter weinig na die verbeteringswerken, die Mijn Telenet ligt er ook altijd uit als je nergens anders terecht kan om een eventuele aanpassing te doen aan je account, (helpdesks die dicht zijn). En sorry, maar de website van m'n ISP, meer bepaald de klantenpagina waar je je gegevens hebt en kan aanpassen... Da's niet bepaald een pagina waar ik elke dag op ga kijken. Na configuratie hoef ik er bijna nooit meer op te zijn. Dus ben je aan het streamen, loop je tegen de datalimiet aan. Ga je voor die keer in lange tijd naar Mijn Telenet om een blokje bij te huren.... zit je voor de rest van het weekend op f*cking smalband omdat Mijn Telenet er weer eens uitligt.

Daar komt de prijs van een standaard Telenet-abo'tje dan nog eens bij... Voor dat geld mag je toch echt verwachten dat zoiets relatief "stom" als een falende DHCP server je cyberzondagvoormiddag overhoop haalt? (okay er zullen er wel meerdere staan, maar als het de best practice is van Telenet om zo maar ineens ALLES te updaten terwijl er blijkbaar toch niet heel uitgebreid is getest ... dan moet Telenet hun best practices maar eens herbekijken.

[Reactie gewijzigd door Tokkes op 25 juli 2024 14:52]

[sycological]

"Geen lokaal instelbare modem/router (alles moet via de webinterface vn Mijn Telenet... die dan de configuratie naar je modem pushed van over het internet)"

Dikke zever! Ik heb gezegd dat ik enkel een modem wilde, dat ik mijn eigen router heb en ze hebben mij zonder probleem een modem only gegeven. Voor het gros van de bevolking, die geen kaas gegeten hebben van It zaken, is die modem/router ok. Wil je als iter iets anders, waar je zelf makkelijk je configuratie kan doen, gaat dit ook.
Dus informeer u eerst, ipv zo'n uitspraken te doen...

En ben je aan het streamen en loop je tegen je datalimiet aan... welke limiet?

[Tokkes]

Verzet maar eens flink wat data tijdens de piek-uren. Afhankelijk van je abo zullen ze op den duur sowieso eens moeilijk komen doen. Als je niet weet "welke limiet" ben je overduidelijk geen grootgebruiker. FUP != zonder limiet.

Allemaal heel fijn dat je een modem-only hebt gekregen, maar je mag er eens voor gaan rondvragen in je Telenet Centers in de buurt: meer dan de helft weet bij god nog niet eens dat dit wordt aangeboden. Daarbij is het gewoon absurd dat je pakweg je WPA en DHCP instellingen via de servers van Telenet moet configureren? Ben zelf ook geen fan van de prop. firmware van Belgacom op de BBOXes trouwens, maar dit gaat nog lokaal. Daarbij, veel mensen zijn best wel voorstander van een AIO-oplossing. Scheelt hem namelijk weer een doosje, stopcontact, een kabel en wat Wattuur. Het is daarbij perfect technisch mogelijk, aangezien je tot 2 jaar terug aan de lokale instellingen kon prullen door de modem zonder coax op te starten. Niet officieel ondersteund, of course

[Szz]

Het grote verschil is dat de helpdesk van Telenet op deze manier erg makkelijk er kan tussen springen en de mensen verderhelpen, gezien alles via Telenet zelf verloopt en het niet lokaal is. Voor de gemiddelde mens is die modem/router dus echt wel een goed ding, gezien die er niets van snapt. Leg maar eens uit over de telefoon hoe je een router moet instellen, zeker als het van merk x is, waar je zelf nog niet op hebt gewerkt. Dus ik snap de redenering hierachter wel, al ben ik er zelf niet mee akkoord... (vind het nogal op het randje van privacy schending dat ze aan local network dingen kunnen op die manier)

Dat gezegd zijnde, voor diegene die net iets meer controle wil, geven ze je graag een gewone modem zonder ingebouwde router. Ik ben onlangs pas overgeschakeld op fibernet en heb expliciet naar die modem only gevraagd als opmerking op de bestelling. Verder heb ik daar geen moeite in moeten steken. De technieker heeft me vervolgens, tijdens het installeren, even gevraagd wat mijn reden was en gaf me tenslotte groot gelijk in mijn motivering.

[Ibex]

Het moet in ieder geval wel iets met de DHCP geweest zijn. Ik heb hier gewoon mijn "oude" ip address static ingesteld en ik had gewoon internet zoals altijd .

Uitendelijk zijn dergelijke updates meer dan gewoon "windows updates" ofzo, waarbij je even moet herstarten en klaar.

Stel nu even volgend scenario: er zijn een aantal updates voor de dhcp server en die worden getest in het testlab met een paar 100den clients en routers etc. Alles lijkt prima te werken. Men besluit de update door te voeren naar de live systemen en de servers lijken prima te reageren. Maar wanneer alle servers geupdate zijn, en alle honderduizenden modems beginnen stillaan een nieuw ip te vragen (want 24h lease) blijkt dat er ergens een issue in de nieuwe software zit dat vanaf de 100000ste lease de servers beginnen duplicate ip's uit te delen waardoor de boel al snel plat gaat. - Om nu maar iets uit de mouw te schudden.

Stel dat de updates rond 12u 's nachts zijn gestart, met 2u tijd per update (omdat het een of ander complex proces is), tegen dat de 4de server geupdate is, is het alweer 8u. Tegen dat men alle updates gerollbacked heeft (snapshot terugplaatsen), is men 6u verder, en om 14u kan iedereen terug werken.

Ik bedoel maar, updates op dergelijke schaal zijn iets complexer dan de meeste mensen denken .

En 100 man is ook mest mogelijk (al zal het misschien eerder 50 geweest zijn ofzo); een 10 network engineers, een 10 mensen in het NOC die alles in de gaten houden, 50 support engineers die de business klanten die er last van hebben op de hoogte houden en helpen waar mogelijk, 5 mensen die de persberichten moeten opstellen, ...

[analog_]

Deze praktijk om je ex DHCP leases als static te configureren introduceert ook nieuwe problemen voor mensen die vervolgens jouw ex-lease krijgen. Het werkt maar ik zou het zelf niet doen op netwerken waarvan ik het ip-subnet niet beheer, het is vragen om meer problemen.

[Douweegbertje]

Wat is altijd zo leuk vind aan tweakers is dat opeens iedereen een expert is en wel had geweten hoe ze de gehele IT afdeling voor Telenet hadden moeten regelen.

Hier zit dus opeens 50 man die het allemaal precies snappen, en over alle technische gegevens beschikken. Sterker nog, als Telenet een keuze had gemaakt tussen één van de volgende tweakers was dit niet gebeurt:

Booster49
Goldwing1973
Tokkes
CaptJackSparrow
etc..etc..


echt kom op jongens, lekker open deuren intrappen.

Ze hebben gewoon een enorme fout gemaakt, waardoor heel het systeem op zijn gat ging. Verdere discussies over redundantie e.d. zijn zo achterlijk. Het is een ISP, hoogstens kun je hier en daar wat redundantie plaatsen voor elementen waar het nog wat oplevert.
9 van de 10 x is het het niet waard om pure core elementen redunt uit te voeren, dat zou feitelijk betekenen dat ook jouw abonnement 2x zo duur wordt.

Daarnaast weet amper iemand hier iets over de technische eigenschappen van het netwerk. Beetje verhaaltjes ophouden hoe het wel moest gaat niet op. Grote kans dat er op bepaalde punten dingen dubbel zijn uitgevoerd, maar dat er met een grote fout dit geen nut heeft.

[Tomsworld]

Om 15u30 geeft telenet tekst en uitleg :

http://www.nieuwsblad.be/...articleid=DMF20130203_034

"Het telecombedrijf geeft om 15u30 een persconferentie in Mechelen. "

[Core2Quad]

Het echte probleem is, aangezien ik de zoon ben van een Telenet-medewerker, dat ze bij hun DHCP servers een update hebben uitgevoerd en die was gefaald. Dus lag het hele netwerk plat

edit:
Typo

[Reactie gewijzigd door Core2Quad op 25 juli 2024 14:52]

[Anoniem: 329694]

En de falende wijziging kun je voorkomen door deze eerst in een testomgeving uit te voeren. Ik begrijp dus ook niet waarom ze na de faal actie wel testen uitvoeren, en niet voor de DNS wijziging.

[Teun_2]

Ik kan me niet voorstellen dat dit niet getest is. De enige verklaring is dat er bij de test niets is misgelopen, maar in de productieomgeving wel. Telenet is echt niet het bedrijf dat zijn technologische zaken niet op orde heeft. Klantvriendelijkheid en service kan beter, maar het bedrijf heeft zijn technische zaakjes best op orde.

[Tokkes]

Daarom dat het als officiele uitleg voor de datalimieten geeft dat het netwerk overbelast kan geraken als ze de grootverbruikers niet limiteren in hun dataverbruik? Daarom dat een half land een halve (super)zondag zonder internet zat na een crappy update? Is het normaal niet
DEV->TEST->PILOT->PROD? Dit had volgens mij bij de pilot-fase kunnen tevoorschijnkomen. En waarom blijkbaar alles ineens updaten? (aangezien de waarschijnlijke backup er ook uit lag)

Zoals ik eerder al reageerde op dit artikel: Telenet heeft monopolie in vlaanderen op de kabel. Eens mensen ergens bij een ISP zitten (in België toch) gaan ze zo snel niet veranderen (lees: bijna nooit). Komt nog eens bij dat VDSL nog niet overal evengoed beschikbaar is (12Mbit lijntje is niet optimaal voor TV te kijken) in België dus Telenet zit zowaar gebeiteld qua klanten. Waarom zouden ze in hemelsnaam kosten maken of moeite doen voor klanten die ze waarschijnlijk toch niet verliezen en andere klanten die ze toch niet van BGC gaat afnemen.

Laat nog eens een speler los op de vlaamse kabelmarkt en voor het jaar om is kunnen de lucky few onder ons een 500/500Mbit abo afnemen. Zolang Telenet alleenheerser blijft en kan pochen met 100Mbit als (enige?) in Vlaanderen, zal er nie rap iet veranderen.


@filipili:
Inderdaad, maar ik zou ervanuit gaan dat er iemand toch snel met de aanleg van een fibernetwerk zou beginnen en al een proefprojectje uitrollen. Okay, niet binnen een jaar, zelfs niet binnen 2, maar toch binnen ZEER afzienbare tijd.

[Reactie gewijzigd door Tokkes op 25 juli 2024 14:52]

[filipili]

500/500 lijkt wat veel over de kabel, gezien de huidige docsis standaard slechts ong 400/100 toestaat. De huidige Telenet modems kunnen naar verluid 200mbit aan.

Bij VDSL is het niet beter, met de VDSL Vectoring upgrade bij BGC zou het gaan tot zo'n 100 mbit, maar wel enkel over relatief korte afstand van hun vdsl straatkastje (ROP).

Wat er volgens mij dringend moet komen in dit Belgenland is FTTH.

[reaper_unique]

Omdat je met die test niet test of de update correct zal gebeuren. Het is dus mogelijk dat er tijdens het verrichten van de update zelf iets mis is gelopen. Dat is een belangrijk verschil dat sommigen al eens over het hoofd durven zien.

[Zer0CooL]

Sorry, maar deze reactie is echt COMPLEET naast de kwestie

[TereZz]

Daar gaat iets gruwelijk mis, 100 man om 1 DHCP server te herstarten/instellen.. Lijkt de overheid bijna wel.

14:42
Ik bedoel hiermee te zeggen, konden ze niet proactief een backup server inzetten in plaats van achteraf een probleem waardoor vele klanten zonder internet en belangrijker nog, telefonie zitten...
Je kunt niet voor alle klanten 1 DHCP server hebben zitten die het kan verprutsen voor heel het (klanten)netwerk van Telenet. Als dit zo is hebben zei simpelweg hun zaakjes niet op orde.

[Reactie gewijzigd door TereZz op 25 juli 2024 14:52]

[yvesg]

In een krantenartikel beschrijft de CEO van Telenet dat zij beschikken over 4 DHCP servers.
Elk van deze servers kan de hele load op zich aan, maar door een software-update (die naar mijn mening niet goed gepland is), gingen ze alle 4 tegelijk down.
Waarschijnlijk hebben ze de patch op alle 4 de servers tegelijk uitgerold en te laat gezien dat er iets mis ging.
Die 100 man die zijn opgeroepen zullen dan ook wel 'Helpdeskmedewerkers' geweest zijn.
Alhouwel de hele ochtend alle service lijnen van Telenet onbereikbaar bleven.

[Anoniem: 132385]

Moet de eerste vraag niet zijn... Wat was het voor een update en was deze wel noodzakelijk?

[triflip]

Je weet niet wat mis was met de DHCP server. Misschien moesten er eerst errors gefixt worden? En natuurlijk zijn die 100 man niet gebruikt om de server te rebooten maar om analyses te maken en testen te doen!

Beetje simpel, je lijkt de overheid wel!

[SuBBaSS]

Nou is het dan ook wel een beetje een suggestieve titel met zo'n "standaard consumentenhelpdesk-oplossing": even rebooten en klaar.
Uit het bericht zelf is wel op te maken dat het schijnbaar wat ingewikkelder ligt, want als ze 100 man nodig hebben voor 1 reset dan is het natuurlijk een mop in worden: hoeveel telenet engineers heb je nodig om 1 dhcp-server te resetten?

Het artikel waarnaar verwezen wordt meld overigens ook dit:

Het blijft onduidelijk hoeveel mensen met problemen kampen en in welke gebieden de problemen het grootst zijn. “Alles hangt af van de instellingen van de computers en de modems bij de mensen thuis”, aldus Coenjaerts.

Aparte uitspraak? Wat hebben de computers er nou mee te maken? Dit is toch het stukje tot het modem, zeg maar? Kun je op je thuisnetwerk nog zulke exotische configuraties hebben, als je modem geen ip krijgt houdt het verder op natuurlijk..

[psycho202]

Niet echt, sommige (oudere) modems of mensen met een modem-only option ipv een modem+ router bakje hadden er geen of minder last van, doordat zij geen nieuw IP moesten krijgen om de ... tijd.

Ikzelf had er jammergenoeg wel last van, en heb nu nog een extra reden om over te schakelen naar een modem-only option...

[filipili]

Ik heb zelf de modem only setup met daarachter een mikrotik router, ik had ook problemen: router logs laten zien dat ze deze nacht zond half 5 begonnen, de DHCP-lease werd opgezegd en de router kreeg geen nieuw IP. Ik heb de dhcp-client meermaals herstart in de voormiddag, bleef wachten op een IP tot iets voor 12, toen kreeg ik weer hetzelfde IP als voorheen. Het heeft wel even weer gewerkt tussen 05 en 06:30..

[kaaas]

Werkte het niet om je laatste ip adres als static ip adres op te geven?
Of heb je een dynamisch adres bij telenet?

[filipili]

Heb ik geprobeerd, jammergenoeg wist ik het gateway adres niet, noch het subnetmasker... Na wat gokken heb ik het maar opgegeven en ben wat anders gaan doen
EDIT: Btw, ik heb een dynamisch IP, normaalgezien.

[Reactie gewijzigd door filipili op 25 juli 2024 14:52]

[ovan]

Zou toch niet lukken. Vaste adressen worden bij telenet ook langs DHCP uitgestrooid en het vaste IP-adres wordt bepaald door het mac adress van je netwerkkaart . Dit moet je instellen op mijn telenet. En static klant zijn.

[kaaas]

Ja en als dhcp het dan niet doet kun je dus handmatig een ip adres en gateway instellen zodat je als nog verder kunt. Je mac adres veranderd niet zolang je dan maar je eigen ip adres gebruikt is er niets aan de hand.
Zoals ibex verderop in de comments ook heeft gedaan.

Edit wijze les is dus schrijf dat soort dingen ergens op zodat je die bij de hand hebt bij een voorval als dit.

[Reactie gewijzigd door kaaas op 25 juli 2024 14:52]

[SuBBaSS]

Je reageert op mij? En "niet echt" is je reactie op mijn "Aparte uitspraak"?
In dat geval snap ik niet helemaal waar jouw post mijn bedenking beantwoord?
Het ging mij vooral om dat stukje "Alles hangt af van de instellingen van computers..."
Ik begrijp dus nog steeds niet waar de instellingen van de computers van gebruikers van hun netwerk de DHCP-afgifte beïnvloedt als die computers nog altijd achter een modem zitten?

[Martin-S]

Het blijft onduidelijk hoeveel mensen met problemen kampen en in welke gebieden de problemen het grootst zijn. “Alles hangt af van de instellingen van de computers en de modems bij de mensen thuis”, aldus Coenjaerts.

Aparte uitspraak? Wat hebben de computers er nou mee te maken? Dit is toch het stukje tot het modem, zeg maar? Kun je op je thuisnetwerk nog zulke exotische configuraties hebben, als je modem geen ip krijgt houdt het verder op natuurlijk..

Idd aparte uitspraak. Misschien hebben sommige mensen een statisch IP-adres en wordt dat wel toegekend. (Modem vraagt aan DHCP of 123.123.123.123 (statisch IP adres) vrij is, DHCP server vind dat wel best en "keurt het goed").

Zodra klanten een dynamisch adres hebben snapt de DHCP server het niet meer en wordt er geen adres toegekend. (Modem zegt tegen DHCP server "ik wil een IP" (dynamisch IP adres) en de DHCP server raakt de kluts kwijt.)

Weet niet op het zo werkt, maar vond het wel een leuk theorie

[edit ] lees net hieronder dat het misschien werd veroorzaakt door een fout tijdens een update van de dns servers.

[Reactie gewijzigd door Martin-S op 25 juli 2024 14:52]

[IStealYourGun]

Ik vraag me af hoe je met 100 man zo een probleem kan analyseren, ik vermoed dat die 100 een beetje PR praat is.

[junkchaser]

Of eerder 99 helpdesk medewerkers :-p

[TheGhostInc]

Inderdaad, een professioneel bedrijf maakt daar een App voor zodat de junior helpdeskmedewerker dat ook vanuit de kroeg kan doen

Maar volgens mij staat er in de tekst al duidelijk dat het er meer dan 1 zijn, en met mijn (beperkte) kennis van DHCP servers weet ik al dat die dingen complexer zijn dat een IP-je uitgeven. Het kan al snel in de tientallen lopen met enkele hoofdmachines maar ook lokaal per regio nog zo'n apparaat.

Daarnaast is dit volgens mij een kabelaar, die hebben sowieso alweer een koppeling tussen Kabelmodem <-> DHCP...

Maar goed, kom maar op met alle 'Captain Hindsight'-opmerkingen

[devil-strike]

Kabelmodems hangen aan een CMTS niet aan dhcp server, neemt niet weg dat als dhcp niet werkt en je lease verloopt je dus zonder internet komt tezitten.

[nexhil]

Ze gebruiken ze ook om te testen , dus ze doen niets verkeerd.

[ThomasG]

En jij denkt dat een persoon een storing een complex netwerk kan oplossen? We hebben het hier niet over een thuisnetwerk met een router, een switch en een servertje. Als er een storing optreed, ga je niet zomaar van alles opnieuw opstarten en aan wat kabels lopen trekken. Je moet eerst lokaliseren waar het probleem zit, en wat de oorzaak daarvan is. Ik kan me best voorstellen dat ze bij een netwerk als dat van Telenet 100 man voor nodig hebben. Ze staan natuurlijk niet met z'n alle om de server heen, maar hebben bijvoorbeeld ook bij de verschillende verdeel stations gekeken, of het probleem niet (ook) daar zat.

[Anoniem: 359489]

Jij zou het daar eens snel allemaal in je eentje gaan oplossen hè jij... :-)

[TitusV]

Wat een prutsers bij Telenet...

Infrastructuur waar ze (nagenoeg) niet in investeren
Klantendienst van niveau nihil
Duur
FUP die werkelijk nergens op slaat
Traffic shaping volle bak

Als er een deftig alternatief was in BE, dan hadden ze mij al lang geleden als klant verloren...

Ben benieuwd of ze nog wat gaan compenseren voor de uitval of dat het (waarschijnlijk) bij een sorry gaat blijven...

[bbc]

De compensatie is al begonnen ...
edit: bron: http://klantenservice.tel...op-zondag-3-februari-2013

Sporting Telenet-zenders op zondag 3 februari
Op zondag 3 februari (vanaf 14 uur tot 5 uur morgenvroeg, tot na de Superbowl) zijn alle Sporting Telenet-zenders (standaardzendernummers vanaf 200) gratis te bekijken voor alle digitale tv-klanten.


Had u al een Sporting Dagpas besteld om deze zondag te kijken? Dan rekenen we deze niet aan of we brengen hem in mindering op uw volgende aanrekening.

Gratis film uit de TV-theek
Als geste voor de hinder zullen we u binnenkort een gratis film aanbieden uit onze TV-theek. Wij zullen u hiero

[Reactie gewijzigd door bbc op 25 juli 2024 14:52]

[bvanaerde]

Allemaal leuk en wel, maar ik kijk geen sport. Oké, nu ben ik mogelijk een beetje aan't zeuren, maar ik vind dit geen compensatie.

Hoogst waarschijnlijk had ik deze reactie niet gemaakt als Telenet niet zo hoge "administratiekosten" aanrekent als je ook maar een dag of twee te laat je factuur betaalt. Moet de klant nu ook maar meteen harde cash als compensatie eisen?

[Booster49]

Het hele netwerk op zijn knieën door falende DHCP servers?
Konden ze niet gewoon overswitchen naar backup servers die toch al standby draaiden, of staat redundantie niet in het woordenboek van Telenet?

[Tokkes]

Telenet heeft gewoon wat probleempjes met geld willen uitgeven teneinde een beter en stabieler product te kunnen aanbieden. Zolang de breedbandmarkt hier in dit apenland niet dringend herzien wordt, zal Telenet ook geen moeite doen of kosten maken voor iets wat ze toch geen klanten kost.

[Bauknecht]

Van de afgelopen zes jaar is dit de eerste keer dat ik een onaangekondigde panne heb, en daarnaast heb ik één keer geweten dat er onbeschikbaarheid was tgv gepland onderhoud. Als je zelf in de IT werkt, en je weet hoe complex ogenschijnlijk zeer eenvoudige dingen kunnen zijn achter de schermen, vind ik dat geen slecht bilan. Maar ja, de beste stuurlui...

[bbc]

Van de afgelopen zes jaar is dit de eerste keer dat ik een onaangekondigde panne heb,

Ik lag er ook uit, maar over het algemeen is het netwerk inderdaad vrij stabiel. Een andere keer lagen de dns servers eruit. Toen ben ik overgeschakeld op de dns van google en ik had al direct spijt dat ik het niet eerder gedaan had. Die telenet dns servers zijn pokketraag!
Als ze zoveel volk op een zondagochtend ter plaatse hebben vraag ik me af of ze geen upgrade ronde aan het doen waren.

[nebur86]

dat waren ze volgens mij ook aan het doen, stond in 1 van die artikelen over de storing

[IStealYourGun]

Dat is één ervaring. Ik woon in een stad en hier gebeurt het toch gemiddeld 2 a 3 keer per jaar dat het onaangekondigd op zijn gat gaat, dus ik vermoed dat het zelfs vaker zal zijn, want overdag op mijn werk merk ik er niets van. En als je de twitter pagina op nahoud dan merk je dat er wel wat vaker lokale probleempjes zijn in een straat of buurt.

[Loller1]

Dit is anders de eerste keer sinds 7 jaar Telenet gebruik dat ik merk dat de boel er zonder voorafgaande waarschuwing onderuit gaat.

[Tokkes]

Dan heb jje ofwel geluk, ofwel gebruik je je connectie niet dusdanig zwaar dat een paar verloren packetjes niet veel uitmaken. Ik heb anders al meer dan genoeg meegemaakt dat het internet hier gewoon los een uurtje of 2-3 eruit ging. EPG ging er op die moment ook uit en signal-led op de modem pinkte toen. Of meer regelmaat dan uitzondering dat ik te maken heb met packetloss van 20-30%. (gemeten met Pingplotter, eerste 2 nodes (dus modem -> eerste node buiten?) gaan goed, de derde (Modem - 1ste buiten - 2de buiten) was een damn PITA en Telenet doodleuk: Het probleem ligt bij u, we gaan een technieker langssturen. Die technieker komt langs, ziet da het probleem niet bij mij ligt (wist ik ook al...) maar wilt mij wel aanrekenen. Gezegt dat hij dan maar ineens die boellen mocht van de muur halen en terug meepakken. "Jamaar dat doen wij niet...." -"Wacht, blijf nog 2 minuten hier, ik bel even effe naar uwe klantendienst".

Ik was namelijk niet de enige in de straat/blok die problemen had. Haperende gesprekken bij Skype, connection loss bij gamesessies, downloads die corrupt geraken.... Probleem was dat deze klanten niet klaagden ("wat haalt het uit?"-mentaliteit) en Telenet dus niet per se wist dat er problemen waren op onze node(s). Nu zou een pingplotter-test toch voldoende moeten zeggen dat het probleem blijkbaar niet per se binnen ligt?


Het feit dat ze zoveel volk op een zondagmorgen optrommelen ligt aan het feit dat ze WETEN dat dit onacceptabel is en dat die servers ASAP de lucht in moesten.

Ze hebben hier zopas een nieuwe fiberbundel in de grond gestoken, misschien dat het nu beter zou gaan. Maakt mij alleszins niet uit, ben al lang overgestapt en ben niet van plan ooit nog een rotte cent aan Telenet & co te spenderen zolang ze het niet verdienen.

ik ben zelf werkzaam in de IT btw, en ik kan me best wel inbeelden hoe complex de oplossing kan zijn voor een simpel probleem. Doch als je als kabelaar verantwoordelijk bent voor het internet van meer dan 1 miljoen Vlaamse klanten, dan is iets als dit onacceptabel.

[Reactie gewijzigd door Tokkes op 25 juli 2024 14:52]

[Fire69]

Waarom moeten ze over op backup-servers? Als na een herstart alles terug werkt, is het puur een software-probleem, daarvoor heb je toch geen andere server voor nodig?

[Goldwing1973]

"Waarom moeten ze over op backup-servers?"
Heel simpel, als ze een backup server of "fail-over" server hadden gehad was dit probleem nooit gebeurd.
Server 1 was in storing gegaan, en de fail-over server neemt het over, en dit is echt geen complexe opstelling hoor, maar wel een hele veilige (en ik spreek uit ervaring, heb er al menig opgezet)

[IceM]

Hoe kun je nu stellen dat "dit probleem nooit gebeurd" was met een back-up opstelling? Als de storing veroorzaakt wordt door bugs in de software, fouten in de configuratie van de opstelling of een ander probleem dat niet zozeer te wijten is aan het falen van de hardware/machine dan had een back-up server exact hetzelfde probleem gehad.

Het is altijd makkelijk om dingen te roepen bij een nieuws post van 4 alinea's, maar aangezien er 100 personen nodig zijn om dit snel op te lossen is de kans vrij reëel dat dit met een back-up server ook gebeurd was.

[Zer0]

Server 1 was in storing gegaan, en de fail-over server neemt het over, en dit is echt geen complexe opstelling hoor, maar wel een hele veilige (en ik spreek uit ervaring, heb er al menig opgezet)

Als je het over 1 server hebt is het inderdaad niet zo complex, maar als het om een array van dhcp-servers gaat, wat op zich al aardig complex kan zijn, wordt het er zeker niet eenvoudiger op.

[Blokker_1999]

Hoe vaak hebben we de laatste jaren niet gezien dat ook backup systemen kunnen falen. Dat wanneer men alles test ze gewoon werken en wanneer ze effectief moeten ingrijpen ze gewoon dienst weigeren? Of dat een storing ernstiger is dan gedacht.

Van wat ik begrepen heb ging het om een mislukte software update. Wanneer je die update dan ook naar je backups uitrolt na het voltooien op de hoofd zit je ook daar met problemen.

Het is eenvoudig om kritiek te geven zonder dat we in detail weten wat er exact is gebeurd.

[Anoniem: 359489]

Waarom voortgaan op een eenvoudige uitleg in een persbericht?
Server down is de courante uitleg, de echte technische uitleg is uiteraard van een totaal andere aard.
Sorry hoor maar dit is echt onnozel!

[CaptJackSparrow]

Heeft men daar nog niet door welke drie zaken het belangrijkst zijn?

Redundancy, redundancy en redundancy!

[TheGhostInc]

Grappig, de meeste keren dat ik een profi-systeem heb zien falen ging het mis door de redundancy.

Grappig voorbeeld:
Redundant power + 2x UPS, 1 van de stoppen springt eruit, 1 van de UPS-en loopt leeg (andere stond dus nog op netspanning), lege UPS schakelt server uit....
Maar ook 2 RAID of netwerkkaarten waarvan er 1 'een beetje' stuk gaat en waarna de andere het ook niet meer snapt.

Door de toegenomen complexiteit is het risico van een probleem groter geworden, dus soms is redundant niets meer dan risico toevoegen, want HEEL veel dingen kunnen er best een uurtje uitliggen. Bijv. E-mail, alsof een bedrijf stopt te bestaan als de mail er een uur uitligt, gaan ze maar een keer koffiedrinken, doen ze anders toch ook?

[Reactie gewijzigd door TheGhostInc op 25 juli 2024 14:52]

[IStealYourGun]

Dat is niet echt een excuus voor geen redundantie, aangezien het testen er een onderdeel van is. Ik ben zeker dat Telenet wel redundantie heeft, maar redundantie is ook niet magische en het kan daar ook foutlopen.

En veel dingen kunnen we inderdaad een uurtje missen, maar een corebusiness van een bedrijf is meestal wel cruciaal om winst te maken. Of dat nu internet is als ISP of wagens als autofabriek. Als het stil valt dan is je personeel technisch werkloos en maak je verlies.

[DenHond]

De Belgische telecom markt legt liever de nadruk op besparingen, hoge prijzen en misleidende reclame.

[BlaDeKke]

Degene die deze downmod woont niet in België...

[wjn]

Hoe wil je dhcp redundant uitvoeren dan?

Er moeten unieke adressen worden uitgedeeld dus hoeveel servers je ook neerzet, ze moeten uiteindelijk allemaal van elkaar weten welke adressen vrij zijn en welke uitgegeven zijn.

Uit eigen ervaring weet ik ook dat bij een storing in een complex netwerk (als er een update fout gaat of als er vanwege management redenen [uptime!] juist geen updates waren doorgevoerd) het makkelijk 12 uur of meer kan duren, voordat alles weer draait.

[Anoniem: 1322]

Via Google?

Je kunt DHCP al jaren redundant opzetten met clustering (in verscheidene OSen). Tevens kun je tegenwoordig met 2012 een nieuw soort HA opzetten:

http://blogs.technet.com/...r-2012-dhcp-failover.aspx

[neganav]

Ik vind het grappig om te zien hoeveel mensen menen dat ze kunnen zeggen dat de ISP geen verstand van zaken heeft omdat deze zijn systemen niet redundant uitgevoerd zou hebben.

Tenzij een van deze personen daadwerkelijk bij Telenet werkt, kan men hier slechts over speculeren, zonder de kern van het probleem te raken.

Dat men meent dat er een wanbeleid gevoerd wordt door de ISP is meer gebaseerd op een gevoel dat men zelf voldoende kennis van internetarchitectuur heeft om te kunnen bepalen dat dit simpel is op te lossen, dan op feitelijke kennis.

Dat door het hebben van een redundant systeem dit probleem voorkomen zou kunnen worden is pure speculatie, gezien (naar ik aanneem) het merendeel van de mede-Tweakers geen kennis heeft van de systemen die bij Telenet staan, het feitelijke probleem, noch de omvang of oorzaak hiervan. (ook ik hoor bij deze groep)

Het redundant uitvoeren van systemen is lang niet altijd een haalbare oplossing, zowel vanuit financieel, alsmede technisch oogpunt. Zelfs als een systeem redundant wordt uitgevoerd is dit nog altijd kwetsbaar voor hetzelfde probleem dat het 1e systeem heeft laten crashen.

Meestal wordt er bij updates eerst het redundant of een testopstelling geüpdatet, en dit wordt (meestal) uitvoerig getest, voordat men aan kritische of draaiende systemen gaat sleutelen.


Wat achtergrondinformatie over DHCP (RFC 2123) voor de geïnteresseerden:


Ik ga het in het stuk hieronder niet hebben over diverse technieken zoals ADSL, CMTS, DSLAM, HFC, DSL, CIDR (RFC 1517, RFC 1518, RFC 1519, RFC 4632 en RFC 950 ) of NAT (RFC 2663,RFC 1918, RFC 3489 en RFC 5389), enkel over de interactie tussen DHCP servers van een ISP en de modems bij klanten.

DHCP systemen zijn kritisch in elk netwerk dat gebruik maakt van het Internet Protocol (RFC 791), tenzij alles gebaseerd is op fixed ip adressering.

Dit is technisch niet (altijd) haalbaar, gezien er vaak gewerkt wordt door middel van IP-blocks in de vorm xxx.xxx.xxx/24 die worden uitgedeeld aan woonwijken of regio’s. De ISP heeft dan meestal het IP-block xxx.xxx/16. Fixed IP's vind men wel vaak terug bij datacenters e.d., maar veel minder vaak bij 'gewone consumenten abonnementen'. Dit houdt niet in dat de desbetreffende IPS deze service niet aanbied.

Het probleem met fixed ip’s is het feit dat mensen makkelijk van ISP kunnen en willen wisselen.

Zou men met fixed ip’s werken, dan zou dit betekenen dat elke keer als een persoon met ip adres xxx.xxx.xxx.xxx van bijv. ISP X naar ISP Y zou wisselen, dit IP adres zou moeten worden opgenomen in de routing table van de dns-servers van ISP Y, gezien zij(de DHCP/DNS servers) al het verkeer van de desbetreffende ISP verzamelen. Dit gebeurd wel, maar (voornamelijk) bij zakelijke contracten die een fixed IP garanderen.

Om deze reden bestaat DHCP, en wordt er gebruik gemaakt van het zogenaamde Longest Prefix Matching.


DHCP:

Bij DHCP krijgt ieder modem, of modem/router combinatie een IP adres toegestuurd, en zit hieraan een lease-time gekoppeld. Voordat dit gebeurd moet er echter wel een uitwisseling aangegaan worden tussen de DHCP server en de desbetreffende client. Dit gebeurd meestal via een broadcast naar 255.255.255.255 of een netwerk specifiek adres.

Intern houd een DHCP server een strikte scheiding aan tussen externe en interne IP-adressen, en gedraagt zich als een router. De DHCP server heeft een extern IP-adres, en alle interne IP-adressen die geleased worden aan clients (modems die in de meterkast staan) worden via routing-table aan elkaar gekoppeld. Hierbij moet je de DHCP server zien als een router, en alle connecties hierachter moeten gezien worden als het clients zoals pc’s of printers e.d.. Voor de routering van pakketten wordt (vaak) gebruik Longest Prefix Matching (dit leg ik aan na het eind van DHCP uit), in combinatie met diverse routerings algoritmen.

Als de DHCP server om wat voor reden dan ook (ik heb geen informatie betreffende de situatie bij Telenet) geen IP-adressen meer uitdeelt, en de huidige IP-lease verloopt, vervalt het IP-adres, en wordt deze uit de routing-table van de DHCP server gehaald. Het logische vervolg hiervan is dat het verkeer dat voor de desbetreffende client bestemd was niet meer aankomt, gezien de DHCP server niet weet waar de pakketten heen moeten.

Dit soort situaties kunnen ontstaan als er bij het updaten van de software een fout in de server ontstaat, maar ook als een land al het verkeer van bijv. Youtube naar zich toe trekt, om zo te verhinderen dat de bevolking van dat desbetreffende land toegang heeft tot Youtube.

Disclaimer: ik sla hier een paar stappen over, dat weet ik, maar dat is (naar mijn mening) niet interessant het huidige verhaal (voor de mensen zie hier wel geïnteresseerd in zijn: Distance vector routing protocol en Dijkstra's algorithm.)

Om het verhaal helemaal af te maken nog even iets over Longest Prefix Matching en fixed IP’s

Longest prefix matching:

Longest Prefix Matching is een methode om routering van IP-adressen te realiseren.

Stel: (de gebruikte IP-ranges zijn intern en dus niet buiten een thuis netwerk beschikbaar)
Bedrijf A heeft IP adres 192.168.20.16/28 (/28 betekend dat 28 van de beschikbare 32 bits vast staan)
Bedrijf B heeft IP adres 192.168.0.0/16

Als adres 192.168.20.19 opgezocht zou moeten worden, zou dat in beide gevallen een match genereren, maar omdat 192.168.20.16/28 een langere prefix heeft (want het subnet mask is /28 ), heeft deze een hogere prioriteit in het routing algoritme en wordt de data voor 192.168.20.19 naar 192.168.20.16/28 verstuurd.

In dit geval zou een typische routing table van een DHCP server er als volgt uitzien:

Adres | uitgaande interface (kabel)
192.168.20.16/28 | 1
192.168.0.0/16 | 2

Op deze manier worden ook fixed IP’s gerouteerd.

Edit: links toegevoegd, typo's verwijderd

[Reactie gewijzigd door neganav op 23 juli 2024 15:14]

[MPAnnihilator]

Wat haal jij hier allemaal bij om te bewijzen dat het mogelijks wel een complexer probleem is/was dan de meeste denken

Niemand weet welk systeem men gebruikt bij Telenet als DHCP server , maar je hoeft heus geen expert te zijn om het verhaal van updates en uren lange downtime in vraag te stellen.

Een DHCP server , enkel , of in cluster , heeft geen terrabytes aan storage wat een restore tijd van meedere uren kan verklaren ! Zo'n server , indien hij virtueel draait of niet , kan toch echt op een uur of 2 volledig hersteld worden vanuit een backup.

Iets zegt mij dat ze gewoon geen goed rollback plan hadden , en men gewoon is blijven verder zoeken naar de oplossing op dat "nieuwe" systeem...

( ik werk bij een niet publieke ISP voor alle duidelijkheid , veel kleiner in schaal , maar voor DHCP lijkt me de grootte niet zo relevant. )

[analog_]

Je probeert een verband tussen routing en DHCP te leggen die er niet is. DHCP is een alternatief voor statische adressering en werkt traditioneel per layer 2 segment. Hier kan je nog wat aan knoeien met DHCP relays welke elkaar moeten kunnen bereiken, either direct of met tussenliggende routering.

Het stuk over routering, subnetting en hoe routes worden geselecteerd worden is puur offtopic hier en een aantal van je redenaties en verhalen kloppen gewoon niet (statische ip's zou ISP switchen vergemakkelijken, ...).

Het enige waar ik naar toe wil is dat deze +2 misleidend is, de inhoud van het bericht is deels correct en ontopic maar vooral vanaf de helft onjuist of offtopic, ik hoop dat niet teveel mensen bovenstaande als waarheid opnemen.

[neganav]

Zoals ook netjes in mijn post staat, is het deel na

"Wat achtergrondinformatie over DHCP (RFC 2123) voor de geïnteresseerden:"

enkel en alleen bedoeld als achtergrondinformatie over DHCP. dit is inderdaad offtopic (dit is naar mijn idee subjectief gezien het wel over DHCP gaat)

Ik weet niet zo goed waar je in mijn verhaal leest dat statische ip's het switchen van ISP juist zou vergemakkelijken, dit is niet waar, indien dit ergens staat, is dat onbedoeld en een fout vanuit mijn kant.

Hetgeen ik probeer uit te leggen voor de mensen die misschien niet precies weten hoe DHCP werkt, wat het nou precies is, en waarom zij geen internet hadden, is hoe dit allemaal samenhangt.