Onderwerp: TransIP, broadcast storms & alternatieven

Heeft iemand anders hier ook last van? De afgelopen maand geeft Nagios vaak aan dat de gateway down is, en via Cacti zien we een broadcast storm van 2-10Mbit tot het hersteld is. Het was gisteren weer raak om 11:50 pm tot 0:05, 0:17 tot 0:48, 0:49-0:50... 12 keer in laatste 31 dagen is een beetje veel naar mijn mening.

Okay, ik weet dat een kabeltje verkeerd erin steken en een lusje maken bij goedkope switches tot dit soort dingen kan leiden, maar dit soort storingen horen toch niet thuis op een core switch in een datacenter? Of werkt "set port broadcast" anders dan ik denk?


Iets anders: hoe zit het eigenlijk met andere datacenters in Nederland? Ik weet dat er veel prijsvechters zijn, maar is meer betalen voor een hogere "tier" datacenter een optie? Die zie je namelijk niet echt vaak langskomen bij reclames, maar na een paar nachtelijke foutmeldingen betaal je liever iets meer voor zekerheid...

Hoe herken ik de stabiliteit / kwaliteit van datacenter en providers? 20u / x TB / y Amp is makkelijk, maar ik zie via de websites van providers niet echt het verschil tussen bijvoorbeeld Leaseweb en Transip, behalve dat de eerste goedkoper is...

Is 99.889% uptime (4m43 warning: 44% packet loss avg. 39m14 critical: 100% loss/unreachable) voor deze prijs te laag of zit ik gewoon te dromen en proberen voor een dubbeltje op de voorste rij te zitten?

Heb je losse colo bij TransIP?
Eigen VLAN?

Wij ervaren deze problemen ook de laatste tijd bij TransIP. Zo ook vannacht. Maar ook enkele weken geleden een paar keer overdag. Ik heb nog geen contact opgenomen met TransIP hierover, maar ben wel voornemens dat volgende keer te doen.

Edit:
Wij hebben overigens ook geen eigen VLAN. Ik heb het idee (maar misschien leg ik verbanden die er niet zijn) dat het is sinds ze ook IPv6 aanbieden (die wij overigens nog niet geimplementeerd hebben).

Geen eigen vlan, ze verhuren geen kwart/half secure racks, maar het is geen probleem in ons rack. Dat is wat we eerst dachten, en we vroegen TransIP om iedereen te vragen wat voorzichtiger te zijn in dat rack, specifiek diegene die aan het werk waren (access moet je van te voren aanvragen), maar het was die keer een rack klant die zijn twee upstreams verkeerd aansloten.

Die andere 11 keer? Niet nagevraagd, maar aangezien snmp in de rack-subnet het prima deed is het waarschijnlijk geen lokaal probleem.

In de afgelopen maand is het netwerk van TransIP enkele malen inderdaad tijdelijk onbereikbaar geweest. Wij vinden het zeer vervelend dat jullie hier hinder van hebben ondervonden, waarvoor onze excuses.

De oorzaak van de onbereikbaarheid is echter geen triviale zaak en daarmee helaas ook niet zomaar op te lossen.

Wij hebben hard gewerkt om herhaling te te voorkomen, en zullen dit blijven doen. Graag informeren wij jullie daarom over de oorzaak van deze problemen en de door ons gekozen oplossing.

Wanneer er in een netwerk twee of meer netwerkpaden bestaan naar dezelfde switch dan kan dat tot gevolg hebben dat uiteindelijk alle poorten op alle aangesloten switches overspoeld worden met verkeer, met in het ergste geval onbereikbaarheid van het gehele netwerk tot gevolg. Vatbaarheid voor dergelijke netwerkloops is inherent aan de opzet van alle zogenaamde ‘Layer2 netwerken’.

In ons geval is een netwerkloop ontstaan op het moment dat een van onze klanten met zijn fout-geconfigureerde switch meerdere netwerkpaden ontsloot. Door deze samenloop van omstandigheden hebben onze voorzorgsmaatregelen, zoals bijvoorbeeld ‘Rapid Spanning Tree’, niet kunnen voorkomen dat tot tweemaal toe gedurende korte tijd ons netwerk werd overspoeld door een enorme hoeveelheid verkeer. De impact van de loop werd versterkt door de toegenomen snelheid van het gehele netwerk.

Om herhaling in de toekomst te voorkomen hebben wij in de afgelopen periode de onderstaande maatregelen genomen:

• Allereerst is de procedure voor nieuwe klanten per direct aangepast: gebruik van de tweede poort is pas toegestaan na overleg met TransIP, ingebruikname geschiedt enkel onder direct toezicht.
• Daarnaast is er reeds een proprietair detectiesysteem in gebruik genomen dat dag en nacht het netwerk monitort op de aanwezigheid van loops. Mochten de eerste tekenen van een netwerkloop zich voordoen op een bepaalde poort dan wordt deze onmiddellijk dichtgezet.
• Tot slot is onlangs de fysieke infrastructuur van het netwerk aangepast. Verregaande segementering vermindert de impact van toekomstige loops aanzienlijk.

Afgelopen zaterdagnacht, echter, was er iets anders aan de hand: een van onze klanten had door een configuratiefout een dDOS-achtige situatie (intern) in zijn rack laten ontstaan. De hoeveelheid verkeer die dit veroorzaakte bemoeilijkte het ‘bereiken’ van de hardware en het isoleren van de bron, met tot gevolg dat er op het gehele netwerk tijdelijk sprake was van (veel) packetloss.

Tot slot zijn wij benieuwd naar uw precieze logs van de vermeende downtimes, zoals genoemd in dit topic. Zou u zo vriendelijk willen zijn deze te e-mailen (support@transip.nl)? Alhoewel er enkele keren sprake is geweest van onbereikbaarheid, kunnen wij ons niet vinden in het hierboven genoemde aantal.

Nogmaals onze welgemeende excuses voor de overlast,

TransIP

Oorspronkelijk geplaatst door TransIP

In ons geval is een netwerkloop ontstaan op het moment dat een van onze klanten met zijn fout-geconfigureerde switch meerdere netwerkpaden ontsloot. Door deze samenloop van omstandigheden hebben onze voorzorgsmaatregelen, zoals bijvoorbeeld ‘Rapid Spanning Tree’, niet kunnen voorkomen dat tot tweemaal toe gedurende korte tijd ons netwerk werd overspoeld door een enorme hoeveelheid verkeer. De impact van de loop werd versterkt door de toegenomen snelheid van het gehele netwerk.

Wanneer Spanning Tree goed geconfigureerd staat, zou dat onmogelijk moeten zijn. Het klinkt dus eerder alsof dit niet goed geconfigureerd stond, aan de kant van TransIP. Lijkt me een goede zaak om dat nog even op te helderen.

Oorspronkelijk geplaatst door Apoc

Wanneer Spanning Tree goed geconfigureerd staat, zou dat onmogelijk moeten zijn. Het klinkt dus eerder alsof dit niet goed geconfigureerd stond, aan de kant van TransIP. Lijkt me een goede zaak om dat nog even op te helderen.

Bij een interne Broadcaststorm (bij de klant in het rack) zorgt STP er niet voor dat deze storm wordt tegengehouden, deze zal gewoon verder gaan broadcasten in het getroffen VLAN. BPDU Filter is een oplossing, echter ook dit kan weer problemen geven...

Helaas kan er bij STP veel mis gaan, zodra de kant van de klant niet goed is geconfigureerd dan kan het gehele VLAN last krijgen van een broadcaststorm, zelfs als de kant van de leverancier goed is geconfigureerd. Het is ook niet aan te raden om klanten in een shared VLAN STP mee te geven, mocht er wat fout gaan, dan heeft iedereen binnen dat VLAN er last van. Binnen een private VLAN is het de verantwoordelijkheid van de klant om zijn infrastructuur goed te configureren.

Vreemd, TransIP erkent downtime hier en problemen, maar kwam met een advertentie richting mij : Onze uptime over de afgelopen 365 dagen is: 100%.

Lijkt me een vreemde situatie, of word dit niet onder downtime gerekend?

Staat er ook bij of dat op netwerk 100% is of stroom 100% ?
100% is nagenoeg onmogelijk

Oorspronkelijk geplaatst door WickedWay

Vreemd, TransIP erkent downtime hier en problemen, maar kwam met een advertentie richting mij : Onze uptime over de afgelopen 365 dagen is: 100%.

Lijkt me een vreemde situatie, of word dit niet onder downtime gerekend?

Het is toch niet omdat een deel van je interne netwerk (vlan) een probleem heeft dat dit daarom ook voor de rest van je netwerk moet gelden. Je kan dus perfect 100% uptime op jaar hebben als je het van de edge/border routers, core switches bekijkt. Het staat je trouwens ook vrij om verdere uitleg aan TransIP te vragen hoe ze aan die 100% komen (met dit voorval in gedachten).

daarnaast is 100% feitelijk gelijk aan 99,5% of meer
(iets met significante cijfers...)

Oorspronkelijk geplaatst door t.bloo

daarnaast is 100% feitelijk gelijk aan 99,5% of meer
(iets met significante cijfers...)

Juist ja, en dan was ik nog vergeten te vermelden in mijn vorige post of je in die 100% de aangekondigde maintenance hier in mee telt of juist niet. Want je kan dan ook perfect 100% uptime hebben als je geen downtime hebt buiten je maintenance window. Maar met je maintenance window ingerekend bvb maar 96% uptime halen.