Co w sieci siedzi. Agregacja interfejsów

Transkrypt

1 1 (Pobrane z slow7.pl) Co w sieci siedzi. Agregacja interfejsów przełącznika. Dzięki połączeniu ze sobą portów uzyskujemy: zwiększona przepustowość łącza - wiele fizycznych łączy zagregowane w ramach jednej grupy poszerza dostępne pasmo. Oznacza to, że tworząc kanał EtherChannel prędkość utworzonego łącza jest sumą prędkości interfejsów fizycznych tworzących ten kanał. Jeśli do konfiguracji kanału zostało użytych 6 interfejsów FastEthernet łączna prędkość wyniesie 600 Mb/s. Założenie w swej koncepcji słuszne choć jak dowiesz się za chwilę nie oznacza to, że uzyskana rzeczywista prędkość przesyłu danych odpowiada zawsze przepustowość łącza. rozłożenie obciążenia - prowadzona komunikacja jest rozkładana na szereg łączy. Przy czym na uwadze należy mieć fakt iż pojedyncza sesja jest prowadzona z wykorzystaniem tylko jednego łącza. Rozłożenie obciążenia w przypadku agregacji łącza nie można traktować jako sposób przesłania pakietów tworzących jedną sesje poprzez różne fizyczne zagregowane łącza przełącznika. Wyobraź sobie Czytelniku autostradę, droga ta posiada szereg pasów prowadzących w jedną stronę. Autostrada pomieści większą liczbę samochodów lecz każdy z pojazdów porusza się jednym pasem. Wracając do przykładu z agregacją 6 interfejsów FastEthernet oznacza to, że pojedyncza sesja pomimo wykorzystania łącza o przepustowości 600 Mb/s będzie ograniczona do prędkości 100 Mb/s większa dostępność oraz redundancja - awaria łącza przypisanego do grupy nie powoduje wyłączenia grupy, ruch sieciowy nadal będzie przekazywany. Opis agregacji łącza przedstawię na urządzeniach firmy Cisco. Agregacja w terminologii Cisco jest określana jako EtherChannel i jest sposobem budowania grupy łączy pomiędzy przełącznikami Cisco. EtherChannel bazuje na standardzie 802.3ad, który później został przemianowany na standard 802.1ax opisujący agregację łączy. Według tego standardu agregacja łączy jest opisywana jako (źródło: Agregacja łączy umożliwia zagregowanie jednego łącza lub większej liczby łączy w celu utworzenia grupy agregacji łączy LAG (ang. link aggregation group) w taki sposób, że klient MAC może traktować tę grupę, jakby była pojedynczym łączem. W przypadku urządzeń CISCO grupę LAG możemy utworzyć jednym z trzech sposobów:

2 2 (Pobrane z slow7.pl) statyczny EtherChannel zwany też również jako mode on Sposób ten bazuje na ręcznej konfiguracji grupy LAG, dynamiczny EtherChannel - sposób ten polega na wykorzystaniu jednego z dwóch dostępnych protokołów pozwalających w sposób całkowicie automatyczny na utworzenie grupy LAG. Protokoły odpowiedzialne za konsolidację portów to LACP (ang. Link Aggregation Control Protocol) i PAgP (ang. Port Aggregation Protocol). Protokół PAgP jest autorskim rozwiązaniem firmy Cisco. Stosując metodę statyczną wymuszamy utworzenie kanału EtherChannel bez negocjacji (administrator konfigurację wykonuje samodzielnie) oznacza to, że żaden z protokołów nie jest wykorzystywany tak więc żadne pakiety nie są pomiędzy przełącznikami wymieniane. Wybranie tej metody spowoduje natychmiastowe utworzenie kanału nawet gdy w sąsiednim przełączniku interfejsy są skonfigurowane nieprawidłowo. W przypadku drugiego rozwiązania czyli dynamicznego tworzenia kanału jak już zostało wspomniane można wykorzystać jeden z protokołów - PAgP bądź LACP. Protokoły te dbają o prawidłową konfigurację tworzonego łącza. Użycie protokołów definiujemy w trybie konfiguracji interfejsu a do dyspozycji mamy następujące opcje: Protokół PAgP auto desirable Protokół LACP passive active Port pracujący w tym trybie samodzielnie nie inicjuje łącza, kanał zostaje utworzony pasywnie na zainicjowaną konfigurację. Port pracujący w trybie desirable aktywnie negocjuje utworzenie kanału. Port w sposób pasywny uczestniczy w procesie tworzenia łącza, negocjacja w tym trybie nie jest inicjonowana. Port pracujący w trybie active aktywnie negocjuje utworzenie kanału. Dociekliwy Czytelnik za pewnie zapyta - Który protokół wybrać? Jeśli masz do dyspozycji urządzenia firmy CISCO możesz postawić na protokół PAgP choć warto mieć na uwadze, że co nowsze urządzenia sieciowe tej firmy wsparcia dla tego rozwiązania są już pozbawione a zaś te starsze protokołu LACP nie obsługują. Jeśli korzystasz z urządzeń różnych producentów to wyboru nie masz i musisz zdecydować się na LACP. Na koniec jeszcze ogólna uwaga odnosząca się do konfiguracji interfejsów fizycznych, które będą wchodzić w skład łącza EtherChannel. Interfejsy mogą być skonfigurowane w trybie trunk lub jako access. Dodatkowo trzeba zadbać aby interfejsy fizyczne tworzące łącze miały konfigurację zgodną co do szybkości interfejsu oraz duplexu.

3 3 (Pobrane z slow7.pl) Połączenie logiczne działa tak długo jak długo aktywne jest przynajmniej jedno połączenie fizyczne. W trakcie opisu często będą pojawiać się terminy EtherChannel oraz Port Channel. W niektórej literaturze zdarza się, że terminy te są używane zamiennie choć tak naprawdę określają dwa różne pojęcia. Tak więc mianem EtherChannel będziemy określać logiczny kanał utworzony pomiędzy przełącznikami zaś Port Chanel jest to interfejs powstały na obu końcach przełączników tworzących kanał EtherChanel w skład którego wchodzą interfejsy fizyczne wykorzystane do utworzenia skonsolidowanego łącza. Nasze rozważania na temat konfiguracji EtherChannel przeprowadzimy z wykorzystaniem topologii zaprezentowanej na rysunku poniżej. Jak widać omówimy każdą z metod utworzenia kanału EtherChannel. Lecz zanim przejdziemy dalej jeszcze taka krótka dygresja na temat całego mechanizmu. Wykonanie połączeń pomiędzy przełącznikami jak w zaprezentowanej topologii powyżej nie pozostanie bez konsekwencji gdyż takie połączenie może doprowadzić do powstania pętli czego skutkiem będzie przesyłanie ramek w nieskończoność. Ramki te skutecznie spowodują zablokowanie normalnego ruchu sieciowego (należy pamiętać, że w przypadku warstwy drugiej nie ma zabezpieczeń takich jak występują w warstwie trzeciej - pole TTL). Brak zabezpieczeń wymusiło wprowadzenie innych mechanizmów, których zadaniem jest dbanie o prawidłowość funkcjonowania sieci. Takim mechanizmem jest m.in. protokół STP. Aby nie wchodzić zbytnio w szczegóły i sposób działania (protokół ten opisze wkrótce) to dodam tylko, iż zadaniem protokołu jest takie zarządzanie

4 4 (Pobrane z slow7.pl) łączami poprzez ich włączanie i wyłączanie aby nie doprowadzić do powstania pętli. Oczywiście topologie podobne do tej zaprezentowanej powyżej stosuje się aby zapewnić redundancję tak by zabezpieczyć się przed ewentualną awarią łącza a wspomniany protokół STP dba o prawidłowe działanie sieci. Aby sprawdzić konfigurację sieci z punktu widzenia protokołu STP należy wydać polecenie: show spanning-tree Po wydaniu polecenia na switchu SW2 i analizie uzyskanych wyników dochodzimy do wniosku iż przełącznik ten pełni funkcję root bridge (zarządza działaniem mechanizmu STP) i dlatego wszystkie interfejsy przełącznika mogą przekazywać dane. Wydanie tego samego polecenia np. na przełączniku SW1 dostarcza nam już inne informacje. Między innymi dowiadujemy się, że interfejs Fa0/2 jest w stanie blokowania. Interfejs ten tworzy połączenie z przełącznikiem SW2. Z przełącznikiem tym komunikacja odbywa się z wykorzystaniem interfejsu Fa0/1. Interfejs Fa0/2 przejdzie w stan przekazywania pakietów w momencie awarii łącza korzystającego z interfejsu Fa0/1

5 5 (Pobrane z slow7.pl) Całe te odejście od tematu wpisu doprowadza nas do następującego wniosku - a mianowicie pomimo zastosowania dodatkowych połączeń pomiędzy przełącznikami to i tak na wskutek działania protokołu STP do komunikacji jest wykorzystywane pojedyncze łącze. Drugie łącze wchodzi do gry tylko w przypadku awarii łącza podstawowego. Stwierdzenie te pozwala nam wysnuć drugi wniosek: czemu by nie wykorzystać zestawione połączenie w bardziej efektywny sposób skoro i tak jest nie użytkowane. I w tym momencie do gry wchodzi mechanizm Etherchannel - skoro mamy zapewniona komunikację z danym przełącznikiem poprzez różne interfejsy połączmy je w wspólny kanał transmisji. Fakt poszerzenia dostępnego pasma na pewno lepiej wpłynie na działanie naszej sieci niż utrzymywanie nieczynnego łącza. Dygresje tą pozostawiam do przemyśleń własnych a tym czasem przejdźmy dalej. Przełącznik SW1-SW3 EtherChannel protokół PAgP Rozpoczynamy od agregacji łącz pomiędzy przełącznikami SW1 a SW3. Zestawienie połączenia będzie realizowane z wykorzystaniem interfejsów f0/3 oraz f0/4 przełącznika SW1 oraz tych samych portów f0/3 oraz f0/4 przełącznika SW3. Agregacje łączy wykonamy z wykorzystaniem protokołu PAgP.

6 6 (Pobrane z slow7.pl) Aby utworzyć kanał EtherChannel w pierwszej kolejności przechodzimy do trybu konfiguracji portów. Aby wydawane polecenia dotyczyły zarówno portu f0/3 oraz f0/4 została wykorzystana opcja range. Aby utworzyć zagregowane łącze z wykorzystaniem protokołu PAgP należy wydać polecenie: channel-group <numer_grupy> mode desirable Numer grupy określamy indywidualnie ważne by numer ten był unikatowy w obrębie przełącznika. Oznacza to, że numer utworzonej grupy nie może zostać powtórzony (wykorzystany dwukrotnie). Zakres wartości do wykorzystania od 1 do 64. Zgodność numeru grupy na przełącznikach tworzących skonsolidowane łącze nie jest wymagane, choć oczywiście zaleca się aby wartość przyznana grupie była taka sama na obu przełącznikach takie podejście sprzyja przejrzystości konfiguracji. Wybranie trybu desirable spowoduje aktywne negocjowanie utworzenia kanału. Po wydaniu polecenia łącza wchodzą w skład nowego interfejsu logicznego: Port-channel 1 (Po1) Fakt utworzenia kanału EtherChannel możemy sprawdzić za pomocą komendy: show etherchannel Jak widać poniżej kanał LAG o identyfikatorze 1 korzystający z protokołu PAgP został utworzony. Fakt utworzenia kanału nie gwarantuje nam, że zbudowane w ten sposób łącze jest w stanie przekazywać ruch sieciowy. Aby sprawdzić w jakim stanie jest łącze EtherChannel można wykorzystać polecenie: show etherchannel summary Po wydaniu komendy w formie tabeli zostaną wyświetlone wszystkie interfejsy Port-Channel wraz z informacją o stanie interfejsu, sposobie utworzenia oraz interfejsach fizycznych tworzących grupę LAG.

7 7 (Pobrane z slow7.pl) Analiza uzyskanych danych wskazuje, że interfejs Po1 jest wyłączony (symbol D down). Jeszcze więcej informacji na temat utworzonego kanału oraz portów wchodzących w jego skład poznamy dzięki poleceniu: show etherchannel detail (polecenie omówimy trochę szerzej za chwilę, gdy uda nam się utworzyć działający kanał EtherChannel).

8 8 (Pobrane z slow7.pl) Status interfejsu Po1 możemy również sprawdzić za pomocą polecenia: show ip interfeces brief Jak można stwierdzić interfejs jest w stanie down (kanał nie został jeszcze skonfigurowany po drugiej stronie switch SW3).

9 9 (Pobrane z slow7.pl) Aby łącze EtherChannel mogło przekazywać ruch sieciowy należy je również skonfigurować na przełączniku SW3. Podobnie jak to było w przypadku switcha SW1 do konfiguracji łącza wykorzystamy przełącznik range. Po określeniu interfejsów, które wejdą w skład grupy LAG (interfejs f0/3 oraz f0/4) wydajemy polecenie: channel-group 1 mode auto Po wydaniu komendy interfejs łącza Port-channel 1 osiągnął status up. Oznacza to, że łącze LAG zostało włączone. Aby sprawdzić status kanału skorzystamy z znanego nam już polecenia: show etherchannel summary Po analizie uzyskanych wyników stwierdzamy, że interfejs Po1 działa (flaga U łącze w

10 10 (Pobrane z slow7.pl) użyciu). Jak już wiesz czytelniku jeszcze dokładniejsze wyniki stanu łącza oraz interfejsów fizycznych uzyskamy po wydaniu komendy: show etherchannel detail Gdy łącze działa prawidłowo i interfejs jest aktywny w wynikach polecenia pojawi się informacja o interfejsie sąsiada. Jak widać poniżej lokalny port f0/3 przełącznika SW1 (sekcja Local information) jest połączony z portem f0/3 sąsiada czyli przełącznika SW3 (sekcja Partner s information).

11 11 (Pobrane z slow7.pl) Dodatkowo fakt włączenia interfejsu Po1 można zweryfikować po wydaniu polecenia: show ip interface brief

12 12 (Pobrane z slow7.pl) Interfejs Po1 będzie również uwzględniany przez protokół STP. Po sprawdzeniu stanu działania protokołu widać, że interfejsy fizyczne Fa0/3 oraz Fa0/4 zostały zastąpione interfejsem logicznym Po1.

13 13 (Pobrane z slow7.pl) Konfigurację interfejsu fizycznego możemy dodatkowo zweryfikować za pomocą polecenia: show running-config interface <nazwa_interfejsu> - interfejs do utworzenia zagregowanego łącza wykorzystał protokół PAgP, tryb pracy portu desirable a także za pomocą komendy: show interfaces f0/3 switchport interfejs f0/3 pracuje w trybie access i jest częścią puli interfejsów fizycznych przynależnych do grupy LAG Port-Channel Po1.

14 14 (Pobrane z slow7.pl) Oprócz sprawdzenia informacji na temat interfejsów przypisanych do kanału Etherchannel możemy dokonać również sprawdzenia ustawień utworzonego interfejsu logicznego Port-Channel 1. Sprawdzenia dokonujemy za pomocą polecenia: show interfaces port-channel <numer_interfejsu> Przeglądając konfigurację portu warto zwrócić uwagę na parametr BW (bandwidth pasmo) wartość ta odpowiada: ilość połączonych interfejsów x pasmo każdego z nich. W przykładzie zostały użyte dwa łącza FastEthernet tak więc maksymalne pasmo dostępne dla interfejsu Po1 wynosi kb/s (2 interfejsy x kb/s) Dodatkowo w sekcji Members in this channel poznamy interfejsy tworzące dany kanał LAG.

15 15 (Pobrane z slow7.pl) Łącze EtherChannel z wykorzystaniem protokołu PAgP pomiędzy przełącznikami zostało zestawione, tak więc do weryfikacji stanu łącza możemy również wykorzystać polecenia systemu IOS, które są przynależne temu protokołowi. Jednym z poleceń jest: show pagp neighbor Po wydaniu komendy poznamy informacje o interfejsach sąsiada. Jak widać poniżej łącze LAG jest zestawione z interfejsami f0/3 oraz f0/4 przełącznika SW3 a interfejsy te pracują w trybie auto. Dodatkowo poznamy czas pracy interfejsów.

16 16 (Pobrane z slow7.pl) Aby poznać interfejsy lokalne przełącznika wykorzystujące protokół PAgP należy wykorzystać polecenie: show pagp internal Informacje o stanie wymienianych informacji PAGP poznamy po wydaniu polecenia: show pagp counters Ewentualne problemy z kanałem EtherChannel, który jest budowany za pomocą protokołu PAGP możemy rozwiązać włączając proces debugowania tego protokołu. Debugowanie uruchomimy za pomocą komendy: debug pagp <opcja> Poniżej na zrzucie włączony proces debugowania zdarzeń (przełącznik SW1) protokołu PAGP oraz wynik informacji uzyskanych na skutek wyłączenia interfejsów sąsiada tworzących łącze LAG.

17 17 (Pobrane z slow7.pl) Przełącznik SW1-SW2 EtherChannel protokół LACP Po ustaleniu łącza EtherChannel pomiędzy przełącznikiem SW1 a SW3 przechodzimy do zestawienia kanału pomiędzy switchem SW1 a SW2. Lecz tym razem skorzystamy z protokołu LACP. Konfigurację rozpoczynamy od konfiguracji przełącznika SW1. Kanał zostanie utworzony z wykorzystaniem interfejsów f0/1 oraz f0/2 (interfejsy są tożsame z tymi użytymi na przełączniku SW2). Tak samo jak w przypadku PAgP konfigurację przeprowadzamy w trybie konfiguracji interfejsu. Interfejsy przełącznika SW1 ustawiamy do pracy w trybie active (aktywne negocjowanie utworzenia kanału). Numerowi tworzonej grupy została przypisana wartość 2. Po wydaniu polecenia: channel-group 2 mode active został utworzony interfejs Port Channel Po2, w skład którego weszły interfejsy fizyczne f0/1 oraz f0/2. Stan interfejsu Po2 możemy sprawdzić wydając komendę: show etherchannel summary. Interfejs jest w stanie down (flaga D).

18 18 (Pobrane z slow7.pl) Dokładniejsze informacje o stanie łącza uzyskamy wydając polecenie: show etherchannel detail

19 19 (Pobrane z slow7.pl) Aby kanał EtherChannel został utworzony musimy skonfigurować przełącznik SW2. Na przełączniku tym w trybie konfiguracji interfejsów wydajemy polecenie: channel-group 2 mode passive. Wydanie komendy powoduje ustawienie portów fizycznych w tryb pasywnej negocjacji. Oznacz to, że zagregowane łącze powstanie gdy poprosi o to sąsiad. Porty przełącznika SW1 zostały skonfigurowane tak aby inicjować utworzenie kanału tak więc łącze EtherChannel pomiędzy przełącznikami zostaje utworzone interfejs Port-channel 2 zmienia stan na up. Łącze LAG zostało skonfigurowane za pomocą protokołu LACP a ogólny proces tworzenia łącza przebiegał następująco: interfejsy skonfigurowane za pomocą flagi active wygenerowały na swoich łączach ramki LACPDU (ang. LACP Data Unit) - przełącznik SW1 sąsiad po odebraniu ramki LACPDU (gdy jest skonfigurowany do korzystania z protokołu LACP) odpowiedział na zapytanie wysyłając odpowiedź przełącznik SW2, przełączniki utworzyły dynamiczną grupę LAG interfejs Port-Channel Po2 Stan łącza możemy sprawdzić za pomocą znanego nam polecenia: show etherchannel summary. Interfejs Po2 działa prawidłowo (flaga U).

20 20 (Pobrane z slow7.pl) Dokładny stan portów możemy skontrolować za pomocą już również wykorzystywanego polecenia: show etherchannel detail

21 21 (Pobrane z slow7.pl) Dokładniejszy opis uzyskanych informacji 1 - informacja o grupie LAG, 2 - użyty protokół, 3 - stan portu, 4 - numer grupy, oraz identyfikator interfejsu Port-channel, 5 - informacja o interfejsie lokalnym tworzącym kanał EtherChannel m.in. stan portu, priorytet 6 - informacja o interfejsie sąsiada tworzącym kanał EtherChannel m.in. stan portu, priorytet, czas przyłączenia oraz ID. Na przełączniku SW2 wydano dodatkowo dwa polecenia tak aby doprecyzować konfigurację związaną z protokołem LACP.

22 22 (Pobrane z slow7.pl) Polecenie: lacp system-priority <priorytet> (punkt 1) jest odpowiedzialne za zdefiniowanie numeru priorytetu systemu LACP. Polecenie wydane w trybie konfiguracji globalnej odpowiada za ustalenie, który z przełączników ma pierwszeństwo w podjęciu decyzji o utworzeniu kanału EtherChannel. Zasada jaka obowiązuje - niższy priorytet ma pierwszeństwo. W przypadku pozostawienia domyślnych wartości, decyduje adres MAC - niższy adres ma pierwszeństwo. Wartość priorytetu może być ustalona od 1 do (domyślnie 32768). Komenda: lacp port-priority <priorytet> (punkt 2) jest wydawana w trybie konfiguracji interfejsu a odpowiada za przydzielenie priorytetu interfejsom. Kanał LAG może maksymalnie wykorzystywać 8 interfejsów fizycznych lecz przydzielonych łączy do kanału może być więcej. Poprzez manipulację parametrem lacp port-priority definiujemy, które interfejsy mają być aktywne a które mają być użyte w przypadku awarii. Wartość priorytetu może być ustalona od 1 do (domyślnie 32768). Wartości ustalonych priorytetów możemy odnaleźć w wynikach już zaprezentowanych poleceń (lub tych, które będą przedstawione za chwilę). Na przykład wartość lacp port-priority poznamy po wydaniu komendy: show etherchannel detail zaś wartość lacp system-priority po wydaniu komendy: show lacp sys-id Aby poznać protokoły, które zostały wykorzystane do utworzenia zagregowanych łączy wraz z informacją o grupie wydaj polecenie: show etherchannel protocol (na switchu SW1 są uruchomione dwa protokoły PAgP oraz LACP przy czym pierwszy z nich obsługuje grupę 1 a drugi grupę 2). Tak jak to miało miejsce w przypadku protokołu PAgP tak i w przypadku korzystania z protokołu LACP stan utworzonego łącza można skontrolować za pomocą poleceń przynależnych temu

23 23 (Pobrane z slow7.pl) protokołowi. Pierwsze polecenie: show lacp neighbor pokarze status portów sąsiada. Jak widać poniżej porty f0/1 oraz f0/2 przełącznika SW2 (sąsiad przełącznika SW1) działają prawidłowo. Porty te zostały skonfigurowane do pracy w trybie pasive (flaga P). Stan interfejsów lokalnych poznasz za pomocą komendy: show lacp internal (grupę LAG o identyfikatorze 2 tworzą łącza f0/1 oraz f0/2, interfejsy są skonfigurowane do pracy w trybie active flaga A) Stan wymiany ramek pomiędzy przełącznikami poznasz wydając komendę: show lacp counters

24 24 (Pobrane z slow7.pl) I tak jak w przypadku protokołu PAgP problemy z działaniem kanału LAG zestawionego za pomocą LACP można próbować rozwiązać włączając proces debugowania protokołu. Poniżej na listeningu za pomocą polecenia: debug lacp event zostało włączone monitorowanie zdarzeń, które dotyczą działania protokołu LACP - interfejs Port-Channel2 przestał działać (powód - wyłączenie interfejsów sąsiada) by ponownie wróć do normalnego stanu pracy. Oczywiście tak jak w przypadku protokołu PAgP stan konfiguracji protokołu LACP w kontekście działania mechanizmu STP poznamy wydając polecenie: show spanning-tree Interfejsy F0/1 i F0/2 zostały zastąpione interfejsem logicznym Po2

25 25 (Pobrane z slow7.pl) Przełącznik SW2-SW3 EtherChannel mode on Kanały EtherChannel na łączach pomiędzy przełącznikami SW1-SW3 oraz SW1-SW2 zostały utworzone dynamicznie z wykorzystaniem protokołów PAgP oraz LACP. Do omówienia został nam sposób trzeci a mianowicie utworzenie łącza LAG w sposób całkowicie statyczny. Zagregowane łącze utworzymy pomiędzy przełącznikami SW2 (interfejs f0/3 oraz f0/4) oraz SW3 (interfejs f0/1 oraz f0/2). Rozpoczynamy od konfiguracji switcha SW2. Aby zestawić kanał za pomocą flagi range określamy grupę interfejsów co do których będzie przeprowadzana konfiguracja a następnie za pomocą komendy: channel-group 3 mode on zostaje utworzone zagregowane łącze. Jak widać poniżej w przeciwieństwie do dwóch poprzednich metod interfejs logiczny Port-channel 3 od razu jest w stanie up.

26 26 (Pobrane z slow7.pl) Informację o działającym kanale EtherChannel potwierdzimy po wydaniu polecenia: show etherchannel summary (interfejs Po3 działa flaga U, został utworzony ręcznie brak informacji o użyciu protokołu). Dodatkowo potwierdzenie utworzenia kanału LAG w trybie mode on możemy zweryfikować za pomocą polecenia: show etherchannel <nr_interfejsu> protocol Jak można stwierdzić po poniższym zrzucie interfejs został skonfigurowany z wykorzystaniem trybu ręcznego mode on. Jeszcze jednym poleceniem, które również pomoże nam w zebraniu informacji o utworzonych łączach EtherChannel jest komenda: show etherchannel <id_portu> port-channel Oprócz podstawowych danych o interfejsie uzyskamy również informację o interfejsach fizycznych budujących dany kanał.

27 27 (Pobrane z slow7.pl) Oczywiście polecenia te również można używać w kontekście łączy zestawionych w sposób dynamiczny. Interfejs Po3 pomimo tego, że jest w stanie up (przełącznik SW2) nie działa jeszcze prawidłowo gdyż nie został skonfigurowany jego sąsiad. Aby kanał EtherChannel mógł zacząć przekazywać ruch sieciowy należy przeprowadzić konfigurację na przełączniku SW3. Konfiguracja przebiega analogicznie jak w przypadku switcha SW2. Łącze EtherChannel w trybie ręcznym zostało utworzone. O dodatkowych sposobach weryfikacji utworzonych kanałów jeszcze parę słów za chwilkę.

28 28 (Pobrane z slow7.pl) Użycie agregacji łączy może dać wrażenie, że jest to dobry sposób na zwiększenie ogólnej przepustowości łącza w sytuacjach w których jest to konieczne. W pewnych sytuacjach rozumowanie takie będzie jak najbardziej prawidłowe i rzeczywiście uzyskamy zwiększenie dostępnego pasma łącza lecz może również zdarzyć się tak, że pomimo prawidłowej konfiguracji kanału EtherChannel i zwiększenia dostępnego pasma łącza nadal będziemy mieć problem z uzyskaniem pożądanej prędkości przesyłania pakietów gwarantującej prawidłowe funkcjonowanie naszej sieci. Więc rodzi się pytanie Od czego stan taki zależy? I dlaczego tak się dzieje, że w jednym przypadku decyzja o konfiguracji kanału LAG będzie strzałem w dziesiątke zaś w drugim strzałem w płot? Odpowiedź na to pytanie nie jest sprawą prostą a już na pewno pomimo poznania odpowiedzi nie rozwiążemy problemów we wszystkich sytuacjach. Aby móc w sposób efektywny wykorzystać mechanizm agregacji kanałów trzeba uzmysłowić sobie w jaki sposób jest realizowana funkcja rozłożenia obciążenia w kanale EtherChannel na poszczególne interfejsy fizyczne. Działanie algorytmu, który podejmuje decyzję o przesłaniu danych poprzez poszczególny interfejs fizyczny polega na przyporządkowaniu interfejsowi liczby z zakresu od 0 do 7. Oznacza to, że w zależności od liczby łączy fizycznych budujących kanał LAG, interfejsowi będzie przyporządkowana jedna wartość bądź więcej. Poniżej na rysunku zaprezentowano rozłożenie przydzielania liczby wartości w zależności od liczby interfejsów w kanale EtherChannel.

29 lub może w bardziej obrazowy sposób w przeliczeniu na procenty 29 (Pobrane z slow7.pl)

30 30 (Pobrane z slow7.pl) Jak widać najkorzystniej równoważenie obciążenia przebiega w przypadku wyboru kanału EtherChannel składającego się z 8, 4 i 2 łączy fizycznych gdyż w tych przypadkach łącza są obciążone równomiernie. W pozostałych zaś przypadkach ruch sieciowy nie rozkłada się w równy sposób na wszystkie interfejsy fizyczne. Jak już wspomniano jest to spowodowane tym, że niektórym interfejsom zostaje przypisana większa liczba wartości niż pozostałym a co za tym idzie jest wyższe prawdopodobieństwo, że na skutek działania algorytmu decydującego o trasie przesyłu danych, łącze te zostanie wybrane chętniej. Na przykład w sytuacji w której kanał EtherChannel tworzy pięć łączy, trzem zostaną przypisane dwie wartości zaś dwóm pozostałym tylko jedna wartość. Oznacza to, że trzy interfejsy będą wykorzystywane w większym stopniu niż dwa pozostałe. Domyślna metoda wyboru ścieżki transmisji dla pakietów opiera się przeważnie na docelowym adresie MAC choć w zależności od modelu przełącznika i wersji oprogramowania IOS będzie można zdecydować się na: źródłowy adres IP (src_ip_addr), docelowy adres IP (dest_ip_addr)

31 31 (Pobrane z slow7.pl) źródłowy i docelowy adres IP (src-dst-ip) źródłowy adres MAC (src_mac_addr) docelowy adres MAC (dest_mac_addr) źródłowy i docelowy adres MAC (src-dst-mac) port źródłowy (src_port) port docelowy (dest_port) port źródłowy i docelowy (src-dst-port) Aby bardziej zrozumieć mechanizm rozłożenia obciążenia w kanale EtherChannel przeanalizujmy sytuacje zaprezentowaną na rysunku poniżej. Grupa użytkowników (po lewej) aby uzyskać dostęp do usług musi skontaktować się z grupą serwerów (po prawej). Załóżmy w naszym przykładzie, że najbardziej obciążonym serwerem jest serwer plików, który pochłania 60% przepustowości łącza. Ruch sieciowy jest przekazywany poprzez dwa przełączniki pomiędzy, którymi zestawiono łącze EtherChannel zbudowane z 4 interfejsów FastEthernet. Mogłoby by się wydawać, że nie powinno być problemu z przepustowością łącza gdyż zestawiony kanał pozwala nam w jedną stronę wysłać dane z prędkością 400 Mb/s co w przeliczeniu na serwer plików daje nam 240 Mb/s. Niestety zastosowanie domyślnej konfiguracji (algorytm oparty na docelowym adresie MAC) spowoduje, że pomimo zestawienia łącza LAG wymagana przepustowość łącza nie zostanie osiągnięta. Stanie się tak ponieważ w kanale EtherChannel ruch do serwera plików w przypadku wyboru metody opartej na docelowym adresie MAC będzie przekazywany tylko poprzez jedno wybrane łącze. Zaś ruch sieciowy do innych serwerów będzie przekazywany przez odrębne łącza w skonfigurowanej wiązce EtherChannel. Tak więc na przełączniku SW1 bardziej trafioną metodą wyboru ścieżki przesyłu danych będzie metoda bazująca np. na źródłowym adresie MAC ruch od hostów będzie rozkładany na poszczególne interfejsy. Na switchu SW2 pozostawienie domyślnej konfiguracji da pożądany efekt rozłożenia ruchu sieciowego na wszystkie łącza fizyczne gdyż przełącznik SW2 ruch pakietów od strony serwerów w kierunku hostów będzie rozkładał na poszczególne interfejsy wchodzące w skład zbudowanego łącza LAG. Zmiana na metodę bazującą na źródłowym adresie MAC spowoduje, że pakiety od serwera plików zostaną przesłane jednym i tym samym łączem czyli nasz problem nie zostaje rozwiązany. Aby na przełączniku sprawdzić dostępne metody działania algorytmu wyboru ścieżki należy wydać

32 32 (Pobrane z slow7.pl) polecenie: port-channel load-balance? Zmiany dokonujemy poprzez wybranie odpowiedniej flagi z dostępnych. Np. zmiana ustawień na metodę bazującą na źródłowych adresach MAC dokonamy za pomocą polecenia: port-channel loadbalance src-mac Polecenie wydajemy w trybie konfiguracji globalnej co oznacza, że wybrana metoda będzie stosowana do wszystkich portów przełącznika skonfigurowanych w ramach kanału EtherChannel. Weryfikację ustawień dokonamy za pomocą komendy: show etherchannel load-balance Podczas pracy skonfigurowanego łącza EtherChannel warto kontrolować, które z łączy są wykorzystywane najintensywniej. Ogólne pojęcie o użyciu łącza poznamy odszukując w wynikach wydawanych poleceń wartości Load. Parametr ten jest uwzględniany np. w poleceniach: show etherchannel <interfejs> port-channel czy show etherchannel detail

33 33 (Pobrane z slow7.pl) Aby poznać jaką decyzję podejmie przełącznik w wyborze interfejsu przez, który zostanie przekazany ruch sieciowy można posiłkować się poleceniem: test etherchannel load-balance interface portchannel <numer_interfejsu> mac <adres_mac_źródłowy> <adres_mac_docelowy> Wydanie przykładowego polecenia na przełączniku SW2: test etherchannel load-balance interface port-channel 2 mac 00d0.c0d7.2dd fc spowoduje wykonie testu, którego efektem będzie informacja o wyborze danego interfejsu - ramka zostanie wysłana z wykorzystaniem interfejsu Fa0/1 I tak już na zakończenie jeszcze jedna uwaga na konfigurację kanału EtherChannel w środowiskach w których korzysta się z sieci VLAN. Aby pokazać problem na przykładzie przyjęto następującą topologię sieciową. Pomiędzy dwoma przełącznikami SW1 oraz SW3 skonfigurowano kanał EtherChannel za pomocą protokołu LACP. Kanałowi LAG został przypisany identyfikator 2 (interfejs Port-Channel 2) Do każdego z

34 34 (Pobrane z slow7.pl) przełączników został podłączony host, który należy do sieci VLAN 10. W tak zbudowanej sieci sprawdźmy czy Host1 potrafi nawiązać poprawną komunikację z Hostem2. Jak widać poniżej test ping kończy się niepowodzeniem. Tak więc rodzi się pytanie - Co jest powodem braku komunikacji pomiędzy komputerami? Aby odpowiedzieć na postawione pytanie należy sprawdzić ustawienia interfejsu logicznego Po2. Ustawienia zweryfikujemy za pomocą komendy: show interfaces Po2 switchport Czytelnik mający styczność z sieciami VLAN pewnie już wie w którym kierunku należy pójść by problem rozwiązać dla tych zaś którzy z tematyką nie do końca są obeznani już śpieszę z odpowiedzią. Winą braku łączności pomiędzy hostami jest sposób konfiguracji interfejsów wchodzących w skład kanału LAG. Interfejsy

35 35 (Pobrane z slow7.pl) te pracują w trybie access co oznacza, że ruch sieciowy będzie przekazywany tylko pomiędzy urządzeniami przypisanymi do domyślnej sieci VLAN1. Skoro interfejsy fizyczne pracują w trybie access interfejs logiczny Po2 odziedziczy to ustawienie i również w tym trybie będzie pracował. Aby móc przesłać ruch sieciowy należący do różnych VLAN-ów kanał EtherChannel pomiędzy przełącznikami musi pracować w trybie magistrali bądź mówiąc inaczej w trybie trunk. Aby poprawić konfigurację musimy zmienić tryb pracy interfejsów fizycznych. Konfigurację rozpoczniemy od przełącznika SW1. W tym celu wydajmy polecenie: interface range f0/3-4 (punkt 1) tak by przeprowadzić za jednym zamachem konfigurację wszystkich interfejsów fizycznych budujących łącze LAG. Aby zmienić tryb pracy interfejsu na trunk należy wydać polecenie: switchport mode trunk (punkt 2) Niestety wydanie polecenia kończy się niepowodzeniem gdyż domyślnie jest ustawiona opcja Auto - przełącznik ma możliwość prowadzenia komunikacji poprzez łącze trunk z wykorzystaniem enkapsulacji bazującej na protokole 802.1Q bądź ISL. Tak wiec by wydanie komendy zakończyło się sukcesem należy zdecydować się na jeden z protokołów. Protokół ISL jest rozwiązaniem starszym więc nie pozostaje nam nic innego jak zdecydowanie się na protokół 802.1Q. Aby łącze trunk mogło prowadzić enkapsulację pakietów z wykorzystaniem protokołu 802.1Q należy wydać polecenie: switchport trunk encapsulation dot1q (punkt 3). Po wydaniu polecenia, ponowna próba ustawienia pracy łącza na trunk kończy się sukcesem (punkt 4). Wydanie wszystkich tych poleceń spowoduje wyłączenie i ponowne włączenie interfejsów fizycznych oraz

36 36 (Pobrane z slow7.pl) powiązanego z tymi interfejsami łącza Po2. Proces konfiguracji możemy również obserwować na switchu SW3. Uważnego czytelnika analizującego powyższe listeningi może zastanowić komunikat: Interface Port-channel2, changed state to up Bo czemu interfejs pracuje skoro zmiana trybu pracy interfejsów została przeprowadzona tylko na przełączniku SW1? Odpowiedź jest dość prosta - O zmianę konfiguracji pozostałych interfejsów (również przełącznika sąsiedniego) zadbał protokół LACP. Przeglądając stan konfiguracji portu Po2 na przełączniku SW1 dochodzimy do wniosku, iż pracuje on w trybie magistrali tak więc kanał ma możliwość przenoszenia ramek należących do różnych sieci VLAN.

37 37 (Pobrane z slow7.pl) Podobne spostrzeżenia poczynimy po stronie przełącznika SW3. Różnica w konfiguracji pomiędzy przełącznikami jest taka iż na przełączniku SW1 ustawienia zostały zdefiniowane przez administratora a na switchu SW3 na wskutek negocjacji.

38 38 (Pobrane z slow7.pl) Ostatnim etapem jest sprawdzenie efektów przeprowadzonej konfiguracji. Tak więc sprawdźmy ponownie czy Host1 uzyskał możliwość komunikacji z Hostem2. Przeprowadzona próba ping kończy się sukcesem.

39 39 (Pobrane z slow7.pl) I to by było na tyle. Mam nadzieję, że po tej dawce informacji samodzielna konfiguracja kanału EtherChannel nie będzie żadnym problemem. BIBLOGRAFIA: