Vervolg discussie m.b.t. storing Nikhef

[Apoc]

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]

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.

[phreak]

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?

[phreak]

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.

[ProServe]

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.

[gjtje]

Kan je niet meerdere AMS-IX verbinding krijgen op verschillende locaties? Ik dacht dat sommige partijen dit wel hadden.

[phreak]

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.

[ju5t]

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?

[Paulewk]

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.

[luser]

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/document...p-template.htm

En voor cisco:
http://www.cisco.com/en/US/docs/ios/...e_Chapter.html

[MMaI]

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?

[phreak]

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/document...p-template.htm

En voor cisco:
http://www.cisco.com/en/US/docs/ios/...e_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.

[ProServe]

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.

[phreak]

Wel mooi om te zien dat er toch nog gegoogled wordt naar aanleiding van dit topic

[wonko]

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.