Onderwerp: Vervolg discussie m.b.t. storing Nikhef

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.

Oorspronkelijk geplaatst door Apoc

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.

Oorspronkelijk geplaatst door Paulewk

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?

Oorspronkelijk geplaatst door Ber|Art

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.

Oorspronkelijk geplaatst door Ber|Art

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

Oorspronkelijk geplaatst door Paulewk

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.

Oorspronkelijk geplaatst door Paulewk

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.

Oorspronkelijk geplaatst door phreak

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..

Oorspronkelijk geplaatst door phreak

Dus, klepel?

Oorspronkelijk geplaatst door 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..

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 BGP

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?

Oorspronkelijk geplaatst door Ber|Art

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.

Oorspronkelijk geplaatst door Ber|Art

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?

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?