Nexus 9200 testy peer-link i keep-alive link
Nexus 9200 testy peer-link i keep-alive link
Robiłem dzisiaj testy nexus 9200 i testowałem sobie różne scenariusze.
Rozpięcie keep-alive link - nic się nie dzieje
Rozpięcie peer-link - w zależności czy mamy orphan ports i vpc to część będzie wyłączona i to mi działało natomiast dziwne było co innego na 4 próby shutdown interface peer-link tylko w jednej próbie powiedzmy aktywny/główny został przełącznik nr 1 a w trzech pozostałych przypadkach zawsze aktywny/główny był przełącznik nr 2. Nie ważne na którym przełączniku robiłem sh int peer-link zawsze zostawał nr 2 i tylko raz w ostatnim teście było to nr 1. Trochę dziwne bo w vpc domain to nr 1 ma lepsze priority niż nr 2.
Natomiast dziwnie się działo w dwóch pozostałych testach:
1) rozpiąłem keep-alive link i wiadomo nic się nie podziało i wszystko działa, następnie rozpiąłem peer-link i przełączniki zaczęły działać jakby jako osobne byty, wszystkie porty były up ale ruch tak jakby nie do końca działał poprawnie coś jakby się przycinał czy gubił i musiał być retransmitowany - w sensie nie można się zalogować na serwer a za chwilę można.
Powracając do stanu startowego najpierw wróciłem peer-link i pokazał mi się komunikat, że bez keep-alive link to peer-link się nie zestawi. No więc w kolejnym kroku podniosłem keep-alive link i w zasadzie wszystko mi rozłączyło i dopóki peer-link nie wstał całkowicie to ruch w zasadzie umarł.
2) rozpiąłem najpierw peer-link i tutaj zadziałało zgodnie z planem czyli część portów przeszła w stan suspend, z racji HA to wszystko działało poprawnie dalej i nie było żadnego zgrzytu. Następnie wyłączyłem keep-alive i tutaj też nie miało to żadnego wpływu. Aby wrócić do stanu startowego stwierdziłem że zmienię kolejność aby najpierw podnieść keep-alive link i dopiero potem peer-link. No to podniosłem keep-alive link i w zasadzie nic się nie zmieniło, wszystko chodziło jak chodziło. Tutaj pomyślałem, że skoro mam w stanie up keep-alive link to peer-link powróci bez problemu. No i tutaj się zdziwiłem, bo po podniesieniu peer-link wszystko totalnie stanęło i dopóki vpc nie uzyskało pełnego sync to w zasadzie nic nie działało z ruchu przechodzącego przez te przełączniki 9200.
Mam świadomość że rozpięcie jednoczesne keep-alive i peer-link jest sytuacją mocno nieporządaną i skrajną - no ale rodzi mi się pytanie czy te moje testy w miarę poprawnie wyszły czy to jest taki trochę przypadek i powinno się to zachować inaczej? Jak ktoś robił coś podobnego i by się podzielił wnioskami to chętnie posłucham.
Rozpięcie keep-alive link - nic się nie dzieje
Rozpięcie peer-link - w zależności czy mamy orphan ports i vpc to część będzie wyłączona i to mi działało natomiast dziwne było co innego na 4 próby shutdown interface peer-link tylko w jednej próbie powiedzmy aktywny/główny został przełącznik nr 1 a w trzech pozostałych przypadkach zawsze aktywny/główny był przełącznik nr 2. Nie ważne na którym przełączniku robiłem sh int peer-link zawsze zostawał nr 2 i tylko raz w ostatnim teście było to nr 1. Trochę dziwne bo w vpc domain to nr 1 ma lepsze priority niż nr 2.
Natomiast dziwnie się działo w dwóch pozostałych testach:
1) rozpiąłem keep-alive link i wiadomo nic się nie podziało i wszystko działa, następnie rozpiąłem peer-link i przełączniki zaczęły działać jakby jako osobne byty, wszystkie porty były up ale ruch tak jakby nie do końca działał poprawnie coś jakby się przycinał czy gubił i musiał być retransmitowany - w sensie nie można się zalogować na serwer a za chwilę można.
Powracając do stanu startowego najpierw wróciłem peer-link i pokazał mi się komunikat, że bez keep-alive link to peer-link się nie zestawi. No więc w kolejnym kroku podniosłem keep-alive link i w zasadzie wszystko mi rozłączyło i dopóki peer-link nie wstał całkowicie to ruch w zasadzie umarł.
2) rozpiąłem najpierw peer-link i tutaj zadziałało zgodnie z planem czyli część portów przeszła w stan suspend, z racji HA to wszystko działało poprawnie dalej i nie było żadnego zgrzytu. Następnie wyłączyłem keep-alive i tutaj też nie miało to żadnego wpływu. Aby wrócić do stanu startowego stwierdziłem że zmienię kolejność aby najpierw podnieść keep-alive link i dopiero potem peer-link. No to podniosłem keep-alive link i w zasadzie nic się nie zmieniło, wszystko chodziło jak chodziło. Tutaj pomyślałem, że skoro mam w stanie up keep-alive link to peer-link powróci bez problemu. No i tutaj się zdziwiłem, bo po podniesieniu peer-link wszystko totalnie stanęło i dopóki vpc nie uzyskało pełnego sync to w zasadzie nic nie działało z ruchu przechodzącego przez te przełączniki 9200.
Mam świadomość że rozpięcie jednoczesne keep-alive i peer-link jest sytuacją mocno nieporządaną i skrajną - no ale rodzi mi się pytanie czy te moje testy w miarę poprawnie wyszły czy to jest taki trochę przypadek i powinno się to zachować inaczej? Jak ktoś robił coś podobnego i by się podzielił wnioskami to chętnie posłucham.
Re: Nexus 9200 testy peer-link i keep-alive link
1. Keep-alive to tylko link heartbeat dla przełączników. Jest wymagany w momencie zestawiania peer-linka - nie ma keep-alive, peerlink się nie zestawi, oraz w momencie całkowitego padu peer-linka. W drugiej sytuacji zapobiega on właśnie split brain, czyli efektowi który obserowałeś, oba przełączniki pracowały równocześnie, nie wiedząc, że ten drugi również działa.
2. W momencie wyłączenia peer-linka, przełączniki sprawdzają czy drugi żyje, co rozbija się na dwa scenariusze:
2a. gdy przełączniki widzą się po keepalive, wtedy secondary (a dokładniej operational secondary) wyłącza wszystkie swoje porty vpc, zachowując włączone porty orphan
2b. gdy przełączniki się nie widzą po keepalive, wtedy znów dwa scenariusze: a) przełącznik primary działa jak działał i uznaje, że secondary np się restartuje lub jest wyłączony, b) przełącznik secondary uznaje, że od tego mementu on jest primary i wszystkie porty zostają włączone
Role primary/secondary nie są preemptive, więc jak stary primary wraca do żywych, zostaje on operational secondary.
Informacje o vPC masz w show vpc
2. W momencie wyłączenia peer-linka, przełączniki sprawdzają czy drugi żyje, co rozbija się na dwa scenariusze:
2a. gdy przełączniki widzą się po keepalive, wtedy secondary (a dokładniej operational secondary) wyłącza wszystkie swoje porty vpc, zachowując włączone porty orphan
2b. gdy przełączniki się nie widzą po keepalive, wtedy znów dwa scenariusze: a) przełącznik primary działa jak działał i uznaje, że secondary np się restartuje lub jest wyłączony, b) przełącznik secondary uznaje, że od tego mementu on jest primary i wszystkie porty zostają włączone
Role primary/secondary nie są preemptive, więc jak stary primary wraca do żywych, zostaje on operational secondary.
Informacje o vPC masz w show vpc
Kod: Zaznacz cały
nexus# sh vpc
Legend:
(*) - local vPC is down, forwarding via vPC peer-link
vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : primary
Number of vPCs configured : 4
Peer Gateway : Enabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Disabled
Delay-restore status : Timer is off.(timeout = 150s)
Delay-restore SVI status : Timer is off.(timeout = 10s)
Operational Layer3 Peer-router : Enabled
vPC Peer-link status
---------------------------------------------------------------------
id Port Status Active vlans
-- ---- ------ -------------------------------------------------
1 Po1 up 1,10-20
Re: Nexus 9200 testy peer-link i keep-alive link
Dzięki za tyle info. Tak sh vpc sobie podglądałem cały czas, plus miałem konsolę też odpaloną. Po tym jak przeczytałem twojego posta to doszedłem o co chodzi w moim przypadku. Ja na tych 9200 miałem na testac podłączony tylko jeden serwer zwykłymi portami access i po stronie serwera jest robione HA i inne rzeczy dla niego - serwer ma swój jakby wewnętrzny mały przełącznik. Jednak nie wziąłem jednego pod uwagę, że mam przecież od 9200 uplinki jako vpc właśnie do przełączników wyżej którymi są nexus 9300. Także jak zrobiłem klasyczny split brain to wtedy dalej działały porty od vpc 9200<>9300 i dlatego część ruchu po prostu była nazwijmy to kolokwialnie uwalana.
"zachowując włączone porty orphan" - no to tutaj coś źle doczytałem i muszę to jeszcze raz posprawdzać, bo miałem dziwną sytuację ale jeszcze w poniedziałek sprawdzę w notatkach. Mam na 9200-1 dwa porty do serwera i na 9200-2 także dwa porty do tego samego serwera i wszystkie są orphan. Jednak w momencie rozpinania peer-link z włączonym oczywiście keep-alive to na secondary przełączniku porty serwera mimo że orphan to jednak były wyłączane i to raczej przez przełącznik. No muszę to jeszcze zweryfikować.
"zachowując włączone porty orphan" - no to tutaj coś źle doczytałem i muszę to jeszcze raz posprawdzać, bo miałem dziwną sytuację ale jeszcze w poniedziałek sprawdzę w notatkach. Mam na 9200-1 dwa porty do serwera i na 9200-2 także dwa porty do tego samego serwera i wszystkie są orphan. Jednak w momencie rozpinania peer-link z włączonym oczywiście keep-alive to na secondary przełączniku porty serwera mimo że orphan to jednak były wyłączane i to raczej przez przełącznik. No muszę to jeszcze zweryfikować.
Re: Nexus 9200 testy peer-link i keep-alive link
Zerknij na sesję Cisco Live BRKDCN-2249. Masz info jak się zachowuje vPC w momencie awarii i jakie sa najlepsze praktyki.
To, że porty orphan nie są wyłączane, nie znaczy, że mają jakąś komunikację Szczególnie jest to niefajne w przypadku vSphere i warto zerknąć na polecenie
Na konsoli w przykładowej topologii, przy vpc primary N1, przy standardowej konfiguracji wygląda to tak:
To, że porty orphan nie są wyłączane, nie znaczy, że mają jakąś komunikację Szczególnie jest to niefajne w przypadku vSphere i warto zerknąć na polecenie
Kod: Zaznacz cały
Nexus(config-if)# vpc orphan-ports suspend
Na konsoli w przykładowej topologii, przy vpc primary N1, przy standardowej konfiguracji wygląda to tak:
Kod: Zaznacz cały
┌──────────┐ E1/1 ┌──────────┐
│ ├─────────┤ │
│ N1 ├─────────┤ N2 │
│ │ E1/2 │ │
└─┬───────┬┘ └┬────────┬┘
│ E1/3│ │E1/3 │
E1/4│ │ Po │ │ E1/4
│ xxxxxxxxxxxxxxx │
│ xxxxxxxxxxxxxxx │
Gi0/0│ │G0/0 G0/1│ │ Gi0/0
┌────────┴─┐ ┌┴───────────┴┐ ┌┴─────────┐
│ │ │ │ │ │
│ S1 │ │ S2 │ │ S3 │
│ │ │ │ │ │
└──────────┘ └─────────────┘ └──────────┘
Kod: Zaznacz cały
vPC2# 2022 Apr 2 11:15:19 vPC2 %$ VDC-1 %$ %VPC-2-VPC_SUSP_ALL_VPC: Peer-link going down, suspending all vPCs on secondary. If vfc is bound to vPC, then only ethernet vlans of that VPC shall be down.
Kod: Zaznacz cały
vPC2# sh int status
--------------------------------------------------------------------------------
Port Name Status Vlan Duplex Speed Type
--------------------------------------------------------------------------------
Eth1/1 *** vPC Peer-Link channelDo trunk auto auto 10g
Eth1/2 *** vPC Peer-Link channelDo trunk auto auto 10g
Eth1/3 -- suspndByV trunk auto auto 10g
Eth1/4 -- connected trunk full 1000 10g
(...)
--------------------------------------------------------------------------------
Port Name Status Vlan Duplex Speed Type
--------------------------------------------------------------------------------
Po1 *** vPC Peer-Link disabled trunk auto auto --
Po11 -- suspndByV trunk auto auto --
Kod: Zaznacz cały
vPC2# sh vpc
Legend:
(*) - local vPC is down, forwarding via vPC peer-link
vPC domain id : 1
Peer status : peer link is down
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : secondary
Number of vPCs configured : 1
Peer Gateway : Enabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Disabled
Delay-restore status : Timer is off.(timeout = 30s)
Delay-restore SVI status : Timer is off.(timeout = 10s)
Operational Layer3 Peer-router : Disabled
Virtual-peerlink mode : Disabled
vPC Peer-link status
---------------------------------------------------------------------
id Port Status Active vlans
-- ---- ------ -------------------------------------------------
1 Po1 down -
vPC status
----------------------------------------------------------------------------
Id Port Status Consistency Reason Active vlans
-- ------------ ------ ----------- ------ ---------------
11 Po11 down failed Peer-link is down -
Re: Nexus 9200 testy peer-link i keep-alive link
U mnie wyglądało to inaczej, no ale to nie dziwne, bo po rozpięciu peer-link przełącznik secondary nie ma kompletnie nigdzie dostępu, więc logiczne jest, że porty są odłączane jeżeli są orphan. Mam wtedy pewność, że jakiś ESX czy coś innego nie próbuje przez taki port puszczać ruchu jeżeli jego port byłby on w stanie UP czyli teoretycznie ok i w pełni funkcjonalny.
https://i.ibb.co/pXnZWXF/Screenshot-fro ... -12-05.png
Ale też w dokumencie, który podrzuciłeś (dzięki bo bardzo ciekawy i pomocny!) też jest że orphan są wyłączane (strona 19). Rozumiem, że u ciebie na N1 i N2 porty e1/4 nie były orphan?
https://i.ibb.co/pXnZWXF/Screenshot-fro ... -12-05.png
Ale też w dokumencie, który podrzuciłeś (dzięki bo bardzo ciekawy i pomocny!) też jest że orphan są wyłączane (strona 19). Rozumiem, że u ciebie na N1 i N2 porty e1/4 nie były orphan?
Re: Nexus 9200 testy peer-link i keep-alive link
Dokładnie tą stronę zacytowałem pisząc o vpc orphan-ports suspend
E1/3 to link vpc który został suspendowany na secondary
E1/4 to właśnie porty orphan które zostały connected, nawet na secondary
Re: Nexus 9200 testy peer-link i keep-alive link
No to dziwne, że ich nie uśpił skoro zostały klasycznie osierocone
Ja jeszcze tutaj znalazłem ciekawy dokument opisujący wszystkie możliwe scenariusze rozpięcia VPC
https://www.firewall.cx/cisco-technical ... oting.html
Re: Nexus 9200 testy peer-link i keep-alive link
A jeszcze jedno pytanko bo nie mogę się nigdzie doszukać.
W konfiguracji peer-link należy dać spanning tree type network:
Czy teraz jak łącze 9300 z 9200 przy pomocy vpc z jednej i drugiej strony to też muszę zrobić to samo czyli spanning tree type network? Z tego co czytam w dokumentach Cisco to tylko na peer-link powinno być network. Ja testuję teraz ISSU upgrade i na 9200 mam ok:
Ale już na 9300 mam niestety problem:
i dopiero jak włączone po stronie 9300 na vpc w kierunku do 9200 "spanning tree type network" to problemu nie mam i wszystkie trzy kryteria są passed.
W konfiguracji peer-link należy dać spanning tree type network:
Kod: Zaznacz cały
interface port-channel11
description vpc11 peer-link po11
switchport
switchport mode trunk
spanning-tree port type network
vpc peer-link
Kod: Zaznacz cały
# show spanning-tree issu-impact
For ISSU to Proceed, Check the Following Criteria :
1. No Topology change must be active in any STP instance
2. Bridge assurance(BA) should not be active on any port (except MCT)
3. There should not be any Non Edge Designated Forwarding port (except MCT)
4. ISSU criteria must be met on the VPC Peer Switch as well
Following are the statistics on this switch
No Active Topology change Found!
Criteria 1 PASSED !!
No Ports with BA Enabled Found!
Criteria 2 PASSED!!
No Non-Edge Designated Forwarding Ports Found!
Criteria 3 PASSED !!
ISSU Can Proceed! Check Peer Switch.
Kod: Zaznacz cały
# show spanning-tree issu-impact
For ISSU to Proceed, Check the Following Criteria :
1. No Topology change must be active in any STP instance
2. Bridge assurance(BA) should not be active on any port (except MCT)
3. There should not be any Non Edge Designated Forwarding port (except MCT)
4. ISSU criteria must be met on the VPC Peer Switch as well
Following are the statistics on this switch
No Active Topology change Found!
Criteria 1 PASSED !!
No Ports with BA Enabled Found!
Criteria 2 PASSED!!
List of all the Non-Edge Ports
Port VLAN Role Sts Tree Type Instance
---------------- ---- ---- --- --------- ---------
port-channel21 7 Desg FWD PVRST 7
Criteria 3 FAILED !!
ISSU Cannot Proceed! Change the above Config
Ostatnio zmieniony 05 kwie 2022, 12:30 przez bart, łącznie zmieniany 1 raz.
Re: Nexus 9200 testy peer-link i keep-alive link
Jak ustawię na portach między 9300<>9200
To wszystko jest ok i nie mam żadnych błędów i mogę robić non-disruptive ISSU upgrade, tylko pytanie czy to aby na pewno poprawna konfiguracja dla vpc pomiędzy Nexusami? W sensie takim, że rezygnuję z STP na rzecz ISSU tylko, że w przypadku jakiś nieprzewidzianych problemów, awarii etc brak STP może się odbić czkawką.
Kod: Zaznacz cały
spanning-tree port type edge trunk
Re: Nexus 9200 testy peer-link i keep-alive link
Wychodzi, że jeżeli chcę mieć ISSU na 9300 to bez VXLAN się nie obejdzie.
Re: Nexus 9200 testy peer-link i keep-alive link
type network to Bridge Assurance i na peer-linku robi się automatycznie. Na pozostałych interfejsach możesz zrobić ręcznie, chociaż nie wszystkie przełączniki to wspierają.
Z ISSU to zależy od platformy i softu. Warto zerknąć na dokumentację. Ale czy na pewno musisz zawsze mieć ISSU? Czy może lepiej zaprojektować sieć tak, żeby restart jednego przełącznika nie powodował katastrofy?
Z ISSU to zależy od platformy i softu. Warto zerknąć na dokumentację. Ale czy na pewno musisz zawsze mieć ISSU? Czy może lepiej zaprojektować sieć tak, żeby restart jednego przełącznika nie powodował katastrofy?
Re: Nexus 9200 testy peer-link i keep-alive link
Produkcyjnie wszystko jest w HA więc restart jednego przełącznika nie powinien powodować żadnych problemów. No ale skoro jest możliwość bez restartu to też bym chciał to mieć. NXOS mam w wersjicbr pisze: ↑05 kwie 2022, 19:48 type network to Bridge Assurance i na peer-linku robi się automatycznie. Na pozostałych interfejsach możesz zrobić ręcznie, chociaż nie wszystkie przełączniki to wspierają.
Z ISSU to zależy od platformy i softu. Warto zerknąć na dokumentację. Ale czy na pewno musisz zawsze mieć ISSU? Czy może lepiej zaprojektować sieć tak, żeby restart jednego przełącznika nie powodował katastrofy?
NXOS: version 10.2(1) [Feature Release]
także z tego co znalazłem w moich C93180YC-FX3 Chassis i C92348GC-X Chassis jest wspierane już non-disruptive ISSU upgrade.
Nie wiem czy nie mam gdzieś babola etc. bo połączenie między 9200<>9300 mam tak:
9300
Kod: Zaznacz cały
# sh run int po21
!Command: show running-config interface port-channel21
!Running configuration last done at: Wed Apr 6 14:55:54 2022
!Time: Wed Apr 6 15:21:34 2022
version 10.2(1) Bios:version 01.06
interface port-channel21
description vpc21 n93k to n92k
switchport
switchport mode trunk
mtu 9216
vpc 21
Kod: Zaznacz cały
# sh run int po21
!Command: show running-config interface port-channel21
!Running configuration last done at: Wed Apr 6 12:04:58 2022
!Time: Wed Apr 6 15:22:30 2022
version 10.2(1) Bios:version 05.42
interface port-channel21
description vpc21 n92k to n93k
switchport mode trunk
mtu 9216
vpc 21
9200
Kod: Zaznacz cały
# show spanning-tree issu-impact
For ISSU to Proceed, Check the Following Criteria :
1. No Topology change must be active in any STP instance
2. Bridge assurance(BA) should not be active on any port (except MCT)
3. There should not be any Non Edge Designated Forwarding port (except MCT)
4. ISSU criteria must be met on the VPC Peer Switch as well
Following are the statistics on this switch
No Active Topology change Found!
Criteria 1 PASSED !!
No Ports with BA Enabled Found!
Criteria 2 PASSED!!
No Non-Edge Designated Forwarding Ports Found!
Criteria 3 PASSED !!
ISSU Can Proceed! Check Peer Switch
Kod: Zaznacz cały
# show spanning-tree issu-impact
For ISSU to Proceed, Check the Following Criteria :
1. No Topology change must be active in any STP instance
2. Bridge assurance(BA) should not be active on any port (except MCT)
3. There should not be any Non Edge Designated Forwarding port (except MCT)
4. ISSU criteria must be met on the VPC Peer Switch as well
Following are the statistics on this switch
No Active Topology change Found!
Criteria 1 PASSED !!
No Ports with BA Enabled Found!
Criteria 2 PASSED!!
List of all the Non-Edge Ports
Port VLAN Role Sts Tree Type Instance
---------------- ---- ---- --- --------- ---------
port-channel21 7 Desg FWD PVRST 7
Criteria 3 FAILED !!
ISSU Cannot Proceed! Change the above Config
Re: Nexus 9200 testy peer-link i keep-alive link
A który jest rootem w STP i co mówi o tym dokumentacja ISSU?
Re: Nexus 9200 testy peer-link i keep-alive link
No przyglądnąłem się jeszcze raz swojej konfiguracji i przez te testy zupełnie o pewnych rzeczach zapomniałem, że mam podłączone z boku. Teraz porobiłem porządki z STP i wszystko śmiga jak należy.