Verouderde core-routers veroorzaken vertragingen

In de VS en Canada hebben providers dinsdag last gehad van trage of uitvallende verbindingen. Oorzaak zouden verouderde routers zijn die niet overweg kunnen met bgp-routingtables die meer dan 512.000 entry's bevatten en hierdoor vastlopen of nieuwe routeringen niet langer accepteren.

Via het border gateway-protocol worden internetrouters continu voorzien van routeringen. Deze routeringen moeten het internetverkeer in goede banen leiden. Verouderde routers kunnen echter niet meer dan 512.000 routes opslaan in het ternary content addressable memory, een specifiek geheugengebied in routers waarin de routeringstabel wordt opgeslagen. Krijgen de routers toch meer dan de 512K aan entry's, dan kunnen deze vastlopen. Ook komt het voor dat de apparaten niet langer nieuwe routeringen wil accepteren of er wordt overgeschakeld naar een softwaremodus waarbij veel lag kan ontstaan.

Dinsdag lijkt dit probleem de kop op te zijn gestoken nu het aantal routeringen is gegroeid tot over de 512.000. In de VS en Canada kregen providers enkele uren lang te maken met haperende internetverbindingen of onbereikbare hostingpartijen, meldt ZDnet. Zo was de site van LastPass enige tijd offline als gevolg van een onbereikbare hoster. Een aantal grote providers heeft inmiddels toegegeven dat de bgp-problemen met oudere routers een rol hebben gespeeld. De isp's zeggen maatregelen te hebben getroffen om de problemen te verhelpen.

Opvallend is dat veel providers pas nu besluiten in te grijpen. In maart liet een ipv4-reseller al weten dat de kans groot was dat het 512K-probleem ergens in augustus tot november zich zou openbaren. Ook netwerkleveranciers als Cisco hebben hun klanten gewaarschuwd. Het lijkt er echter ook op dat veel bedrijven verouderde routers niet of niet op tijd hebben vervangen door routers die wel overweg kunnen met de immer groeiende routeringstabellen die het internetverkeer overeind moeten houden.

Reacties (130)

[Aschtra]

Had hier al een verhaal van gelezen:

http://www.reddit.com/r/t...nd_every_isp_knew_it_was/

Ze wisten het blijkbaar ook nog is.

[eekhoorn12]

Hier ook nog een hele write up van wat er gebeurd is:
http://www.bgpmon.net/what-caused-todays-internet-hiccup/

[Nas T]

Offtopic: nog eens...niet nog is
Makkelijker gezegd, maar wat was dan de oplossing? En brengt dat niet enorm veel kosten mee?
Misschien zijn de gevolgen onderschat of is de groei naar de 512.000 onverwacht snel gegaan.
Op zich wel een vreemd verhaal, ik zou niet verwachten dat dit zou gebeuren.

[Verwijderd]

ik denk dat het vooral een probleem is van beursgenoteerde bedrijven, de CEO denkt maar aan 1 ding, en das de winstmarge en het laatste wat ie wil horen is dat er een team ingenieurs en technici komt vertellen dat de winst voor dit jaar beter zou geinvesteerd worden in nieuwe apparatuur...
En de klant is de pineut...

[Armin]

Beetje 1920 manier van denken

Een goede CEO weet dat problemen uitstellen meer kost. En als jij eerder investeerd dan de concurent, is dat juist een potentieel voordeel. Ik denk eerder dat de technici op hun kop krijgen als ze het niet vertellen, maar wel wisten, en dan opeens de zaak uitvalt.

Verder hangt het van de markt af. Hele veel markten zijn niet enkel concurentie op prijs. Nieuwe investeringen die de kostprijs X% verhogen kunnen dan meer dan X% omzet/winst opleveren.

Het idee dat alles om kosten gaat, is ook een beetje een kijkje in de gedachtengang van de klant. Ik bedoel dat niet flauw, maar Nederlanders zijn ook een volk waar men heel erg op de prijs is. Niet voor niets zijn er op talloze plaatsen (ook buiten Belgie ) moppen over zuinige Hollanders. Nederlanders zijn niet vaak bereid 5% extra te betalen voor extra snelheid/service/etc Die kiezen liever 5% korting. Dat is echter geen universele menselijk voorkeur.

[Golodh]

Ik vrees dat je je hiermee vergist. Het levert een bedrijf namelijk niets op om betere service te bieden dan anderen zolang er geen concurrenten zijn.

Dat geldt ook in dit geval: het kost alleen maar geld om eerder je routers te upgraden dan de rest, tenzij je klanten kunnen weglopen. En dat is niet zo (zie bovenstaande posten over het oligopolie van de VS internet aanbieders).

M.a.w. het management heeft correct gehandeld vanuit commercieel perspectief.

[MSalters]

Het gaat hier om routers die je eerder in datacentres vind. Dat is wel degelijk een concurrende markt. Het maakt LastPass weinig uit waar ze hun servers precies hosten.

[Armin]

Het levert een bedrijf namelijk niets op om betere service te bieden dan anderen zolang er geen concurrenten zijn.

Hier is wel concurentie, maar ook los daarvan een vaak voorkomend misverstand.

Meer service kan leiden tot hogere marges omdat mensen dan soms bereid zijn meer te betalen. Iets wat inderdaad minder vaak in onze Nederlandse volkaard voorkomt maar dus niet universeel is.

Nederlanders prefereren vaak liever 5% korting voor dezelfde service, dan 5% meer bealen voor meer service. Maar Amerikanen bijvoorbeeld trekken veelvuldig de buidel voor service in dat soort situaties.

[Lunacy]

Ik geef je gelijk maar moet toch constateren dat het in de praktijk heel vaak gebeurd. Als ik dan alleen al kijk naar de bedrijven die nu extended windows xp support hebben gekocht bij Microsoft terwijl het al jaren vast lag wanneer xp eruit ging ...

[Nas T]

...het laatste wat ie wil horen is dat er een team ingenieurs en technici komt vertellen dat de winst voor dit jaar beter zou geinvesteerd worden in nieuwe apparatuur...

Hangt er van af. Als diezelfde ingenieurs vertellen dat als dit niet gebeurd, er een miljoenenstrop boven het hoofd hangt...mwao.
Het klopt op zich wel dat leidinggevenden te maken hebben met korte-termijn visie.

[JackBol]

Slechte CEO dan. Iedere senior leader zou moeten weten dat customer satisfaction belangrijk is om revenue te borgen.

[Cerberus_tm]

Het probleem is dat Internetaanbieders, vooral in America, een oligopolie vormen; op veel plaatsen is er zelfs maar één aanbieder voor breedband beschikbaar. En waar dat niet het geval is is overstappen lastig. Er wordt in America extreem veel geklaagd over de belabberde internettoegang bij de grote aanbieders, maar mensen kunnen geen kant op, vooral niet als de grote vier alle hetzelfde (slechte) onderhoudsbeleid voeren. Er is nauwelijks marktwerking in een oligopolie of een plaatselijk monopolie.

[Reactie gewijzigd door Cerberus_tm op 30 juli 2024 02:14]

[MSalters]

Niet helemaal duidelijk waarom dit een +2 krijgt. De internet breedband aanbieders (richting consumenten) zijn de randnetwerken, en dit artikel gaat over de core switches. Dat zie je ook aan het feit dat bijvoorbeeld LastPass down ging: dat is geen site die bij iemand thuis gehost wordt maar ergens in een datacentre.

[Cerberus_tm]

Het hele artikel gaat over internetproviders....

[JackBol]

Kan jij dan de arbitraire franse woorden achterwege laten svp?

[Blokker_1999]

Ik zou zeggen dat de groei zeer goed is ingeschat geweest als anderen al wisten dat het tussen augustus en november zou gebeuren dan zit men recht in die periode.

En zo is het met andere problemen net hetzelfde. Neem nu IPv6, vele ISPs blijven stilzitten op dat gebied en wachten totdat er echt problemen ontstaan om dan snel snel een oplossing te gaan zoeken. In plaats van tijdig de signalen op te vangen en er naar te handellen.

Nu moet men hier ineens alsnog dringend nieuwe apparatuur gaan plaatsen, en door het feit dat dit zo snel moet gebeuren en het dus een haastklus is zullen de kosten groter zijn en is er meer risico op het maken van fouten. Ook hebben de getroffen ISPs imago schade opgelopen.

[Verwijderd]

IPv6 is heel andere koek dan dit. Met IPv6 kun je makkelijk nog een jaar of 5-10 wachten voordat het penibel wordt. Als het al ooit penibel wordt. Ik wacht zelf al sinds 1996 op IPv6. 18 Jaar dus, and counting.

[marcelvb]

Dit probleem en de overschakeling naar IPv6 is vergelijkbaar met:

• het feit dat de olie al een hele tijd bijna op en we moeten overschakelen naar iets anders
• dat het klimaat langzaam verandert waardoor de zeespiegel stijgt
• dat je moet stoppen met roken omdat je anders kanker krijgt

Dit artikel gaat over de psychologie van klimaatverandering, maar is ook wel van toepassing op andere zaken denk ik.

Mensen kunnen niet goed overweg met lange termijn risico's.

Maar goed, slaap lekker verder.

[Verwijderd]

Als de olie op is, kan ik niet meer autorijden. Lastig.

Als de IPv4 adressen op zijn, heb ik daar (bijna) geen last van. Mijn v4 Internet blijft gewoon nog lekker werken. En de eerste 5 jaar (of meer), zal mijn v4 Internet beter werken dan het v6 net. (In zoverre dat ik er meer bestemming mee kan bereiken dan via v6).

Dat is nogal een verschil.

Klimaatverandering is ook verschrikkelijk. Voor anderen. Straks loopt Nederland nog onder. Verschrikkelijk. 1 Miljard chinezen liggen er wakker van. Oh nee, toch niet. Die zijn blij met hun econmische vooruitgang. Die blijven CO2 de lucht in jagen alsof het niks is. Blij met hun nieuwe welvaart.

Klimaatverandering is technisch een lastig probleem. We weten nog steeds niet goed hoe het op te lossen (op een rendabele manier). Een ander probleem is honger in de wereld. Daarvan weten we precies hoe we het moeten oplossen. Er zijn geen technische problemen. Er is voedsel zat. Het is vooral een kwestie van (eerlijke) distributie. En toch kan de wereldpolitiek al 100 jaar het probleem niet oplossen. En er gaan ieder jaar 3 miljoen kinderen dood aan ondervoedig.

En dat simpele probleem kan de wereld niet oplossen. We hoeven er niets voor te laten. Denk je echt dat de wereld als geheel klimaatverandering kan tegengaan ?

[Mentalist]

Als de olie op is, kan ik niet meer autorijden. Lastig.

Dat is natuurlijk kortzichtig. Niet alleen jij, maar ook de vrachtwagenchauffeur die jouw eten naar de supermarkt moet brengen kan niet meer rijden. Elektriciteit zou ook spontaan vele malen duurder worden, want daar kan je ook op rijden. Vele plastics worden ook indirect uit olie gemaakt en zelfs medicijnen als paracetamol vinden hun oorsprong in aardolie.

De staatskas is opeens ook een stuk leger, dus er komen weer flink extra belastingen op andere zaken.

Natuurlijk is de olie nooit "op", alleen zal het steeds schaarser worden tot niemand het meer kan betalen. Tegen de tijd dat een doosje paracetamol 10 euro kost in plaats van 50 cent kan jij allang geen volle tank meer betalen.

Als de IPv4 adressen op zijn, heb ik daar (bijna) geen last van. Mijn v4 Internet blijft gewoon nog lekker werken. En de eerste 5 jaar (of meer), zal mijn v4 Internet beter werken dan het v6 net. (In zoverre dat ik er meer bestemming mee kan bereiken dan via v6).

Dat is nogal een verschil.

Op dat moment zijn IPv4 adressen wel schaars en kan er een biedoorlog uitbreken. Jouw internet zal dan duurder worden. Waarschijnlijker is dat veel ISP's klanten geen direct internetadres meer geven maar alleen nog een lokaal adres uitdelen. Gewoon NAT dus, wat je afaik al wel eens op mobiele netwerken kan zien.

Op die manier kan je IPv4 nog heel lang rekken, misschien wel voor altijd.

Klimaatverandering is ook verschrikkelijk. Voor anderen. Straks loopt Nederland nog onder. Verschrikkelijk. 1 Miljard chinezen liggen er wakker van. Oh nee, toch niet. Die zijn blij met hun econmische vooruitgang. Die blijven CO2 de lucht in jagen alsof het niks is. Blij met hun nieuwe welvaart.

En wij kopen al die zooi, want ze pompen het voor ons de lucht in hoor.

Klimaatverandering is technisch een lastig probleem. We weten nog steeds niet goed hoe het op te lossen (op een rendabele manier).

Tuurlijk kunnen we dat wel oplossen. Maar stel er staat een tafel voor je. Je hebt een volle maag. Op tafel staat ingeblikte vis waar je een week van kan eten en een boek waarmee je kan leren vissen. Je mag één item uitkiezen.

De wereld kiest massaal voor de vis in plaats van het boek.. Want als je dat boek kiest moet je werken, dingen leren, je gewoontes veranderen.. En op korte termijn zal het minder opleveren dan de ingeblikte vis.

[Reactie gewijzigd door Mentalist op 30 juli 2024 02:14]

[gws24]

Dit was toch ook het probleem bij de uitval van ING gisteren?

EDIT: Zie nieuws: Klanten klagen over bereikbaarheid internetbankieren ING - update

[Reactie gewijzigd door gws24 op 30 juli 2024 02:14]

[3DDude]

Want de ING zit in de VS en Canada? Dacht het ook niet nee..
Lijkt me sterk ( we zullen hier toch ook wel 'core routers hebben bij de AMS-IX).
@t hieronder: ShadowBumble ik bedoelde meer
Core routers staan in amerika, maar ook in amsterdam (nederland).
Beiden weten die route maar als jij vanaf nederland de ING wil bereiken pak je toch de route van de core-router die in amsterdam staat? Als dat ding gewoon fatsoenlijk werkt moet dat niet zo'n probleem geven .. (denk ik dan? )

Lijkt me namelijk een beetje onzin om in Nederland het internet op te gaan --> Via NL Core router --> Amerika Core router --> Terug NL Core router --> ING NL..

(tenzij de ING gehost wordt in Amerika, dan heb ik niks gezegd )


Buiten dat is dat wellicht gewoon een 'excuus verhaal naarbuiten van de ING'

@t hieronder ok ok, de AMS-IX is alleen de exchange en heeft geen core routers, de ISP's die hebben die dus en die maken weer gebruik van de exchange... helder.

[Reactie gewijzigd door 3DDude op 30 juli 2024 02:14]

[Beaves]

AMS-IX heeft gen core-routers want de AMS-IX is geen ISP! Het is puur een marktplaats van switchpoorten waarop ISP's (of grote bedrijven die zelf een link op de AMS-IX willen) poorten afnemen en waarover ze met andere ISP's kunnen connecteren.

Het probleem is verder niet dat de core-routers van veel ISP's, ook in Nederland, verouderd zijn, maar dat de default max-value niet door de beheerders is aangepast. Het is namelijk helemaal niet zo dat je 'even' een nieuwe router moet plaatsen bij >510.000 routes, want de meeste routers kunnen meer routes prima behappen, alleen moet je ze wel vertellen dat ze dat moeten doen. Dat dit niet standaard zo is, komt weer omdat je als beheerder continue een afweging hebt over hoe je de (beperkte) resources zoals CPU en TCAM geheugen moet verspreiden over de diverse taken. Als je meer resources toewijst aan de hoeveelheid routes zal je ergens anders concessies moeten doen, bijvoorbeeld over de max. MAC adressen of over de max. hoeveelheid VPLS instances.

Dat dit niet eerder gedaan is, is wel slordig want zoals ook in het artikel vermeld staat is dit niet iets wat niemand zag aankomen. Het is echter zo dat er, waarschijnlijk omdat een grote partij door een config error voor veel meer routes gezorgd heeft, de route-tabel een korte spike heeft gekend tot over de 510.000 routes. Als ik nu bij ons kijk dan zitten we op 503317 routes.

[Chveu007]

AMX-IX heeft wel degelijk core routers, alleen maken ze gebruik van de Brocade MLX series, welke meer routes aankunnen dan de oudere Cisco routers waarover het gaat.
Voor het overige klopt je verhaal niet helemaal wat betreft de default max-value. Veel ISP gebruiken Cisco routers van de 6500 series, en deze kunnen afhankelijk van de gebruikte supervisor engine max 1000000 routes aan. Dit is echter enkel het geval wanneer je uitsluitend IPv4 gebruikt. ISP's adverteren natuurlijk ook IPv6, welke 2 entries per route innemen in je routingtabel. Eveneens worden er dan nog wat entries gereserveerd voor MPLS en IP Multicast. De standaard verdeelsleutel bij een Cisco 6500 series is als volgt. 6509E#sh mls cef maximum-routes !
FIB TCAM maximum routes :!
=======================!
Current :-!
-------!
IPv4 + MPLS - 512k (default)!
IPv6 + IP Multicast - 256k (default).

Wat je dus wel zou kunnen doen, is meer ruimte reserveren voor je IPv4 entries en in het oog houden dat je IPv6 entries niet tegen de limiet aanlopen. ISP die Juniper core routers gebruiken kennen het betreffende probleem trouwens ook niet.

[JackBol]

De AMS-IX participeert niet in routing. De AMS-IX systemen die onderdeel uitmaken van het peering VLAN hebben dus exact 0 (nul) BGP routes in memory. Hooguit wat IGP routes voor loopbacks en directly-connected.

De maximale state die de MLX'en van de AMS-IX hoeft bij te houden zijn de +/- 1000 ARP entries voor de aangesloten peering routers.

[GrooV]

AMSIX heeft zelf gewoon routers, zie https://ams-ix.net/technical/ams-ix-infrastructure

Ze gebruiken de Brocade MLX 32

[JackBol]

Ik zeg ook niet dat ze geen routers hebben. Ik zeg dat ze niet participeren in routing.
Op die MLX systemen draait alleen een MPLS/VPLS service, wat je had kunnen lezen als je zelf je link had aangeklikt.

[Reactie gewijzigd door JackBol op 30 juli 2024 02:14]

[TryOG]

Ik lees her en der tijdelijke fixes door de L2 geheugentabel aan de L3 tabel toe te wijzen waarmee de linecards of routers meer routeringen aankunnen.

Ook wijzen sommigen de ongebruikte capaciteit die voor IPv6 bedoeld was toe aan IPv4, maar dan nog is het probleem dat je de linecards of routers moet reloaden waarbij het volgende geldt:

Hoe langer die apparaten draaien, hoe groter de kans is dat ze stuk gaan.

Dit gaat Cisco miljoenen aan vervangingen en reparaties kosten. Maar aan de andere kant hebben ze nu een goed argument dat de cliënten moeten upgraden.

[Verwijderd]

Dit gaat Cisco miljoenen aan vervangingen en reparaties kosten.

Kosten ? Ze gaan juist extra verdienen. Zij kunnen er niets aan doen als het Internet uit de specificaties groeit die jij hebt uitgekozen toen je een router kocht.

[Reactie gewijzigd door Verwijderd op 30 juli 2024 02:14]

[ShadowBumble]

Want de ING zit in de VS en Canada? Dacht het ook niet nee..

Bij de ING is er gewoon iets omgevallen wat via hele vage meuk aan elkaar zit

ING lag eruit door problemen bij een netwerkleverancier op een interconnect, die heel toevallig ook last had van het 512k probleem Bgp routeringen op het internet houden niet spontaan op bij de landsgrenzen

[TryOG]

Agreed.

Symptomen in Noord-Europa waren o.a. dat Google' wel werkte en dat je op de hoofdpagina van YouTube kon komen, maar video's werden tijdelijk niet afgespeeld.

Ik heb trouwens ook een paar seconden uitval gehad met software die verbinding heeft met databases in de VS.

[NaoPb]

Google werkte bij mij een tijdje niet, gisteren. Ik ben toen maar even gaan douchen en daarna werkte het weer .

[FlyEragon]

Aah, Google smells you !

[NaoPb]

Hihi, ik kwam wel in de verleiding om een dergelijke opmerking te maken. Maar ik heb het maar niet gedaan .

[Powermage]

Nope, maar de routetabellen zijn natuurlijk een globaal probleem, niet alleen in de VS, ik weet een grote partij in NL die ook te laat was met updaten van de core routers en last kreeg van dit probleem.

[LittleBrittany]

Ziggo zeker. heb er iedere dag last van.

[FatalError]

Nee, Ziggo had zijn zaken goed voor elkaar.

[LittleBrittany]

Ik ben over bedaard internet inderdaad tevreden met Ziggo. maar met wifi en dan voornamelijk met me MBP. is het vreselijk lijkt net 2000's. moet iedere X handmatig de wifi resetten.

[Powermage]

Ik had het idd niet over ziggo, tent levert geen consumenten verbindingen maar zit meer in de datacenters

[jeroenICT]

Want de ING zit in de VS en Canada? Dacht het ook niet nee..
Lijkt me sterk ( we zullen hier toch ook wel 'core routers hebben bij de AMS-IX).

Buiten dat is dat wellicht gewoon een 'excuus verhaal naarbuiten van de ING'

Waarom zou dit probleem alleen in de VS of canada moeten voordoen. ISPS en hosting providers hier gebruiken ook CISCO switches en overige netwerkapparatuur hoor.

[Yariva]

Ben nog een beetje nieuw in de netwerkwereld, maar zijn 512.000 entries in een routing tabel niet enorm in-efficient? Zo te horen delen ze het dan niet op in verschillende area's *kugh* ospf. Please correct me if i'm wrong

[it0]

OSPF=Interiour Routing Protocol
BGP= External Routing protocol

Appels en peren dus. Het ene gebruik je binnen je netwerk, Het andere om met andere netwerken te praten. Zoveel entries heb je ook alleen als je aan peering doet, dus dat is alleen voor de zware jongens. BV een ISP kan slechts 1 BGP entry hebben.

[TheKmork]

Ja en nee. Je haalt nu denk ik peering en transit door elkaar.

Peering doe je tussen partijen die grofweg gelijkwaardig zijn, en daarbij wissel je alleen de prefixen van je eigen netwerk en eventueel die van je onderliggende klanten uit. Hierbij zul je dus geen volledige internet routing table uitwisselen, want dan kan het zijn dat peers via jouw netwerk weer naar andere peers gaan (waar je dus als ISP niets aan verdient, want beide kanten betalen niet, maar wel kosten voor maakt).
Echter als je transit levert aan kleinere partijen (dus jij bent toegangsweg tot "het internet" voor deze partijen) dan zul je wel een full routing table naar die partijen adverteren. Uiteraard kan dit ook door middel van default routes, maar aangezien ISPs vanaf een bepaalde grootte toch al gauw dual-homed (meerdere upstream transit partijen) willen die graag specifieke tabellen zodat het verkeer gewoon de kortste weg kan kiezen (via provider A of provider B ) in plaats van alles via provider A en pas bij failure naar provider B.

De nuances zijn heel was specifieker uiteraard, maar uiteindelijk komt het erop neer dat vrijwel alle providers van enig formaat intern wel gebruik maken van full routing tables (en dus van rond de 500k prefixes).

Wat OSPF/BGP betreft heb je echter wel gelijk. Het is vrijwel onmogelijk om OSPF op een wereldwijde schaal toe te passen. Sowieso kan BGP prima met dergelijke grote routeringstabellen omgaan, want het maakt geen volledige topology voor zichzelf, het bepaalt alleen voor zichzelf wat de beste next-hop voor een bepaalde prefix is. Router A heeft dus geen idee waar IP adres 1.2.3.4 zich bevindt, alleen dat pakketten met bestemming 1.2.3.4 doorgestuurd moeten worden naar router B en die ziet maar weer wat hij er mee doet (en die herhaalt dat proces weer tot het bij de bestemming is).

[Reactie gewijzigd door TheKmork op 30 juli 2024 02:14]

[Raindeer]

Mag ik jou dan weer corrigeren op een foutje. Peering gebeurd tussen partijen van allerlei verschillende grote. Je hoeft niet grofweg gelijkwaardig te zijn. Niet voor niets heeft de AMS-IX route-servers waar 400 partijen met elkaar peeren, zonder te kijken naar elkaars formaat. De economische reden om te peeren is dat het transit uitspaart en betere performance oplevert. En beide partijen hebben altijd exact evenveel verkeer naar elkaar, want de een zijn inkomend is de ander zijn uitgaande verkeer. Dat verkeer heeft soms wel een verschillende prijs, want een kleine ISP heeft niet de inkoopmacht van een grote contentprovider, dus de kleine ISP is vaak beter af door een peering agreement dan de grote contentprovider.

Een goed voorbeeld is Netflix. Netflix is bereid om te peeren met iedereen, maar directe peerings (private peerings), zonder tussenkomst van een IXP is voorbehouden aan partijen met meer dan 3Gbit/s peak traffic. Alle andere partijen gaan via een IXP (indirecte of publieke peering)

Je bent trouwens niet de enige die de fout maakt te denken dat peering tussen gelijkwaardige partijen gebeurd, de meeste literatuur herhaald deze misconceptie. Er is echter geen empirische noch een onderliggende economische basis voor.

[TheKmork]

Tja, echter heb ik dit niet zo zeer uit literatuur maar ben ik werkzaam als peering/transit coordinator/engineer bij een internationale provider. Je hebt gelijk dat er weliswaar allerlei partijen aangesloten zitten op AMS-IX maar dat betekent niet dat al die partijen zomaar met iedereen peeren. Er zijn vele voorbeelden op de AMS-IX zonder open peering policy, die dus alleen peerings opzetten met partijen van vergelijkbare grootte.

Natuurlijk is het zo dat grootte niet zo zeer refereert naar de grootte van het netwerk of het aantal prefixes, maar naar de hoeveelheid uitgewisseld verkeer. En natuurlijk is het wel zo dat jouw uitgaande verkeer (bijvoorbeeld) mijn inkomende verkeer is, maar over het algemeen zetten bedrijven hoofdzakelijk peerings op met partijen waar de ratio inkomend/uitgaand grofweg gelijk is (dit kan eventueel 1:2 of 1:3 worden, maar groter is het verschil over het algemeen toch niet bij de grotere partijen). In die zin is peering dus wel degelijk hoofdzakelijk tussen partijen van vergelijkbare grootte.

Je hebt het er ook over dat het verkeer soms een verschillende prijs heeft, maar peering is over het algemeen settlement free. Er zijn wel voorbeelden van partijen die betalen voor peering, maar dat zijn er over het algemeen niet zo veel, aangezien je dan over het algemeen beter een transit kunt afnemen (waarmee je het hele internet kunt bereiken, voor weliswaar een iets hogere prijs) dan een paid peering (waarmee je dus alleen bij het netwerk van de peering partner en zijn klanten komt, wat dus maar een klein stukje van het internet is - afhankelijk van hoe groot die peering partner is uiteraard).

Uitzondering zijn inderdaad partijen als Google, Netflix en zo nog wel enkelen die hoofdzakelijk content leveren, maar bij die partijen is het ook wel zo dat het voordeel voor beide partijen gelijk is: De content partij wil de kortste weg naar de eindgebruikers, en de netwerkpartij wil zijn eindgebruikers tevreden houden door goede performance te leveren (hoewel ook daar weer afwegingen gemaakt worden hoe waardevol content X voor die provider is en of ze wel of niet direct gaan peeren met zo'n partij).

[Reactie gewijzigd door TheKmork op 30 juli 2024 02:14]

[Raindeer]

Ik hoop dat je Bill Norton's stuk over Traffic ratios kent.

Maar stel je voor een willekeurige transitboer, zeg KPN International heeft een peering agreement met een Belgacom International. In het begin is verkeer in evenwicht. KPN is echter actief in Amsterdam en andere grote transit locsties. Belgacom doet alleen zijn retailklanten en een serie Belgische AS-en. Belgacoms verkeer groeit.KPN groeit harder. Na 2 jaar is KPN 5x zo groot als Belgacom. Is het nu KPN die aan Belgacom moet betalen? Zie standpunt US operators in US VS Netflix, Orange etc. Of is het Belgacom die aan KPN betaald? Conform standpunt US operators in Europa en standpunten van Tier 1 netwerken.

[cbravo2]

Er is nog een reden: Security en betrouwbaarheid. Als je je eigen routes onder controle hebt dan heeft een ander dat niet.

[Stewie!]

http://www.bgpexpert.com/books.php ;-)
Netwerken koppelen op het internet dmv BGP. Elk netwerk adverteert zijn eigen routes, soms als groot pakket, soms in kleine blokjes opgedeeld ivm policy en wat voor reden dan ook. Doordat er geen nieuwe IPv4 adressen meer zijn adverteren de netwerken steeds kleinere blokjes, die ze bijvoorbeeld huren, aangekocht hebben, etc. Dit heeft de groei van het aantal routes in de laatste 2 jaar enorm versneld. Oude routers kunnen hier niet mee overweg zonder aanpassingen of vervangingen. Slapende netwerkbeheerders zijn dus het probleem.

Iedere netwerker zag dit jaren geleden al aankomen.

[Reactie gewijzigd door Stewie! op 30 juli 2024 02:14]

[Blokker_1999]

Niet noodzakelijk de schuld van de slapende netwerkbeheerder. Als zijn baas geen budget vrijmaakt voor een upgrade is het verhaal ook snel afgelopen.

[Verwijderd]

Dit heeft de groei van het aantal routes in de laatste 2 jaar enorm versneld.

De laatste 2 jaar ? Zeg maar de laaste 20 jaar. (BGP4 is toevallig precies 20 jaar oud dit jaar). Hier een grafiekje van de groei.
https://en.wikipedia.org/...ocol#Routing_table_growth
https://upload.wikimedia....-BGP_Table_growth.svg.png

[_-= Erikje =-_]

Dat wel, maar niet iedereen aggregeert zijn/haar prefixes netjes of kan ze netjes aggregeren, zeker nu de ipv4 space aan het opraken is worden de prefixes steeds kleiner. Er zijn nu AS nummers met alleen een /25 waar ik voorheen alles kleiner dan een /24 de prullenbak in gooide.
Gaat een ander routing protocol geen verandering in brengen.

Wat vervelender is is dat sommige hardware (lees Cisco) een beperkte hardware FIB heeft waar domweg niet meer entries inpassen, die boxes vallen terug in software/CPU forwarding en zeg maar dag tegen de performance. Is met ipv6 straks een nog groter probleem als aggregatie niet netjes gedaan word.

[Verwijderd]

Dat het met IPv4 meer en meer wordt weet ik vrij zeker, het steeds verder ophakken van subnets en het verspreiden / delen over verschillende locaties gebeurd al tijden.

Met IPv6 weet ik het nog niet, de "grote" routers die asic's hebben zullen volgens mij vrij grote subnetten doorsturen, Deutsche telecom bv die een /19 aankondigd.

Anderen /32 maar veel specifieker? Ik denk het niet, ik hoop het niet. De noodzaak is minder, echter blijft natuurlijk dat network operators secuur moeten blijven werken.

[Bacchus]

IPv6 is er mede op ontworpen om voor dit probleem een oplossing te bieden door inderdaad de adresruimte in veel grotere brokken uit te geven.

[Verwijderd]

Er is helemaal niets in IPv6 ontworpen om dit probleem aan te pakken. Er is alleen hoop. Hoop dat deze keer alle ASen zich wel netjes zullen gedragen. Dat alles gesummarized wordt tot een prefix per AS. En dat er geen wildgroei zal ontstaan. Gaat niet gebeuren.

Wat nodig was geweest, zijn beter methodes voor multi-homing van ASes.Inclusief aanpassing in DNS. Methodes voor easy renumbering van een heel AS. Terwijl bv TCP verbindingen op blijven. Voor locator-identifier separation. Betere automatisch summarization. Noem maar op. Maar dat heeft IPv6 allemaal niet. IPv6 is precies hetzelfde als IPv4, maar dan met langer adressen. (Niet aankomen met geneuzel dat je geen ARP of DHCP meer nodig hebt, we hebben het hier over architectonisch perspectief van het hele routing systeem).

[Reactie gewijzigd door Verwijderd op 30 juli 2024 02:14]

[Bacchus]

Er is helemaal niets in IPv6 ontworpen om dit probleem aan te pakken.

RFC 1752, §5.2.

Er is alleen hoop. Hoop dat deze keer alle ASen zich wel netjes zullen gedragen. Dat alles gesummarized wordt tot een prefix per AS. En dat er geen wildgroei zal ontstaan. Gaat niet gebeuren.

Anders dan jij kijk ik hier iets optimistischer tegenaan maar ik moet toegeven dat er niets dichtgetimmerd is.

[...] Noem maar op. Maar dat heeft IPv6 allemaal niet. IPv6 is precies hetzelfde als IPv4, maar dan met langer adressen.

Qua routing zijn alleen de langere adressen relevant maar juist die zijn een stap op weg om het gebrek aan structuur dat IPv4 plaagt, op te lossen.

Van de andere kant is IPv6 maar een paar jaar jonger ('95 vs '81) en is het misschien ook wel tijd om IPv6 over te slaan en een nieuw protocol te bedenken met de inmiddels opgedane inzichten.

[Reactie gewijzigd door Bacchus op 30 juli 2024 02:14]

[Verwijderd]

RFC 1752, §5.2.

Hahaha.
Er staat: "IPv4 heeft een groeiend aantal prefixes. Dat moeten we niet willen met z'n allen". Dat was het. Geen woord over hoe dat te doen. Stricte assignment is niet het antwoord, want multi-homing. Er wordt verwezen naar address autoconf. Da's niet genoeg. Je moet hele ASes on-the-fly kunnen renumberen. Ik blijf er bij, er zit niks in IPv6, behalve hoop.

Van de andere kant is IPv6 maar een paar jaar jonger ('95 vs '81) en is het misschien ook wel tijd om IPv6 over te slaan en een nieuw protocol te bedenken met de inmiddels opgedane inzichten.

En hier ben ik het helemaal 100%, wat zeg ik, 1000% met je eens. De eerste keer dat ik op Tweakers iemand dit hoor zeggen.

[Reactie gewijzigd door Verwijderd op 30 juli 2024 02:14]

[ShadowBumble]

kuch OSPF en BGP zijn 2 verschillende routering protocollen OSPF is enorm lastig om op wereldwijde schaal toe te passen omdat iedereen dezelfde administratie dan zal moeten bij houden ( In een nutshell als je alle verschillen wilt hebben google even ). Vandaar dat BgP veel schaalbaarder is, maar 512k entries zijn niet inefficient zo groot is het net gewoon tegenwoordig .

[Reactie gewijzigd door ShadowBumble op 30 juli 2024 02:14]

[Verwijderd]

Er is geen technische reden voor de 500k+ entries in de global BGP reden. Alleen politieke, historische en economische redenen. Als je meer prefixes adverteert dan nodig is, kost dat je niks. De kosten zijn voor de gehele community. Daarom wordt er nogal laks over gedaan. Hetzelfde probleem zal zich gaan voordoen als IPv6 ooit populair wordt.

[daemonix]

Merkwaardig. Nanog staat er al een hele tijd vol mee. Blijkbaar zitten er ISP's te slapen en lezen de voor hun belangrijkste nieuwsgroep niet.

[ArcticWolf]

Kost geld he...

[TheKmork]

Niet eens, want het is in de meeste gevallen iets wat gewoon in de configuratie van de routers aan te passen is. Default is de limiet weliswaar 512k, maar is (in elk geval bijvoorbeeld bij Cisco) gewoon dmv configuratie te verhogen. Het enige waar je wel rekening mee moet houden is dat de router daardoor wel weer zwaarder belast wordt, dus je moet wel de afweging maken hoeveel CPU/TCAM geheugen je wilt toewijzen aan de routing table (zoals Beaves iets hierboven ook al stelt)

[Verwijderd]

De CPU wordt zwaarder belast als je meer prefixes in je TCAM hebt ? Lijkt me sterk.

[TheKmork]

Ik denk dat je enigszins verkeerd begrijpt wat ik bedoelde. Ik bedoel dat zowel de CPU als het TCAM geheugen beperkte resources zijn, en je dus wel moet nadenken welke je waaraan toewijst en dat je het dus niet overbelast.
Wellicht is mijn bewoording niet helemaal juist gekozen, maar vandaar dat ik ook naar de uitgebreidere reactie van Beaves verwees.
Een grotere routing table an sich vereist niet een zwaardere CPU, maar de bijbehorende route calculaties wel. De CPU zal over het algemeen echter niet zo zeer de bottleneck zijn wat de routing table betreft, maar met name het geheugen.

[BadRespawn]

Niet eens, want het is in de meeste gevallen iets wat gewoon in de configuratie van de routers aan te passen is.

Dat wordt door een techneut gedaan, en dat kost geld. Relatief gezien kost het niet veel, maar veel bedrijven zijn wat dat betreft net Dagobert Duck.

[TheKmork]

Hoewel je technisch gezien wel gelijk hebt gaat het hier om ISPs welke (als het goed is) gewoon eigen netwerkbeheerders in vaste dienst hebben. Uiteraard moeten die ook betaald worden voor hun uren, maar hun werk is om het netwerk stabiel en draaiend te houden, dus valt dit gewoon onder hun reguliere werkzaamheden. Als je een configuratiewijziging van 1 regeltje al als kostenpost gaat zien kun je waarschijnlijk je bedrijf wel direct opdoeken, want die kosten zijn vrijwel nihil. Natuurlijk is er enige tijd nodig voor impact analyse, inplannen reboots apparatuur en voorbereiden change, maar over het algemeen wordt dat dan gecombineerd met andere zaken (zoals bijvoorbeeld IOS upgrade), dus kan ik me niet voorstellen dat kosten hier de overweging zijn.
Het enige dat eventueel een issue zou kunnen zijn is het feit dat de router ervoor herstart moet worden, maar het is niet dat dit issue pas gisteren uberhaupt bekend is. De IPv4 full routing table is al >1 jaar boven de 450k, dus dat de limiet eraan ging komen was al heel lang bekend. Ik mag er dus toch wel hopen dat er in die tijd wel de kans is geweest om een geplande router herstart te doen.

[ShadowBumble]

Merkwaardig. Nanog staat er al een hele tijd vol mee. Blijkbaar zitten er ISP's te slapen en lezen de voor hun belangrijkste nieuwsgroep niet.

Dat is gedeeltelijk waar, er is namelijk geen enkele grote isp die bleeding edge IOS-en van Cisco draait ( al adviseerd Cisco dit wel altijd ) en waarom niet omdat er te weinig bewijs is dat de software goed werkt, ISP's willen over het algemeen niet even 50.000 klanten offline brengen omdat cisco toevallig een bugje heeft in bleeding edge.

[JackBol]

Repartitioning van de TCAM is reeds mogelijk vanaf release 12.2(18)SXF, welke in 2006 gereleased was. Sinds dien zijn er 8 major releases en 30+ minor releases geweest.

Als je nog software had draaien waarin deze functionaliteit niet zat, heb je als ISP zelf zitten slapen.

[furio911]

Lijkt mij dat ze de situatie wilden uitmelken door de routers te gebruiken tot het punt dat ze het 'begeven'.

[Neko Koneko]

Algemene opvatting binnen het bedrijfsleven, waarom geld uitgeven als er (nog) geen probleem is?

En zelfs als er een probleem is, vooral niet te veel geld in steken. Pas als het probleem niet meer met trucjes weg te moffelen is en het oplossen ervan inmiddels een tienvoud duurder is geworden, dan gaan we eens kijken of we er misschien iets aan moeten doen

[Reactie gewijzigd door Neko Koneko op 30 juli 2024 02:14]

[marcelvb]

Als je nu als ISP had geïnvesteerd in een nieuwere router en/of betere configuratie, dan had je nu wel mooi gratis reclame gehad, als provider die het wel goed geregeld heeft. Al die andere zitten nu met boze klanten.

[cbravo2]

Hier is de lijst van NL 'ISP's: https://www.ripe.net/membership/indices/NL.html Al deze bedrijven moeten hun netwerk via BGP laten routen. Veel hebben het eea wèl op orde.

[MSalters]

Waarom geld uitgeven als je ook een software setting kunt aanpassen? Geef niet de financieel directeur de schuld van de luiheid van de netwerk beheerder. Die 512K limiet van Cisco's is een instelling, en met de huidige hoeveelheid IPv4 en IPv6 routes had die instelling best hoger gekund.

[sirono]

ik weet niet wat zo'n ding kost, maar kan me voorstellen dat ze maximaal profijt eruit willen halen.

[MrR0b3rt]

Route summarization anyone? Just kidding, weet niet eens of BGP dat wel ondersteund (en of dit nog niet wordt toegepast).

Wel slordig dat ze dit hebben zien aankomen maar niets hebben gedaan, maarja dat is wat we tegenwoordig gewend zijn...vaak gebeuren dingen reactief ipv proactief.

[Reactie gewijzigd door MrR0b3rt op 30 juli 2024 02:14]

[Verwijderd]

Route summarization anyone? Just kidding, weet niet eens of BGP dat wel ondersteund (en of dit nog niet wordt toegepast).

BGP heeft summarization uitgevonden !
Rond 1991-1992 was het al duidelijk dat het aantal routes op het Internet uit de klauwen aan het lopen was. Vijf duizend routes in BGP3 al !
Er is toen binnen de IETF een werkgroep opgericht om daar op korte termijn wat aan te doen. Die werkgroep heette Classless Inter-Domain Routing (Cidr).
https://en.wikipedia.org/wiki/Cidr

De CIDR werkgroep kwam met het summarization idee. BGP3 werd aangepast naar BGP4. Ipv classfull routes kon BGP4 nu variable-length prefixes adverteren. OSPF en RIP konden dat toen nog niet, in hun toenmalige versies. (Ik denk dat IS-IS het wel kon, maar dat werd pas in 1994 populair onder ISPs). OSPF (versie 3) en RIP (versie 2) hebben later ook summarization ingevoerd. Maar BGP4 was de eerste.

Note: summarization is niet het zaligmakend antwoord op dit probleem. Vele ISPs en ASes moeten wel ge-desummarizeerde prefixes adverteren. Omdat dat de enige manier is waarop multi-homing werkt. Stel je bent een bedrijf, je wilt altijd bereikbaar zijn. Dan neem je 2 of 3 verbindingen bij 2 of 3 verschillende ISPs. Maar welke IP adressen ga je dan gebruiken ? Antwoord: je neemt je eigen Provider-Independent addressen, en laat alle drie je ISPs jouw prefix adverteren. Je krijgt dus een extra prefix voor ieder bedrijf in de wereld dat robust aan het Internet wil hangen. En dat zijn er een hoop. En worden er alleen maar meer. Omdat IPv6 routing precies hetzelfde werkt, zal het probleem zich ook snel bij IPv6 gaan voordoen, zodra het populair wordt.

[Reactie gewijzigd door Verwijderd op 30 juli 2024 02:14]

[MSalters]

Van die 500K routes zijn er dus een groot aantal redundant? 2 of 3 routes die van mijn AS naar dat multi-homed AS lopen? Dan vraag je je af waarom die Cisco routers kritische routes droppen (zoals naar de ING) in plaats van de redundante routes.

[Verwijderd]

Niet redundant.
Wel overlappend.

Bv, ISP A heeft prefix 123.123/16.
Andere ISP B heeft prefix 123.124/16.
Jij wilt via beide aan het net hangen.
Welk adres ga je gebruiken ?
Als je 123.123.1/24 gebruikt, zal niemand je pakketjes via ISP B sturen.
Als je 123.124.1/24 gebruikt, zal niemand je pakketjes via ISP A sturen.

Er zijn drie mogelijkheden.
1) Je vraagt Provider Independant adressen aan. Je krijgt dan bv 199.199.1/24. En laat die door zowel A als B adverteren.
2) Je neemt 123.123.1/24. Maar dan moet je ISP B vragen om het ook te adverteren. Note: omdat een /24 korter is dan een /16, zal iedereen je traffic via ISP B sturen. Dus moet ISP jouw /24 ook adverteren. ISP A zal dus 123.123/16 *en* 123.123.1/24 adverteren. Overlappend.
3) Gespiegeld case, waar je 123.124.1/24 gebruikt.

Je ziet, voor iedere klant die mult-homed wil zijn, moet je een extra prefix adverteren. Anderen kunnen die niet zomaar voor je summarizen, want breekt je multi-homing. Dit is een van de redenen dat je nooit perfecte summarization kunt gebruiken.

Redundant routes droppen ? Je bedoelt langere prefixes ? Misschien doen ze dat wel. Het hele probleem is dan dat verschillende routers verschillende kijk op de topologie hebben. En pakketjes op verschillende manier doorsturen. En dat geeft routing loops. En daarom komen pakketjes niet meer op de bestemming aan.

[Reactie gewijzigd door Verwijderd op 30 juli 2024 02:14]

[MSalters]

Mijn punt is dat in mogelijkheid 1 (PI adres) er 2 routes geadverteerd worden, en blijkbaar ook door de Cisco's bewaard worden in de TCAM. Waarom bewaart Cisco beiden, als 1 genoeg is? BGP zal uiteraard beiden moeten adverteren voor redundancy, maar je router moet de BGP messages soweso vertalen naar een TCAM tabel. Waarom wordt er in die stap niet ontdubbeld?

[Verwijderd]

Ik snap je vraag niet helemaal.

Stel een ISP adverteert 1 prefix. 123.123/16.
Stel die ISP heeft 20 multi-homed klanten, die ieder een /24 krijgen.
Die ISP zal dan 21 prefixes moeten adverteren.
En er zullen dan 21 prefixes in overal in de BGP-RIB komen, en overal in de FIB en TCAM.

Natuurlijk zou je kunnen optimaliseren.
Als 123.123/16 en 123.123.1/24 en 123.123.2/24 etc etc allemaal naar dezelfde next-hop wijzen, dan kun je alle /24s weglaten. En heb je maar 1 prefix in de TCAM nodig inderdaad.

Maar dat vergt bewerking van alle prefixes als je entries uit de RIB in de FIB stopt. En dat is niet triviaal. Het kan. Ik heb het met eigen ogen gezien. (De BGP developers van Procket hebben dit geimplementeerd. De BGP implementatie van Procket leeft voort in NX-OS). De vraag is of cisco dat idee ook in andere OSs (classic IOS, IOS XR, CataOS, etc) heeft geimplenteerd. Het lijkt er op van niet.

[MSalters]

"21 prefixes in overal in de BGP-RIB komen, en overal in de FIB en TCAM."

Dat zegt iedereen dus, maar waarom? Als die prefix al in de TCAM staat (onder een andere ISP), waarom zou je die prefix dan nog eens toevoegen?

Het mergen van routes is vanzelfsprekend, maar dat is niet wat ik bedoel. Ik bedoel dat je niet "123.123.001 /24" in de TCAM zet als "123.123.001 /24" er al in stond (multi-homed via een andere ISP).

[WhatsappHack]

Ja soort van, in BGP heet het Aggregation. Niet helemaal hetzelfde proces, maar goed vergelijkbaar.
Er wordt aardig veel gebruik van gemaakt; maar het is niet altijd even handig...
Dat de huidige BGP tabellen zo groot zijn heeft in eerste instantie te maken met een enorme groei in het internet, maar ook met slordigheid/laksheid en een aantal onervaren partijen. Het kan wat efficienter.

[Reactie gewijzigd door WhatsappHack op 30 juli 2024 02:14]

[atillav]

Zoals ik het nu lees moet je een afweging maken tussen het totale geheugengebruik en dit heel specifieke. Als er nu geen goede balans meer te maken is in zo'n router, wat zijn nog de opties? Kan je extra geheugen bijplaatsten of praten we dan wel over extra routers. Want dan snap ik de wat trage actie om dit probleem op te lossen. Het is dan een geldprobleem geworden.

[Verwijderd]

Zoals ik het nu lees moet je een afweging maken tussen het totale geheugengebruik en dit heel specifieke.

Het "normale geheugen" en TCAM zijn twee heel andere soorten geheugen. Die ergens anders in de router zitten De route-processor is net een gewone computer, met een CPU en RAM. Dat is het brein. De linecards doen de packet-forwarding. Daar zit TCAM geheugen, om snel bestemmingen op te kunnen zoeken.

Kan je extra geheugen bijplaatsten of praten we dan wel over extra routers.

Typisch hebben routers RAM dat vast zit gesoldeerd. Misschien dat er tegenwoordig meer high-end routers zijn waar je geheugen bij kunt plaatsen. TCAM zit altijd vastgesoldeerd op de linecards. Normaal gesproken zal je je linecards moeten vervangen om meer TCAM te krijgen.

[atillav]

Dus ultieme oplossing is (die linecards vervangen) investeren, want ze zullen niet gratis zijn?

[Bl@ckbird]

Bij oudere Cisco 6500 switches moet je met een commando aangeven hoeveel ruimte van het TCAM memory gebruikt wordt voor IPv4 en hoeveel voor IPv6. (Standaard zijn dit 512k routes) Heb je een 6500 met een recente supervisor 2T dan wordt dit dynamisch gedaan.

[Wampa1]

Gaat dit probleem trouwens niet alleen maar groter worden met IPv6 straks weidelijk geïmplementeerd? Met NAT op dit moment kan ik me voorstellen dat entries al aardig worden gereduceerd, maar kan er naast zitten.

[hackerhater]

Nee bij IPv6 gaat dit probleem juist flink kleiner worden.
Gezien de blokken van IPv6 veel logischer ingedeeld zijn.

Je hoeft niet meer alle netwerkjes meer bij te houden, maar je eigen land + blokken per land.

[Reactie gewijzigd door hackerhater op 30 juli 2024 02:14]

[Verwijderd]

Nee bij IPv6 gaat dit probleem juist flink kleiner worden.

Dream on.

Zoek eens op hoe het werkt als je je bedrijf via twee ISPs met het Internet wilt verbinden. Zgn multi-homing. Je krijgt een prefix in de global routing tabel voor ieder bedrijf (of instelling) dat zich robust wil verbinden aan het Internet. Dat werkt precies hetzelfde met IPv6 als met IPv4. De grote van de global routing tabel zal dus afhangen van hoeveel bedrijven (prefixes) multi-homed willen zijn. En imho zal dat aantal alleen maar groeien.

[hackerhater]

Gezien de blokken straks geografisch ingedeeld zijn.
Waarom zouden de core-routers van andere landen meer moeten weten van die blokken dan welk block bij welk land hoort?

Zelfs voor bedrijven met 2 ISP's. Die vallen nog altijd onder hetzelfde land-block

[Verwijderd]

Het Internet heeft zijn eigen topologie. Die moet je via routing weergeven. Dat heeft helemaal niks met geographie te maken. Hoe jouw pakketjes van UPC via provider 1, provider 2, provider 3 bij de bestemming komen hangt af van policy. Van wie er wie betaalt. Routing via BGP is geen RIP of ISIS of OSPF, waar je even de kortste weg zoekt.

Stel je stuurt iets naar Australie. Australie heeft 1 prefix. En er zijn 10 lijnen die er naar toe lopen. Via welke lijn stuur je het ? Met 1 prefix in je RIB weet je het niet. Maar die lijnen worden allemaal door andere ISPs betaalt. Het is belangrijk dat je de lijn kiest die betaalt wordt door jouw bestemming. Daarvoor moet je deaggrereren.

Jou summarization zal moeten gebeuren aan de grenzen van een land. Maar er zijn genoeg netwerken die niet netjes binnen een land vallen. Internationale bedrijven. En netwerken die over een heel continent lopen. Of meerdere continenten.

Adressen zijn locators. Ze geven aan waar iets is. Hoe je er moet komen.
De meeste mensen denken aan adressen als identifiers. Wie iemand is. Als de identifier maar uniek is, is het goed. Identifiers kun je hierarchish uitdelen. Maar locators moeten worden uitgedeeld naar de hand van de toplogie van een netwerk. Als de toplogie veranderd, moeten adressen ook worden veranderd. IPv6 heeft niks extras om dit mogelijk te maken. Helaas.

[hackerhater]

Klopt, maar het is dan een heel stuk minder versnipperd dan IPv4 nu is.
Een IP-range die bij west-europa hoort zal niet ineens verwijzen naar z-amerika.

[WhatsappHack]

Ik heb echt, en dat is best triest , behoorlijk weinig ervaring met grootschalige IPv6 routeringen. Ondanks de IPv4 depletie ben ik nog niet echt genoodzaakt geweest me er in te verdiepen; eigenlijk ben ik er dus "zo een" die te lang wacht met IPv6, wellicht. Enfin;

Maar als ik dat zo lees wat je zegt, en ik bedenk hoe BGP werkt... Als alles in zoveel geagreggeerde routes staat: wordt het dan niet een stuk makkelijker om valse routes te adverteren waarmee je dus veel grotere blokken kan verkrachten totdat het opgelost wordt?
BGP injecties hebben we al vaker gezien, vaak door medewerkers van de ISP's die het slechte pad op gaan of door achterlijk slechte beveiliging, maar als er dus enorme blokken opeens in 1 route gepropt worden: dan lijkt het me makkelijker te misbruiken, niet?

[TheKmork]

Hoewel het strictly speaking mogelijk is hebben de meeste grote ISPs sowieso filtering om BGP injecties tegen te gaan (ze staan bijvoorbeeld alleen toe dat je prefixes adverteert die volgens RIPE/RADB/etc aan jou toe behoren). Daarnaast is men druk bezig met de implementatie van beveiligingsfeatures zoals rPKI om dit soort injecties nog weer moeilijker te maken.
Dit is verder niet IPv6 specifiek maar ook voor IPv4 uiteraard, maar wat ik hiermee wil uitdragen is dat men volop bezig is om dit tegen te gaan.

Dat wil natuurlijk niet zeggen dat het onmogelijk wordt, en op zich heb je gelijk dat men hierdoor makkelijker grote blokken IPs kunnen kapen omdat de prefixes ook groter worden, maar aan de andere kant wordt de adressering ook enigszins eenvoudiger, dus is het ook wat eenvoudiger om de benodigde filters te installeren op je peerings/klanten om te voorkomen dat die "illegale" prefixes (die niet aan ze toebehoren) adverteren.

[yeadder]

Ik zie een overeenkomst met de Millennium bug.

Jammer dat deze voorspelbare limieten tot problemen leiden.
Wat dat betreft zou de ICT sector nog iets kunnen leren van de productie industrie.

[Verwijderd]

Ik zie een overeenkomst met de Millennium bug.

Er is juist geen overeenkomst.

De Millennium bug was een hoop hype. En er gebeurde niks.
Hier was men relatief stil over. Maar er was juist wel impact die te merken viel.

[Verwijderd]

De Millennium bug was een hoop hype. En er gebeurde niks.

Gek dan toch dat zoveel programmeurs het er zo druk mee hebben gehad.

Er is (bijna) niks gebeurt omdat het eindelijk eens wel serieus werd genomen. Het daarom hype noemen is wat kortzichtig.

[MSalters]

Precies, en als de netwerkbeheerders vorige week net zo proactief waren geweest als de programmeurs in 1999, dan was dit ook een non-event geweest.

Dit is overigens niet de eerste keer dat we zoiets hadden. Bij het overschrijden van de 64K routes schijnt er ook een aantal routers vervangen te zijn. Maar dat gebeurde wel op tijd.

[frickY]

Cisco heeft voor zover mij is verteld pas recent een patch warning uitgegeven, en niet eens als zijnde kritiek.
Er waren geen aanwijzingen dat de 510k grens op zeer korte termijn overschreven zou gaan worden.. Veel partijen hadden het onderhoudsmoment ergens in de komende weken geplant staan.
Tot er een partij besloot eens een berg nieuwe routeringen toe te voegen en het vroegtijdig mis ging.

Hebben er hier van 09:51 tot omstreeks 11:20 last van gehad.

[Reactie gewijzigd door frickY op 30 juli 2024 02:14]

[Barreljan]

Patch ? Dat is een gewoon setting die al jaren in de boeken staat hoor

Maar zover ik weet is het al van te voren aan zien komen, zeker weten. De full-routing tabel zit al geruime tijd over de 500k. Dus je kan, als je regelmatig even kijkt (sho ip bgp op cisco) en de eerste 5 regels even leest dan kan je een inschatting maken. Elke maand even kijken en bijhouden. Bij mijn werk hebben we het ook gedaan en zo keurig op tijd de boel vervangen (502k) en als ik nu kijk (2 maanden verder) zie ik de tabel op de nieuwe routers regelmatig de 515k aanraken.