Svitsj i Connectrix B-serien: Defekte FOS-849642 &FOS-847091 – 7. generasjons direktører og svitsjer kan støte på en feiltilstand som forårsaker CRC-feil, portfeil eller forårsaker en forstyrrende omstart

Berørte
produkterBrocade X7-8, X7-4, 7730 og 7720 som kjører FOS v9.1.x eller FOS v9.2.0
Korrigert i utgivelser Brocade FOS v9.1.1c, v9.2.0a og nyere versjoner, er bare 7.generasjons versjoner


i fare.
7. generasjons direktører (X7-8 og X7-4) med fc64-48 og/eller FC32-X7-48-portblad installert står i fare for å oppleve både overflyt og "verifisere"-feil. Fc32-64 og FC32-48 portblader installert i Gen 7-direktører står ikke i fare for å støte på noen av feilene.
7. generasjons svitsjer (G730 og G720) står bare i fare for at bufferoverflyten svikter. Disse svitsjene utsettes ikke for, og de står heller ikke i fare for å støte på "verify" error failure condition (Kontroller) feiltilstanden.
For ytterligere risiko må strukturen oppleve stor overbelastning, noe som resulterer i administrasjon av oversubscription av Traffic
Optimizer. Følgende RASlog-melding vil bli observert hvis det har oppstått et slikt svarnivå: Handlingen for oversubscription management av Traffic Optimizer finnes bare i FOS v9.1.x-fastvaren. 7. generasjons produkter
som kjører på FOS v9.0.x, er ikke utsatt for noen av feilforholdene.

Risikoforhold for
bufferoverflytFor at bufferoverflyten skal forekomme, må F-portene på Gen 7-katalogen
eller -svitsjen i tillegg til å kreve en periode med stor overbelastning også ha blitt konfigurert fra standardverdien til et større antall buffere. FOS vil
tilordne de fleste 28 buffere som standard.
Alle Gen 7-direktører eller -svitsjer som har hatt maksimalt antall F-Port-buffere økt over standardverdiene som brukes av
FOS, er potensielt utsatt, og alle X7-8- eller X7-4-direktører som tidligere kjørte FOS v9.0.x, kan være utsatt for å
støte på «verifiser»-feil. I begge tilfeller må trafikkoptimalisering også forsøke å administrere ruting av rammer som svar på
en oversubscription-hendelse forårsaket av en periode med stor overbelastning.

Hvis du vil bestemme direktører og svitsjer som kan være utsatt, bruker du kommandoen "portbuffershow" for å vise bufferbruk

hvis totalen av all bufferbruk for porter på samme ASIC/brikke som også er soner samlet, utgjør en verdi som er større enn 256 buffere, og Gen 7-svitsjen anses å være utsatt for å støte på en bufferoverkjøring dersom en alvorlig overbelastningshendelse krever oversubscription-administrasjon fra trafikkoptimalisering. Feilen oppstår ikke på alle hendelser i forbindelse med oversubscription-administrasjon, ettersom antall buffere som administreres på tidspunktet for hendelsen, må overskride 256 mens Trafikkoptimalisering administrerer overtegning, men konfigurert til å håndtere mer enn 256 buffere vil utsette svitsjen for risiko.
I eksemplet som vises ovenfor, hvis alle de åtte F-portene er i én sone sammen, står svitsjen i fare for å støte på en rammebufferoverflyt
mens Traffic Optimizer administrerer en oversubscription-tilstand ettersom det totale antallet bufferbruker i dette eksemplet er 360.
I følgende eksempel der F-portene ikke er alle soner sammen, er ikke denne svitsjen i fare ettersom de to sonene (vist i grønt) totalt utgjør henholdsvis 232 buffere og 128 buffere.

Det maksimale antallet porter som brukes for administrasjon av oversubscription er 8 porter. Hvis mer enn 8 porter er sonert sammen fra samme ASIC/brikke, utgjør det totalt de åtte portene med de høyeste verdiene for bufferbruk for å fastslå risiko.

MERK: 7. generasjons direktører og svitsjer som aldri har endret bufferantallet for F-port fra standard, kan ikke oppleve dette problemet med overflyt i rammebufferen. Den maksimale verdien som brukes som standardinnstilling for maks./reserverte buffere, er 28 for 7. generasjons produkter, men færre buffere kan tilordnes avhengig av svitsjtype og optisk hastighet. Kunder
som aldri har økt sitt maksimale/reserverte bufferantall fra standard, vil ikke støte på problemer med bufferoverflyt
. Selv om åtte porter er sonert sammen, og bruker maksimal standardtildeling av 28 buffere per port, er den totale verdien av
maksimal bufferbruk bare 224 rammer.

"Verify" Failure Risk Conditions
(Bekreft) feilrisikoforholdI tillegg til problemet med bufferoverflyt kan X7-8- og X7-4-direktører også potensielt være utsatt for å "verifisere" feilmeldinger hvis følgende betingelser er oppfylt i denne rekkefølgen:

• X7-8- eller X7-4-direktør som tidligere kjørte på FOS v9.0.x
• Director blir deretter oppgradert til FOX v9.1.x
• Director har deretter F-porter som logger seg på og logger på i v9.1.x-versjonen
• Direktør støter deretter på en oversubscription-hendelse som krever administrasjon fra Traffic Optimizer
• Direktør utfører deretter en HA-failover (fastvareoppgradering fører til failover)
• Directoren støter på en annen oversubscription-hendelse som krever administrasjon fra Traffic Optimizer 

X7-8- eller X7-4-direktører som oppfyller alle disse betingelsene, i den angitte sekvensen, kan være utsatt for å støte på "verifisere" feil under oversubscription management fra Traffic Optimizer.

• X7-8- eller X7-4-direktører som bare har kjørt på FOS v9.1.x-fastvare, er ikke utsatt for å støte på «verify»-feilen fordi bare v9.1-programmeringsmodellen brukes for alle porter. Gen 7-direktører må tidligere ha kjørt med FOS v9.0.x for å være utsatt for dette problemet.
• X7-8- eller X7-4-direktører som har blitt kaldoppstartet / slått av og på mens de kjører på FOS v9.1.x-fastvare, er heller ikke utsatt for å støte på "verify"-feilen, da alle porter vil bruke v9.1-programmeringen etter at du har startet opp på nytt

Symptomer
7. generasjons direktører og svitsjer som har støtt på en oversubscription-administrasjonshendelse, vil se følgende
Traffic Optimizer RASlog: Ytterligere symptomer som kan oppstå på grunn av disse identifiserte problemene, kan være:

• Store antall CRC-feil på en kobling kan observeres som ikke er løst ved utskifting av optisk/kabel
• Rammer kan forkastes, kreditt på en kobling kan gå tapt
• Porter kan være defekte, ASIC kan stoppe opp og være defekt
• En direktør kan oppdage en uventet HA-failover eller til og med en kald omstart av director
• Svitsjer kan observere en kald omstart

Oversubscription management by the Traffic Optimizer feature under specific conditions could cause failure scenarios impacting transmission of frames or ports being managed (Oversubscription management by the Traffic Optimizer feature under specific conditions could cause failure scenarios
impacting transmission of frames or ports being managed. I situasjoner med store overbelastninger kan disse feilene også
påvirke ytelsen til andre Fabric OS-daemoner (FOS), som er aktive på svitsjen, noe som fører til tidsavbrudd for programvareovervåkning, noe som resulterer i ha-failover- eller svitsjkrise
.

7. generasjons direktører og svitsjer (X7-8, X7-4, 7730 og 7720) som støter på en overflyt av rammebuffere mens de forsøker
å administrere og omrute overabonnerte flyter som svar på en alvorlig overbelastningshendelse, kan forårsake uventede feil. Hvis
antallet rammer overkjører bufferen som brukes til å administrere håndteringen av oversubscription, kan
du gå glipp av disse overflødige rammene under håndtering av trafikkoptimalisering. Disse overflødige rammene kan potensielt overskrives av andre rammer som fører
til CRC-feil eller til og med portfeil hvis overskriftsinformasjon overskrives. I situasjoner med store overbelastninger kan administrasjon av disse overflyt-/overflødige rammene føre til blokkering av andre FOS-daemoner, noe som kan føre
til tidsavbrudd for overvåking. Kritiske daemoner som blir tidsavbrutt, vil føre til omstart av HA-failover eller forstyrrende svitsj.

I tillegg til mulig håndtering av rammeoverflyt, kan X7-8- og X7-4-direktører som tidligere hadde vært i drift på FOS v9.0.x og senere oppgradert til FOS v9.1.x, støte på bekreftelsesfeil etter HA-failovers (inkludert de som er forårsaket av fastvareoppgraderinger til nyere versjoner av v9.1.x). Flere feilmeldinger vil bli observert under administrasjon av oversubscription av Traffic Optimizer på grunn av en oppdaget konflikt i programmeringen av porter som opprettes når noen porter, men ikke alle porter, tilbakestilles mens de er på v9.1.x. Konflikten mellom programmering av overbelastningsadministrasjon på porter som aldri ble tilbakestilt i v9.0.x og senere støtte på overbelastningsadministrasjon mens v9.1.x på porter som ble tilbakestilt, kan vises etter en HA-failover-hendelse.

Work-Around ( Løsning
) På risiko» kan direktører og svitsjer deaktivere administrasjonstiltak for trafikkoptimalisering for oversubscription.
Utsteder følgende CLI-kommando fra vedlikeholdskontoen for å deaktivere virkemåten for administrasjon av oversubscription
i Traffic Optimizer MERK: Vedlikeholdskommandoen må kjøres på alle logiske svitsjer i kabinettet.
MERK: Innstillingen vil vedvarende på tvers av fail-overs og strømsykluser

Korrigerende handling
En programvareløsning som leveres i FOS v9.1.1c og høyere, vil forhindre disse feilene. De samme løsningene leveres
også i FOS v9.2.0a og nyere versjoner av FOS v9.2.x. Oppgradering til disse versjonene av FOS vil forhindre overkjøring av rammer på grunn av administrasjon av
oversubscription, og vil også forhindre "verifisere" feil på X7-direktører.

For alle Gen 7-direktører eller -svitsjer (X7-8, X7-4, 7730 og 7720) som fortsatt kjører en versjon av FOS v9.0.x og kan være "utsatt"
, anbefales det å vente på utgivelsen av FOS v9.1.1c før oppgradering.

7. generasjons direktører og svitsjer som for øyeblikket opererer på v9.1.x- eller v9.2.0-utgivelser, og som er fastslått å være utsatt,
bør iverksette løsningen. Hvis du deaktiverer handlingen for administrasjon av trafikkoptimeringsoversubscription, forhindrer du at
både bufferoverkjøring og "verifiserer"-feil oppstår. Etter at du har oppgradert til v9.1.1c eller v9.2.0a, kan handlingen administrasjon av oversubscription
aktiveres på nytt via følgende kommando:
Utstede følgende CLI-kommando fra vedlikeholdskontoen for å aktivere handlingsatferden for oversubscription-administrasjon på nytt i Traffic Optimizer MERK: Vedlikeholdskommandoen må kjøres på alle logiske svitsjer i kabinettet.

Enhver Gen 7-direktør eller -svitsj som allerede har støtt på "bufferoverflyt"-feilen, må utføre en kald omstart
for å kunne gjenopprettes fullstendig fra feiltilstanden: Alternativ 1: Utfør omstartshandlingen som vises ovenfor, og implementer
deretter løsningen for å deaktivere handlingen administrasjon av oversubscription fra alternativ 2 for trafikkoptimering: Oppgrader til en versjon av FOS med løsningen, og utfør deretter omstartshandlingen som vises ovenfor.

Hvis du oppgraderer til en versjon av FOS med den angitte løsningen, vil det forhindre at "bufferoverflyt"-feilen oppstår, men
når den mislykkede tilstanden oppstår, vil bare en kald omstart av ASIC løse feiltilstanden.
Oppgradering til en versjon av FOS med den angitte løsningen vil forhindre og automatisk gjenopprette fra "verify"-feiltilstanden
uten ytterligere tiltak.

Etter at du har oppgradert til en versjon av FOS som inneholder løsningen, vil det bli utført en kontroll av internt minne for å finne ut om director eller svitsjen tidligere har støtt på feilen og krever en omstart for å gjenopprette fra feiltilstanden.
Følgende RASlog vises dersom feiltilstanden oppdages etter oppgradering av FOS til en versjon med løsningen: Hvis RASlog ovenfor observeres etter oppgradering av FOS, har director eller svitsjen tidligere støtt på "bufferoverflyt
"-feilen før oppgraderingen, og må utføre en kald omstart for å gjenopprette helt fra feiltilstanden: