Onderwerp: Down? Storing? Evoswitch Leaseweb?

In Easynet voor zo ver wij kunnen zien geen problemen.
Kevin z'n server is vast gelopen, en heeft niets te maken met de problemen in Evo.
Alle overige servers in dezelfde range van Kevin zijn gewoon up.

Ik vind het allemaal maar erg vreemd. Ergens rond 01.50 uur klapt alles er uit in datahal 1. Na het herstarten van de stroom blijken klanten "opeens" loops te veroorzaken op het netwerk (welke nerd legt me dit even uit?). Logischerwijs zou je denken dat ze dat dan ook al deden VOOR de stroomstoring, toch ?

Vervolgens verlaten we bezweet het datacenter om 7.00 uur in de ochtend nadat alles is herstart en nagelopen en knalt vervolgens datahal 2 er uit. Volgens NOC van LeaseWeb is daar WEL een stroomstoring geweest, volgens de vele engineers ter plaatse absoluut niet.

En tussendoor klapt datahal 1, nu qua netwerk, er nog een paar keer uit.

En volgens NOC is het zo dat datahal 2 offline ging omdat 1 klant een loop veroorzaakte. Ook deze kan ik technisch niet plaatsen. Is het nu serieus zo dat iemand met 1 actie een datahal down haalt ?

Ik zou het graag allemaal wat beter snappen want helaas, helaas ... mijn klanten accepteren het verhaal zoals het nu is niet.

Oorspronkelijk geplaatst door Erik H.

Ik vind het allemaal maar erg vreemd. Ergens rond 01.50 uur klapt alles er uit in datahal 1. Na het herstarten van de stroom blijken klanten "opeens" loops te veroorzaken op het netwerk (welke nerd legt me dit even uit?). Logischerwijs zou je denken dat ze dat dan ook al deden VOOR de stroomstoring, toch ?

Vervolgens verlaten we bezweet het datacenter om 7.00 uur in de ochtend nadat alles is herstart en nagelopen en knalt vervolgens datahal 2 er uit. Volgens NOC van LeaseWeb is daar WEL een stroomstoring geweest, volgens de vele engineers ter plaatse absoluut niet.

En tussendoor klapt datahal 1, nu qua netwerk, er nog een paar keer uit.

En volgens NOC is het zo dat datahal 2 offline ging omdat 1 klant een loop veroorzaakte. Ook deze kan ik technisch niet plaatsen. Is het nu serieus zo dat iemand met 1 actie een datahal down haalt ?

Ik zou het graag allemaal wat beter snappen want helaas, helaas ... mijn klanten accepteren het verhaal zoals het nu is niet.

Dat van 7:00 lijkt mij geen stroomstoring in DH2 geweest te zijn, want daar hebben we geen last van gehad. Wel met die klap van 1:50 ongeveer. Toen ging een deel in DH2 bij ons plat. Heel kort maar, maar weer voldoende.

Dus OF het is in een kleiner deel geweest in DH2 om 7 uur zodat het ons niet trof, OF het is geen stroomstoring geweest en is het "gewoon" een netwerk storing.

Over dat laatste kunnen we helaas niet oordelen omdat we niet in het leaseweb netwerk zitten. Wij zijn rechtstreeks klant bij Evoswitch.

Oorspronkelijk geplaatst door Erik H.

Ik vind het allemaal maar erg vreemd. Ergens rond 01.50 uur klapt alles er uit in datahal 1. Na het herstarten van de stroom blijken klanten "opeens" loops te veroorzaken op het netwerk (welke nerd legt me dit even uit?). Logischerwijs zou je denken dat ze dat dan ook al deden VOOR de stroomstoring, toch ?

Een klant bouwt een mooi gelooped netwerk, maar scheidt de inks dmv vlans.
Als er geen "write mem" of vergelijkbaar wordt gedaan zal de vlan config weg zijn na en reboot.
De power dip heeft die reboot veroorzaakt, dus na de powerdip zijn er loops.

Oorspronkelijk geplaatst door Erik H.

En volgens NOC is het zo dat datahal 2 offline ging omdat 1 klant een loop veroorzaakte. Ook deze kan ik technisch niet plaatsen. Is het nu serieus zo dat iemand met 1 actie een datahal down haalt ?

De colo routers die problemen hebben gehad staan in DH1.
Heel datahal 1 is niet offline gegaan door de loop, alleen het colo gedeelte van hal1.

Oorspronkelijk geplaatst door kilobit

Een klant bouwt een mooi gelooped netwerk, maar scheidt de inks dmv vlans.
Als er geen "write mem" of vergelijkbaar wordt gedaan zal de vlan config weg zijn na en reboot.
De power dip heeft die reboot veroorzaakt, dus na de powerdip zijn er loops.

En welke noob test zijn routers, switches en servers niet na installatie (plaatsing) door zelf een herstart te doen. Trouwens dan nog mag die loop niet heel de colo zaal er uit gooien, of mis ik het punt dat er geen vlan's gebruikt worden aan leaseweb kant.

Een netwerk loop kan je niet voorkomen door vlans te gebruiken. Een loop trekt de CPU load van de router naar de 100% met als gevolg dat je router plat ligt.

correct me if i'm wrong

Oorspronkelijk geplaatst door dennis0162

Een netwerk loop kan je niet voorkomen door vlans te gebruiken. Een loop trekt de CPU load van de router naar de 100% met als gevolg dat je router plat ligt.

Op een rackswitch kan je een loop voorkomen door vlans te gebruiken.
Routers maakt het niet uit of er vlans worden gebruikt of niet.

Als er een loop "downstream" is van de routers en er worden daardoor xxxxxx packets per second gestuurd naar de router moet de router daar iets meer doen.

Als het een enkele ARP request is (maar wordt vermenigvuldigd door de loop) zal het ARP proces te veel CPU gaan verbruiken. Als het unicast packets zijn, waarvoor geen ARP entry is zal er worden ge "gleaned" naar de route processor, dit om een ARP request te genereren, wat op zijn beurt ook te veel CPU tijd zal verbruiken.

Beide gevallen kan een router voor worden beschermd, bij cisco door ratelimiters, policers en CoPP. Echter is er een zeer fijne balans tussen beschermen en funktionaliteit limiteren. Er is nagenoeg geen enkele configuratie die in alle situaties zal funktioneren en beschermen tegen alle mogelijke storingen / aanvallen.

Een router gaat niet echt plat door een te hoge CPU belasting, het zijn "alleen" de dynamische routing protocollen (BGP / OSPF) die sneuvelen. (geen CPU cycles beschikbaar om op tijd keep-alives en hello's te genereren / antwoorden)

Oorspronkelijk geplaatst door kilobit

Een router gaat niet echt plat door een te hoge CPU belasting, het zijn "alleen" de dynamische routing protocollen (BGP / OSPF) die sneuvelen. (geen CPU cycles beschikbaar om op tijd keep-alives en hello's te genereren / antwoorden)

Hij gaat dus niet plat maar word compleet nutteloos ? Of heb jij de gehele routing tabel statisch gerouteerd ?

Oorspronkelijk geplaatst door Paulewk

Of heb jij de gehele routing tabel statisch gerouteerd ?

Die snap ik niet.
Bi statische routering zou bovenstaande geen issue zijn toch?

Oorspronkelijk geplaatst door kilobit

Op een rackswitch kan je een loop voorkomen door vlans te gebruiken.
Routers maakt het niet uit of er vlans worden gebruikt of niet.

Als er een loop "downstream" is van de routers en er worden daardoor xxxxxx packets per second gestuurd naar de router moet de router daar iets meer doen.

Als het een enkele ARP request is (maar wordt vermenigvuldigd door de loop) zal het ARP proces te veel CPU gaan verbruiken. Als het unicast packets zijn, waarvoor geen ARP entry is zal er worden ge "gleaned" naar de route processor, dit om een ARP request te genereren, wat op zijn beurt ook te veel CPU tijd zal verbruiken.

Beide gevallen kan een router voor worden beschermd, bij cisco door ratelimiters, policers en CoPP. Echter is er een zeer fijne balans tussen beschermen en funktionaliteit limiteren. Er is nagenoeg geen enkele configuratie die in alle situaties zal funktioneren en beschermen tegen alle mogelijke storingen / aanvallen.

Een router gaat niet echt plat door een te hoge CPU belasting, het zijn "alleen" de dynamische routing protocollen (BGP / OSPF) die sneuvelen. (geen CPU cycles beschikbaar om op tijd keep-alives en hello's te genereren / antwoorden)

Ik zeg onzin...

Er zijn bepaalde routers die gewoon port of VLAN kunnen shutdownen
bij juniper kan dit na het detecteren van een loop.

Bij een zo groot netwerk zoals leaseweb hadden ze dit kunnen verwachten.

Oorspronkelijk geplaatst door kilobit

Die snap ik niet.
Bi statische routering zou bovenstaande geen issue zijn toch?

Waar ik op doel is dat je (terecht) opmerkt dat bij hoge CPU load dynamische routeringsprotocollen problemen krijgen. En dus alleen statisch routeren nog werkt.

Ken jij echter anno 2009 zowat 10 nog routers die alles statisch doen? Een router die niet meer dynamisch kan routeren is imo vrij nutteloos.

The EvoSwitch datacenter scheduled an 16h00 - 17h00 emergency maintenance window after todays UPS disruption. We expect no services to be affected during this maintenance.

Oorspronkelijk geplaatst door Merlijn

Om even wat onduidelijkheden uit de weg te nemen:

- kosten voor een belletje zullen uiteraard niet in rekening worden gebracht tijdens een storing. Dit is anders (zoals ergens als is aangegeven) indien onterecht een belletje gemaakt wordt (en je geen SLA hebt)

- de storing zat in de UPS. Hierdoor is deze zeer kort (< 1sec) niet beschikbaar geweest (zoals het op dit ogenblik lijkt) met de bekende gevolgen. Een No-break doet hier weinig van af, aangezien deze altijd door de UPS loopt. Doet je UPS het niet, dan heb je dus ook geen No-break (daar heb je dan of een 2e aparte No-break voor, of een 2e short-break).

- Klanten die nog hinder ondervinden worden verzocht een e-mail te sturen naar support@leaseweb.com

Dus ik kan concluderen dat er gewoon geen UPS tussenzit ?
tussen de colo 1.3
dit is nu de 2e keer in 2 jaar tijd dat het is gebeurd

Een sales manager wist ons te vertellen dat dit geen 2e keer zou gebeuren.

Oorspronkelijk geplaatst door rensariens

The EvoSwitch datacenter scheduled an 16h00 - 17h00 emergency maintenance window after todays UPS disruption. We expect no services to be affected during this maintenance.

Oh dit ken ik deden ze dat vorig jaar ook al.
zouden ze ook al wat vervangen of gewoon niet gedaan.

Oorspronkelijk geplaatst door Phu

Dus ik kan concluderen dat er gewoon geen UPS tussenzit ?
tussen de colo 1.3
dit is nu de 2e keer in 2 jaar tijd dat het is gebeurd

Sterker nog: 2x in 2 weken tijd. In ieder geval voor ons

Oorspronkelijk geplaatst door Paulewk

Ken jij echter anno 2009 zowat 10 nog routers die alles statisch doen? Een router die niet meer dynamisch kan routeren is imo vrij nutteloos.

Dus jullie hebben geen DFZ?