Nexus 9200 testy peer-link i keep-alive link

Problemy i dyskusje z zakresu rozwiązań i technologii Data Center
Wiadomość
Autor
bart
wannabe
wannabe
Posty: 464
Rejestracja: 09 maja 2005, 10:33
Lokalizacja: Zielona Góra
Kontakt:

Nexus 9200 testy peer-link i keep-alive link

#1

#1 Post autor: bart »

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.

cbr
wannabe
wannabe
Posty: 91
Rejestracja: 09 wrz 2015, 19:35

Re: Nexus 9200 testy peer-link i keep-alive link

#2

#2 Post autor: cbr »

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

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

bart
wannabe
wannabe
Posty: 464
Rejestracja: 09 maja 2005, 10:33
Lokalizacja: Zielona Góra
Kontakt:

Re: Nexus 9200 testy peer-link i keep-alive link

#3

#3 Post autor: bart »

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ć.

cbr
wannabe
wannabe
Posty: 91
Rejestracja: 09 wrz 2015, 19:35

Re: Nexus 9200 testy peer-link i keep-alive link

#4

#4 Post autor: cbr »

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

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     -


bart
wannabe
wannabe
Posty: 464
Rejestracja: 09 maja 2005, 10:33
Lokalizacja: Zielona Góra
Kontakt:

Re: Nexus 9200 testy peer-link i keep-alive link

#5

#5 Post autor: bart »

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?

cbr
wannabe
wannabe
Posty: 91
Rejestracja: 09 wrz 2015, 19:35

Re: Nexus 9200 testy peer-link i keep-alive link

#6

#6 Post autor: cbr »

bart pisze: 04 kwie 2022, 12:15 Ale też w dokumencie, który podrzuciłeś (dzięki bo bardzo ciekawy i pomocny!) też jest że orphan są wyłączane (strona 19)
Dokładnie tą stronę zacytowałem pisząc o vpc orphan-ports suspend ;)
bart pisze: 04 kwie 2022, 12:15 Rozumiem, że u ciebie na N1 i N2 porty e1/4 nie były orphan?
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 :)

bart
wannabe
wannabe
Posty: 464
Rejestracja: 09 maja 2005, 10:33
Lokalizacja: Zielona Góra
Kontakt:

Re: Nexus 9200 testy peer-link i keep-alive link

#7

#7 Post autor: bart »

cbr pisze: 04 kwie 2022, 18:12 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 :)
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

bart
wannabe
wannabe
Posty: 464
Rejestracja: 09 maja 2005, 10:33
Lokalizacja: Zielona Góra
Kontakt:

Re: Nexus 9200 testy peer-link i keep-alive link

#8

#8 Post autor: bart »

A jeszcze jedno pytanko bo nie mogę się nigdzie doszukać.
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
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:

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.
Ale już na 9300 mam niestety problem:

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
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.
Ostatnio zmieniony 05 kwie 2022, 12:30 przez bart, łącznie zmieniany 1 raz.

bart
wannabe
wannabe
Posty: 464
Rejestracja: 09 maja 2005, 10:33
Lokalizacja: Zielona Góra
Kontakt:

Re: Nexus 9200 testy peer-link i keep-alive link

#9

#9 Post autor: bart »

Jak ustawię na portach między 9300<>9200

Kod: Zaznacz cały

spanning-tree port type edge trunk
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ą.

bart
wannabe
wannabe
Posty: 464
Rejestracja: 09 maja 2005, 10:33
Lokalizacja: Zielona Góra
Kontakt:

Re: Nexus 9200 testy peer-link i keep-alive link

#10

#10 Post autor: bart »

Wychodzi, że jeżeli chcę mieć ISSU na 9300 to bez VXLAN się nie obejdzie.

cbr
wannabe
wannabe
Posty: 91
Rejestracja: 09 wrz 2015, 19:35

Re: Nexus 9200 testy peer-link i keep-alive link

#11

#11 Post autor: cbr »

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?

bart
wannabe
wannabe
Posty: 464
Rejestracja: 09 maja 2005, 10:33
Lokalizacja: Zielona Góra
Kontakt:

Re: Nexus 9200 testy peer-link i keep-alive link

#12

#12 Post autor: bart »

cbr 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?
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 wersji
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
9200

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
I teraz jak robię test to 9200 jest ok ale 9300 już nie co jakby nie patrzeć jest trochę nielogiczne.

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
9300

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

cbr
wannabe
wannabe
Posty: 91
Rejestracja: 09 wrz 2015, 19:35

Re: Nexus 9200 testy peer-link i keep-alive link

#13

#13 Post autor: cbr »

A który jest rootem w STP i co mówi o tym dokumentacja ISSU? ;)

bart
wannabe
wannabe
Posty: 464
Rejestracja: 09 maja 2005, 10:33
Lokalizacja: Zielona Góra
Kontakt:

Re: Nexus 9200 testy peer-link i keep-alive link

#14

#14 Post autor: bart »

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.

ODPOWIEDZ