10
Der "768k-Day" kommt
Für Leute, die Router mit BGP-Fulltable betreiben vielleicht ein interessanter Hinweis:
Die IPv4-Fulltable erreicht voraussichtlich innerhalb der nächsten 2-3 Monate die magische Größe von 786.432 Routen.
Warum ist diese Grenze "magisch"?
Wenn per BGP Routen empfangen werden, werden diese normalerweise erstmal in den RAM geladen. Der ist zwar vergleichsweise langsam, dafür hat so ein halbwegs moderner Router reichlich davon - in der Regel irgendwas um 2-4 GB. Da passen dann auch die Routen von mehreren BGP-Upstreams hinein.
Dann geht der Router alle diese Routen durch, errechnet die besten Pfade und schreibt diese errechneten Informationen in das (T)CAM.
Das CAM ist speziell dafür optimiert, die Routinginformationen zu speichern. Darin können superschnell die Informationen abgerufen werden, allerdings ist dieser Platz teuer und auch sehr begrenzt.
Während im RAM problemlos zig Millionen Routinginformationen Platz finden, ist im CAM häufig nur Platz für maximal 1.000.000 Routen - und das ist nur bei den wirklich fetten Routern so.
Kleine Router, die nicht dafür konzipiert sind irgendwelche Fulltables aufzunehmen, bieten meistens nur Platz für weniger als 2.000 Routen.
Jedenfalls muss dieser Platz sinnvoll genutzt werden, daher hat Cisco eine Zeit lang seine Router mit der Voreinstellung ausgeliefert:
Ja, wir haben Platz im TCAM für 1.000.000 Routen - aber der wird partitioniert für 512k IPv4-Routen und 256k IPv6-Routen.
Dann kam es am 12. August 2014 zum 512k-Day: Die Routingtabelle überstieg die Anzahl von 512.000 IPv4-Routen und die so partitionierten CAMs konnten keine weiteren Routen mehr aufnehmen.
Was dann passiert hängt maßgeblich von der Firmware des Routers ab. Einige weigerten sich, weitere Routen aufzunehmen. Einige fingen an Software-Forwarding auf der normalen CPU zu machen (was gruselig langsam ist), andere hatten für dieses Szenario offenbar überhaupt keine Lösung und crashten.
Kurz: Das war an dem Tag sehr, sehr ruckelig im gesamten Internet.
Stand Jetzt (24.04.) stehen wir bei 746.823 IPv4-Routen in der Fulltable, bei steigender Tendenz.
Es wird so insgesamt erwartet, dass innerhalb der nächsten Monate die magische 786k-Grenze erreicht ist - was aber vermutlich hauptsächlich auf der Annahme basiert, dass die Anzahl der Routen so steigt wie in den letzten paar Wochen. Allerdings kommt es immer wieder mal vor, dass ziemlich ruckartig eine große Zahl IPv4-Routen ins Internet gespült wird. Meistens sind das irgendwelche Provider, die IPv4-Adressen regional anders sortieren und deshalb z.B. ein /18-Präfix nicht als eine einzige Route ins Internet advertisen sondern daraus viele kleine /24-Präfixe bilden. So werden aus einer Route dann 64 Routen.
Trivia zum "512k-Day" vom August 2014:
Cisco hatte damals einen Workaround veröffentlicht, wie man kurzfristig das TCAM umpartitionieren kann.
Da wurde die Partitionierung dahingehend geändert, dass man statt 512k IPv4-Routen nun 768k Routen speichern kann - daher auch die neue "magische" Grenze bei 768k.
Aber da man Speicher nicht einfach so erschaffen kann, leidet bei der Umpartitionierung der Speicher für IPv6-Routen. Dieser ist nach dieser Konfiguration auf 120k Routen begrenzt.
Das reicht momentan noch aus (aktuell ca. 88.000 IPv6-Präfixe in der Fulltable) und es wächst auch nicht so stark an wie bei IPv4, deshalb war das tatsächlich eine gute kurzfristige Lösung.
Aber Jetzt hat man auf diesen Routern eigentlich kaum mehr Spielraum das CAM umzupartitionieren, ohne Konnektivität auf einer Adressfamilie zu verlieren
Die IPv4-Fulltable erreicht voraussichtlich innerhalb der nächsten 2-3 Monate die magische Größe von 786.432 Routen.
Warum ist diese Grenze "magisch"?
Wenn per BGP Routen empfangen werden, werden diese normalerweise erstmal in den RAM geladen. Der ist zwar vergleichsweise langsam, dafür hat so ein halbwegs moderner Router reichlich davon - in der Regel irgendwas um 2-4 GB. Da passen dann auch die Routen von mehreren BGP-Upstreams hinein.
Dann geht der Router alle diese Routen durch, errechnet die besten Pfade und schreibt diese errechneten Informationen in das (T)CAM.
Das CAM ist speziell dafür optimiert, die Routinginformationen zu speichern. Darin können superschnell die Informationen abgerufen werden, allerdings ist dieser Platz teuer und auch sehr begrenzt.
Während im RAM problemlos zig Millionen Routinginformationen Platz finden, ist im CAM häufig nur Platz für maximal 1.000.000 Routen - und das ist nur bei den wirklich fetten Routern so.
Kleine Router, die nicht dafür konzipiert sind irgendwelche Fulltables aufzunehmen, bieten meistens nur Platz für weniger als 2.000 Routen.
Jedenfalls muss dieser Platz sinnvoll genutzt werden, daher hat Cisco eine Zeit lang seine Router mit der Voreinstellung ausgeliefert:
Ja, wir haben Platz im TCAM für 1.000.000 Routen - aber der wird partitioniert für 512k IPv4-Routen und 256k IPv6-Routen.
Dann kam es am 12. August 2014 zum 512k-Day: Die Routingtabelle überstieg die Anzahl von 512.000 IPv4-Routen und die so partitionierten CAMs konnten keine weiteren Routen mehr aufnehmen.
Was dann passiert hängt maßgeblich von der Firmware des Routers ab. Einige weigerten sich, weitere Routen aufzunehmen. Einige fingen an Software-Forwarding auf der normalen CPU zu machen (was gruselig langsam ist), andere hatten für dieses Szenario offenbar überhaupt keine Lösung und crashten.
Kurz: Das war an dem Tag sehr, sehr ruckelig im gesamten Internet.
Stand Jetzt (24.04.) stehen wir bei 746.823 IPv4-Routen in der Fulltable, bei steigender Tendenz.
Es wird so insgesamt erwartet, dass innerhalb der nächsten Monate die magische 786k-Grenze erreicht ist - was aber vermutlich hauptsächlich auf der Annahme basiert, dass die Anzahl der Routen so steigt wie in den letzten paar Wochen. Allerdings kommt es immer wieder mal vor, dass ziemlich ruckartig eine große Zahl IPv4-Routen ins Internet gespült wird. Meistens sind das irgendwelche Provider, die IPv4-Adressen regional anders sortieren und deshalb z.B. ein /18-Präfix nicht als eine einzige Route ins Internet advertisen sondern daraus viele kleine /24-Präfixe bilden. So werden aus einer Route dann 64 Routen.
Trivia zum "512k-Day" vom August 2014:
Cisco hatte damals einen Workaround veröffentlicht, wie man kurzfristig das TCAM umpartitionieren kann.
Da wurde die Partitionierung dahingehend geändert, dass man statt 512k IPv4-Routen nun 768k Routen speichern kann - daher auch die neue "magische" Grenze bei 768k.
Aber da man Speicher nicht einfach so erschaffen kann, leidet bei der Umpartitionierung der Speicher für IPv6-Routen. Dieser ist nach dieser Konfiguration auf 120k Routen begrenzt.
Das reicht momentan noch aus (aktuell ca. 88.000 IPv6-Präfixe in der Fulltable) und es wächst auch nicht so stark an wie bei IPv4, deshalb war das tatsächlich eine gute kurzfristige Lösung.
Aber Jetzt hat man auf diesen Routern eigentlich kaum mehr Spielraum das CAM umzupartitionieren, ohne Konnektivität auf einer Adressfamilie zu verlieren
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 443636
Url: https://administrator.de/knowledge/der-768k-day-kommt-443636.html
Ausgedruckt am: 21.12.2024 um 14:12 Uhr
10 Kommentare
Neuester Kommentar
Moin,
Wer y2k überlebt hat, wird auch das durchstehen.
lks
Wer y2k überlebt hat, wird auch das durchstehen.
lks
Wird Zeit das LISP eingeführt wird
Habe damit zwar nichts zu tun, aber deine Beschreibung finde ich gut
Wieder was gelernt!
Danke!
Wieder was gelernt!
Danke!
Habe damit zwar nichts zu tun
Stimmt ja nicht ganz. Spätestens wenn dein Provider das vergessen oder ignoriert hat und du mit einmal kein Internet mehr hast weil die Routen fehlen, dann schon... 
Danke - dafür bin ich im Büro berüchtigt, auch und besonders bei den Berichtsheft-Pflichtigen Azubis
"Orrr, jetzt greift der Dicke wieder zum Duden, komm wir gehen besser wieder"
Auf dem Foto oben siehst du aber rank und schlank aus ! 
Und vor allem ist da kein Bart
Update dazu:
Das RIPE stellt fest, dass mit 768k wohl eher nicht 768.000 sondern vielmehr 1024 * 786 =786.432 Routen gemeint ist.
Zudem ist dieser magische Schwellwert bei einigen ganz wenigen Route-Collectors, von denen sie Daten erhalten, bereits knapp überschritten.
Dass die Fulltable an einigen Stellen im Internet ein bisschen voller ist als anderswo liegt übrigens daran, dass manche Provider bestimmte Routen nur an Internet-Exchanges (wie DECIX oder AMSIX) veröffentlichen, nicht aber an Transit-Carrier wie Telekom, Level3 oder Cogent.
Diese Routen tauchen deshalb nicht überall auf sondern nur an diesen Internet-Exchanges und werden normalerweise auch nicht weitergegeben.
Die Deutsche Glasfaser machte z.B. eine Zeit lang den Stunt, dass sie ein /20-Präfix an den Internet-Exchanges als zwei /21-Präfixe advertised. An die anderen Carrier wurde nur die /20-Route weitergegeben.
Damit wird quasi erzwungen, dass Traffic von ebenfalls an diesem Internet-Exchange angeschlossenen Providern in jedem Fall über diesen IX läuft und nicht anderswo her. Die /21-Route ist ja schlicht einfach spezifischer als die /20-Route über Cogent (oder wen auch immer).
Das RIPE stellt fest, dass mit 768k wohl eher nicht 768.000 sondern vielmehr 1024 * 786 =786.432 Routen gemeint ist.
Zudem ist dieser magische Schwellwert bei einigen ganz wenigen Route-Collectors, von denen sie Daten erhalten, bereits knapp überschritten.
Dass die Fulltable an einigen Stellen im Internet ein bisschen voller ist als anderswo liegt übrigens daran, dass manche Provider bestimmte Routen nur an Internet-Exchanges (wie DECIX oder AMSIX) veröffentlichen, nicht aber an Transit-Carrier wie Telekom, Level3 oder Cogent.
Diese Routen tauchen deshalb nicht überall auf sondern nur an diesen Internet-Exchanges und werden normalerweise auch nicht weitergegeben.
Die Deutsche Glasfaser machte z.B. eine Zeit lang den Stunt, dass sie ein /20-Präfix an den Internet-Exchanges als zwei /21-Präfixe advertised. An die anderen Carrier wurde nur die /20-Route weitergegeben.
Damit wird quasi erzwungen, dass Traffic von ebenfalls an diesem Internet-Exchange angeschlossenen Providern in jedem Fall über diesen IX läuft und nicht anderswo her. Die /21-Route ist ja schlicht einfach spezifischer als die /20-Route über Cogent (oder wen auch immer).
tja solche Problem hat nur wer nen Router im Decix stehen hat... oder einen neuen IX für ein neues Land aufbauen möchte. Wobei der Bedarf da eher gering wäre. Schottland wäre ein Kandidat dafür, der Südsudan oder Neuwerk erklärt sich für unabhängig um endlich das .NEW zu kriegen.
Nein, dem ist nicht so und zeigt eher das du das BGP Protokoll und Peering nicht wirklich verstanden hast. Jeder der eine Full Table laden muss, egal wo der Router steht, und einen festen (eingelöteten) Speicher hat, hat dieses Problem.
Viele weichen deshalb auf Software Lösungen aus wie Quagga oder Bird auf einem normalen Intel Rechner um Full Tables lokal vorzuhalten und den Speicherproblemen so aus dem Wege zu gehen.
https://www.de-cix.net/de/locations/germany/frankfurt/routeserver-guide
("Route Server Setup")
Viele weichen deshalb auf Software Lösungen aus wie Quagga oder Bird auf einem normalen Intel Rechner um Full Tables lokal vorzuhalten und den Speicherproblemen so aus dem Wege zu gehen.
https://www.de-cix.net/de/locations/germany/frankfurt/routeserver-guide
("Route Server Setup")
