Bekijk Volledige Versie : Vervolg discussie m.b.t. storing Nikhef
Tijdens de storing van Nikhef gisteravond, kampten veel grote netwerken met problemen, omdat zij niet in staat waren om al het verkeer over andere locaties te routen. Het lijkt mij toch interessant om die discussie hier voort te zetten. Ik doel dan voornamelijk op de volgende 2 posts:
http://www.webhostingtalk.nl/1013329-post248.html
http://www.webhostingtalk.nl/1013338-post249.html
Allereerst mijn reactie op de post van Phreak:
Wat hij daar stelt is dat je voor je transit verkeer niet zelf kunt bepalen over welke routes dit loopt. Dat is niet waar:
Allereerst; over het algemeen gebruiken netwerken meer uitgaand verkeer dan inkomend verkeer (dat is natuurlijk niet per se waar, maar over het algemeen werkt het wel zo). Van het uitgaande verkeer kun je natuurlijk zelf weldegelijk bepalen over welke routes je het naar buiten stuurt. Als 1 van je carriers een bepaald percentage gebruikt, kun je je routers het overige verkeer over andere routes laten lopen. Je hoeft niet per se altijd je verkeer over je snelste routes te laten lopen (als je daarmee het vollopen van een verbinding - en dus packetloss - kunt voorkomen).
Ten tweede het inkomende verkeer; voor dit verkeer is het moeilijker om te bepalen over welke routes het loopt, maar je kunt natuurlijk wel je netblocks limiteren tot een aantal carriers wat ze kunnen gebruiken. Stel je hebt twee /18 ranges en 6 transit carriers, dan zou je bijvoorbeeld elke /18 beperken zodat ze uitsluitend gebruik kunnen maken van maximaal 3 carriers. Je kan de eerste range dus uitsluitend gebruik laten maken van carrier A, B en C, en je kan de tweede range gebruik laten maken van carrier D, E en F. Feitelijk verdeel je je netwerk dus over verschillende segmenten. Uiteraard hoef je het niet enkel te verdelen over 2 segmenten, je kunt zoveel segmenten maken als noodzakelijk is.
Verder:
Meerdere transits is natuurlijk een absolute must voor iedereen, maar om te denken dat storingen van deze omvang hiermee kunnen worden opgevangen is een beetje naief.
Ik vind het juist naief om te stellen dat je storingen van dergelijke omvang niet kunt opvangen. Ik zeg niet dat het makkelijk is, maar het kan weldegelijk. Als jij 50gbps over de AMS-IX gooit, zul je erop voor bereid moeten zijn om die 50gbps over alternatieve routes te kunnen gooien.
Natuurlijk, het is goedkoper voor elk netwerk om geen alternatieve routes beschikbaar te hebben zodra Nikhef uitvalt, en het vereist aardig wat geld om die alternatieve transits beschikbaar te hebben. Echter, zo lang je ervoor kiest om die kosten uit te sparen, blijft die keuze natuurlijk gewoon de verantwoording van het netwerk in kwestie, en kun je dus feitelijk niet adverteren dat je een volledig redundant netwerk draait.
FunnyMedia
28/10/08, 15:01
Idd n.a.v de storing ben ik zeer benieuwd naar de reactie van Nedzone.
Is erg jammer dat als er een stroomstoring is in 020 (nikhef) dat dan het gehele Nedzone netwerk plat lig.
Ik verwacht wel een uitleg van mijn leverancier vandaag.
Op zich is het natuurlijk erg raar dat het verkeer niet omgezet kan worden.
Dit zal voor Nedzone wel een goede les zijn waaruit ze actie gaan ondernemen.
Verder geen slecht woord over Nedzone. (Wil NIET bashen!!!)
Is een klein maar zeer fijn DC waar je overdag ook nog eens hulp kan vragen van een Nedzone engeneer.
Je kunt je traffic niet loadbalanced over je verschillende transits uitgooien, gaat gewoon niet werken, zo werkt BGP niet, BGP kiest het beste PAD ookal zit deze uplink vol, zal hij de kortste route pakken, nogmaals, al heb je 100 transit boeren, gaat 1 specifieke route maar over 1 boer en als daar net 1001 Mbit naar toe gaat, heb je issue's..
telnet@rtr1-ams-tc2#sh ip bgp 70.87.6.117
Number of BGP Routes matching display condition : 0
Status codes: s suppressed, d damped, h history, * valid, > best, i internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 70.84.0.0/14 82.98.253.161 5552 120 0 6461 21844 i
* 70.84.0.0/14 82.98.253.162 5568 120 0 6461 21844 i
* 70.84.0.0/14 81.18.163.166 0 120 0 (65002) 3356 21844 i
Last update to IP routing table: 5d23h39m51s, 1 path(s) installed:
Gateway Port
82.98.253.161 1/3
Route is advertised to 4 peers:
81.18.165.134(33803) 81.18.165.130(33803) 81.18.163.166(65002)
81.18.163.198(65003)
In de bgp tabel, zoals hierboven beschreven een IP van theplanet.com, pakt hij zijn best path, het is niet zo dat hij als er packetloss op de lijn zit in verband met congestion dat hij automatisch ander path pakt, Zodra deze route niet meer beschikbaar is, metric lager en of er een andere kortere route zich aanbied zal hij dit doen, maar dit is niet "intelligent routing".
Apoc, klepel?
ls 1 van je carriers een bepaald percentage gebruikt, kun je je routers het overige verkeer over andere routes laten lopen. Je hoeft niet per se altijd je verkeer over je snelste routes te laten lopen (als je daarmee het vollopen van een verbinding - en dus packetloss - kunt voorkomen).
Welk protocol gebruik je hiervoor? Ik ben hier erg benieuwd naar, want ik moest het meestal handmatig rerouten als ik congestion krijg.
Ik vind het juist naief om te stellen dat je storingen van dergelijke omvang niet kunt opvangen. Ik zeg niet dat het makkelijk is, maar het kan weldegelijk. Als jij 50gbps over de AMS-IX gooit, zul je erop voor bereid moeten zijn om die 50gbps over alternatieve routes te kunnen gooien.
Wat Merlijn juist probeert te zeggen, is dat ookal heb je dezelfde capaciteit gereserveerd op je transits, je een grote kans hebt dat ook je transits problemen hebben. Dat kan enerzijds door het transport wat een grote kans heeft dat het door SARA/NIKHEF/TC1 loopt, of het vollopen van hun backbonelinks/handoffs met bepaalde ISPs.
De hele ISP markt is gebouwd op oversubscribing, ook de transitmarkt.
Hoeveel transits er ook zijn, als de AMS-IX echt goed platgaat, vangen ze echt die 500Gbit/s niet op hoor.
Kan je niet meerdere AMS-IX verbinding krijgen op verschillende locaties? Ik dacht dat sommige partijen dit wel hadden.
Kan je niet meerdere AMS-IX verbinding krijgen op verschillende locaties? Ik dacht dat sommige partijen dit wel hadden.
Veel ISP's, vooral access providers zitten op Science Park ivm de connectivity voor telecom verkeer (ADSL etc) , dus als dat uitvalt, heb je net als gisteravond issue's.
Voorop gesteld, mijn kennis van netwerken is nihil.
Maar waarom zijn er dan geen meerdere locaties zoals Sciense Park? Dat zou dan toch zulk soort problemen kunnen voorkomen?
getUP, dat is 1 heel groot probleem inderdaad, er zou een 2e lokatie als het science park moeten zijn eigenlijk, dat zou een hoop oplossen.
Je kunt je traffic niet loadbalanced over je verschillende transits uitgooien, gaat gewoon niet werken, zo werkt BGP niet, BGP kiest het beste PAD ookal zit deze uplink vol, zal hij de kortste route pakken, nogmaals, al heb je 100 transit boeren, gaat 1 specifieke route maar over 1 boer en als daar net 1001 Mbit naar toe gaat, heb je issue's..
Dit is niet 100% correct:
Met een moderne router kan je zoiets doen als equal path loadbalancing waardoor je indien je 2 gelijk lange paden hebt kan loadbalancen over de 2. Met 100 transit boeren heb je een mooie kans dat er zeker 2 een gelijk pad hebben.
Voorbeeld voor juniper staat in het JUNOS Secure BGP Template:
http://www.cymru.com/gillsr/documents/junos-bgp-template.htm
En voor cisco:
http://www.cisco.com/en/US/docs/ios/iproute/configuration/guide/irp_bgp_multi_load_ps6441_TSD_Products_Configurati on_Guide_Chapter.html
er wordt in gehele bovenstaande lijst gesproken over transit, maar geld dit niet net zo hard voor peering providers? Natuurlijk heeft transit een hogere prio op de lijnen omdat hiervoor gewoon afgerekend wordt, maar wordt in de gehele discussie niet gewoon aalle traffic bedoelt, en niet alleen transit? Is even ter verduidelijking voor mij -.-.
Een tweede locatie als science park zou zeker beter en veiliger zijn, wat te doen bij natuurrampen etc in de buurt van science park? zou hele infrastructuur in dat geval omlaag halen, terwijl een secondary (backup) locatie dit in principe op zou kunnen vangen. Eea kost natuurlijk fors veel geld als startup, maar zou tevens gebruikt kunnen worden voor hogere breedband/glasvezel penetratie (zuiden van NL / Noord-Oost NL).
.:edit:. @luser
is er voor BGP niet zoeits als round-robin ondersteuning, zodat je bij (bijna) volle transit partners willekeurig een backup lijn gebruikt? zou natuurlijk wel traffic management vereisen, maar neem aan dat dit standaard draait. Eventueel als round-robin geen goed idee is, een nearest neighbour aanpak?
Dit is niet 100% correct:
Met een moderne router kan je zoiets doen als equal path loadbalancing waardoor je indien je 2 gelijk lange paden hebt kan loadbalancen over de 2. Met 100 transit boeren heb je een mooie kans dat er zeker 2 een gelijk pad hebben.
Voorbeeld voor juniper staat in het JUNOS Secure BGP Template:
http://www.cymru.com/gillsr/documents/junos-bgp-template.htm
En voor cisco:
http://www.cisco.com/en/US/docs/ios/iproute/configuration/guide/irp_bgp_multi_load_ps6441_TSD_Products_Configurati on_Guide_Chapter.html
Dat is allemaal wel heel mooi wat je zegt, maar ga jij 100 transit boeren aansluiten met een bepaalde commitment, niemand geeft je een 1GE of 10GE poort zonder enige vorm van commitment. En normale partijen willen een MIX van transitpartijen, en niet 10 dezelfde transitboeren op verschillende locaties, en ELKE transitpartij heeft andere routes.
Dit is niet 100% correct:
Met een moderne router kan je zoiets doen als equal path loadbalancing waardoor je indien je 2 gelijk lange paden hebt kan loadbalancen over de 2. Met 100 transit boeren heb je een mooie kans dat er zeker 2 een gelijk pad hebben.
Dat kan je dus alleen doen als je 2 paden naar dezelfde transit partij (AS) hebt. Het werkt niet als je 2 verschillende (even lange) paden naar verschillende transit partijen hebt.
Wel mooi om te zien dat er toch nog gegoogled wordt naar aanleiding van dit topic :)
er wordt in gehele bovenstaande lijst gesproken over transit, maar geld dit niet net zo hard voor peering providers? Natuurlijk heeft transit een hogere prio op de lijnen omdat hiervoor gewoon afgerekend wordt, maar wordt in de gehele discussie niet gewoon aalle traffic bedoelt, en niet alleen transit? Is even ter verduidelijking voor mij -.-.
Idd, voor een router is er geen verschil te zien tussen transit en peering, behalve misschien aan de gewichten/kosten die aan de paden gekoppeld zijn.
/me ziet hier een hoop mensen die groot voorstander zijn van asynchrone routing ;)
Geen moeilijke woorden gaan gebruiken nu he :)
Je kunt je traffic niet loadbalanced over je verschillende transits uitgooien, gaat gewoon niet werken, zo werkt BGP niet, BGP kiest het beste PAD ookal zit deze uplink vol, zal hij de kortste route pakken, nogmaals, al heb je 100 transit boeren, gaat 1 specifieke route maar over 1 boer en als daar net 1001 Mbit naar toe gaat, heb je issue's..
In de bgp tabel, zoals hierboven beschreven een IP van theplanet.com, pakt hij zijn best path, het is niet zo dat hij als er packetloss op de lijn zit in verband met congestion dat hij automatisch ander path pakt, Zodra deze route niet meer beschikbaar is, metric lager en of er een andere kortere route zich aanbied zal hij dit doen, maar dit is niet "intelligent routing".
Apoc, klepel?
Welk protocol gebruik je hiervoor? Ik ben hier erg benieuwd naar, want ik moest het meestal handmatig rerouten als ik congestion krijg.
Jij gaat er vanuit dat netwerken uitsluitend BGP gebruiken, maar BGP standalone is eigenlijk een heel simpel protocol, er zijn veel geavanceerdere oplossingen. Kijk bijvoorbeeld eens naar Avaya ANS (http://support.avaya.com/japple/css/japple?PAGE=Product&temp.productID=227906). Het is ook gebaseerd op BGP, maar dan VEEL geavanceerder.
Dat kan je dus alleen doen als je 2 paden naar dezelfde transit partij (AS) hebt. Het werkt niet als je 2 verschillende (even lange) paden naar verschillende transit partijen hebt.
Onzin, het kan zelfs met paden die niet even lang zijn, en ook naar verschillende transit partijen. Nogmaals, als je uitgaat van enkel BGP, dan ben je natuurlijk zeer beperkt in je mogelijkheden, maar er zijn veel geavanceerdere oplossingen.
@Funnymedia; dit topic is NIET bedoeld tegen een specifieke partij, het is een discussie in het algemeen. Het is dan ook niet de bedoeling dit topic te projecteren op een specifieke partij.
Dat kan je dus alleen doen als je 2 paden naar dezelfde transit partij (AS) hebt. Het werkt niet als je 2 verschillende (even lange) paden naar verschillende transit partijen hebt.
We hebben het momenteel alleen aanstaan bij een klant welke enkele verbindingen heeft naar een $tier1 partij en waar ivm netwerk topologie link aggregation niet kon. Monitoring zit niet bij ons dus weet niet zeker hoe efficient het is.
Klinkt naar een leuke test voor het labo :D
Jij gaat er vanuit dat netwerken uitsluitend BGP gebruiken, maar BGP standalone is eigenlijk een heel simpel protocol, er zijn veel geavanceerdere oplossingen. Kijk bijvoorbeeld eens naar Avaya ANS (http://support.avaya.com/japple/css/japple?PAGE=Product&temp.productID=227906). Het is ook gebaseerd op BGP, maar dan VEEL geavanceerder.
Ah natuurlijk, en je gaat iedereen nu even vertellen dat we over moeten stappen op ANS? Avaya is VoIP minded, niet eens routing.
Aanvulling: ANS is "Adaptive Networking Software" en is geen protocol, zie ook nergens dat het RFC complient is.
Denk toch eens fatsoenlijk na joh.
Kan je het even uittekenen voor ons Apoc, zonder dat asynchrone routing voorkomt.
Buiten dat, ga maar eens een transit/traffic provider vinden die dat protocol met je wilt praten.
Onzin, het kan zelfs met paden die niet even lang zijn, en ook naar verschillende transit partijen. Nogmaals, als je uitgaat van enkel BGP, dan ben je natuurlijk zeer beperkt in je mogelijkheden, maar er zijn veel geavanceerdere oplossingen.
OKOK, jij kan het weten natuurlijk! (???) Er zullen vast veel geavanceerdere oplossingen zijn, alleen raar dat 99.9% van het internet via BGP en AS'en met elkaar praat.
Ik zie een markt voor je :)
Ah natuurlijk, en je gaat iedereen nu even vertellen dat we over moeten stappen op ANS? Avaya is VoIP minded, niet eens routing.
Aanvulling: ANS is "Adaptive Networking Software" en is geen protocol, zie ook nergens dat het RFC complient is.
Ah ja, daarom gebruiken grote netwerken in de VS die geen VOIP doen het ook? Bijvoorbeeld http://www.gnax.net/aboutus/
Als jij denkt dat Avaya alleen op VOIP richt en geen verstand van routing hebt, dan zou ik je toch maar eens opnieuw laten voorlichten. Ik heb in de VS zelf met engineers van Avaya gewerkt en zij hebben hun oplossingen geimplementeerd in netwerken die absoluut geen VOIP verkeer gebruiken.
En al doen ze wel VOIP verkeer, dat staat er helemaal los van. Het punt is dat wat ik omschreef weldegelijk mogelijk is.
OKOK, jij kan het weten natuurlijk! (???) Er zullen vast veel geavanceerdere oplossingen zijn, alleen raar dat 99.9% van het internet via BGP en AS'en met elkaar praat.
Ik zie een markt voor je :)
Misschien moet je het even beter lezen. Avaya ANS is een oplossing die gebaseerd is op BGP, het is geen nieuw protocol.
Lees wat hier boven staan, 0,0 is hier "ANS" minded, Cisco, Foundry en Juniper en whatever model "except Avaya" zul je dit protocol in terugvinden.
99,99% van alle routers babbelen BGP, niet ruklaak zo maar iets gaan zeggen.
Iets met bel en klepel? :)
Ik ga niet alles lezen, maar met AS Path kan je het een en ander loadbalancen over je transits, enkel op het moment dat 1 partij een kortere aspath heeft is dat direct de BEST route... dus loadbalancen doe je dan ook niet....
Misschien moet je het even beter lezen. Avaya ANS is een oplossing die gebaseerd is op BGP, het is geen nieuw protocol.
Nogmaals:
Adaptive Networking Software (ANS) provides adaptive management for network infrastructure. The software can monitor, assess, and adjust the network environment in real time to maximize applications availability, while optimizing between cost and performance. The result is a network infrastructure that is self-healing and self-optimizing.
Software != Protocol
BGP = een Protocol -> http://www.ietf.org/rfc/rfc1771.txt
ANS = Adaptive Networking Software
Zie je het NU?
Edit: lees je RFC's, vraag rond bij IETF, RIPE of what ever, voordat je met betere uitspraken komt.
Nogmaals:
Adaptive Networking Software (ANS) provides adaptive management for network infrastructure. The software can monitor, assess, and adjust the network environment in real time to maximize applications availability, while optimizing between cost and performance. The result is a network infrastructure that is self-healing and self-optimizing.
Software != Protocol
BGP = een Protocol
ANS = Adaptive Networking Software
Zie je het NU?
Edit: lees je RFC's, vraag rond bij IETF, RIPE of what ever, voordat je met betere uitspraken komt.
Ben jij nou echt doof? Lees nou eens wat ik zeg. De Adaptive Network Software in dit geval IS GEBASEERD OP bgp. Je kunt een netwerk wat momenteel BGP draait, laten optimaliseren door de software van Avaya, en nog steeds BGP praten. De software beinvloed je uitgaande routes, in BGP.
Avaya ANS heeft niets te maken met de wijze waarop jouw routers tegen andere routers praten, ze praten nog steeds dezelfde taal, echter worden er andere (betere) routes/carriers gekozen. Zo kun je bijvoorbeeld een carrier die voor 80% belast wordt, niet verder belasten door geen nieuwe uitgaande verbindingen over die carrier te lopen. Dat is wat Avaya ANS doet. Probeer mij nou niet de les te lezen over BGP en ANS, ik heb beide jarenlang zelf gebruikt in de VS.
Ben jij nou echt doof? Lees nou eens wat ik zeg. De Adaptive Network Software in dit geval IS GEBASEERD OP bgp. Je kunt een netwerk wat momenteel BGP draait, laten optimaliseren door de software van Avaya, en nog steeds BGP praten. De software beinvloed je uitgaande routes, in BGP.
Avaya ANS heeft niets te maken met de wijze waarop jouw routers tegen andere routers praten, ze praten nog steeds dezelfde taal, echter worden er andere (betere) routes/carriers gekozen. Zo kun je bijvoorbeeld een carrier die voor 80% belast wordt, niet verder belasten door geen nieuwe uitgaande verbindingen over die carrier te lopen. Dat is wat Avaya ANS doet. Probeer mij nou niet de les te lezen over BGP en ANS, ik heb beide jarenlang zelf gebruikt in de VS.
Tuurlijk meneer de expert :)
Vertel mij eens even hoe ik dat implementeer op mijn foundry's, je hebt continue route changes, en waarom zou ik mijn capaciteit die over IX verkeer loopt willen afvloeien naar transit.
Het is helemaal niet gebaseerd op BGP, het managed misschien BGP, maar het is er totaal niet opgebaseerd.
Verder is de vraag of je zoiets geautomatiseerd wilt doen, dat kan lijkt mij compleet onvoorspelbare routing veroorzaken en je onverwacht op hoge kosten jagen omdat bijvoorbeeld ANS je dure transit / PP prefereerd boven je goedkope.
Ben jij nou echt doof? Lees nou eens wat ik zeg.
Je durft wel, meeste niet-mods zouden al een paar puntjes gekregen hebben na zo'n uitspraak...
Probeer mij nou niet de les te lezen over BGP en ANS, ik heb beide jarenlang zelf gebruikt in de VS.
Ok, weet je toevallig welke ISPs het in Europa gebruiken?
Enige wat ik uit de docs haal, is dat het de metrics van de routes aanpast, naar gelang de software een pad niet of wel geschikt vind.
Het is helemaal niet gebaseerd op BGP, het managed misschien BGP, maar het is er totaal niet opgebaseerd.
Verder is de vraag of je zoiets geautomatiseerd wilt doen, dat kan lijkt mij compleet onvoorspelbare routing veroorzaken en je onverwacht op hoge kosten jagen omdat bijvoorbeeld ANS je dure transit / PP prefereerd boven je goedkope.
Dit soort systemen heb ik wel vaker voorbij zien komen (Geloof dat peakflow ook zoiets dergelijks had), maar waarom zou je dat uberhaupt willen implementeren.
Maar idd, het is niet gebaseerd op BGP maar een stukje software op een server die je routes wil optimaliseren op je router.
Dus, klepel?
Een stukje uit de PDF van ANS.
The ANS system bases its selection of service provider for a given prefix on its analysis of measured
traffic, not on statistical assumptions (load balancing) or the predefined rules of the Border Gateway
Protocol (BGP).
Whenever a currently selected Internet Service Provider (ISP) link is observed to be experiencing
significant delays that degrade its ability to deliver packets to a specific prefix, the ANS system can—if you allow it—update your network routing tables so that your routers will use a different service provider for traffic to that prefix.
You can configure the ANS system to favor the lowest-cost or the least utilized service provider. You can use the system in report only mode, in which traffic is measured and analyzed but routes are not actually asserted to your edge routers.
Blijft het punt dat het raar is dat er geen oplossing is voor dit (grote) probleem op dit moment :( er zal toch iets moeten gebeuren nu?
Blijft het punt dat het raar is dat er geen oplossing is voor dit (grote) probleem op dit moment :( er zal toch iets moeten gebeuren nu?
Het probleem is vrij gemakkelijk op te lossen: 100 GigE! Zodra de 100GigE er is dan hebben we voorlopig geen last meer van dit probleem.
Blijft het punt dat het raar is dat er geen oplossing is voor dit (grote) probleem op dit moment :( er zal toch iets moeten gebeuren nu?
Ja, dat is het lastige ervan, het grote probleem is capaciteit, niet BGP :)
Het is helemaal niet gebaseerd op BGP, het managed misschien BGP, maar het is er totaal niet opgebaseerd.
Dat is inderdaad wat ik bedoelde, excuses als ik het verwarrend omschreef.
Verder is de vraag of je zoiets geautomatiseerd wilt doen, dat kan lijkt mij compleet onvoorspelbare routing veroorzaken en je onverwacht op hoge kosten jagen omdat bijvoorbeeld ANS je dure transit / PP prefereerd boven je goedkope.
Dit kun je gewoon instellen. Je kunt bijvoorbeeld instellen dat al het verkeer wat over peering KAN, ook over peering gestuurd wordt (tenzij de peering verbindingen niet beschikbaar zijn, natuurlijk).
Natuurlijk moet je het niet "out of the box" in je netwerk implementeren en vervolgens het geheel zelf laten beslissen wat het doet.
je hebt continue route changes, en waarom zou ik mijn capaciteit die over IX verkeer loopt willen afvloeien naar transit.
Je hebt niet continue route changes, het is een stuk geavanceerder dan dat. Je kunt het zelfs zo instellen dat het je verkeer per carrier constanter maakt om kosten uit te sparen. Daarnaast; waarom je verkeer die over exchanges loopt zou willen afvloeien naar transit? Misschien gaat dit hele topic daar juist over? Als bijvoorbeeld Nikhef platligt en een groot gedeelte van de exchanges niet beschikbaar zijn..
Dus, klepel?
Je kunt je traffic niet loadbalanced over je verschillende transits uitgooien, gaat gewoon niet werken, zo werkt BGP niet, BGP kiest het beste PAD ookal zit deze uplink vol, zal hij de kortste route pakken, nogmaals, al heb je 100 transit boeren, gaat 1 specifieke route maar over 1 boer en als daar net 1001 Mbit naar toe gaat, heb je issue's..
Mijn punt is dat wat jij in eerste instantie zei, simpelweg niet klopt. Met een ANS oplossing kun je je uitgaande verkeer weldegelijk uitspreiden over je carriers om het vollopen van 1 bepaalde carrier te voorkomen.
Ontopic:
Dit probleem word denk ik overigens vooral dus gecreeerd doordat het 'nederlandse internet' (om het even heel simpel te zeggen) mijns inziens teveel gecentreerd is op een paar plaatsen in Amsterdam.
Maarja, das natuurlijk weer logisch, waarom zou je naar X pops gaan als je al je benodigde peers @ Nikhef kan krijgen... veel cheaper.
Of, waarom zou je naar carrier X op pop Y connecten als het verkeer uiteindelijk toch weer via Nikhef loopt, dan kan je net zo goed daar direct connecten.
Je hebt niet continue route changes, het is een stuk geavanceerder dan dat. Je kunt het zelfs zo instellen dat het je verkeer per carrier constanter maakt om kosten uit te sparen. Daarnaast; waarom je verkeer die over exchanges loopt zou willen afvloeien naar transit? Misschien gaat dit hele topic daar juist over? Als bijvoorbeeld Nikhef platligt en een groot gedeelte van de exchanges niet beschikbaar zijn..
Rrrrright... succes verder he!
BTW, mijn netwerk was verder wel netjes up, zoals vele andere netwerken die wel goed multihomed waren, pluspuntjes voor die mensen die up bleven!
Toedelsch!
Ber|Art edit: Dit is niet nodig ontopic a.u.b.
Ja, dat is het lastige ervan, het grote probleem is capaciteit, niet BGPDus het probleem is makkelijk op te lossen door de capaciteit uit te breiden. Als het zo simpel is waarom is dit dan nog niet gebeurd? Of is dit erg kostbaar en is het allemaal allen een kwestie van geld?
Dus het probleem is makkelijk op te lossen door de capaciteit uit te breiden. Als het zo simpel is waarom is dit dan nog niet gebeurd? Of is dit erg kostbaar en is het allemaal allen een kwestie van geld?
Dit is inderdaad erg duur, maar alleen capaciteit lost het niet op, meer spreiding zal ook nodig zijn imo.
Dus het probleem is makkelijk op te lossen door de capaciteit uit te breiden. Als het zo simpel is waarom is dit dan nog niet gebeurd? Of is dit erg kostbaar en is het allemaal allen een kwestie van geld?
Geld is niet zozeer het probleem als je geen verkeer doet kost je dat ook klauwen met geld
dus liever een wat duurdere transit dan helemaal geen verkeer
Alleen zoals gisteren waren zelfs carriers offline.
dus kan je wel slim lopen BGP'en maar als je router plat ligt of je netwerktransit is weg
wat wil je dan bgp'en baked luft?
MediaServe
28/10/08, 17:32
Je kunt ook static routes met BGP gebruiken. Wellicht kun je zo een failover maken voor de AMS-IX prefixes met het meeste traffic. Als een AMS-IX route dood is, dan pakt BGP de volgende route met de laagste metric. Als dat nou een static route is naar een transit provider, en je plaatst verschillende static routes voor verschillende prefixes, dan heb je toch een vorm van loadbalancing?
:innocent:
Het probleem is vrij gemakkelijk op te lossen: 100 GigE! Zodra de 100GigE er is dan hebben we voorlopig geen last meer van dit probleem.
Dat is hetzelfde als zeggen: wij lossen het fileprobleem op door een extra baan aan te leggen. Als er maar auto's bij blijven komen loop je toch weer tegen het probleem aan. En je moet ook de afritten en secundaire wegen verbeteren ;)
Dus het probleem is makkelijk op te lossen door de capaciteit uit te breiden. Als het zo simpel is waarom is dit dan nog niet gebeurd? Of is dit erg kostbaar en is het allemaal allen een kwestie van geld?
Omdat de 40 en 100GigE nog niet op de markt zijn. Wat je nu ziet is dat netwerken moeten aggregaten met 10 GigE poorten, zoals Eweka nu 80 GigE AMS-IX heeft door simpelweg 8 x 10GigE te bundelen.
Om ook nog eens 80 GigE "leeg" te laten puur voor de backup betekend dit dat je dubbel moet investeren in verbindingen en apparatuur, dus je mbit gaat over de kop. Verder moet je ook de garantie hebben dat als je 80 GigE naar een transitpartij legt deze het op zijn eigen backbone wel vrij moet hebben.
Door straks te gaan werken met 100GigE heb je enkel 2 interfaces nodig in plaats van 20.
Uiteraard zal het even duren voordat de 40 en 100GigE in productie gaan, maar dit kan het probleem _deels_ oplossen.
APOC als je het allemaal zo goed weet waarom heb je dan geen eigen netwerk ?
maar ben je maar een afnemer van een partij ?
Het netwerk waar wij draaien had het probleem dat ze hun traffic over andere routes niet kwijtkonden niet, dus wat dat betreft is daar geen reden toe.
Dit topic is gericht tegen de partijen die hun traffic niet via andere routes kwijt konden, en dat is in mijn mening kwalijk. Vervolgens kwam Merlijn van LW met een verhaal dat het niet mogelijk is om al hun verkeer over transit te gooien als Nikhef plat gaat, en Phreak voegde er aan toe dat al dat verkeer dan over 1 carrier zou gaan omdat je het verkeer niet zou kunnen uitspreiden over meerdere carriers - en mijn reactie daarop was dat dat onzin is.
Dit probleem word denk ik overigens vooral dus gecreeerd doordat het 'nederlandse internet' (om het even heel simpel te zeggen) mijns inziens teveel gecentreerd is op een paar plaatsen in Amsterdam.
Maarja, das natuurlijk weer logisch, waarom zou je naar X pops gaan als je al je benodigde peers @ Nikhef kan krijgen... veel cheaper.
Helemaal mee eens. En tuurlijk is het veel goedkoper, maar dat neemt niet weg dat je een alternatief beschikbaar zou moeten hebben om niet geheel van 1 locatie afhankelijk te zijn. In de huidige situatie, waarin je niet naar een ander Science Park kunt uitwijken, zal dat dus (vaak) betekenen dat je naar transit moet uitwijken.
Of, waarom zou je naar carrier X op pop Y connecten als het verkeer uiteindelijk toch weer via Nikhef loopt, dan kan je net zo goed daar direct connecten.
Tuurlijk zou je sowieso ook via Nikhef moeten kunnen verbinden, maar je moet ook een alternatief beschikbaar hebben.
Dat is hetzelfde als zeggen: wij lossen het fileprobleem op door een extra baan aan te leggen. Als er maar auto's bij blijven komen loop je toch weer tegen het probleem aan. En je moet ook de afritten en secundaire wegen verbeteren ;)
Je vergelijking slaat kant noch wal...
1. http://www.ispam.nl/archives/2487/groei-dataverkeer-op-internet-stagneert/
2. Je hebt het wel over een vertienvoudiging van de capaciteit!
3. Zie het als computers... elk jaar worden ze sneller omdat de programma's zwaarder worden.
Je vergelijking slaat kant nog wal...
Vind ik niet:
1. http://www.ispam.nl/archives/2487/groei-dataverkeer-op-internet-stagneert/
Het feit dat het momenteel stagneert, betekent niet dat er geen verdere exponentiele groei komt in de nabije toekomst. Er zijn momenteel overal plannen om glasvezel aan te leggen naar huizen, en ik verwacht dat daarmee toch een flinke groei komt.
2. Je hebt het wel over een vertienvoudiging van de capaciteit!
Dat is waar, maar als je naar de groei van de AMS-IX kijkt over de afgelopen jaren, dan is dat niet HEEL veel.
3. Zie het als computers... elk jaar worden ze sneller omdat de programma's zwaarder worden.
Volgens mij werkt het eerder andersom - nieuwe programma's worden zwaarder omdat er snellere computers beschikbaar zijn om die programma's te draaien.
Helemaal mee eens. En tuurlijk is het veel goedkoper, maar dat neemt niet weg dat je een alternatief beschikbaar zou moeten hebben om niet geheel van 1 locatie afhankelijk te zijn. In de huidige situatie, waarin je niet naar een ander Science Park kunt uitwijken, zal dat dus (vaak) betekenen dat je naar transit moet uitwijken.
Transit of peering heeft er niet mee te maken omdat dat dus in de huidige situatie nog steeds vaak over Nikhef zal gaan.
Dat is waar, maar als je naar de groei van de AMS-IX kijkt over de afgelopen jaren, dan is dat niet HEEL veel.
Niet veel? Nu hebben ze ongeveer 100 poorten nodig om 500 Gbit te kunnen switchen (50 x 10 GigE x RX/TX) dit kunnen ze nu dus opvangen door 10 poorten. Nogal een verschil?
Jij stelt in dit topic voor om te gaan loadbalancen, maar dat is toch niets meer dan uitstel van executie?
Naar mijn mening is de 100gigE op DIT moment de oplossing, over 10 jaar zijn we toe aan de 1TeraE oid :)
Transit of peering heeft er niet mee te maken omdat dat dus in de huidige situatie nog steeds vaak over Nikhef zal gaan.
Inderdaad de locatie is gewoon offline enige oplossing zou zijn
dat je bijvoorbeeld fallback op SARA of TC1 zou moeten hebben
en dan vanuit daar transport naar je colocatie
Nadeel is sommige carriers zitten niet in SARA en wel weer in TC1
Transit of peering heeft er niet mee te maken omdat dat dus in de huidige situatie nog steeds vaak over Nikhef zal gaan.
Als jij in een Nederlands datacenter die transit afneemt, dan is er inderdaad een grote kans dat die transit ook over Nikhef loopt. Maar ook daar zijn 2 oplossingen voor:
- Je zou bij de carrier kunnen navragen hoe hun routes lopen, om bepaalde locaties te ontwijken
- Indien dat niet mogelijk is, zou je een fiber naar bijvoorbeeld Duitsland kunnen nemen en je verkeer daar over transit gooien. Uiteraard, ik begrijp dat voor jullie netwerk vooral het Nederlandse verkeer het meeste relevant is, dus dan is dat minder van toepassing (omdat het Nederlandse verkeer wellicht dan weer terugkomt naar Nederland, wederom over de Nikhef).
Bottom line is dat eigenlijk ieder netwerk via minimaal 2 verschillende locaties bereikbaar zou moeten zijn.
Je vergelijking slaat kant noch wal...
Is dat zo? Dat groei stagneert betekend niet dat er geen groei is. De AMSIX zit ook weer boven de groeiverwachtingen. En een vertienvoudiging in capaciteit is geweldig, alleen nogmaals: dat is geen structurele oplossing. Zoals Proserve aangaf: zij hadden nergens last van omdat ze de verbindingen in meerdere datacentra afnemen en Nedzone was blijkbaar weer het tegenovergestelde.
Niet veel? Nu hebben ze ongeveer 100 poorten nodig om 500 Gbit te kunnen switchen (50 x 10 GigE x RX/TX) dit kunnen ze nu dus opvangen door 10 poorten. Nogal een verschil?
Jij stelt in dit topic voor om te gaan loadbalancen, maar dat is toch niets meer dan uitstel van executie?
Naar mijn mening is de 100gigE op DIT moment de oplossing, over 10 jaar zijn we toe aan de 1TeraE oid :)
Tuurlijk, ik erken zonder meer dat 100gigE een gedeeltelijke (voorlopige) oplossing kan bieden. Maar het punt is dat de meeste netwerken in Nederland gewoon 1gbit lijntjes hebben naar hun transit carriers, en in dat opzicht is het niet alsof de beschikbaarheid van 100gig poorten daar verandering in zou brengen.
MediaServe
28/10/08, 17:54
Je vergelijking slaat kant nog wal...
De vergelijking van Stewie klopt wel degelijk.
Je wilt een probleem oplossen, niet alleen uitstellen.
Jij stelt in dit topic voor om te gaan loadbalancen, maar dat is toch niets meer dan uitstel van executie?
Nee, alleen de capaciteit verhogen is uitstel van executie. Je moet juist zoeken naar een structurele oplossing, oftewel de load kunnen verdelen tussen uplinks die WEL actief zijn.
Is dat zo? Dat groei stagneert betekend niet dat er geen groei is. De AMSIX zit ook weer boven de groeiverwachtingen. En een vertienvoudiging in capaciteit is geweldig, alleen nogmaals: dat is geen structurele oplossing. Zoals Proserve aangaf: zij hadden nergens last van omdat ze de verbindingen in meerdere datacentra afnemen en Nedzone was blijkbaar weer het tegenovergestelde.
Dan is toch het hele topic nutteloos? Het hele verhaal van loadbalancen staat mij niet zo aan, de oplossing is uitbreiding, zijn er geen huizen dan bouwen we extra huizen! Je hebt bijna geen ruimte nodig voor uitbreiding als het gaat om het protocol.
De ruimte is er, dus wat staat er in de weg om niet te gaan uitbreiden? Vraag aanbod?
Tuurlijk, ik erken zonder meer dat 100gigE een gedeeltelijke (voorlopige) oplossing kan bieden. Maar het punt is dat de meeste netwerken in Nederland gewoon 1gbit lijntjes hebben naar hun transit carriers, en in dat opzicht is het niet alsof de beschikbaarheid van 100gig poorten daar verandering in zou brengen.
De partijen met 1Gig hebben ook geen enkel probleem, het probleem zit hem op dit moment bij de grote jongens: Leaseweb, Eweka etc etc. Daar gaat dit topic toch over?
ps. we praten nu allemaal langs elkaar heen?
Als jij in een Nederlands datacenter die transit afneemt, dan is er inderdaad een grote kans dat die transit ook over Nikhef loopt. Maar ook daar zijn 2 oplossingen voor:
- Je zou bij de carrier kunnen navragen hoe hun routes lopen, om bepaalde locaties te ontwijken
- Indien dat niet mogelijk is, zou je een fiber naar bijvoorbeeld Duitsland kunnen nemen en je verkeer daar over transit gooien. Uiteraard, ik begrijp dat voor jullie netwerk vooral het Nederlandse verkeer het meeste relevant is, dus dan is dat minder van toepassing (omdat het Nederlandse verkeer wellicht dan weer terugkomt naar Nederland, wederom over de Nikhef).
Bottom line is dat eigenlijk ieder netwerk via minimaal 2 verschillende locaties bereikbaar zou moeten zijn.
Probleem is dan dat je doel netwerk ook niet afhankelijk van Nikhef moet zijn, anders zal je daar nog steeds uitkomen.
Je 2e punt klopt, wij konden bijvoorbeeld gisteren al ons colo verkeer gewoon via London en Frankfurt afhandelen omdat we daar ook transit afnemen en onze fibers daarheen niet via Nikhef lopen.
De partijen met 1Gig hebben ook geen enkel probleem, het probleem zit hem op dit moment bij de grote jongens: Leaseweb, Eweka etc etc. Daar gaat dit topic toch over?
ps. we praten nu allemaal langs elkaar heen?
Exact.
Probleem is dan dat je doel netwerk ook niet afhankelijk van Nikhef moet zijn, anders zal je daar nog steeds uitkomen.
Je 2e punt klopt, wij konden bijvoorbeeld gisteren al ons colo verkeer gewoon via London en Frankfurt afhandelen omdat we daar ook transit afnemen en onze fibers daarheen niet via Nikhef lopen.
Inderdaad, je doel netwerk moet ook bereikbaar zijn via een tweede locatie, daar kun je zelf natuurlijk weinig aan doen.
Dan is toch het hele topic nutteloos? Het hele verhaal van loadbalancen staat mij niet zo aan, de oplossing is uitbreiding, zijn er geen huizen dan bouwen we extra huizen! Je hebt bijna geen ruimte nodig voor uitbreiding als het gaat om het protocol.
Ik moet erkennen dat je gedeeltelijk gelijk hebt, maar uitbreiden is niet de enige oplossing. Als je op de snelweg bijvoorbeeld auto's geautomatiseerd 20 cm van elkaar met exact dezelfde snelheid zou kunnen laten rijden, dan los je ook het fileprobleem op. Dit exacte voorbeeld is dan niet letterlijk toepasbaar op internetverkeer, maar het is slechts een voorbeeld om aan te geven dat er meerdere oplossingen denkbaar zijn, waar dus ook ANS een rol zou kunnen spelen.
Je zei:
Naar mijn mening is de 100gigE op DIT moment de oplossing
Het punt is; op DIT moment zijn er geen 100gigE poorten beschikbaar, en ANS of een andere soortgelijke oplossing wel, waarmee je dus meerdere kleinere (10gigE) verbindingen gebruikt kunnen worden. Als je bij een carrier in de toekomst een 100gigE kan afnemen, dan moet je er ook 10x 10gigE poorten moeten kunnen afnemen.
De partijen met 1Gig hebben ook geen enkel probleem, het probleem zit hem op dit moment bij de grote jongens: Leaseweb, Eweka etc etc. Daar gaat dit topic toch over?
Dat is dus niet helemaal waar. Er zijn genoeg netwerken die een paar 1gbit lijnen voor verkeer naar transit carriers hebben, en daarnaast enkele 10gbit lijnen naar de AMS-IX. Dat maakt ze dus volledig afhankelijk van de AMS-IX.
Dat is dus niet helemaal waar. Er zijn genoeg netwerken die een paar 1gbit lijnen voor verkeer naar transit carriers hebben, en daarnaast enkele 10gbit lijnen naar de AMS-IX. Dat maakt ze dus volledig afhankelijk van de AMS-IX.
Heb je wel eens geprobeerd om 10G af te sluiten bij een transit provider zonder er een paar mbits overheen te doen?
Heb je wel eens geprobeerd om 10G af te sluiten bij een transit provider zonder er een paar mbits overheen te doen?
Dat is niet waar ik op doelde. Als een netwerk bijvoorbeeld 4gigabit over de AMS-IX stuurt, zou je op je transit verbindingen genoeg ruimte moeten overhouden om dat verkeer op te vangen, mocht de AMS-IX uitvallen. Je hebt daar niet per se 10gigE verbindingen bij de transit carriers voor nodig.
Stel je doet 4gig exchange verkeer en 1 gig transit verkeer, dan zou je dus naast je 10gigE verbindingen bij de AMS-iX, minimaal 5x een 1gigE verbinding bij transit carriers moeten afnemen (en dat is prima mogelijk als je normaliter gemiddeld 200mbit over iedere 1gigE transit doet (wanneer de AMS-IX wel gewoon werkt).
Probleem is vaak je moet bj 1gbit ook minimum commitment afnemen
Kale lijn geen verkeer overheen doen kost ook geld
Probleem is vaak je moet bj 1gbit ook minimum commitment afnemen
Kale lijn geen verkeer overheen doen kost ook geld
Klopt, maar in mijn voorbeeld zou je dan dus die gigabit transit verkeer kunnen uitspreiden over die 5 gigE verbindingen (5x 200mbit). Natuurlijk kost dat meer dan wanneer je die gigabit verkeer uitspreid over 2 gigE verbindingen (2x 500mbit), maar je houdt dan dus wel veel meer speling over wanneer (bijvoorbeeld) de AMS-IX uitvalt. Het lijkt me dat dat de extra kosten wel verantwoord.
Stel dat je ervoor kiest om niet genoeg speling over te houden om de uitval van een exchange op te kunnen vangen, dan spaar je normaliter dus wel wat kosten uit, maar in het geval van een storing van die exchange, heb je dus wel zelf die keuze voor lagere betrouwbaarheid gemaakt.
Om weer even lekker kort door de bocht te reageren. Iedereen heeft het over de kosten, vooral dat Nikhef goedkoop is omdat iedereen er toch al zit.
Nu kan ik niks zeggen over jullie financiele plaatje, maar missen de partijen die het niet op orde hebben nu niet juist inkomsten? Uiteindelijk is het toch een kwestie van de kosten tegen de baten afwegen en kijken in hoeverre het rendabel, of nog belangrijker, winstgevend kan zijn om te loadbalancen cq meerdere locaties op te zetten? Zit hier nu zo'n wezenlijk verschil in?
Nogmaals, leek aan het woord hier, dus nog een vraag, waarom zou nou juist capaciteitsvergroting een oplossing bieden? Zit je dan niet alsnog met een SPOF zijnde Nikhef?
Nogmaals, leek aan het woord hier, dus nog een vraag, waarom zou nou juist capaciteitsvergroting een oplossing bieden? Zit je dan niet alsnog met een SPOF zijnde Nikhef?
Er lopen 3 discussies door elkaar, lees het allemaal even terug.
dreamhost_nl
28/10/08, 19:22
...zijn er geen huizen dan bouwen we extra huizen...
Ik heb nog aan toe de discussie stilzwijgend gevolgd, maar hier ontgaat me toch echt de vergelijking. Waar is de term "huizen" in jouw vergelijking hier de synoniem van?
Ik heb nog aan toe de discussie stilzwijgend gevolgd, maar hier ontgaat me toch echt de vergelijking. Waar is de term "huizen" in jouw vergelijking hier de synoniem van?
Die vergelijking klopt inderdaad niet, die met een snelweg is wat dat betreft beter.
Er lopen 3 discussies door elkaar, lees het allemaal even terug.
Ik denk dat hij voornamelijk op jou reageerde en hij heeft wel een punt. Als je momenteel een 10gigabit poort op Nikhef had, dan had het geen verschil gemaakt als dat geupgrade kan worden naar 100gigabit. Plat = plat.
Het punt is voornamelijk; je kan een snelweg wel verbreden, maar als die hele snelweg afgesloten wordt, maakt het niet uit hoe breed die snelweg is. Het is dan natuurlijk wel van belang dat de omliggende wegen voldoende capaciteit hebben om het normale verkeer van die snelweg op te kunnen vangen. En daar gaat het me juist om; je moet voldoende capaciteit hebben om ervoor te zorgen dat je het dataverkeer van elke willekeurige locatie kunt opvangen als die locatie plat gaat. Dat is hier het voornaamste probleem. Zoals ik eerder omschreef, heb je daar niet per se 100gigE poorten voor nodig, je kan dat ook prima uitspreiden over kleinere verbindingen, zolang het er maar genoeg zijn.
Die vergelijking klopt inderdaad niet, die met een snelweg is wat dat betreft beter.
Het punt is voornamelijk; je kan een snelweg wel verbreden, maar als die hele snelweg afgesloten wordt, maakt het niet uit hoe breed die snelweg is. Het is dan natuurlijk wel van belang dat de omliggende wegen voldoende capaciteit hebben om het normale verkeer van die snelweg op te kunnen vangen. En daar gaat het me juist om; je moet voldoende capaciteit hebben om ervoor te zorgen dat je het dataverkeer van elke willekeurige locatie kunt opvangen als die locatie plat gaat. Dat is hier het voornaamste probleem. Zoals ik eerder omschreef, heb je daar niet per se 100gigE poorten voor nodig, je kan dat ook prima uitspreiden over kleinere verbindingen, zolang het er maar genoeg zijn.
Hoe wil je dat spreiden dan, geef eens een duidelijk voorbeeld?
Ik vind dat een aantal mensen in deze discussie niet langer kijken dan hun neus lang is.
In de trant van:
"als je maar genoeg backup poorten hebt"
"als je maar niet via nikhef loopt"
Mijn beleving gisteren was iets anders.
Door de uitval van gisteren viel niet alleen 200Gbit/s AMS-IX peering verkeer weg, maar ook xxxGbit/s transit poorten, en nog een yyyGbit/s private peering tussen de "grote" jongens op NIKHEF.
Dit is een pure schatting, maar als je wel eens een rondje langs alle kasten op nikhef bent gelopen weet je dat het verdomd veel 10GE poorten zijn, mogelijk viel er wel een Tbit/s aan verkeer weg.
Na de uitval moesten alle netwerken gebruik maken van hun alternatieve paden. Dat heeft bij veel partijen voor problemen gezorgd.
En dan hebben we het nog niet eens over "probleem" destinations als bijvoorbeeld DTAG, peering capaciteit is normaliter al moeilijk met die netwerken.
Simpel voorbeeld: Netwerken als Leaseweb, en Eweka hebben duizenden Mbit/s naar bepaalde eyeball netwerken. Als beide bij uitval gebruik maken van carrier-Y voor eyeball-Z zal waarschijnlijk de peering tussen carrier-Y en eyeball-Z vol lopen.
Het is onmogelijk om te bepalen wat voor consequenties een storing als gisteren heeft op alle peering punten. Immers Eweka weet niet wie er nog meer gebruik gaat maken van zijn carrier-Y voor eyeball-Z zodra er een groot probleem plaats vindt.
Eweka heeft aangegeven verkeer te hebben gestuurd via LINX en DE-CIX, maar als ik de stats van beide bekijk hebben zeer weinig andere netwerken (of carriers) dat gedaan. vooral de DE-CIX stats is niks op te zien.
my 2 cents.
Ik denk dat hij voornamelijk op jou reageerde en hij heeft wel een punt. Als je momenteel een 10gigabit poort op Nikhef had, dan had het geen verschil gemaakt als dat geupgrade kan worden naar 100gigabit. Plat = plat.
Dat is ook totaal niet waar ik op doel. Ik heb het over de capaciteit van de carriers, die kunnen nu de 50 of 80 Gbit niet aan, wat straks met de komst van 100 GigE een stuk gemakkelijker zal worden (uiteraard tijdelijk, straks spreken we over terabits inplaats van gigabits).
De discussie ging over dat een aantal "grote" partijen het verkeer niet konden door pushen richting transit omdat ook deze niet voldoende capaciteit hadden.
Vandaar dat ik dus zeg: Er lopen momenteel 3 discussies in 1 topic.
Hoe wil je dat spreiden dan, geef eens een duidelijk voorbeeld?
Ik gaf eerder al het volgende voorbeeld:
Stel je doet 4gig exchange verkeer en 1 gig transit verkeer, dan zou je dus naast je 10gigE verbindingen bij de AMS-iX, minimaal 5x een 1gigE verbinding bij transit carriers moeten afnemen (en dat is prima mogelijk als je normaliter gemiddeld 200mbit over iedere 1gigE transit doet (wanneer de AMS-IX wel gewoon werkt).
Of bedoelde je iets anders?
Eweka heeft aangegeven verkeer te hebben gestuurd via LINX en DE-CIX, maar als ik de stats van beide bekijk hebben zeer weinig andere netwerken (of carriers) dat gedaan. vooral de DE-CIX stats is niks op te zien.
Dat is dus zo ongeveer mijn punt; dat is een van de mogelijkheden waar je je verkeer overheen zou kunnen sturen als alternatief. Het punt is dus juist dat dat vrijwel niet gedaan wordt.
Dat is ook totaal niet waar ik op doel. Ik heb het over de capaciteit van de carriers, die kunnen nu de 50 of 80 Gbit niet aan, wat straks met de komst van 100 GigE een stuk gemakkelijker zal worden (uiteraard tijdelijk, straks spreken we over terabits inplaats van gigabits).
Ik begrijp je punt wel, maar ik zeg enkel dat dit niet per se DE oplossing hoeft te zijn.
Als ik je goed begrijp, bedoel je dat carriers nu onderling met elkaar verbonden zijn via 10gigE poorten, en dat dit dan geupgrade kan worden naar 100gigE poorten. Een vertienvoudiging van de capaciteit van de carrier als geheel. Tuurlijk lost dit een gedeelte van het probleem op tegen de tijd dat 100gigE poorten beschikbaar zijn, maar het probleem is dat die 100gigE poorten er nu nog niet zijn.
Juist daarom zeg ik juist; het kan ook nu al, zonder de 100gigE poorten opgelost worden, met kleinere verbindingen. Natuurlijk kan jij niet zien hoeveel mensen gaan re-routen naar die bepaalde carrier (en je kunt dus ook niet vooraf inschatten of die carrier overbeladen gaat worden), maar daarvoor kun je dus onder andere een ANS oplossing voor gebruiken (die dit kan detecteren en daarop gebaseerd aanpassingen kan maken).
Natuurlijk; het upgraden van de carriers zodat zij ieder 10 keer zo veel capaciteit beschikbaar hebben, is een betere oplossing. Ik zeg enkel dat het niet de enige oplossing is.
Overigens; hoe vaak komt het nu voor dat een carrier als Level3 (bijvoorbeeld) overbeladen wordt? Ik weet niet exact hoeveel capaciteit ze hebben, maar je kunt er toch wel van uit gaan dat zij een zeer ruime capaciteit hebben, die zij over hun eigen netwerk kunnen distributeren. Wellicht dat Level3 een verkeerd voorbeeld is, dat weet ik om eerlijk te zijn niet. Maar ik heb niet het idee dat de capaciteit van de carriers een heel groot probleem is, desnoods neem je een fiber naar Londen of Frankfurt en gooi je het daar over een X aantal carriers. Het probleem is m.i. meer dat de netwerken zelf (en dus niet de carriers) niet genoeg aan redundancy doen - zij kunnen zelf alternatieve routes verzorgen (desnoods via het buitenland).
De capaciteit van de carriers onderling zou de situatie wellicht makkelijker (en goedkoper) maken, maar ook zonder grotere capaciteit van de carriers onderling kan het probleem verholpen worden.
De discussie ging over dat een aantal "grote" partijen het verkeer niet konden door pushen richting transit omdat ook deze niet voldoende capaciteit hadden.
Dat was niet de discussie. De discussie is dat zij niet genoeg transit capaciteit afnemen, niet dat de beschikbaarheid er niet is. De beschikbaarheid is er, desnoods via het buitenland.
Dat is dus zo ongeveer mijn punt; dat is een van de mogelijkheden waar je je verkeer overheen zou kunnen sturen als alternatief. Het punt is dus juist dat dat vrijwel niet gedaan wordt.
Dus als die 200Gbit/s van AMS-IX naar Frankfurt was gestuurd had niemand een probleem gehad?
Ik kan mij een artikel herinneren over de enorme kosten van 100gigE. Volgens mij kan dat op korte termijn nooit een oplossing voor het probleem zijn.
Een ander punt dat ik nog niet opgebracht zie is dat 40/100Gbit behoorlijke consequenties heeft voor long-haul.
Nagenoeg alle trajecten die langer zijn dan 100KM moeten worden versterkt.
Bij het versterken is timing van groot belang. Je kan je voorstellen dat 100Gbit/s waves hele andere versterkers/regenerators nodig hebben dan 10GE waves.
Terrestrial lijnen kan je relatief makkelijk bij alle tussenstations ff een andere versterker op het lijntje prikken.
Submarine is het al erg moeilijk, deze units zijn vaak geintegreerd met de kabel.
Dus voor 100GE TAT moet er gewoon even een paar nieuwe kabeltjes gelegd worden.
En met een globale recessie voor de boeg zit dat er niet in de komende paar jaar..
Freakingme
28/10/08, 23:54
Ik kan mij een artikel herinneren over de enorme kosten van 100gigE. Volgens mij kan dat op korte termijn nooit een oplossing voor het probleem zijn.
Zijn die kosten dan de kosten zoals kilobit die schetst, of doel jij op iets anders?
Zijn die kosten dan de kosten zoals kilobit die schetst, of doel jij op iets anders?
Volgens mij het ontwikkelen van de ASIC's (de chips)
Vooral timing, en error rate zijn het moeilijkst, en dus meest duur, om goed te krijgen.
100Gbit is 100.000.000.000 bitjes per seconde door de ASIC heen halen
Simpel gezegd een 100Ghz CPU (om naar leken computer termen te vertalen ookal is het niet hetzelfde)
Ik wil me niet al te zeer mengen in de hoge vorm van 'google' discussies over hoe een bepaalde route moet lopen om toch een bepaalde vorm van uptime te garanderen. Maar waarom zo moeilijk denken? Waarom pakt men niet gewoon het probleem aan bij het begin, en zorgt men er niet gewoon voor dat een Datacenter doet waarvoor het benoemd is, het zijn van een 'Datacenter' en niet een 'Offlinecenter'.
Als men gewoon zorgt dat er 24/7 stroom is dan heb je geen backup routes nodig in princiepe ;),
Ik wil me niet al te zeer mengen in de hoge vorm van 'google' discussies over hoe een bepaalde route moet lopen om toch een bepaalde vorm van uptime te garanderen. Maar waarom zo moeilijk denken? Waarom pakt men niet gewoon het probleem aan bij het begin, en zorgt men er niet gewoon voor dat een Datacenter doet waarvoor het benoemd is, het zijn van een 'Datacenter' en niet een 'Offlinecenter'.
Als men gewoon zorgt dat er 24/7 stroom is dan heb je geen backup routes nodig in princiepe ;),
Haha.. goede..
En als we nou even heel veel briefjes van 1000 euro bij drukken is elke nederlander heel erg rijk, dat is namelijk zelfde "leken logica".
ps. mocht je dat serieus bedoeld hebben; beweer je dat de data in een datacenter er opeens niet meer was? Of ben je het met ons eens dat het juist om het transport gaat?
Tweede ps, mocht je de magische formule hebben voor ideaal transport, vertel het ook even aan Eurlings. Dataverkeer heeft namelijk heel erg veel overeenkomsten met wegverkeer (vooral wat ongelukken betreft))
Als er een mega ongeluk is op de A4 waarbij alle banen beide kanten op dicht zijn lopen de A12, A2 en A44 helemaal vast.
Het gaat toch ook echt niet alleen om stroom? Dit keer was het probleem een power outage.
Een volgende keer is het probleem dat graafwerkzaamheden op twee plekken rond science park alle fibers kapot trekken.
De keer erna een exploit die alle cisco routers offline trekt etc etc...
De kern van de hele discussie is m.i. dat grote verstoringen bij grote internetknoopunten niet vanzelfsprekend goed kunnen worden opgevangen.
Klopt, ik sluit me aan bij je logica dat het probleem telkens weer wat anders kan zijn, echter vind ik een power-outage niet kunnen.
Misschien is dit wederom een goede leer ;)
Klopt, ik sluit me aan bij je logica dat het probleem telkens weer wat anders kan zijn, echter vind ik een power-outage niet kunnen.
Misschien is dit wederom een goede leer ;)
Daarom gaf ik het voorbeeld van 1000 euro biljetten bijdrukken.
Zo simpel is het niet, stroom leveren is een zeer complexe materie.
Als er een magische formule was die 100% stroom zou garanderen zou iedereen dat gebruiken.
Iedereen is het wel eens dat de non redundant UPS van NIKHEF een bijzonder grote SPOF is, maar ookal wordt die opgelost ben je nog niet gevrijwaard van problemen.
Dat was niet de discussie. De discussie is dat zij niet genoeg transit capaciteit afnemen, niet dat de beschikbaarheid er niet is. De beschikbaarheid is er, desnoods via het buitenland.
Als dat de discussie is (was) dan zal ik je snel uit de brand helpen, want ik kan je verzekeren dat wij, Eweka, en alle andere partijen echt wel genoeg transit verkeer hebben om een uitval op te vangen (of onderhoud of whatever, waardoor 1 lokatie tijdelijk geen verkeer meer zal routeren). Dat is het probleem ook niet.
De alternatieven zoals die hier worden gegeven door sommigen (LINX/DECIX/BNIX) zijn vaak geen alternatieven bij een dergelijke uitval. Meestal gooi je al rechstreeks verkeer naar deze exchanges en niet via de AMSIX. Daarnaast zal verkeer alleen via deze exchanges gaan (bij uitval AMSIX) als de partijen van de AMSIX ook op deze Exchanges zitten (en zelfs dan ligt het eraan of verkeer via de exchanges zal lopen, of via je transit, want (zoals eerder genoemd) BGP zal in principe altijd best-path kiezen. Dat ligt echter aan de router/netwerk configuraties. Ik heb overigens nergens gezegd dat het niet kan.
Er word in deze discussie erg makkelijk gedacht over capaciteit en simpel-weg uitbreiden/meer inkopen. Helaas is het niet zo simpel als het om grote volumes gaat. Wij kunnen lokaal wel uitbreiden, alleen transitpartijen moeten hun complete back-bone uitbreiden.
Capaciteit is in principe de hele issue, alleen even simpelweg zeggen dat er meer moet worden ingekocht,bij meerdere partijen etc. etc. is simplistisch denken. Het ging bij deze storing om 500+ Gbps, als het al niet tegen de 1Tbps loopt. Simpelweg ook stellen dat transit/peering partijen 2 keer zoveel capaciteit moeten hebben als dat ze aan verkeer doen heeft ook geen zin. Bij een uitval van dergelijke omvang, vallen (soms) complete partijen weg. In plaats van dat partij B zijn verkeer van lokatie A naar lokatie B ziet gaan, krijgt deze er ook nog eens verkeer bij van partij A. Het is soms (zeker bij grote volumes) voor partijen moeilijk in te schatten wat er aan extra verkeer bij kan komen (lees niet).
Als dat de discussie is (was) dan zal ik je snel uit de brand helpen, want ik kan je verzekeren dat wij, Eweka, en alle andere partijen echt wel genoeg transit verkeer hebben om een uitval op te vangen (of onderhoud of whatever, waardoor 1 lokatie tijdelijk geen verkeer meer zal routeren). Dat is het probleem ook niet.
De alternatieven zoals die hier worden gegeven door sommigen (LINX/DECIX/BNIX) zijn vaak geen alternatieven bij een dergelijke uitval. Meestal gooi je al rechstreeks verkeer naar deze exchanges en niet via de AMSIX. Daarnaast zal verkeer alleen via deze exchanges gaan (bij uitval AMSIX) als de partijen van de AMSIX ook op deze Exchanges zitten (en zelfs dan ligt het eraan of verkeer via de exchanges zal lopen, of via je transit, want (zoals eerder genoemd) BGP zal in principe altijd best-path kiezen. Dat ligt echter aan de router/netwerk configuraties. Ik heb overigens nergens gezegd dat het niet kan.
Er word in deze discussie erg makkelijk gedacht over capaciteit en simpel-weg uitbreiden/meer inkopen. Helaas is het niet zo simpel als het om grote volumes gaat. Wij kunnen lokaal wel uitbreiden, alleen transitpartijen moeten hun complete back-bone uitbreiden.
Capaciteit is in principe de hele issue, alleen even simpelweg zeggen dat er meer moet worden ingekocht,bij meerdere partijen etc. etc. is simplistisch denken. Het ging bij deze storing om 500+ Gbps, als het al niet tegen de 1Tbps loopt. Simpelweg ook stellen dat transit/peering partijen 2 keer zoveel capaciteit moeten hebben als dat ze aan verkeer doen heeft ook geen zin. Bij een uitval van dergelijke omvang, vallen (soms) complete partijen weg. In plaats van dat partij B zijn verkeer van lokatie A naar lokatie B ziet gaan, krijgt deze er ook nog eens verkeer bij van partij A. Het is soms (zeker bij grote volumes) voor partijen moeilijk in te schatten wat er aan extra verkeer bij kan komen (lees niet).
Ik wil hier ook even op inspelen.
Merlijn heeft hier 100% gelijk in, Eweka routeerde inderdaad veel via DEC-IX en LINX, maar dit was maar 20% van usenet traffic ongeveer, de overige 80% was om bovengenoemde redenen weg.
Mijn punt was vooral dat andere services zoals CDN en Colo up bleven, omdat we dat om konden routeren over oa andere exchanges en Transit wat niet @ Nikhef of NL aangesloten was.
Merlijn en Paul,
Ik zeg helemaal niet dat als de AMS-IX uitvalt, dat je dan alles over buitenlandse exchanges kunt gooien. Ik zei dat je dan alles over transit kunt gooien (uiteraard niet naar de partijen die zelf onbereikbaar zijn, maar daar kun je niets aan doen).
Met "over het buitenland gooien", bedoelde ik niet uitsluitend de buitenlandse exchanges (hoewel je eventueel ook een beetje verkeer daar kwijt kan, maar natuurlijk niet allemaal). Stel dat de transit carriers in Nederland vol zitten, dan kan je ook nog gebruik maken van transit in het buitenland. Redelijk wat verkeer wat over de AMS-IX loopt, gaat ook naar het buitenland - het is niet alsof er alleen Nederlandse providers op de AMS-IX zijn aangesloten. Ik begrijp dat in het geval van Eweka het meeste verkeer binnen Nederland blijft, maar bij de meeste andere netwerken is er ook veel internationaal verkeer.
Tuurlijk, als het netwerk waar je verkeer naar toe stuurt problemen heeft, dan kun je hier weinig aan doen. Maar bij bijvoorbeeld Leaseweb was er zelf veel packetloss, ook naar de netwerken die wel via een alternatieve route beschikbaar waren. Het enige wat ik daaruit kan opmaken is dat de carriers waarover het verkeer gestuurd werd, vol zaten, en Leasweb kan dat weldegelijk voorkomen door het verkeer over meer verschillende carriers (met meer capaciteit) te sturen. Uiteraard heb je daar wel geavanceerde techniek (bijvoorbeeld ANS) voor nodig.
Nogmaals, ik wil niet op een bepaalde partij inzoomen, en het bovenstaande gaat zeker niet alleen over Leaseweb. Als je bijvoorbeeld Nedzone kijkt (welke geheel onbereikbaar was toen Nikhef plat lag), dan is dat natuurlijk nog een stuk kwalijker.
Zoals ik al zei, dat Leaseweb bijvoorbeeld Nedzone niet kon bereiken, is iets waar Leaseweb niets aan zou kunnen doen, omdat Nedzone uitsluitend via Nikhef bereikbaar was. Maar Leaseweb kan wel iets doen aan het feit dat er veel packetloss was naar partijen die wel buiten Nikhef om bereikbaar waren. Nogmaals; ik begrijp dat de transit partijen in Amsterdam niet zomaar 500Gbit even kunnen opvangen. Maar je moet wat dat betreft wat meer "out of the box" denken. Je kunt ook uitwijken naar transit buiten Amsterdam.
Als men gewoon zorgt dat er 24/7 stroom is dan heb je geen backup routes nodig in princiepe ;),
Het is gebleken dat je daar simpelweg niet van uit kunt gaan. Buiten dat, zonder die backup routes (bijvoorbeeld Nedzone), ben je volledig afhankelijk van een locatie. Dat moet je sowieso niet willen.
Buiten het feit dat je altijd alternatieve routes (met voldoende bandbreedte) beschikbaar zou moeten hebben, blijf ik erbij dat eigenlijk alle partijen een dikke UPS in hun rack voor hun routers zou moeten hangen. Dit heeft natuurlijk alleen zin als iedereen dit doet. Ik zie eigenlijk geen reden om dit niet te doen, zo veel kost een UPS niet (zeker als je het afzet tegen de prijs van een router).
Het is gebleken dat je daar simpelweg niet van uit kunt gaan. Buiten dat, zonder die backup routes (bijvoorbeeld Nedzone), ben je volledig afhankelijk van een locatie. Dat moet je sowieso niet willen.
Buiten het feit dat je altijd alternatieve routes (met voldoende bandbreedte) beschikbaar zou moeten hebben, blijf ik erbij dat eigenlijk alle partijen een dikke UPS in hun rack voor hun routers zou moeten hangen. Dit heeft natuurlijk alleen zin als iedereen dit doet. Ik zie eigenlijk geen reden om dit niet te doen, zo veel kost een UPS niet (zeker als je het afzet tegen de prijs van een router).Volgens mij komt het overal nog steeds voor dat er één feed faalt en dat men hun router op één feed heeft aangesloten.
Ik heb nog niks vernomen over het falen van beide feeds in de DC's.
AW-Hosting
29/10/08, 13:05
Het is gebleken dat je daar simpelweg niet van uit kunt gaan. Buiten dat, zonder die backup routes (bijvoorbeeld Nedzone), ben je volledig afhankelijk van een locatie. Dat moet je sowieso niet willen.
Waar haal jij deze informatie vandaan? Ik heb namelijk nog wat via de e-mail heen en weer gepraat met Nedzone, en er was wel degelijk een backup route.
Deze route liep via TeleGlobe die hoog en laag beweerde dat hun routes buiten Nikhef om liepen, maar dit bleek dus niet het geval te zijn. Hierdoor lag heel NedZone plat.
Ook komt er binnen 2 weken een duidelijke verbetering in de capaciteit, infrastructuur en redundantie van het netwerk. Alleen weet ik niet of ik al deze inside informatie mag delen dus dat laat ik over aan NedZone zelf.
Het is gebleken dat je daar simpelweg niet van uit kunt gaan. Buiten dat, zonder die backup routes (bijvoorbeeld Nedzone), ben je volledig afhankelijk van een locatie. Dat moet je sowieso niet willen.
Buiten het feit dat je altijd alternatieve routes (met voldoende bandbreedte) beschikbaar zou moeten hebben, blijf ik erbij dat eigenlijk alle partijen een dikke UPS in hun rack voor hun routers zou moeten hangen. Dit heeft natuurlijk alleen zin als iedereen dit doet. Ik zie eigenlijk geen reden om dit niet te doen, zo veel kost een UPS niet (zeker als je het afzet tegen de prijs van een router).
Hierbij sluit ik me aan, zelfs wij hebben hebben eigen ups'en.
Als ze de datacenter's zelf hun core switchen voorzien van eigen UPS'en zijn we al stukken verder.
Ik zeg helemaal niet dat als de AMS-IX uitvalt, dat je dan alles over buitenlandse exchanges kunt gooien. Ik zei dat je dan alles over transit kunt gooien (uiteraard niet naar de partijen die zelf onbereikbaar zijn, maar daar kun je niets aan doen).
Opzich is er zelf een betere manier: laat ams-ix wat animo creëren om de poorten over 2 locaties te spreiden van zowel access als content providers.
Opzich kost fiber tussen een aantal locaties ook niet zoveel meer in Amsterdam + je dient voor je backup geen extra transit commitments af te nemen (zolang iedereen op die manier werkt).
Ideaal zou zijn dat deze aparte locatie een andere exchange is zodat je ook software problemen op hun platform & dat van ams-ix omzeilt.
Volgens mij komt het overal nog steeds voor dat er één feed faalt en dat men hun router op één feed heeft aangesloten.
Ik heb nog niks vernomen over het falen van beide feeds in de DC's.
Dat is nog erger - heb je een dure router staan, zorg je niet voor goede power uplinks. Wij draaien dan geen eigen netwerk, maar als we dat wel gaan doen, komt er voor iedere router toch minimaal een UPS die de router een uur kan laten draaien.
Waar haal jij deze informatie vandaan? Ik heb namelijk nog wat via de e-mail heen en weer gepraat met Nedzone, en er was wel degelijk een backup route.
Deze route liep via TeleGlobe die hoog en laag beweerde dat hun routes buiten Nikhef om liepen, maar dit bleek dus niet het geval te zijn. Hierdoor lag heel NedZone plat.
Ik beschuldigde Nedzone ook nergens van, don't get me wrong. Ik zei enkel dat alle routes via Nikhef liepen. Als Teleglobe tegenover Nedzone gegarandeerd heeft dat hun routes buiten Nikhef om lopen, dan ligt de fout inderdaad niet bij Nedzone zelf (al blijven zij uiteraard wel eindverantwoordelijke tegenover hun klanten).
Opzich is er zelf een betere manier: laat ams-ix wat animo creëren om de poorten over 2 locaties te spreiden van zowel access als content providers.
Opzich kost fiber tussen een aantal locaties ook niet zoveel meer in Amsterdam + je dient voor je backup geen extra transit commitments af te nemen (zolang iedereen op die manier werkt).
Ideaal zou zijn dat deze aparte locatie een andere exchange is zodat je ook software problemen op hun platform & dat van ams-ix omzeilt.
AMS-IX biedt die mogelijkheid natuurlijk al. Wellicht dat het een goed idee zou zijn als AMS-IX hun klanten dit inderdaad duidelijker aanbeveelt, maar hun klanten kunnen dit al doen en zouden dat dus ook moeten doen. Tuurlijk, kost net wat meer, maar voor betrouwbaarheid betaal je nu eenmaal.
Echter, dit heeft alleen zin als ALLE partijen die bij de AMS-IX peeren, een uplink hebben op minimaal 2 locaties. Hetzelfde geldt voor bijvoorbeeld een aansluiting op de NL-IX; dit heeft alleen zin voor het peeren met partijen die daar peeren. Enerzijds kun je daar natuurlijk weinig aan doen als je zelf wel bereikbaar bent op meerdere locaties, maar anderzijds kun je dit toch voor zijn door toch voldoende transit beschikbaar te hebben om al het peering verkeer op te vangen. En nogmaals, die transit capaciteit is er, en ja, ook genoeg om de hele AMS-IX op te vangen mocht die helemaal plat liggen.
Nogmaals, ik zeg ook niet dat het goedkoop is om de mogelijkheid te hebben om alles over transit te kunnen gooien. Voor echte redundancy betaal je nu eenmaal. Bottomline is wel dat als je die investering niet maakt, dat je dan bij netwerkproblemen door uitval van een locatie enkel jezelf kan verwijten.
Als Teleglobe tegenover Nedzone gegarandeerd heeft dat hun routes buiten Nikhef om lopen, dan ligt de fout inderdaad niet bij Nedzone zelf (al blijven zij uiteraard wel eindverantwoordelijke tegenover hun klanten).
En zolang jij niet weet hoe of wat, waarom blijf jij dan maar speculeren en namen noemen?
En zolang jij niet weet hoe of wat, waarom blijf jij dan maar speculeren en namen noemen?
Ik speculeer helemaal niets, het feit is dat Nedzone onbereikbaar was omdat alles over de Nikhef liep, en Nikhef lag plat. Bij wie de schuld ligt, doet er in deze discussie niet toe.
Naar mijn idee is dit weer typisch zon gevalletje waarbij je niet moet gaan kijken wie zn schuld het is maar hoe we het kunnen voorkomen. Ik vind preventie veel belangrijker, dan wie schuldig is. Natuurlijk moet er wel over gepraat worden als het door nalatigheid of dergelijke komt maar dan nog...
dreamhost_nl
29/10/08, 19:19
Precies, zo meen ik me te herinneren dat ook de netwerken in Grafix te Alphen a/d Rijn "down" waren door de meest recente stroomstoring in Grafix te Capelle a/d IJssel (even ter voorbeeld). Daar kunnen we net zo'n discussie over starten... lijkt me daarom tijd voor een {xx} hier...
Precies, zo meen ik me te herinneren dat ook de netwerken in Grafix te Alphen a/d Rijn "down" waren door de meest recente stroomstoring in Grafix te Capelle a/d IJssel (even ter voorbeeld). Daar kunnen we net zo'n discussie over starten... lijkt me daarom tijd voor een {xx} hier...
Dit is weer precies z'n "De klok wel hebben horen luiden, maar niet weten waar de klepel hangt."
Het heeft totaal niets met BGP te maken, maar met de gateways met klanten welke net waren verhuisd van Capelle naar Alphen. De Gateways stonden dus nog in Capelle. Zowel GrafiX, Caveo en het Technotop netwerk draaien op het moment volledig onafhankelijk _per locatie_.
Iedereen in dit topic heeft in zekere mate gelijk, enkel waarvan een aantal op dit moment niet haalbare oplossingen. ANS is inderdaad een mooi stukje software, maar op het "grote" internet zie ik niet zo snel netwerken hier gebruik van maken.
Een netwerk moet op minimaal 2 locaties zijn prefixes announcen naar aparte transitleveranciers. Enkel moet dit van twee kanten komen, dus zowel van de access als contentprovider. We hebben er immers niets aan als een grote content leverancier wel redundant is maar alle accessproviders op hun gat liggen door uitval op het sciencepark.. maar laten we eerlijk zijn.
Het internet is ooit opgezet als "onfaalbaar" geheel. Door middel van vele verspreide routers en verbindingen zou het eigenlijk onmogelijk moeten zijn om het te laten falen. Het geheel zou een reguliere graaf moeten zijn, waarbij iedere node ongeveer evenveel verbindingen heeft. In de praktijk zijn er echter een paar grote knooppunten met heel veel, veel minder verbonden, takken naar de rest. Dit is in meerdere onderzoeken aangetoond (referenties kan ik opzoeken, maar kan het merendeel wsl toch niet bij).
Het probleem hiermee is dat de redundantie weg is. Het omvallen van enkele grote knooppunten helpt de connectiviteit op het internet gewoon om de zeep. Het is compleet irrelevant of het hierbij om transit of peering gaat, gezien alle grote transit toko's uiteindelijk ook dezelfde knooppunten (NIKHEF, Sara etc.) gebruiken. Natuurlijk kan 1 partij het oplossen door z'n uitgaande verkeer zoveel mogelijk te verdelen en meer traffic engineering trucjes toe te passen, maar als iedereen dat doet blijft het probleem nog altijd even groot en is het dus geen oplossing.
Wat de oplossing dan wel is? Niet meer van die enorme knooppunten als in Amsterdam bouwen, maar meer individuele connecties. Probleem daarmee is echter vaak de kosten :-)
Misschien dat jullie het niet meer weten, maar toen die aardbeving twee jaar geleden was in Azie, was China gedurende een half jaar minder goed bereikbaar. Dat geeft al ongeveer aan dat je altijd een zwakke schakel hebt. Hoeveel lijntjes heb je nodig....
Misschien dat jullie het niet meer weten, maar toen die aardbeving twee jaar geleden was in Azie, was China gedurende een half jaar minder goed bereikbaar. Dat geeft al ongeveer aan dat je altijd een zwakke schakel hebt. Hoeveel lijntjes heb je nodig....
Inderdaad.
En wie heeft er zin om voor al die lijntjes te betalen?
200% extra capaciteit (2N+2) neerleggen, alleen om de meest extreme vormen van verstoringen op te kunnen vangen krijgt geen enkele van de grote jongens losgepeuterd bij zijn CFO.
200% extra capaciteit (2N+2) neerleggen, alleen om de meest extreme vormen van verstoringen op te kunnen vangen krijgt geen enkele van de grote jongens losgepeuterd bij zijn CFO.
Het is geen 200% extra capaciteit maar 100% extra capaciteit, maar dat ter zijde.
Je hebt verder geheel gelijk, en dat is inderdaad het probleem - partijen willen niet investeren om dat extra stukje betrouwbaarheid te implementeren. Allemaal leuk en aardig, maar dan moeten die zelfde partijen ook geen 99.9% (of nog hoger) aan netwerk uptime garanderen, want ze kunnen feitelijk helemaal geen uptime garanderen zo lang er geen volledige redunantie is (tenzij je dikke packetloss als uptime rekent).
Enkel moet dit van twee kanten komen, dus zowel van de access als contentprovider. We hebben er immers niets aan als een grote content leverancier wel redundant is maar alle accessproviders op hun gat liggen door uitval op het sciencepark..
Ik heb dit argument al meerdere malen voorbij horen komen, en dit is typisch zo'n argument waar men zich makkelijk achter kan verschuilen. De pot verwijt de ketel zeg maar. Wellicht kun je niet alle partijen via een omweg bereiken, maar er zijn er genoeg die je in ieder geval wel kunt bereiken, en buiten dat ben je dus ook zelf voor anderen ook via een omweg bereikbaar. Omdat sommige anderen niet geheel redundant zijn, is geen reden om dat zelf ook maar niet te zijn.
Het argument over de kosten is een stuk meer steekhoudend - maar de partijen die hiervoor kiezen moeten zich niet achter andere argumenten verschuilen.
Het internet is ooit opgezet als "onfaalbaar" geheel. Door middel van vele verspreide routers en verbindingen zou het eigenlijk onmogelijk moeten zijn om het te laten falen.
Het zou ook niet gefaald hebben als niet in heel NIKHEF in een keer al het licht uitging. Dat is wellicht een vierde discussie of zelfs een eigen topic waard, maar waarom valt alles in een heel DC uit? Ik heb op de MTS (elektro) lang moeten rekenen aan selectiviteit om er voor te zorgen dat een lokale overbelasting niet tot een globale uitval zou leiden.
Ik heb niet gehoord wat er precies gebeurd is, maar in mijn bescheiding mening mag het niet zo zijn dat een storing, waar dan ook binnen de muren van NIKHEF, tot een volledig uitvallen van NIKHEF zou mogen leiden.
Als het niet helemaal duidelijk is hoe ik dat bedoel, neem dan even je eigen spul als voorbeeld. Als ik een metalen staaf door je mailserver heen ram gebeurt er verdomd weinig. De zekering in de voeding van de mailserver piept er uit, en de acht tot vijfendertig machines in hetzelfde rack draaien gewoon door. Als ik een stapje hoger op de vandalisme-ladder stap en een metalen staaf door je hele kast heen timmer valt niet alles van je colocatie-provider uit. Enkel de zekeringsautomaat van jouw rack piept eruit en de andere racks in dezelfde ruimte draaien zonder morren gewoon door. Sla ik een bijl door de feed van je colo-provider, dan zouden gebruikers van andere ruimtes in hetzelfde pand dat niet eens mogen merken. 1 zaal/suite in het donker, de rest snort gewoon door.
Maandagavond had precies dat moeten gebeuren in NIKHEF. Er had een machine, een rack of een ruimte uit moeten vallen, maar niet meer dan dat. In plaats daarvan zat het hele gebouw zonder stroom.
Het gevolg van daarvan is dat partijen die dachten dat ze hun redundancy op orde hebben met twee racks, alle links dubbel en voeding uit A/B-feeds maandagavond het nakijken hadden. Iets wat in het allerergste geval tot uitval van 1/6de van NIKHEF zou hebben mogen leiden (1 van drie fases van twee gescheiden feeds) heeft tot een totaal falen geleid. Hoe heeft dat zo kunnen gebeuren?
(als je denkt dat dit een eigen topic waard is: zeg het gerust..)
Apoc,
Het probleem is dat jou visie een 'perfect world visie' is.
Het probleem daarmee is dat er dusdanig veel geinvesteerd moet worden dat je je zelf compleet uit de markt prijst om nog maar rendabel te blijven.
Voorbeeld, wij zouden ~ 200Gbit aan standby verbindingen moeten hebben naar X transit providers zonder daar een mbit over te doen.
Al die transit providers willen commitments.
Dat is gewoonweg onbetaalbaar en in de praktijk dus helemaal niet interresant.
Verder klopt je redenatie wat betreft 99.9% uptime aanbieden niet. Mensen moeten voor dit soort problemen geen 100% uptime aanbieden. 99.99% kan prima, reken maar uit hoeveel uur uitval 0.01% is dat is op jaarbasis, de storing op Nikhef komt daar niet aan in elk geval..
Jongens ik zie in dit topic een paar vergelijkingen waar je akelig van word zoals een ernstig ongeluk op de snelweg? Vallen er doden bij een storing van afgelopen week? De keuze tussen een ongeluk met tien doden of weer twee uur storing is makkelijk gemaakt. Diegene die liever dat ongeluk zien gebeuren moeten eens heel goed gaan nadenken wie ze zijn en waar ze mee bezig zijn.
Het gaat volgens mij allemaal om calculaties en van een uurtje meer of minder internet zal nooit iemand aan gaan sterven (ik niet althans). Als dit verschil of niets of enkele miljarden euro's kost is de beslissing snel gemaakt natuurlijk. Zeker als de eventuele schadeclaims bij een storing ver onder het te investeren bedrag liggen. Allemaal puur rekenwerk. Natuurlijk word dit nooit hardop gezegd maar zo word er toch echt wel overal naar gekeken en gehandeld (zie voorbeeld Paul hierboven). Helaas kan je bijna wel zeggen.
Iets anders, recessie of niet nieuwe kabels zullen er gelegd worden. Google bijvoorbeeld is ook bezig (http://webwereld.nl/articles/50055/gbps) en ik denk dat dit zeker niet het einde is en er meer kabels zullen volgen. Je begrijpt dat het bezitten of in ieder geval participeren in dit soort projecten goud opleveren. Het kost een hoop maar dat krijg je in veelvoud terug in de vorm van geld en macht.
Apoc,
Het probleem is dat jou visie een 'perfect world visie' is.
Het probleem daarmee is dat er dusdanig veel geinvesteerd moet worden dat je je zelf compleet uit de markt prijst om nog maar rendabel te blijven.
Voorbeeld, wij zouden ~ 200Gbit aan standby verbindingen moeten hebben naar X transit providers zonder daar een mbit over te doen.
Al die transit providers willen commitments.
Dat is gewoonweg onbetaalbaar en in de praktijk dus helemaal niet interresant.
Ik moet erkennen dat het in het voorbeeld van Eweka inderdaad minder interessant is, maar dit heeft naar mijn mening meer met jullie doelgroep te maken. Vat dit overigens niet verkeerd op hoor - het is absoluut niet als afkraken of wat dan ook bedoeld. Tegenover usenet gebruikers valt het nog wel te verkopen als door een dergelijke storing er e.e.a. slechter te bereiken is - en daarnaast bieden jullie volgens mij geen SLA en het past denk ik ook niet binnen de prijsstelling. Maar stel dat je een netwerk aanbieder voor de zakelijke markt bent (access of hosting - dat doet er niet zo veel toe), en een 99.9% of 99.99% uptime op maandbasis garandeerd (en die zijn er genoeg), dan is dat een heel ander ander verhaal.
Verder klopt je redenatie wat betreft 99.9% uptime aanbieden niet. Mensen moeten voor dit soort problemen geen 100% uptime aanbieden. 99.99% kan prima, reken maar uit hoeveel uur uitval 0.01% is dat is op jaarbasis, de storing op Nikhef komt daar niet aan in elk geval..
0.01% uitval op jaarbasis is 0.876 uur, ofwel 52.56 minuten. Daar komt deze storing weldegelijk aan (de storing was na 2 uur verholpen - en ook dan zijn nog niet alle routers gelijk weer online). Er zijn genoeg netwerken die 99.9% uptime per maand garanderen, en dat komt neer op maximaal 43.2 minuten downtime per maand. Tenzij het netwerk AL het verkeer buiten Nikhef om kan routen (bijvoorbeeld over transit), kan deze garantie simpelweg niet gemaakt worden.
Swiftway-UK
30/10/08, 11:49
Voorbeeld:
POP - A Amsterdam
POP - B Parijs
Beide POP geef je eigen Internet Transit verbindingen en connecties lokaal op de internet exchanges.
Redundante (fiber) connectie tussen de twee POPs
FCP op beide locaties
http://www.internap.com/product/technology/fcp/page1537.html
Door dit systeem te hanteren staat Internap in de USA bekend als een van de meest betrouwbare partijen, zij hebben in (bijna) elke stad een POP met eigen transits en verbinden deze POPs daarbij ook met een eigen backbone.
Voorbeeld:
POP - A Amsterdam
POP - B Parijs
Beide POP geef je eigen Internet Transit verbindingen en connecties lokaal op de internet exchanges.
Redundante (fiber) connectie tussen de twee POPs
FCP op beide locaties
http://www.internap.com/product/technology/fcp/page1537.html
Door dit systeem te hanteren staat Internap in de USA bekend als een van de meest betrouwbare partijen, zij hebben in (bijna) elke stad een POP met eigen transits en verbinden deze POPs daarbij ook met een eigen backbone.
Het punt is dat je in Parijs niet zo veel over peering kan gooien als op de AMS-IX, je kan natuurlijk enkel zaken over peering routen naar partijen die op de betreffende exchange aanwezig zijn.
Als je normaliter 70% van je verkeer over de AMS-IX gooit, kan je dat verkeer natuurlijk niet allemaal over de exchange in Parijs gooien als de AMS-IX plat gaat (hetgene wat niet over andere exchanges kan, zal simpelweg over transit moeten). Je hebt dus hoe dan ook hogere kosten als je al je verkeer over een alternatieve route wilt KUNNEN gooien als de AMS-IX plat gaat, en het is afhankelijk van je doelgroep en prijsstelling of je dat al dan niet kunt verantwoorden.
Er zijn dus feitelijk twee mogelijkheden:
1. Als je (bijvoorbeeld) een 99.9% uptime SLA op maandbasis wilt aanbieden, moet je ervoor zorgen dat al het verkeer over een alternatieve locatie gegooid kan worden, mocht elke willekeurige locatie plat gaan. Ja, hier zijn aanzienlijke kosten aan verbonden.
2. Wil je die extra investering niet maken, dan kun je simpelweg niet zo'n hoge SLA aanbieden
Het punt is dat er partijen zijn die zowel een hoge SLA aanbieden, en tegelijkertijd niet al hun verkeer over alternatieve routes kunnen gooien. En dat kan simpelweg niet.
Swiftway-UK
30/10/08, 12:26
Het punt is dat je in Parijs niet zo veel over peering kan gooien als op de AMS-IX, je kan natuurlijk enkel zaken over peering routen naar partijen die op de betreffende exchange aanwezig zijn.
In parijs zijn er tenminste vier grote peering exchanges waarvan twee gratis zijn
PANAP: http://www.panap.fr/
FREEIX: http://www.freeix.net/
PARIX: http://www.parix.net/
SFINX: http://www.renater.fr/spip.php?rubrique15&lang=en
Je kunt er redelijk wat verkeer kwijt. Voor de rest van je verkeer zul je inderdaad meer transit capaciteit in Parijs moeten inkopen dan in Amsterdam.
0.01% uitval op jaarbasis is 0.876 uur, ofwel 52.56 minuten
....
Er zijn genoeg netwerken die 99.9% uptime per maand garanderen, en dat komt neer op maximaal 43.2 minuten downtime per maand.
Hoeveel maanden heeft een jaar Apoc :)?
EDIT, 0.01% van 1 maand is 4-5 minuten (afhankelijk van aantal dagen).
En nog steeds doen veel mensen hier alsof het probleem met het inkopen van veel transit direct is opgelost. Dan ga je er echter vanuit dat die transit toko's allemaal blijven werken, wat gewoon een utopie is. Bij grootschalige uitval (gooi een bom op Amsterdam ofzo) hebben alle transit toko's problemen. Ook al zit jij dan in Londen met 3x de capaciteit die je moet hebben, dan nog kun je je traffic niet kwijt...
[edit]
En je kan natuurlijk iedere SLA aanbieden die je wil. Het hele punt van een SLA is dat je, wanneer je je SLA niet haalt, de klant moet compenseren. Wat dat betreft is het niet halen van je SLA door dit soort geintjes gewoon ingecalculeerd risico. Dat er hier op WHT nou veel aanbieders 99,9% roepen zonder dat er enige consequenties zijn wanneer dat niet gehaald wordt is meer het probleem van de klanten die zo stom zijn om daarmee in zee te gaan.
Maar het is ook wat overdreven door te stellen dat het internet in Nederland zo sterk afhankelijk is van Nikhef.
Natuurlijk is het niet extreem afhankelijk van NIKHEF. De grootste problemen kwamen nu doordat niet iedereen de AMS-IX aansluiting redundant heeft over meerdere locaties. Echter is het uitvallen van het AMS-IX platform als geheel ook nog altijd een reeel scenario, en daar is het Nederlandse internetverkeer wel enorm afhankelijk van ('voordeel' is wel dat je dan waarschijnlijk ook alle access providers mist ;) )
Hoeveel maanden heeft een jaar Apoc :)?
EDIT, 0.01% van 1 maand is 4-5 minuten (afhankelijk van aantal dagen).
Als je dan bijdehand gaat doen, tel dan zelf eerst eens even goed.
Ik zei "0.01% uitval op jaarbasis is 0.876 uur, ofwel 52.56 minuten", en dat klopt weldegelijk:
24 uur x 365 dagen = 8760 uur in een jaar
1% daarvan (delen door 100) = 87.60 uur
0.1% = 8.76 uur
0.01% = 0.876 uur
0.876 uur x 60 minuten = 52.56 minuten
En nog steeds doen veel mensen hier alsof het probleem met het inkopen van veel transit direct is opgelost. Dan ga je er echter vanuit dat die transit toko's allemaal blijven werken, wat gewoon een utopie is. Bij grootschalige uitval (gooi een bom op Amsterdam ofzo) hebben alle transit toko's problemen. Ook al zit jij dan in Londen met 3x de capaciteit die je moet hebben, dan nog kun je je traffic niet kwijt...
Eh, ik volg je niet? Ten eerste gaat het niet om een bom op heel Amsterdam, dat is overmacht. Het gaat om 1 locatie, in dit geval Nikhef. Als jij een fiber naar Londen hebt liggen en je gooit daar alles over transit, waarom zou dat niet werken?
En je kan natuurlijk iedere SLA aanbieden die je wil. Het hele punt van een SLA is dat je, wanneer je je SLA niet haalt, de klant moet compenseren. Wat dat betreft is het niet halen van je SLA door dit soort geintjes gewoon ingecalculeerd risico. Dat er hier op WHT nou veel aanbieders 99,9% roepen zonder dat er enige consequenties zijn wanneer dat niet gehaald wordt is meer het probleem van de klanten die zo stom zijn om daarmee in zee te gaan.
Die denkwijze vind ik onzin. Als jij 99.9% garandeert, dan moet je daar ook van staan. Je moet niet van concequenties en compensatie uitgaan, je moet alles doen om die garantie te halen. Als jij in de eerste plaats al de infrastructuur niet hebt om bij uitval van 1 van je leveranciers je garanties niet meer te kunnen naleven, dan moet je die garantie in de eerste plaats niet maken.
Tuurlijk, het feit dat veel providers nauwelijks compensatie bieden als ze hun SLA niet halen, dat is ook een probleem, dat ben ik met je eens (echter - de klant gaat daarmee akkoord - staat in het contract of de algemene voorwaarden). Ik vind het feit dat er garanties geboden worden die de provider eigenlijk niet kan bieden, veel kwalijker.
Als je dan bijdehand gaat doen, tel dan zelf eerst eens even goed.
Ik zei "0.01% uitval op jaarbasis is 0.876 uur, ofwel 52.56 minuten", en dat klopt weldegelijk:
24 uur x 365 dagen = 8760 uur in een jaar
1% daarvan (delen door 100) = 87.60 uur
0.1% = 8.76 uur
0.01% = 0.876 uur
0.876 uur x 60 minuten = 52.56 minuten
Tja, als jij bijdehand gaat doen, hoeveel minuten is dat per maand dan, 43.20???
52.56/12=4.355.
Eh, ik volg je niet? Ten eerste gaat het niet om een bom op heel Amsterdam, dat is overmacht. Het gaat om 1 locatie, in dit geval Nikhef. Als jij een fiber naar Londen hebt liggen en je gooit daar alles over transit, waarom zou dat niet werken?
Maar die ene locatie kan ook eens wat meer worden (bv. de hele AMS-IX). Dat het nu toevallig alleen NIKHEF is...
Je kan wel een mooie fiber naar Londen hebben liggen, maar als jouw transit toko vervolgens zijn kabeltjes uit Londen grotendeels weer in NIKHEF uit laat komen (en die zijn er zat), dan zal die toch echt problemen hebben met afwerking van het verkeer naar Nederland en verder. Zeker wanneer alle grote partijen proberen bij hem verkeer te dumpen. De links bij de gemiddelde transit partij zijn namelijk gewoon berekend op basis van hoe vol ze zitten en niet op basis van hoeveel verkeer klanten in theorie zouden kunnen doen.
Die denkwijze vind ik onzin. Als jij 99.9% garandeert, dan moet je daar ook van staan. Je moet niet van concequenties en compensatie uitgaan, je moet alles doen om die garantie te halen. Als jij in de eerste plaats al de infrastructuur niet hebt om bij uitval van 1 van je leveranciers je garanties niet meer te kunnen naleven, dan moet je die garantie in de eerste plaats niet maken.
Ach, uiteindelijk staan je servers ook in 1 DC, als daar de stroom uitvalt is het ook over en uit. 1 extra DC waar je van afhankelijk bent maakt voor de kansen dus verdomd weinig uit, en ik denk dat het prima te onderbouwen is dat je 99.9% denkt te halen (lies, damned lies and statistics enzo). Ik betwijfel dus of je perse onder de 99.9% zou komen wanneer je netwerk toevallig van 1 DC afhankelijk is.
Tja, als jij bijdehand gaat doen, hoeveel minuten is dat per maand dan, 43.20???
52.56/12=4.355.
Ik wil niet bijdehand doen, maar gewoon een makkelijkere berekening.
365 * 24 = 8760
8760 uren = 525600 minuten
525600 minuten per jaar = 43800 per maand
43800 / 10000 = 0.01% aka 4.38 :huh:
Offtopic:
Wanneer je je bericht edit en op Meer opties klikt krijg je:
Your submission could not be processed because a security token was missing or mismatched.
If this occurred unexpectedly, please inform the administrator and describe the action you performed before you received this error.
:huh: x 2
Ik wil niet bijdehand doen, maar gewoon een makkelijkere berekening.
365 * 24 = 8760
8760 uren = 525600 minuten
525600 minuten per jaar = 43800 per maand
43800 / 10000 = 0.01% aka 4.38 :huh:
Offtopic:
Wanneer je je bericht edit en op Meer opties klikt krijg je:
Your submission could not be processed because a security token was missing or mismatched.
If this occurred unexpectedly, please inform the administrator and describe the action you performed before you received this error.
:huh: x 2
Denk dat je iets verder terug moet lezen :).
Apoc zegt
0.01% van een jaar = 52.56 minuten
0.01% van een maand is 43.20 minuten
Als je daar op reageerd krijg je een vrij arrogante reactie terug, zoals ik in mijn eerste reactie daarop al zei, het is ongeveer 4 tot 5 minuten per maand, afhankelijk van het aantal dagen (wat dus niet elke maand hetzelfde is).
:W:
Denk dat je iets verder terug moet lezen :).
Ik had het wel gelezen, maar ik quote gewoon het onderste bericht. Ik snap waar je naar toe wilt. ;)
Als iemand daar echt over gaat zeuren (die paar seconden).... o.O
Ik zou gewoon zeggen een 5 minuten per maand.
Tja, als jij bijdehand gaat doen, hoeveel minuten is dat per maand dan, 43.20???
52.56/12=4.355.
Wat praat je nou voor onzin man. Nogmaals, ik zei "0.01% uitval op jaarbasis is 0.876 uur, ofwel 52.56 minuten". Of je nou hoog of laag springt, dat klopt gewoon. Ik heb het helemaal niet over "per maand" gehad toen het om 99.99% uptime ging. Als een provider 99.99% uptime op jaarbasis garandeert, doet het er helemaal niet toe wat de uptime in een willekeurige maand was, het gaat om het jaar als geheel.
Dit was in reactie op Paulewk, hij zei: "reken maar uit hoeveel uur uitval 0.01% is dat is op jaarbasis, de storing op Nikhef komt daar niet aan in elk geval.."
Ik maakte daarop de berekening, om aan te tonen dat de storing van Nikhef weldegelijk die 0.01% op jaarbasis overschreidt.
Denk dat je iets verder terug moet lezen .
Apoc zegt
0.01% van een jaar = 52.56 minuten
0.01% van een maand is 43.20 minuten
Nee Peter, je moet eens leren lezen. Ik zei:
"0.01% uitval op jaarbasis is 0.876 uur, ofwel 52.56 minuten"
"Er zijn genoeg netwerken die 99.9% uptime per maand garanderen, en dat komt neer op maximaal 43.2 minuten downtime per maand"
In het eerste geval gaat het dus om 0.01% van een jaar
In het tweede geval gaat het dus om 0.1% van een maand (LEZEN: 99.9%)
:W:
->|
MediaServe
31/10/08, 12:15
Het is dan inderdaad van belang of een aanbieder het op jaarbasis of maandelijkse basis garandeert. Een garantie op jaarlijkse basis zou ik persoonlijk nooit mee akkoord gaan, dat geeft veel te veel ruimte voor een lange storing en je kunt pas aan het einde van het jaar een claim indienen.
Trouwens hebben we 366 dagen dit jaar, dus geen enkele berekening was correct.
:smartass:
Advice concerning NIKHEF [2008-11-07]
NIKHEF currently does not meet the technical and organisational standards we consider necessary to support the AMS-IX business.
We have notified NIKHEF of this, and have mutually agreed that an external party will define a basic set of standards necessary to professionally support our business.
NIKHEF agrees with us on this approach and promises to work on reaching those standards.
Until then, we consider NIKHEF as an unsuitable site for newcomers to connect their network to the AMS-IX equipment.
We therefore strongly advise new networks to investigate alternative AMS-IX sites.
Advice concerning SARA [2008-11-07]
SARA currently does not meet the technical and organisational standards we consider necessary to support the AMS-IX business.
We have notified SARA of this, and have mutually agreed that an external party will define a basic set of standards necessary to professionally support our business.
SARA agrees with us on this approach and promises to work on reaching those standards.
Until then, we consider SARA as an unsuitable site for newcomers to connect their network to the AMS-IX equipment.
We therefore strongly advise new networks to investigate alternative AMS-IX sites.
5 tekens.
Een conclussie die je deels al kon trekken natuurlijk. Wel goed dat dit nu onderzocht is en naar buiten gebracht wordt. Het is jammer dat eerst het kwaad moet geschieden voordat er uberhaupt acties worden ondernomen lijkt wel.
Ben benieuwd of het nog verdere "directe" gevolgen heeft.
Het is jammer dat eerst het kwaad moet geschieden voordat er uberhaupt acties worden ondernomen lijkt wel.
Ik vind niet dat je dat AMS-IX kunt kwalijk nemen. Als je naar de prijzen van NIKHEF en SARA kijkt, i.c.m. de SLA's die ze hoogstwaarschijnlijk zullen hebben gegeven, zou je toch moeten kunnen verwachten dat dit niet gebeurt. Met de prijzen die in deze locaties betaalt zou je toch minimaal 100% uptime op de stroom moeten kunnen verwachten.
Ik moet tegelijkertijd wel zeggen dat ik het raar vind dat heel veel partijen geen UPS (in het rack) voor hun routers hangen. Ik weet niet of AMS-IX dit zelf wel doet, maar naar mijn mening zou iedereen sowieso een dedicated UPS voor hun router moeten hebben, ongeacht de SLA's die ze met Nikhef en SARA (of welk datacentrum dan ook) hebben.
a) het is nutteloos als de rest van je netwerkpad niet voorzien is van noodstroom
b) het is een enorme verspilling van energie aangezien al die kleine UPS'en lang niet 100% stroom efficiënt zijn.
c) er zijn andere manieren om niet afhankelijk te zijn van een UPS, waarom niet een feed direct op het stroomnet en eentje via de UPS?
a) het is nutteloos als de rest van je netwerkpad niet voorzien is van noodstroom
b) het is een enorme verspilling van energie aangezien al die kleine UPS'en lang niet 100% stroom efficiënt zijn.
c) er zijn andere manieren om niet afhankelijk te zijn van een UPS, waarom niet een feed direct op het stroomnet en eentje via de UPS?
d) Je moet per feed een UPS hebben.
e) Zo'n UPS is soms niet toegestaan omdat niet elk DC die dingen qua brandveiligheid vertrouwd.
a) het is nutteloos als de rest van je netwerkpad niet voorzien is van noodstroom
b) het is een enorme verspilling van energie aangezien al die kleine UPS'en lang niet 100% stroom efficiënt zijn.
c) er zijn andere manieren om niet afhankelijk te zijn van een UPS, waarom niet een feed direct op het stroomnet en eentje via de UPS?
a. Je kunt in ieder geval zorgen dat al je eigen routers dit hebben, of de partijen waar je mee peert dit goede voorbeeld volgen is natuurlijk niet aan jou. Maar omdat sommige andere partijen het niet zullen doen, is echt een loos excuus.
b. Mwa, de nieuwste generatie UPS's hebben een hoog rendement hoor. En tuurlijk zal het altijd meer stroom trekken, maar voor routers lijkt me dat geen zinnig argument om het niet te gebruiken. Stel dat al jouw routers bij elkaar 20 ampere slurpen (en daar kun je toch wel erg grote routers mee draaien), dan zullen ze met een UPS wellicht ergens tussen de 22-25 ampere slurpen (afhankelijk van het rendement). Voor die 2-5 amp extra om je netwerk betrouwbaarder te maken, zou ik het niet laten.
c. Kan, maar als de netspanning uitvalt en de UPS van het datacentrum werkt niet (zoals in de afgelopen maanden bij diverse datacentra het geval was), dan zit je nog steeds met hetzelfde probleem. Ik zou dan toch het heft in eigen handen nemen en zelf een UPS ophangen in het rack.
d) Je moet per feed een UPS hebben.
e) Zo'n UPS is soms niet toegestaan omdat niet elk DC die dingen qua brandveiligheid vertrouwd.
d. Hoeft niet per se. Je kan je A-feed via een UPS aansluiten, je B-feed direct. Als je A-feed uitvalt, vangt de UPS dat een tijdje op en draait je B-feed sowieso gewoon door. Als je B-feed uitvalt gaat de A-feed gewoon door, en als beide feeds uitvallen heb je nog stroom van de UPS op de A-feed.
e. Met een gecertificeerde UPS (bijvoorbeeld van APC) heb ik dat nog nooit gehoord
a) het is nutteloos als de rest van je netwerkpad niet voorzien is van noodstroom
b) het is een enorme verspilling van energie aangezien al die kleine UPS'en lang niet 100% stroom efficiënt zijn.
c) er zijn andere manieren om niet afhankelijk te zijn van een UPS, waarom niet een feed direct op het stroomnet en eentje via de UPS?
a. Je kunt in ieder geval zorgen dat al je eigen routers dit hebben, of de partijen waar je mee peert dit goede voorbeeld volgen is natuurlijk niet aan jou. Maar omdat sommige andere partijen het niet zullen doen, is echt een loos excuus.
b. Mwa, de nieuwste generatie UPS's hebben een hoog rendement hoor. En tuurlijk zal het altijd meer stroom trekken, maar voor routers lijkt me dat geen zinnig argument om het niet te gebruiken. Stel dat al jouw routers bij elkaar 20 ampere slurpen (en daar kun je toch wel grote routers mee draaien), dan zullen ze met een UPS wellicht ergens tussen de 22-25 ampere slurpen (afhankelijk van het rendement). Voor die 2-5 amp extra om je netwerk betrouwbaarder te maken, zou ik het niet laten.
c. Kan, maar als de netspanning uitvalt en de UPS van het datacentrum werkt niet (zoals in de afgelopen maanden bij diverse datacentra het geval was), dan zit je nog steeds met hetzelfde probleem. Ik zou dan toch het heft in eigen handen nemen en zelf een UPS ophangen in het rack.
d) Je moet per feed een UPS hebben.
e) Zo'n UPS is soms niet toegestaan omdat niet elk DC die dingen qua brandveiligheid vertrouwd.
d. Hoeft niet per se. Je kan je A-feed via een UPS aansluiten, je B-feed direct. Als je A-feed uitvalt, vangt de UPS dat een tijdje op en draait je B-feed sowieso gewoon door. Als je B-feed uitvalt gaat de A-feed gewoon door, en als beide feeds uitvallen heb je nog stroom van de UPS op de A-feed.
e. Met een gecertificeerde UPS (bijvoorbeeld van APC) heb ik dat nog nooit gehoord. En naar het beste van mijn weten is het in Nikhef ook gewoon toegestaan.
Het is toch te gestoord voor woorden dat je in een DC betaalt voor een UPS en fatsoenlijke stroomvoorziening, en dat dan iedereen maar zijn eigen UPS op zou moeten gaan hangen? Dan kunnen we net zogoed de hele UPS van het DC maar weglaten. Als je de stroomvoorziening in een DC niet kan vertrouwen dan zou ik eerder op zoek gaan naar een ander DC dan een UPS ophangen.
Ja hoor Mike jij weet een betere datacenter waar alle carriers staan ?
grootste probleem is de meeste carriers in Nederland staan op science park
Dat ze vaak problemen hebben zullen ze vast wel iets aan doen.
je moet ook nagaan wat er draait is misschien 10 of zelfs 20 jaar terug aangelegd.
/edit\ zie net dat 3 jaar geleden bij NIKHEF
Een en andere door een installatiebedrijf is vervangen in 2005
dan moet je eigenlijk de schuld geven aan de installatiebedrijf die het iet goed heeft gedaan
/edit\
Kan je ook wel nagaan dat bijvoorbeeld 16 amp per rack daar gewoon niet haalbaar is.
de infrastructuur moet gewoon drastisch worden vernieuwd.
Maarja SARA NIKHEF etc die daar zitten zijn geen echte coloboeren.
oorspronkelijk leveren ze andere diensten.
zoals rekenencomputers en datafaciliteiten co-locatie doen ze ernaast
Ja, laten we de schuld geven aan het installatiebedrijf... Het gaat uiteindelijk toch gewoon om de stroom die er uit het stopcontact komt, komt die er niet uit, dan ligt dat gewoon bij NIKHEF. Waar zij vervolgens gaan zeiken is hun probleem.
Alle carriers in een ander DC heb je niet nodig om een netwerk te draaien, dan leg je maar wat meer touwtjes, als je netwerk daar beter door blijft draaien. Afhankelijk zijn van een toko als NIKHEF is gewoon killing. Overigens ging de discussie over het ophangen van een UPS in je rack, hadden we al geconcludeerd dat iedereen dat moet doen wil het werken, en als iedereen het doet kan net zogoed iedereen verkassen.
AMS-IX heeft al tijden terug de conclusie getrokken dat SARA en NIKHEF niet te vertrouwen zijn als het op infrastructuur aan komt (beide core locaties zitten al een tijdje op GS en EUN) en ik denk dat het tijd wordt dat meer bedrijven dat doen.