Onderwerp: Proserve.nl en Dataplace.eu plat?

Ze gaan het onderzoeken dus ik ben benieuwd wat eruit komt.
@WeServIT, Gebruiken jullie andere leveranciers dan Proserve?

Het blijft een apart verhaal. In de berichtgeving werd gesproken over alleen dataplace, maar onze servers in EUnetworks waren tot vier uur niet bereikbaar.

Voor mij als fibernoob is het wel opvallend dat True 1 dag eerder ook een probleem had met de fibers waardoor heel Redbus niet meer bereikbaar was.

Eurofiber had de laatste dagen onderhoud zover ik weet maar dat waren enkel firmwareupdates

Oorspronkelijk geplaatst door almar

Het blijft een apart verhaal. In de berichtgeving werd gesproken over alleen dataplace, maar onze servers in EUnetworks waren tot vier uur niet bereikbaar.

Inderdaad, WeservIT was wel online in Dataplace.
Dus het lijkt mij dat 1 van de fibers het wel heeft gedaan?

Mogelijk een foutje in de netwerkapparatuur zelf i.p.v. de fibers?

Oorspronkelijk geplaatst door Piwi-Web

Eurofiber had de laatste dagen onderhoud zover ik weet maar dat waren enkel firmwareupdates

Dat is alleen bij metrofibers van Eurofiber.

Voor zover ik opmaak uit de berichten lagen de verbindingen tussen Nikhef/TC3/DP aan de ene kant en Eunetworks aan de andere kant eruit (in geval van Pro de fibers Eun<>TC3 en Eun<>DP) . Verkeer wat dus via Eun binnenkomt maar naar DP moet loopt dan dood, net als andersom.

Blijkbaar wordt er in de netwerksetup vanuit gegaan dat zo'n split horizon nooit voor kan komen door de redundantie. Zonder je announcements voor Eun en DP volledig uit elkaar te trekken (en daarmee ook je IP reeksen) is het volgens mij ook niet eenvoudig op te lossen.

Blijven er wel enkele vragen over:
- Waarom is de verminderde redundantie niet aangekondigd naar klanten?
- Waarom voeren 2 toko's tegelijk onderhoud uit en kondigt 1 het niet aan?
- Is de huidige netwerksetup, waarbij Eun en DP blijkbaar niet los kunnen functioneren, wel optimaal?

Ze hebben wel meer problemen, al ruim een jaar is het iedere keer raak als ze onderhoud gaan doen aan de routers. Bij een reboot krijgen we 900mbit/s broadcast storms en na al deze tijd weten ze nog geen oplossing. Support mailen, gesprekken hebben.. Niets helpt.

Iets in dat netwerk zit in elk geval goed fout.

Oorspronkelijk geplaatst door CharlieRoot

Iets in dat netwerk zit in elk geval goed fout.

Uit de berichtgeving vanuit Proserve zelf kun je ook niets anders concluderen. Ook is de informatievoorziening (het zogenaamde eindrapport - http://status.proserve.nl/2012/01/11...den-amsterdam/ ) wel zeer beknopt, tenzij de klanten via private kanalen nog van verdere informatie voorzien zijn.

Nouja. Tijdens de 'storing' in hun glas verbinding lag ook heel EuNetworks er uit. One point of failure ergens?

Daarbij was afgelopen weekend in 2 andere DC's onderhoud, wij kregen te maken met broadcast storms. Maar dit lag aldus Proserve aan onze hardware (terwijl wij lagen te slapen).

De problemen hopen op, ze ontkennen alles. Zou niets mis zijn.

EUN heeft netwerktechnisch geen last gehad van de storing volgens het rapport en dat kan ik bevestigen.
Heb er diverse machines hangen en die zijn altijd bereikbaar geweest. Ook monitoring / NOC systeem hebben geen downtime te melden gehad wat dat betreft.

Ik denk dat het topic nu wel gesloten kan worden. Klanten zijn netjes terug gebeld met de exacte oorzaak en ik heb al in de wandelgangen gehoord over aanpassingen die gedaan gaan worden.

Even een paar feiten die voor ons gelden:

- Vanaf het moment dat ons apparatuur in Dataplace live is gegaan (februari 2011) hebben we nog 100% uptime. Wij hebben ook totaal geen hinder ondervonden van de glasvezelstoring. Ik moet er wel bij zeggen dat wij een eigen /20 IP space hebben die direct in Dataplace geannounced is en we redundante BGP sessies naar verschillende routers hebben.
- Tijdens het router onderhoud van afgelopen vrijdag nacht hebben wij totaal geen hinder ondervonden. Op onze smokeping is enkel een route wijziging te zien (wat natuurlijk logisch is).

Zoals Proserve ook al verteld heeft, waarschijnlijk hadden de klanten in EUnetworks welke wel problemen ondervonden de resolvers niet goed staan. De websites die ik geprobeerd heb te bereiken tijdens de storing waren gewoon online vanuit EUnetworks. Logisch ook, want het netwerk in EUnetworks heeft lokaal genoeg capaciteit om verder te draaien zonder de verbindingen.

Oorspronkelijk geplaatst door WeServIT

[..]
Zoals Proserve ook al verteld heeft, waarschijnlijk hadden de klanten in EUnetworks welke wel problemen ondervonden de resolvers niet goed staan. De websites die ik geprobeerd heb te bereiken tijdens de storing waren gewoon online vanuit EUnetworks. Logisch ook, want het netwerk in EUnetworks heeft lokaal genoeg capaciteit om verder te draaien zonder de verbindingen.

Wat ik toch even niet snap, in het noc bericht van Proserve, en ook hierboven, is sprake van *resolvers* die niet goed staan.
Waarom worden webservers onbereikbaar als resolvers niet goed staan ?
Een resolver is de DNS server die een client gebruikt om IP adressen van hostnames op te zoeken.
Een authoritive DNS is de server waarin een (sub) domein gepubliceerd wordt;

Als het gaat om *access* klanten kan ik begrijpen dat verkeerde/onbereikbare resolvers een storing geven, maar de relatie tot server hosting die het niet doet vanwege verkeerde resolvers snap ik minder goed.
(Of staan dingen als database servers altijd op een hostnaam en wordt dns gebruikt om dat te resolven ?)

Oorspronkelijk geplaatst door visser

Wat ik toch even niet snap, in het noc bericht van Proserve, en ook hierboven, is sprake van *resolvers* die niet goed staan.
Waarom worden webservers onbereikbaar als resolvers niet goed staan ?
Een resolver is de DNS server die een client gebruikt om IP adressen van hostnames op te zoeken.
Een authoritive DNS is de server waarin een (sub) domein gepubliceerd wordt;

Als het gaat om *access* klanten kan ik begrijpen dat verkeerde/onbereikbare resolvers een storing geven, maar de relatie tot server hosting die het niet doet vanwege verkeerde resolvers snap ik minder goed.
(Of staan dingen als database servers altijd op een hostnaam en wordt dns gebruikt om dat te resolven ?)

Snap ik eigenlijk ook niet goed, mijn persoonlijke ervaring heeft me geleerd dat sommige zaken er wat langer over doen omdat de hostlookup eerst een time-out moet krijgen (om bvb log files te schrijven). Maar zolang je geen zaken in je log files hebt die hostname lookup doen zou je hier totaal geen last van mogen hebben. Dat is ook een reden waarom ik in (externe) monitoring altijd ip adressen gebruik en geen hostnamen of op de monitoring servers de hostnames op geef in /etc/hosts zodat die static staan, juist om false positieve/negative te vermijden als dns (recurive/authorive) het niet doet.

Oorspronkelijk geplaatst door WeServIT

- Vanaf het moment dat ons apparatuur in Dataplace live is gegaan (februari 2011) hebben we nog 100% uptime. Wij hebben ook totaal geen hinder ondervonden van de glasvezelstoring.

En dat is dus wat ik een beetje slecht trek in de verklaring vanuit Pro. 2 glasvezels die blijkbaar over eenzelfde pad lopen, tsjah, Murphy enzo, maar waarom blijven bepaalde machines dan wel online? Het is vast allemaal prima uit te leggen, en daarom heb ik m'n accountmanager maar aangeraden met een fatsoenlijke RFO te komen ipv het huidige verhaal. Ben benieuwd of dat nog gaat gebeuren.

Het verhaal over 'resolvers die niet goed staan' vind ik ook maar raar trouwens, daar gaan webservers idd niet van plat. Je initiele SSH connectie is wat traag, maar wie checked daarmee nou de uptime van z'n server.

Oorspronkelijk geplaatst door CharlieRoot

Nouja. Tijdens de 'storing' in hun glas verbinding lag ook heel EuNetworks er uit. One point of failure ergens?

Daarbij was afgelopen weekend in 2 andere DC's onderhoud, wij kregen te maken met broadcast storms. Maar dit lag aldus Proserve aan onze hardware (terwijl wij lagen te slapen).

De problemen hopen op, ze ontkennen alles. Zou niets mis zijn.

Totaal geen downtime gehad. Het was netwerk gerelateerd en niet heel EU lag eruit.