skalowanie sieci IP część 2 – wirtualna agregacja

Jak wspomniałem w części pierwszej tej serii, eleganckie projekty – w szczególności te dotyczące sieci IP, charakteryzuje prostota, ale i skalowalność. Na limity skalowalności trafiamy najczęściej (i najszybciej) docierając do dwóch ograniczeń sprzętowych – szybkości procesorów pracujących jako RP oraz zasobów sprzętowych do przechowywania FIBu (i rzadziej – RIBu).

Jedną z klas rozwiązań zapobiegających, lub odsuwających daleko w czasie trafienie w te ograniczenia jest zastosowanie mechanizmów mających na celu ograniczenie zakresu i wielkości pul adresowych używanych w naszej sieci przez agregację tej adresacji w specjalny sposób.

Agregacja adresacji

Pierwszym – i chyba najprostszym – ciekawym rozwiązaniem problemu różnej pojemności tablic routingu na urządzeniach jest wydzielenie węzłów, które przechowywać będą pełne tablice i tych, które przechowywać będą tylko tablice częściowe. Aby taki mechanizm mógł zadziałać poprawnie, należy zapewnić oczywiście informacje routingowe ogólniejsze – czyli w warunkach praktycznych, odpowiednią dystrybucję albo tras domyślnych, albo tras zagregowanych – wskazujących zwykle z routerów dostępowych na routery szkieletowe lub agregacyjne.

Prosta Wirtualna Agregacja – S-VA

Rozwiązanie zaproponowane m.in. przez naszego rodaka – Roberta Raszuka (pozdrawiamy!) polega na rozgłoszeniu wewnątrz systemu autonomicznego prefiksu będącego agregacją wielu dokładniejszych – pod warunkiem, że wskazują na ten sam next-hop. Powoduje to, że w wielu scenariuszach, zamiast przechowywać setki czy tysiące prefiksów, urządzenie może przechowywać jeden – i nadal realizować politykę routingu uznawaną za optymalną.

W pewnym uproszczeniu to cała koncepcja wirtualnej agregacji. Spójrzmy na poniższy rysunek:

Optymalizacja routingu - topologia scenariusza

Optymalizacja routingu – topologia scenariusza

Routery dostępowe (PE3, ale i PE1 czy PE2) wcale nie muszą posiadać pełnej tablicy – wystarczy, że posiadają trasę domyślną wskazującą na router szkieletowy oraz zagregowane prefiksy obejmujące całość rozgłaszanych przez nich prefiksów wskazujące na swoich dwóch sąsiadów.

Wyobraźmy sobie zatem, że router szkieletowy (ISP-EDGE) posiada pełną tablicę routingu – 580k prefiksów IPv4, a routery PE1 i PE2 po 500 prefiksów. Router PE3 również, dla równego rachunku, ma swoje 500 prefiksów z lokalnie podłączonych sieci.

Router PE3 instalując z RIB do FIB zagregowane prefiksy – odpowiednio PF1 (trasa domyślna od routera szkieletowego), PF2 (wszyskie 500 prefiksów via PE1) oraz PF3 (wszystkie 500 prefiksów przez PE2) de facto ogranicza ilość wymaganej ilości pamięci FIB do trzech prefiksów bez spadku dokładności routingu!

Oczywiście tak ekstremalne uproszczenie routingu daje się uzyskać tylko wtedy, gdy prefiksy nie nachodzą na siebie i dają się zagregować bez utraty dokładności routingu. W rzeczywistości może się okazać, że zagregowanych prefiksów będzie więcej, choć i tak być może uda się uzyskać oszczędności.

W rozwiązaniu opisanym w RFC 6769 S-VA, prefiks “agregujący” rozgłasza dodatkowo router szkieletowy oraz każdy z pozostałych routerów PE – PE1 i PE2.

Warto zwrócić uwagę na to, że RFC 6769 jest zgodnie ze swoją nazwą – prostą wersją bardziej ogólnego schematu agregacji prefiksów w sieci, stworzonego przez podobny zespół w ramach prac grupy roboczej GROW w IETFie.

Ten szkic był jednak trochę bardziej skomplikowany – zakładał, że każdy z routerów agregujących prefiks (w naszej topologii router szkieletowy oraz każdy z PE) tworzyć będzie tunel do pola NEXT_HOP z protokołu BGP. O ile zapewniłoby to większą elastyczność całego rozwiązania, pojawił się w trakcie dyskusji na różnego rodzaju forach problem tworzenia i utrzymania tych tuneli (dyskutowano tunele MPLS LSP, ale oczywiście można by również użyć praktycznie dowolnych innych – choćby i GRE). Ponieważ schemat uznano za bardziej skomplikowany i wymagający więcej pracy, przerodził się w prostszą wersję opisaną potem w RFC (oraz powyżej).

Rozwiązanie opisane w szkicu VA, zgodnie z moją wiedzą, nie jest obecnie wspierane przez żadnego producenta ani oprogramowanie, ale rozwiązanie z RFC 6769 wdrożyć można praktycznie wszędzie, gdzie da się wpływać na sposób rozgłaszania prefiksów przez BGP (rozgłaszać agregaty, pomijając rozgłaszanie tras dokładniejszych) oraz (jako uzupełnienie) odfiltrowywać prefiksy pomiędzy tablicą RIB a FIB.

W następnym odcinku serii zajmiemy się LISPem (nie, nie tym językiem programowania).

Linki

Facebooktwittergoogle_plusredditpinterestlinkedinmail