Nexus 5K & 2K – vPC Portchannels

Logo_nx5k

W dzisiejszym wpisie pokażę na przykładzie przełączników Nexus 5500 (2 x 5548UP) oraz 2200 (2 x 2248TP-1GE) jak zbudować redundantną topologię L2 z wykorzystaniem techniki Multi Chassis EtherChannel (MCEC).

 

Topologia

Lewy rysunek przedstawia koncepcję – taką topologię należy stosować przy podłączaniu serwerów, które obsługują protokół 802.3ad. Prawy rysunek odzwierciedla moje urządzenia na których pokażę konfigurację vPC.

 

Konfiguracja

1) Pierwszym krokiem w konfiguracji vPC, który wykonam, będzie odpowiednie ustawienie protokołu Spanning Tree. Domyślnym trybem STP dla rodziny przełączników Nexus jest Rapid PVST+, który to w środowiskach Data Center (seria Nexus właśnie tak jest pozycjonowana) jest mało skalowalny ze względu na ilość logicznych portów jaką dany przełącznik może obsłużyć. Ograniczeń takich w zasadzie nie ma odmiana 802.1s czyli MST – Multiple Spanning Tree. Tryb ten wymusza jednak poczynienie odpowiednich założeń już na etapie wdrażania, ponieważ jakakolwiek zmiana w późniejszym etapie produkcyjnym, możliwa będzie dopiero w oknie serwisowym ze względu na destrukcyjny wpływ na vPC (w większości korporacji, w DC takie okno serwisowe robione jest rzadko lub nawet bardzo rzadko) . W zależności od założeń, proponuję następujące konfiguracje MST :

a) gdy peer keepalive link realizowany jest po interfejsach mgmt0, a load-balancing z wykorzystaniem spanning-tree nie jest zakładany, najlepiej skonfigurować jedną instancję MST oraz przyporządkować do niej pełny zakres vlanów. Dodatkowo Root bridge’m w Spanning Tree zostanie przełącznik N5K-1, który to będzie pełnił również podstawową rolę w domenie vPC. Taka konfiguracja według oficjalnych materiałów Cisco nie będzie sprawiać problemów przy wykonywaniu ISSU czyli bezprzerwowej aktualizacji oprogramowania i właśnie taka zostanie użyta do dalszej  konfiguracji :
N5K-1
stp-a-nx1-1
N5K-2
stp-a-nx2-1

b) gdy peer keepalive link realizowany jest po interfejsach wirtualnych SVI, a load-balancing z wykorzystaniem spanning-tree nie jest zakładany, najlepiej skonfigurować dwie instancje MST :
– jedną instancję MST na vlan w którym znajdą się interfejsy, po których realizowana będzie komunikacja peer keepalive link’u.
– drugą instancję MST na pełny zakres vlan’ów z wyłączeniem vlan’u na potrzeby PKL
Dodatkowo w obu instancjach dla spanning tree zdefiniowałem wyższy priorytet dla przełącznika N5K-1, który zostanie root bridgem.
N5K-1
stp-b-nx1-1b
N5K-2
stp-b-nx2-1b
c) w przypadku gdy do wymagań z punktu b dochodzi potrzeba balansowania ruchem za pomocą spanning-tree, dobrze skonfigurować trzy instancje MST :
– jedną instancję MST na vlan w którym znajdą się interfejsy, po których realizowana będzie komunikacja peer keepalive link’u
– drugą instancję MST na połowę z liczby dostępnych vlan’ów z wyłączeniem vlan’u na potrzeby PKL.
Dla pierwszej i drugiej instancji MST root bridge’em zostanie przełącznik N5K-1
– trzecią instancję MST na pozostały zakres vlan’ów.
Dla trzeciej instancji MST root bridge’em zostanie przełącznik N5K-2

Osobiście odradzam takie wdrożenie, ponieważ balansowanie ruchem, wykorzystując do tego celu Spanning Tree nie jest zalecane i będzie sprawiało problemy w aktualizacji oprogramowania w trybie ISSU, niemniej jeżeli ktoś musi skorzystać z takiej funkcjonalności to konfigurację dla takiego wdrożenia przedstawiam poniżej :
N5K-1
stp-c-nx1-1b
N5K-2
stp-c-nx2-1b

2) Aby konfiguracja vPC była możliwa, muszą zostać włączone odpowiednie feature’y na Nexusach 5K. Ostatnia komenda „feature interface-vlan” potrzebna jest wtedy, gdy komunikacja peer keepalive linku konfigurowana jest na interfejsach vlan’owych.

N5K-1
2-feature-nx1-1
N5K-2
2-feature-nx2-1

3) Wykorzystując interfejsy Ethernet1/31 oraz Ethernet1/32 skonfiguruję PortChannel 5, który posłuży mi w późniejszym czasie do zrobienia peer linku w vPC.

N5K-1
3-po-nx1-1
N5K-2
3-po-nx1-2

4) Konfiguracja domeny vpc 5.

N5K-1
4-vpc-nx1-1-1
N5K-2
4-vpc-nx2-1-1

 

Omówienie najważniejszych komend :

a) vpc domain 5 utworzenie domeny vpc o id 5. Id domeny musi być identyczne na dwóch Nexusach 5K.
b) role priority  przydział priorytetu dla Nexusa 5K (mniej = lepiej). Przełącznik z ustawioną niższą wartością otrzymuje rolę „primary”. Jest to jedna z ważniejszych opcji do ustawienia, ponieważ daje kontrolę nad tym, który przełącznik stanie się głównym w domenie vpc. Oczywiście, za pomocą komendy „show vpc”, możemy w późniejszym czasie sprawdzić, który Nexus otrzymał rolę „primary”, ale osobiście jestem orędownikiem sytuacji, w której sam jestem kowalem swego losu.
c) peer-keepalive destination 172.16.0.186 source 172.16.0.185 vrf management – opcja dla definicji peer keepalive link’u. Na etapie pierwszego uruchomienia Nexus’ów interfejsy mgmt0 dla N5K-1 oraz N5K-2 zostały przeze mnie odpowiednio zaadresowane tj.
N5K-1 – 172.16.0.185/24
N5K-2 – 172.16.0.186/24
Domyślnym vrf’em dla interfejsów mgmt0 jest vrf o nazwie management, dlatego nie można o tym zapomnieć w definicji peer keepalive linku. Gdyby PKL wdrażany był z wykorzystaniem interfejsów Ethernet, dobrze byłoby utworzyć osobny vrf dla tego celu i przyporządkować do niego dany interfejs vlan.
Funkcją peer keepalive link’u jest rozstrzyganie konfliktu w sytuacji, w której ulegnie uszkodzeniu peer link. W takim przypadku, jeden z pary Nexusów musi przejść w tryb „suspended”, a jego wszystkie porty muszą zostać wyłączone – w prawidłowej sytuacji będzie to przełącznik w roli zapasowej domeny vpc.
d) vpc peer-link – opcja konfigurowalna z poziomu interfejsu port channel, która służy do definicji peer linku w domenie vpc.  Peer link jest wykorzystywany do komunikacji dwóch Nexus’ów w domenie vpc m.in do synchronizacji stanu systemu i konfiguracji, przesyłania ruchu multicast i broadcast, a w specyficznych warunkach również unicast.

5) Weryfikacja domeny vPC

N5K-1
4-vpc-nx1-1-2
N5K-2
4-vpc-nx2-1-2

6) Konfiguracja FEX’ów (FEX = Fabric Extender = Nexus 2000)

N5K-1
5-fex-nx1-1-1sec
N5K-2
5-fex-nx2-1-1sec

Omówienie najważniejszych komend :

a) switchport mode fex-fabric delegacja portu jako uplink’u dla fabric extendera. Jeżeli używamy do podłączenia N2K do N5K specjalnych wkładek tj. FETów (Fabric Extender Transciver – są tańsze w zakupie, ale pasują tylko do FEX’ów) to dopiero po wydaniu tej komendy będą rozpoznane przez Nexus’a 5000. Wcześniej, po wydaniu komendy „show interface status” pole type, będzie wyświetlało „Invalid transciver”.
b) fex associate 100 – przyporządkowanie slotu w Nexusie 5000 dla konfigurowanego FEX’a. Porty N2K w N5K widoczne będą jako Ethernet100/1/1 do Ethernet100/1/48.
c) description FEX-1 – ponieważ w jednym Nexus’ie 5000 w trybie „straight-through L2” można podłączyć maksymalnie 24 FEX’y, to warto konfigurować opisy dla FEXów, a nazwę taką nakleić na obudowę poszczególnego Nexus’a 2000, aby w późniejszym czasie wiedzieć jaki port trzeba skonfigurować. Nazwa taka widoczna jest po wydaniu polecenia „show fex” w polu „Description” na Nexus’ie 5000.

7) Weryfikacja poprawności konfiguracji N2K

N5K-1
5-fex-nx1-1-2
N5K-2
5-fex-nx2-1-2
8) Konfiguracja port channel z wykorzystaniem vpc

N5K-1
6-vpc300-nx1-1-1
N5K-2
6-vpc300-nx2-1-1
C3650-1
7-c3650-po-1-1

Jako, że opisywana konfiguracja dotyczy serwerów, a te nie mogą wysłać do naszego N5K ramki BPDU w spanning-tree, to konfiguracja port channel na moim switchu C3650 zawiera również komendę „spanning-tree bpdufilter enable”. Gdybym nie skonfigurował tej opcji, to po podniesieniu portów na C3650 korespondujące z nimi porty na Nexusa’ach przeszły by w stan „Err-disablled” ze względu na domyślną konfiguracją portów FEX’owych – „spanning-tree bpduguard enable”.

9) Weryfikacja konfiguracji MCEC

10) Dodanie zakresu vlanów do bazy vlanów na Nexus’ach 5K

11) Wpływ wyłączenia peer keepalive link’u na domenę vpc

12) Wpływ wyłączenia peer link’u na domenę vpc

13) Wpływ zmiany native-vlan na interfejsie port channel 300

14) Wpływ zmiany parametrów domeny MST (podbicie numeru rewizji na jednym z Nexus’ów)

Brak komentarzy

Dodaj komentarz