skalowanie sieci IP #1

Jedną z dobrych praktyk w budowie rozwiązań sieciowych jest elegancki i skalowany projekt. Oznacza to możliwość łatwej rozbudowy sieci, przebudowy jej i modyfikacji, bez konieczności modyfikacji całości projektu czy niepotrzebnego obciążania urządzeń. Eleganckie i skalowalne projekty żyją latami bez katastrof, niespodzianek a czasem nawet potrafią dać sobie radę z błędami popełnianymi przez operatorów, czy wynikłymi z usterek w oprogramowaniu.

Jednym z tematów którymi chciałbym się w tym artykule zająć jest skalowalność tablic routingu. “Siłowe” podejście stosowane tam, gdzie nie liczymy się z zajętością pamięci i mocą obliczeniową procesorów (często z opłakanymi skutkami) mówi, że urządzenie sieciowe (w ogólności) powinno dać sobie radę z dowolną ilością pełnych tablic – jakkolwiek zdefiniujemy owe “pełne tablice” w naszych warunkach.

Problemem jest jak zwykle rzeczywistość. O ile RIB, czyli Routing Information Base, przechowywana w pamięci zwykle daje sobie radę z przechowaniem prefiksów (dzisiejsze platformy na których realizujemy routing mają zwykle raczej 1-4GB niż 16-64MB – choć nie zawsze, o czym potem), o tyle FIB, czyli Forwarding Information Base, nie zawsze jest tak elastyczny. RIB utrzymywany jest bowiem w pamięci ogólnego przeznaczenia – taniej, możliwej do skalowania razem z rozwojem platformy. FIB natomiast, na urządzeniach przetwarzających ruch sprzętowo, jest zwykle ograniczony z uwagi na specjalne rodzaje pamięci wykorzystywane do jego utrzymania. I nie chodzi tylko o TCAMy stosowane z lubością przez Cisco w Catalystach 6500, routerach 7600, ale również o pamięci typu SRAM czy RLDRAM. Wynika to z wielu powodów – czasu dostępu do poszczególnych komórek pamięci, możliwości realizowania równoległych zapytań o prefiks, łatwości oprogramowania oraz oczywiście możliwości umieszczenia pamięci na kartach liniowych w odległości umożliwiającej wykorzystanie ich większej szybkości przez podsystem realizujący obróbkę ruchu.

Co więcej, nawet jeśli pojemność tablicy FIB jest wystarczająca do dzisiejszych zastosowań, okazuje się, że jej programowanie nie jest natychmiastowe – różnice w prędkości programowania wpisów w FIB mogą doprowadzić nawet do mikropętli w naszej sieci. Opowiadał o tym wielokrotnie na PLNOGu Piotr.

Projektując sieć, w której routing będzie nam zapewniał maksymalną użyteczną dokładność na każdym węźle routującym musimy zatem wziąć pod uwagę rzeczywistość – różne platformy będą miały różne możliwości sprzętowe. I tak na przykład:

  • przełączniki klasy Enterprise, oraz Metro Ethernet, posiadają zwykle zasoby FIB pozwalające przechować od 8000 do 32000 wpisów dla IPv4;
  • routery dostępowe realizujące routing sprzętowo oraz routery agregacyjne, w tym te do sieci Metro Ethernet, posiadają zwykle FIB pozwalający przechować od 64k do 128-512k wpisów dla IPv4;
  • routery szkieletowe, brzegowe i peeringowe – są w stanie przechować od 1M do 2M, czasami 3-3.5M wpisów IPv4

Oczywiście nie zawsze wszędzie może stanąć router szkieletowy po to, aby obsłużyć pełną tablicę – poczynając od finansów, po takie drobiazgi jak chłodzenie czy miejsce na jego instalację.

W ciągu ostatnich lat zagadnienia tego typu były rozbierane wielokrotnie na części pierwsze i przedstawione rozwiązania można zgrupować następująco:

  • kompresujemy wpisy w FIB – pomysł nie całkiem pozbawiony sensu, ale niestety wykonanie pozostawia wiele do życzenia – nie ma niestety żadnej platformy (wg. mojej wiedzy), która realizuje kompresje FIBu bezbłędnie i bez różnego rodzaju mało przewidywalnych problemów – skutkujących bardzo trudnymi do rozwiązania problemami w sieci, pojawianiem się zapętlonego ruchu, znikaniem części ruchu czy w końcu awariami całego węzła sieciowego; rozwiązanie to z uwagi na jego jakość od razu skreślamy;
  • zastosujmy dodatkowe nagłówki/etykiety – obchodzimy w ogóle problem wielkości FIBu, ale urządzenie nie realizuje de facto routingu dla IP – zamiast tego realizuje switching; najpopularniejszym rozwiązaniem tego typu jest MPLS (używamy etykiet), a kolejnym – QinQ (używamy kolejnego VLANu);
  • zoptymalizujmy wykorzystanie przestrzeni adresowej – wydzielmy specjalne pule adresów na naszą infrastrukturę i dla niej trzymajmy adresy w FIB, następnie dla części ważnych prefiksów (i te również trzymajmy w FIB), pozostałe routujmy za pomocą adresacji infrastrukturalnej (rozwiązania wirtualnej agregacji oraz LISP); ta opcja wymaga starannego zaprojektowania/przeprojektowania sieci lub wdrożenie nowego protokołu
  • rozdzielmy RIB i FIB – rozdzielając prefiksy które trzymane są w RIB od tych, które trzymane są w FIB wchodzimy na pole minowe, ale jeśli poruszamy się z konkretnym pomysłem i dobrym projektem, może nam się udać :); rozwiązanie w zależności od zastosowanego sprzętu i producenta nazywa się różnie – choć szukając czegoś w okolicach ‘Selective RIB download‘ powinieneś natrafić na trop (jeśli w ogóle Twój dostawca to wspiera);

W kolejnych częściach artykułu zajmiemy się dwoma ostatnimi rozwiązaniami – pokażę ich zalety i wady, a także przykładowe implementacje.

Facebooktwittergoogle_plusredditpinterestlinkedinmail

2 thoughts on “skalowanie sieci IP #1

  • Stosowanie dodatkowych nagłówków i etykiet (np. MPLS) potrafi ograniczyć dostępne zasoby sprzętowe, co wymusza zastosowanie wspomnianego ‘Selective RIB download‘.

    • Zgadza się – choć to oczywiście zależy od konstrukcji urządzenia i jego typu. Generalnie, powiedziałbym że dodatkowe nagłówki (różnej postaci) można stosować i z i bez takich technik jak Selective RIB download, co oznacza, że zawsze należy spojrzeć na limity skalowalności wielowymiarowo.

Komentarze są niedostępne