Nexus 5596UP Module 2 problem po upgrade

Problemy i dyskusje z zakresu rozwiązań i technologii Data Center

Moderatorzy: mikrobi, aron, garfield, gangrena, Seba

Wiadomość
Autor
martino76
CCIE
CCIE
Posty: 805
Rejestracja: 17 gru 2010, 15:23
Lokalizacja: Dublin

Nexus 5596UP Module 2 problem po upgrade

#1

#1 Post autor: martino76 » 22 lis 2015, 14:50

Witam,

Czy ktoś może miał podobny problem z C5596UP upgrade z wersji 6.0.2.N1.2a do 7.0.7.N1.1, a mianowicie mam drugi module, który byl skonfigurowany jako natywny FC ale po upgrade podniósł się jako ETH gdzie wszystkie porty były niedostępne.

Po upgrade zauważyłem, ze straciłem dostęp do Storyge i przeglądają logi natknąłem się na następujące informacje

Module 2 został wykryty jako ETH i wszystkie interfejsy były jako down ale nie były dostępne na switchu.

Kod: Zaznacz cały

2015 Nov 22 01:24:53 switch %PFMA-5-MOD_STATUS: Module 2 current-status is MOD_STATUS_ONLINE.
2015 Nov 22 01:24:53 switch %ETHPORT-5-IF_DOWN_NONE: Interface Ethernet2/1 is down (None)
2015 Nov 22 01:24:53 switch %ETHPORT-5-IF_DOWN_NONE: Interface Ethernet2/2 is down (None)

Kiedy zrobiłem poweroff module 2 and poweron module 2, wtedy module został poprawnie wykryty wraz z interfejsami FC, ale pojawił się kolejny, wszystkie interfejsy zostały przypisane do VSAN 1 oraz miały status Admin Down zamiast do VSAN 400, który był skonfigurowany na Switch. Musiałem je ręcznie przypisać raz jeszcze do VSAN 400 i podnieść je z CLI.

Kod: Zaznacz cały

2015 Nov 22 02:07:57 D02CoreSW01 %PFMA-5-MOD_DETECT: Module 2 detected (Serial number FOC17056AZV) Model-Type O2 16 port flexible GEM Model N55-M16UP
2015 Nov 22 02:08:28 D02CoreSW01 %PFMA-5-MOD_STATUS: Module 2 current-status is MOD_STATUS_ONLINE.
2015 Nov 22 02:08:28 D02CoreSW01 %PORT-5-IF_DOWN_ADMIN_DOWN: %$VSAN 1%$ Interface fc2/1 is down (Administratively down)   
Line 3930: 2015 Nov 22 02:11:40 D02CoreSW01 %PORT-5-IF_DOWN_OFFLINE: %$VSAN 1%$ Interface fc2/1 is down (Offline)   
Line 3934: 2015 Nov 22 02:11:40 D02CoreSW01 %PORT-5-IF_UP: %$VSAN 1%$ Interface fc2/1 is up in mode F   
Line 4178: 2015 Nov 22 02:40:47 D02CoreSW01 %PORT-5-IF_DOWN_INITIALIZING: %$VSAN 1%$ Interface fc2/1 is down (Initializing)   
Line 4179: 2015 Nov 22 02:40:48 D02CoreSW01 %PORT-5-IF_UP: %$VSAN 400%$ Interface fc2/1 is up in mode
Następstwem tego zachowania była izolacja VSAN 400 na portach vFC do innych switchy w Fabric Domain oraz maly outage SAN Fabric :evil:

Zastanawiam się czy nie otworzyć case z Cisco, ale może ktoś miał podobny problem.

Pozdro,

Awatar użytkownika
balam
wannabe
wannabe
Posty: 974
Rejestracja: 21 cze 2006, 16:27
Lokalizacja: Warszawa

#2

#2 Post autor: balam » 23 lis 2015, 09:44

Ostatnio robilismy 2 upg na 5548 i 5596 - vpc i fexy w skrocie na urzadzeniach.
Pierwszy upg z 5.2(1)N1(3) do 7.0(6)N1(1) na 5548
Drugi po zaleceniach partnera z hopem przez 5.2(1)N1(9) do 7.0(6)N1(1) na 5596 (ze wzgledu na wczesniejszy upg 5548 i bug CSCul22703 z wersja softu na fexach robiony byl z hopem co niewiele zmienilo)
Oba wygladaly podobnie i byly planowane jak disruptive mianowicie konfiguracja fex'ow po pelnym upg zanikala, roznica w konfigu to jakies 30-40% przed i po upg.

Okazalo sie ale to tez chcemy jeszcze potwierdzic, ze po upg N5500 robi cos z FEXami przez okolo 20 min mimo zakonczonego procesu upg. Dodatkowo trzeba sprawdzic porty, bo moga byc admin down u nas pare losowych sztuk bylo.
Somewhere back in time.

martino76
CCIE
CCIE
Posty: 805
Rejestracja: 17 gru 2010, 15:23
Lokalizacja: Dublin

#3

#3 Post autor: martino76 » 23 lis 2015, 10:29

Pewnie dziś otworze case z Cisco czy to nie trafiliśmy na buga. U mnie przypadek był taki, ze module 2 mimo iż slot 2 był skonfigurowany jako FC wstał jako Eth. Musiałem go przekręcić, ale później wszystkie porty FC wylądowały w VSAN 1 oraz wszystkie porty vFC nie były powiązane z fizycznymi portami Eth, przez co również musiałem je podpiąć ręcznie.

Pozdro,

martino76
CCIE
CCIE
Posty: 805
Rejestracja: 17 gru 2010, 15:23
Lokalizacja: Dublin

#4

#4 Post autor: martino76 » 23 lis 2015, 13:28

Może się przyda dla potomnych CSCuj87061 co by odbyło się bez niespodzianek. Szkoda, ze takich rzeczy nie ma w dokumentacji odnośnie procedury upgrade :), moim zdaniem taka informacja o tak istotnym bug powinna tam być.

Pozdro,

Awatar użytkownika
balam
wannabe
wannabe
Posty: 974
Rejestracja: 21 cze 2006, 16:27
Lokalizacja: Warszawa

#5

#5 Post autor: balam » 23 lis 2015, 14:34

martino76 pisze:Może się przyda dla potomnych CSCuj87061 co by odbyło się bez niespodzianek. Szkoda, ze takich rzeczy nie ma w dokumentacji odnośnie procedury upgrade :), moim zdaniem taka informacja o tak istotnym bug powinna tam być.
Zdecydowanie, bo upgrade to totalna porazka przy takich bledach.
Somewhere back in time.

martino76
CCIE
CCIE
Posty: 805
Rejestracja: 17 gru 2010, 15:23
Lokalizacja: Dublin

#6

#6 Post autor: martino76 » 23 lis 2015, 15:04

Twój bug, który podałeś CSCul22703 jest bardzo podobny i wygląd na to ze mogłem trafić na 2 w tym samym czasie
3)FC ports on unified ports not applied
Może, przez to również straciłem vfc binding i miałem VSAN isolation problem.

Pozdro,

Seba
CCIE/CCDE Site Admin
CCIE/CCDE Site Admin
Posty: 6223
Rejestracja: 15 lip 2004, 20:35
Lokalizacja: Warsaw, PL

#7

#7 Post autor: Seba » 23 lis 2015, 16:40

Software jest pisany przez ludzi i zdarza się, że popełniają oni błędy, i chodzi o to, aby minimalizować prawdopodobieństwa pojawienia się problemu lub umożliwić diagnozę i jego usunięcie (via TAC)

W release notes jest zawsze lista znanych i nie rozwiązanych caveats dla danej platformy/softu, a z drugiej strony migrując do nowego software należy wykonać ćwiczenie przeszukania bazy bugów. Ja przynajmniej pracując dla partnerów takie rzeczy robiłem przed migracją softu.

Nie bez kozery istnieją też usługi mające na celu przygotowanie rekomendacji oprogramowania dla platformy i konkretnych funkcjonalności używanych przez klienta, czy to robione przez partnerów/integratorów, czy też przez Professional Services danego producenta (Advanced Services dla Cisco)

Oczywiście nie wyklucza to całkowicie możliwości trafienia na buga, zwłaszcza jeśli jest on nowy, natomiast znacząco podnosi prawdopodobieństwo sukcesu.
"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe."
A. Einstein

martino76
CCIE
CCIE
Posty: 805
Rejestracja: 17 gru 2010, 15:23
Lokalizacja: Dublin

#8

#8 Post autor: martino76 » 23 lis 2015, 17:04

Seba pisze:Software jest pisany przez ludzi i zdarza się, że popełniają oni błędy, i chodzi o to, aby minimalizować prawdopodobieństwa pojawienia się problemu lub umożliwić diagnozę i jego usunięcie (via TAC).
Wiem, ze jest pisany przez ludzi i rozumiem, ze wszystko się może zdążyć i nie mam tutaj do nikogo pretensji. Zapytałem się tylko, czy może ktoś miał podobny przypadek i jak widać nie bylem osamotniony :)
Seba pisze: W release notes jest zawsze lista znanych i nie rozwiązanych caveats dla danej platformy/softu, a z drugiej strony migrując do nowego software należy wykonać ćwiczenie przeszukania bazy bugów. Ja przynajmniej pracując dla partnerów takie rzeczy robiłem przed migracją softu.
Niestety w release note dla wersji 7.x, do której migrowałem nie ma kompletnie wzmianki o bug CSCuj87061 i wygląda na to, ze w/w bug jest od wersji 6.x ale jak dotąd nie ma go naprawionego, wiec każdy distruptive upgrade może skończyć się problemem.
Seba pisze: Nie bez kozery istnieją też usługi mające na celu przygotowanie rekomendacji oprogramowania dla platformy i konkretnych funkcjonalności używanych przez klienta, czy to robione przez partnerów/integratorów, czy też przez Professional Services danego producenta (Advanced Services dla Cisco)
Wersja do której migrowałem jest rekomendowana przez Cisco jako
Cisco Suggested release based on software quality, stability and longevity
Seba pisze:Oczywiście nie wyklucza to całkowicie możliwości trafienia na buga, zwłaszcza jeśli jest on nowy, natomiast znacząco podnosi prawdopodobieństwo sukcesu.
Tak jak napisałeś, nie da się przewidzieć wszystkiego ale fajnie by było gdyby znalazła się informacja w dokumentacji upgrade dla tego release, ze istnieje taki bug itd, który nie ma rozwiązania i jest tylko workaround, bo nie zawsze jest się w stanie przejrzeć wszystkie bugi :)

Pozdro,

Awatar użytkownika
balam
wannabe
wannabe
Posty: 974
Rejestracja: 21 cze 2006, 16:27
Lokalizacja: Warszawa

#9

#9 Post autor: balam » 24 lis 2015, 08:29

Pomine to co Seba napisal, bo lekcje odrabiamy przed oknem serwisowym. Jednak z 4 roznych producentow sprzetu, ktory byl upg w oknie serwisowym tylko Cisco N5k byl problematyczny.
Somewhere back in time.

Awatar użytkownika
mstan
wannabe
wannabe
Posty: 91
Rejestracja: 18 lip 2013, 18:21

#10

#10 Post autor: mstan » 24 lis 2015, 22:12

Trzeba zauwazyc, ze CSCuj87061 dotyczy upgrade'u pomiedzy tzw wersjami niekompatybilnymi i nie jest traktowany jako bug (!).
Przypuszczam, ze z tego powodu nie ma go w release notes'ach dla 7.x.

Pozostaje kwestia jak to poprawic, aby klienci/partnerzy mogli takie informacje mimo wszystko znalezc przygotowujac sie do upgrade.
Release notes'y zawieraja bugi, ktore odnosza sie do danej wersji. Jesli cos nie jest bugiem to nie wchodzi do release notes'ow.
Sprobujemy to przedyskutowac wewnetrznie w Cisco, czy jest mozliwosc dodania jakiejs dodatkowej sekcji w release notes'ach uwzgledniajacej bugi, ktore nie sa bugami.

Odnosnie samego CSCuj87061: zostal zgloszony przez TACa i zarejestrowany jako "prawdziwy" bug, a nastepnie przeanalizowany przez Business Unit i uznano, ze tak to musi zostac i nie ma planowanego fixa. CSCuj87061 zostal opublikowany w Bug Search Toolu dla celow dokumentacji.


Jak sprawdzic w Bug Search Toolu, czy danych problem jest traktowany jako prawdziwy bug czy nie:

Kod: Zaznacz cały

Known Fixed Releases:  (0)
No release planned to fix this bug

Nasuwa sie pytanie, dlaczego wiec takie zachowanie nie jest traktowane jako bug :)

Uzasadnienie jest nastepujace - disruptive upgrade na NX-OS nie oznacza tylko i wylacznie koniecznosci reloadu.
"Disruptive" jest pojeciem szerszym, tzn taki upgrade wymaga wykonania dodatkowych czynnosci, w tym przypadku przepisania fragmentu konfiguracji :(

Szczegoly techniczne opisano w dokumentacji dla CSCuj87061 :
"Now, in this case of Disruptive ISSU with incompatible image, the system reloads with ascii-replay, i.e. all the commands are actually executed line-by-line.
Hence, after reload, the command "port type fc" too is executed by the system and hence this is displayed in "show running-config".
However, this would be effective only after configuration save and reload and hence other configurations for FC interfaces (e.g. "switchport mode F") cannot be effective at this time.
After reload, the FC interfaces become effective, however we need to copy other configurations related to these FC interfaces, which are in earlier saved startup-config."

Mam nadzieje, ze choc troche rozjasnilem temat :)

Edit:
Do sprawdzenia pozostaje kwestia co rozumiemy pod pojeciem wersji niekompatybilnych :)

Warto przed upgradem wykonac polecenie, ktore jedynie wyswietli jak bedzie przebiegal upgrade, bez faktycznego jego wywolania:
#show install all impact <nowy NXOS image>

martino76
CCIE
CCIE
Posty: 805
Rejestracja: 17 gru 2010, 15:23
Lokalizacja: Dublin

#11

#11 Post autor: martino76 » 25 lis 2015, 11:58

mstan pisze: Odnosnie samego CSCuj87061: zostal zgloszony przez TACa i zarejestrowany jako "prawdziwy" bug, a nastepnie przeanalizowany przez Business Unit i uznano, ze tak to musi zostac i nie ma planowanego fixa. CSCuj87061 zostal opublikowany w Bug Search Toolu dla celow dokumentacji.
Michał jeśli nie jest to Bug to powinno to być uwzględnione w dokumentacji upgrade i wspomniane, ze jeśli robisz disruptive upgrade to możesz stracić cześć konfiguracji by uniknąć niespodzianek :)

mstan pisze: Nasuwa się pytanie, dlaczego wiec takie zachowanie nie jest traktowane jako bug :)
Dla użytkownika końcowego nie powinno mieć to znaczenia co się dzieje w tle podczas upgrade i czy komendy są przepisywane linia po linii czy czy w inny sposób. Powinno być to tak zrobione by nie tracić konfiguracji, co dla mnie jest niedopracowaniem czytaj bug :)

Poza tym, jest parę ograniczeń co do ISSU i nie zawsze możesz zrobić ISSU, jeśli masz odpalone L3 lub N5K jest STP root to czeka cie distruptive upgrade lub mały redisgn :)
mstan pisze: Edit:
Do sprawdzenia pozostaje kwestia co rozumiemy pod pojeciem wersji niekompatybilnych :)
Również zadałem te pytanie dla Cisco bo nie do końca rozumiem niekompatybilnych wersji. Zapytałem czy jest to zmiana z major version np 6.x do 7.x ale jeszcze nie dostałem odpowiedzi.
mstan pisze: Warto przed upgradem wykonac polecenie, ktore jedynie wyswietli jak bedzie przebiegal upgrade, bez faktycznego jego wywolania:
#show install all impact <nowy NXOS image>
I jak dostaniesz, ze jest disruptive to co to zmieni. Ja miałem świadomość, ze będę musiał zrobić reboot switcha, bo wiedziałem, ze będę miał distruptive upgrde w związku z w/w ograniczeniami, ale nie miałem pojęcia, ze stracę konfiguracje. Teraz wiem , ze mogę stracić konfig itd, ale jeśli ktoś dalej nie wie lub nie ma takiej świadomości bo w dokumentacji nie ma na ten temat wzmianki, to dalej będzie miał problem po upgrade :).

Pozdro,

Awatar użytkownika
mstan
wannabe
wannabe
Posty: 91
Rejestracja: 18 lip 2013, 18:21

#12

#12 Post autor: mstan » 25 lis 2015, 14:16

Pelna zgoda i i jak to mowia anglojezyczni "We hear you" :)

Z tego co sie dowiedzialem mamy dodane dodatkowe logi/ostrzezenia w trakcie upgrade'u w ramach ponizszego "enhancementu":

CSCut57930 "Add warning when proceeding with ISSU upgrade with incompatible images"

Symptom:
When ISSU encounters incompatible images, configuration is lost if customer proceed with upgrade.
This enhancement will add a warning to the User, stating that configuration will be lost if ISSU upgrade proceeds.


Ta zmiana weszla do wersji 7.1(3)N1(1), 7.2(1)N1(1), 7.3(0)N1(1) i kolejnych z tych serii.
Niestety nie zdazyla wejsc do 7.0(7)N1(1).

martino76
CCIE
CCIE
Posty: 805
Rejestracja: 17 gru 2010, 15:23
Lokalizacja: Dublin

#13

#13 Post autor: martino76 » 25 lis 2015, 14:21

mstan pisze:Pelna zgoda i i jak to mowia anglojezyczni "We hear you" :)

Z tego co sie dowiedzialem mamy dodane dodatkowe logi/ostrzezenia w trakcie upgrade'u w ramach ponizszego "enhancementu":

CSCut57930 "Add warning when proceeding with ISSU upgrade with incompatible images"

Symptom:
When ISSU encounters incompatible images, configuration is lost if customer proceed with upgrade.
This enhancement will add a warning to the User, stating that configuration will be lost if ISSU upgrade proceeds.


Ta zmiana weszla do wersji 7.1(3)N1(1), 7.2(1)N1(1), 7.3(0)N1(1) i kolejnych z tych serii.
Niestety nie zdazyla wejsc do 7.0(7)N1(1).
Michał dzięki za info. To już coś, przynajmniej jakiś message w CLI :). Ale przy następnej aktualizacji będę bogatszy o własne doświadczenie.


[EDIT] A co się kryje pod hasłem niekompatybilny image? Może znasz na to pytanie odpowiedz?

Pozdro,

Awatar użytkownika
konradrz
CCIE
CCIE
Posty: 332
Rejestracja: 23 sty 2008, 14:21
Lokalizacja: Singapore, SG
Kontakt:

#14

#14 Post autor: konradrz » 26 lis 2015, 13:15

Skoro dziś Dzień Indyka to nic w pracy się nie dzieje... :) Offtopicznie.
mstan pisze:Szczegoly techniczne opisano w dokumentacji dla CSCuj87061 :
"Now, in this case of Disruptive ISSU with incompatible image, the system reloads with ascii-replay, i.e. all the commands are actually executed line-by-line.
"i.e." znaczy "na przykład", nie "in other words". Jako typowy grammar-Nazi znajdę tego żętelmena co to napisał i mu nawtykam :)
[edit] (o ascii-replay) tak jest od czasów MDSa, co czasem powodowało problemy z FICONem (który normalnie ma binary state)
mstan pisze:Warto przed upgradem wykonac polecenie, ktore jedynie wyswietli jak bedzie przebiegal upgrade, bez faktycznego jego wywolania:
#show install all impact <nowy NXOS image>
Tak naprawdę to skrypt `install all' i tak odpala tą komendę (z trochę przyciętym outputem), przed pytaniem czy kontynuować. Ciekawostkowo, jeszcze w 2009/2010 wnioskowałem żeby do tego dodać minisprawdzenie bugów (tagowy search po włączonych usługach, taki auto-release-notes-check), żeby od razu wyskakiwało "możesz naciąć się na bug XYZ, sprawdź release notes". Oczywiście, zostałem spuszczony na drzewo, "bo to o megabajt-albo-dwa powiększy nam system imydż".
[edit] fakt, że kod był wtedy prostszy, i mniej dependencies. Teraz to pewnie z 15 MB by było.

Awatar użytkownika
mstan
wannabe
wannabe
Posty: 91
Rejestracja: 18 lip 2013, 18:21

#15

#15 Post autor: mstan » 26 lis 2015, 16:03

konradrz pisze:Skoro dziś Dzień Indyka to nic w pracy się nie dzieje... :) Offtopicznie.
mstan pisze:Szczegoly techniczne opisano w dokumentacji dla CSCuj87061 :
"Now, in this case of Disruptive ISSU with incompatible image, the system reloads with ascii-replay, i.e. all the commands are actually executed line-by-line.
"i.e." znaczy "na przykład", nie "in other words". Jako typowy grammar-Nazi znajdę tego żętelmena co to napisał i mu nawtykam :)

No nie wiem, nie wiem, polemizowałbym :)

i.e. = łac. "id est", czyli po polsku: "to jest", "tj".
https://pl.wiktionary.org/wiki/i.e.


Być może miałeś na myśli :

"e.g." = łac. "exempli gratia", czyli po polsku "na przykład", "np"
https://pl.wiktionary.org/wiki/e.g.

Oba wyrażenia są dość często mylone.

ODPOWIEDZ