Cisco IOS XE – esencja modularności i redundancji?

Dodaj komentarz | , autor: Damian Michalak

PODAJ TO

Cisco ma w swoim portfolio kilka różnych systemów operacyjnych skrojonych na potrzeby różnych obszarów technologicznych i zastosowań. NX-OS używany jest głównie w zastosowaniach Data Center na urządzeniach z serii Nexus (7K, 5K, 3K, 2K), a także na Cisco UCS. Z kolei IOS 15 jest systemem używanym głównie w komercyjnych urządzeniach Cisco z serii Enterprise. Właśnie jego należy opanować w stopniu eksperckim na potrzeby CCIE Routing & Switching. W portfolio Cisco znajduje się poza tym IOS XR używany w zastosowaniach Service Provider oraz IOS XE – modularny system operacyjny, który możemy znaleźć przykładowo w urządzeniach z serii ASR 1K, Cat 4500E/Sup7E, ASR 903. W dzisiejszym artykule postaram się nieco przybliżyć właśnie ten ostatni.

1. Porównanie IOS 15 i IOS XE

Poniższe cechy wyróżniają IOS 15:

  • jest to monolit, system w pełni zależny od platformy sprzętowej, nie oferujący żadnej izolacji pomiędzy procesami, zarówno z perspektywy pamięci jak i CPU
  • wirtualna pamięć jest współdzielona pomiędzy wszystkimi procesami – nic nas nie chroni przed przepełnieniem buforów
  • scheduler nie jest wywłaszczeniowy – przykładowo jesli SNMP zajmie 100% czasu procesora to skutecznie uniemożliwi działanie innych procesów (np. BGP)
  • nie da się zaktualizować IOSa (lub jego części) bez przerwy w dostarczaniu serwisu (wyjątkiem są drogie urządzenia z podwójnymi supervisorami)

IOS XE stoi w opozycji do powyżej wymienionych charakterystyk IOS 15. Dwiema głównymi zaletami IOS XE są:

  • modularność
  • dostępność/niezawodność (high-availability)

IOS XE składa się z tzw. consolidated package oraz z optional packages (paczki software’owe). Rdzeń systemu stanowi zbiór sub-packages, które razem tworzą consolidated package, natomiast optional packages, jak sama nazwa wskazuje, oferują wzbogacenie systemu o dodatkowe, opcjonalne funkcje. Consolidated package może być aktualizowany jako całość, ale można też aktualizować sub-packages indywidualnie.

ISO XE jest systemem zbudowanym na kernelu Linuksa, z interfejsem tradycyjnego IOSa. Wszystkie funkcje tradycyjnego IOSa są udostępniane przez daemon IOSD. W IOS XE można nawet uzyskać dostęp do interfejsu linuksowego za pomocą komendy request platform software system shell r0.

Architektura tego systemu pozwala uruchamiać takie funkcje jak Non Stop Forwarding (NSF) czy też In Service Software Upgrades (ISSU) – wymagają one jednak dużych ilości pamięci DRAM – w przypadku ASR 1K są to aż 4GB. IOS XE ponadto wspiera obsługę wielordzeniowych i wielowątkowych procesorów, pozwalając na skuteczny load-balancing procesów.

2. Rozproszony Control Plane

Jeśli mamy modularne chassis (a w przypadku IOS XE większość platformy sprzętowej jest modularna) to zapewne mamy dwa Route Processor’y (w formie line card’ów). Każdy RP będzie miał niezależnie uruchomione procesy. Route processor to nazwa control plane używana w terminologii IOS XE. Architektura IOS XE implementuje tak zwany distributed control plane. Control Plane w poszczególnych modułach jest nazywany inaczej i jest logicznie odseparowany. Route processory są redundatne i są głównym control plane’m. Moduły ESP implementują FECP czyli Forwarding Engine Control Plane, a moduły SPA implementują IOCP czyli Input Output Control Plane:

untitled-5

3. Consolidated Package i Optional Packages

Wyróżniamy siedem rodzajów sub-packages wchodzących w skład consolidated package:

  1. RPBase – route processor base – wyposaża Route Processor w wyspecjalizowany software do jego obsługi
  2. RPControl – wyposaża system w control plane będący interfejsem między OSem a resztą platformy
  3. RPAccess – umożliwia między innymi używanie SSH do ruchu managementowego
  4. RPIOS – paczka z IOS 15, który może być używany w IOS XE jako jeden z modułów
  5. ESPBase – ta paczka odpowiada za całą funkcjonalność związaną z przekazywaniem pakietów
  6. SIPBase – shared interface processor base – paczka odpowiedzialna za obsługę interfejsów w modułach
  7. SIPSPA – zawiera sterownik kart SPA (Shared Port Adaptor – moduły z interfejsami)

Sub-packages w zasadzie implementują pojedyncze procesy, które składają się na działanie systemu operacyjnego jako całości. Procesy te zostaną omówione w punkcie 5. Ze strony Cisco nie można pobrać pojedynczych sub-packages, można natomiast pobrać cały consolidated package a następnie wyodrębnić poszczególne moduły z poziomu CLI routera.

W tej chwili jest niewiele opcjonalnych pakietów, przykładem może jednak być Cisco Webex Node dla ASR 1K, który jest po prostu… pluginem webexowym 🙂

4. Provisioning file i ROMMON

Jeśli używamy całego consolidated package to urządzenie widzi je jako pojedynczy bootowalny obraz, z którego startowany jest system operacyjny. W przypadku gdy chcemy jednak uruchomić tylko wybrane pakiety, należy do bootowania użyć tzw. provisioning file, który uruchomi jedynie wybrane sub-packages. Ponadto ROMMON jest również osobnym pakietem software’owym, zatem musi być aktualizowany niezależnie od pozostałych paczek.

5. Procesy używane w IOS XE

Poniżej są wymienione jedynie kluczowe procesy, pełna lista jest znacznie dłuższa:

  • Chassis Manager – proces odpowiedzialny za zarządzanie chassis oraz udzielanie systemowi informacji na temat stanu redundancji na poziomie chassis
  • Logger – ten proces udostępnia funkcję logowania pozostałym procesom
  • IOS – implementowany przez paczkę RPIOS, proces odpowiedzialny za routing i forwarding, bazuje na IOS 15
  • Pluggable Services – ten proces jest odpowiedzialny za integrację takich funkcji jak uwierzytelnianie z systemem operacyjnym
  • SPA Driver – proces kontrolujący współdzielone interfejsy
  • Host Manager – udostępnia interfejs między IOSem i wieloma różnymi funkcjami zbierającymi informacje z kernela systemu
  • Interface Manager – proces odpowiedzialny za interakcję pozostałych procesów z interfejsami
  • Forwarding Manager – proces implementujący przekazywanie pakietów w modularnych kartach rozszerzeń
  • Shell Manager – implementuje cały interfejs użytkownika, moduł diagnostyczny w CLI itp.
  • CPP Driver/HA/SP – proces odpowiedzialny za control plane oraz high availability na poziomie software’u

6. Podsumowanie

Urządzenia wyposażone w IOS XE stanowią kuszącą alternatywę dla IOS 15 – oferują pełną redundancję zarówno na płaszczyźnie sprzętowej jak i programowej, ponadto ich modularność sprawia, że aktualizacja oprogramowania niekoniecznie musi oznaczać niedostępność urządzenia i przerwę w działaniu serwisu.

Osobiście jednak zastanawiam się nad tym jak może wyglądać przyszła polityka Cisco? Pełne zastąpienie IOS 15 przez IOS XE? Czy może współegzystencja obu systemów i obsługa dwóch różnych segmentów rynkowych przez nie? A jak Ty sądzisz? Podziel się opinią w komentarzach!

SPODOBAŁ CI SIĘ TEN ARTYKUŁ?
Dołącz do moich subskrybentów, a nie przegapisz kolejnych ciekawych artykułów!

Nie ujawnię nikomu Twojego adresu. Zero spamu.
Damian MichalakCisco IOS XE – esencja modularności i redundancji?