LACP eltérő switch-ek között - loop protect beavatkozik

Sziasztok!

Segítsetek kérlek, nem jövök rá mit rontok el. Az összeállítás:

Központi switch: ZyXel XGS1930-28
LAG2: 27/28 port - LACP - a másik oldalon egy Linux szerver, sima bond
LAG3: 23/24 port - LACP - a másik oldalon az régi iroda Netgear GS724Tv4 switch port 25/26
Mindkét LAG esetén: src-dst-mac a hash type
LACP system priority: 32768

Régi iroda switch: Netgear GS724Tv4
LAG1 - 25/26 port - LACP - Admin mode: Enable; STP Mode: Enable; Link Trap: Enable; LACP Priority: 128; Timeout: Long
LAG2 - 23/24 port - LACP - Admin mode: Enable; STP Mode: Enable; Link Trap: Enable; LACP priority: 32768; Timeout: Short
LACP System Priority: 32768
A LAG1 megy a központi ZyXel switch-be, a LAG2 a következő, FS eszközbe a 9/10 portba

Harmadik switch: FS IES3110-8TF-R
Port 7/8: LACP Enabled; Key: 102; Role: Active; Timeout: Fast; Prio: 32768
Port 9/10: LACP Enabled; Key: auto; Role: Active; Timeout: Fast; Prio: 32768

Nos. Amíg a ZyXel és a Netgear vannak ketten addig minden oké. Gyönyörűen összebeszélnek, felépül a link, hibátlan a működés. Abban a pillanatban hogy rákötöm a harmadik switch-et, a központi ZyXel switch loop protect-je letiltja a Netgear felé menő portokat. Mit nem veszek észre, hol a hiba?

Az Ai-t megkérdeztem, adott tippeket (STP, prioritások, stb), de szeretném érteni amit csinálok, nem vakon állítgatni.

Nagyon köszi!

Hozzászólások

Mi az eredeti cél? Tudsz egy skiccet/rajzot betenni? Vizuálsan hamarabb kijöhet a hiba.

FS-ben hova megy a másik LACP?

Ha a Zyxel tilt, akkor jó eséllyel csináltál egy hurkot azt pedig az ethernet szabvány nem igazán szereti. A csillag topológia lenne a megfelelő. 

Ha lesz rá lehetőség a jövőben, akkor cseréld az összes switchet aznos márkájúra, mert egyszerűbb az üzemeltetés. 

A központi ZyXel 23/24 portból elindul két CAT6 kábel egy másik emeletre. Itt fogadja a Netgear a 25/26 portokon. Eddig rendben van, összeállnak, működik. Innen kell tovább vinni a hálózatot, ipari környezetbe, ahova a költséghatékonyság miatt FS termék került. A Netgear 23/24 portjából elindul szintén kettő CAT6 egy másik épületbe, ahol az FS fogadja a 9/10 portokon. (Azt most nem keverem ide hogy innen tovább fog menni még a 7/8 portokból egy másik ugyanilyen FS felé, egyelőre eddig legyen jó). Nincs lehetőség a kábelezés módosítására, így kaptuk, oldd meg jeligére...

Az mindegy, hogy fizikailag  hogy megy tovább. Rajzold fel a topológiát, felejtsd el az ipari környezetet, mindent, úgy rajzold fel, mintha a 3 switch egymás mellett lenne és a kábelek öt centisek lennének.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Király. Viszont, tapasztalatból mondom, tessék holnap felskiccelni egy Paintbe, és elmenteni valahova. Két év múlva, amikor majd megint hozzá kell nyúlni, a rák se fog emlékezni rá, hogy most akkor mi hova megy.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Nézz meg minden LACP-t, hogy rendben felépül-e két linken. A system-priority-nak értelmezésem szerint itt semmi jelentősége, mert az LACP-nek egy switchen van mindkét portja.

Nézd meg az STP topológiát, ki a root, melyik switch melyik porton látja a root-ot. Azt is ellenőrizd, hogy minden switchen ugyanaz az STP protokoll legyen használatban, az alapértelmezettben lehetnek eltérések. Ettől függetlenül egy láncban nem kellene, hogy hurok legyen, de ha látod az STP topológiát, akkor talán meglesz a hiba oka is.

Illetve a napló is célszerű lenne megnézni, hátha kiderül a blokkolás oka.

Linuxon mit jelent a "sima bond"?

Oké, az STP a gyanús nekem is, ezzel folytatom ma.

A "sima Linux bond" alatt ezt a felállást értem:


auto ens1f0
iface ens1f0 inet manual

auto ens1f1
iface ens1f1 inet manual

auto bond0
iface bond0 inet manual
   bond-slaves ens1f0 ens1f1
   bond-miimon 100
   bond-mode 802.3ad
   bond-xmit-hash-policy layer2+3

Úgyis nézd meg az STP topológiát mindhárom switchen, amikor a Zyxel letiltja a Netgeart, illetve párosával is nézd meg: Zyxel + Netgear (Netgear-FS nem csatlakozik), Netgear + FS (Zyxel-Netgear nem csatlakozik).

Illetve azt is próbáld ki, hogy Zyxel-Netgear 2 link, Netgear-FS 1 link, valamint fordítva: Zyxel-Netgear 1 link, Netgear-FS 2 link.

Mindig ellenőrizd az LACP linkeket is. Az eredményeket írd le (STP root port, STP priority).

Azt is nézd meg, hogy port szinten milyen STP beállítások vannak, nincs-e letiltva/kikapcsolva valamely porton az STP, beleértve az LACP portokat (az ilyen LAG-ok kezelése switchenként eltérő lehet, van, ahol LAG szinten kell kezelni egyes beállításokat, van, ahol port szinten).

Normál STP helyett próbáld meg az RSTP-t is.

Elég furcsa helyzet a leírás alapján, némely tesztnek nem látom értelmét, de mikor sötétben tapogatózik az ember, jobb minden sarkot megnézni, hátha úgy kiderül valami.

Én megnézném az eszközök doksijait: milyen LACP módokat, STP üzemmódokat támogatnak. Továbbá ez lehet akár fw hiba is valamelyik eszközben.

Nos, eddig jutottam, bízom benne hogy másnak is segítség lesz a jövőben. Ezekkel a beállításokkal működik:

ZyXel (a "root" switch):

  • LACP hashing: src-dst-mac
  • LACP Timeout: 30s
  • RSTP bridge priority: 4096
  • RSTP hello time: 2s
  • RSTP max age: 20s
  • RSTP forwarding delay: 15s
  • Érintett portok prioritása: 128
  • Érintett portok Edge mód: kikapcsolva

Netgear switch:

  • LAG type: LACP
  • Admin mode: Enable
  • STP mode: Enable
  • Érintett portok LACP priority: 128
  • Érintett portok LACI timeout: Long
  • STP: Enable
  • STP type: RSTP
  • Bridge priority: 32768
  • Bridge Max Age (secs): 20
  • Bridge Hello Time (secs): 2
  • Bridge Forward Delay (secs): 15
  • Spanning Tree Maximum Hops: 20
  • LACP portok STP Status: Enable
  • LACP portok Fast Link: Enable
  • LACP portok BPDU forwarding: Enable
  • LACP portok Auto Edge: Enable

FS switch a Netgear felé:

  • LACP key: auto
  • LACP role: auto
  • LACP timeout: fast
  • LACP port prio: 32768
  • RSTP priority: 32768
  • Az összes többi paraméter ugyanaz mint a Netgear-nél
  • CIST Aggregated Port Configuration: Admin Edge: Non-Edge
  • CIST Aggregated Port Configuration: Auto Edge: Disable
  • Az érintett portokon STP Enabled, Priority 128, Admin Edge: Non-Edge, Auto Edge: Disable

A két FS között csak az LACP key-t állítottam be, auto helyett a két oldalon megegyezőre.

Köszönöm mindenkinek aki segített, próbált segíteni!

Azért az egy kicsit más liga. :)) Félretéve a viccet: esetemben, mint ma kiderült a kollégák is közrejátszottak ebben a sztoriban. Az egyik kábelt rosszul feliratozták, így nem jó portba került csatlakoztatásra. Emiatt volt a loop... Hofit idézem: "a nyomott agyammal nem értem", hogy ha elírod a kábelen a feliratot, majd arrébb mellé írod a jót, akkor mi a lókukiért nem húzod át vagy törlöd le a rosszat róla... Nem volt rendes kábel jelölés, én kis "naiv" azt gondoltam 4-5 kábelre elég ha felírják filccel. Na ja, vagy nem... Attól függetlenül hogy az RSTP most lett "rendesen" beállítva, lehet működött volna, ha nem tesznek bele nekem egy nem aggregált portot is a LAG-ba... Már kibosszankodtam magam miatta...

Igen, én is így gondolom. Ebben a projektben nem az első hogy más malackodása miatt én szívok. Kezd betelni a pohár azzal hogy már mindenki "informatikus" meg "rendszergazda", közben meg alap dolgok elvégzésébe is sokszor hiba kerül. Mostanában sorozatosan ez van a környezetemben, többek által hátrahagyott trágyát kell nekem ellapátolnom. És még békítsem meg az ügyfeleket is. Nem könnyű, szó se' róla.

Ez esetben a kérdés az, hogy aki ezt félrecímkézte, vajon ott van-e még a csapatban. Egyáltalán lehet tudni, hogy ki csinálta? Mindegyik esetben érdemes összeülni (virtuálisan vagy fizikailag), és kielemezni, hogy mi történt, mindez mit okozott, mennyi időveszteség volt megtalálni a problémát, esetleg még azt kitalálni - ha lehetséges -, hogy hasonló esetet hogyan lehet megelőzni. Nem büntetési, hanem tanulási céllal (lessons learned).

Hát, lehet, de ezeknek a hasznos vége kb annyi, hogy "mindenki figyeljen oda, senki ne bassza el a kábelezést, mert orbitális szopás lesz".

A haszontalanból természetesen kijöhet egy köbkilóméter meddő beszélgetés arról, hogy a felnyomkódós számos, vagy a táblicskus bilincses a jó kábeljelölő-e, és hogy mit kell ráírni arra a jelölőre, esetleg arról, hogy a dokumentáció nagyon fontos, és azt mindig meg kell csinálni, természetesen beleírjuk a processz checklistbe is (közben még egy kör meddő vita arról, hogy külön nyilvántartás van-e, vagy a switchport descriptionba kell-e írni, illetve hogy kurva sok pénzért fejlesszünk szinkront a kettő közé). Ezek valamennyit talán segítenek, egy darabig tényleg kevesebb faszkodás lesz talán, de in reality úgyis lesz olyan, ami kimarad onnan, vagy elbaszódik, szóval elég meddő cselekvés valójában.

"mindenki figyeljen oda, senki ne bassza el a kábelezést, mert orbitális szopás lesz".

Akkor ott nem jól csinálják ezt. Sem. Mert et nem ad választ a felmerülő, kérdésekre, amiket megválaszolva elkerülhető a jövőben a hasonló probléma:
-Mi volt a hiba oka (root cause)?
-Hogyan lehetett volna elkerülni?
-Mire lett volna szükség ahhoz, hogy elkerülhető legyen (pl. jobb dokumentálás, a kábelezés ellenőrzése (4 szem?) az összekötés előtt, sb.)?
-Milyen eljárásrendet, munkautasítást, "sillabusz"-t kell javítani/módosítani/megírni és mikorra?
-Hogyan csináljuk legközelebb?

De ezt egyébként egy korrekt, az eseményt/problémát, illetve annak javítását részletesen leíró post mortem jelentés alapján is össze lehet szedni. A "sz@r volt, de megjavítottuk" mondat egy hibajegyben semmit, de tényleg semmit nem ér. Legyen benne az ok, a következmény, a hiba nyomozása, és a javítás mikéntje is. 

 

Értem én az elméletet, a gyakorlatban is végigcsináltam már többször, mint hogy egyáltalán számon tartani való dolognak nézném. Épp ezért gondolom, hogy ezen hosszasan rugózni nagyjából felesleges, a helyzet elég egyértelmű, a felsejlő megoldások leginkább csak arra jók, hogy a manager nagyon boldog lehessen, persze majd mostantól jobban doksizunk, meg majd minden kábelbedugás mellé odaállítunk egy felügyelőbizottságot, meg ráírjuk a checklistre 132. elemnek... A gyakorlatban ez még mindig mérnöki munka, nem lehet minden egyes apró részletét amit valaha valaki beszopott formális processzel megoldani, mert akkor a formális processz egy élhetetlen valami lesz, amit csak papíron fog létezni, és így alig ad hozzá bármit. Azért van a mérnök, hogy lesz kedves gondolkodni.

Ahol meg egyébként sincs lószar se, és nincs például semmiféle bevett módszertan egymás munkájának ellenőrzésére, vagy a projektek levezénylésére, ott nem egy ilyen piszlicsálé ügy miatt lesz majd rend.

Félreértés ne essék, nyilván érdemes ebből tanulni, de ehhez az ilyen nagyon leülünk bizottságis... hát izé, azt a kolléga lendületből tudja prezentálni: az volt a baj, hogy basztunk rendesen STP-t konfigurálni, és valaki szarul dugta be a kábelt. Javítanivaló: ezentúl konfiguráljuk be az STPt akárhol is vagyunk. Ha van listánk, ahol az ilyesmi van, akkor azt abba a wikibe lendületből bele is lehet írni hosszas meetingelés helyett, Zsoltit megkérjük, hogy ugyan legközelebb nézze már meg mit csinál, Bélát a főnököt meg, hogy találjon már valahol egy tízezrest egy zacskó normális kábeljelölőre, ne kelljen már filctollal bohóckodni.

Szépen megfogalmazva bruttó fél óra, és nem basztunk el RCAval meg meetingeléssel több időt szummában, mint amennyire egyébként a kolléga ideje fájt.

Senki sem mondta, hogy ennek hosszas, több órán át tartó megbeszélésnek kéne lennie. Adott esettől függően lehet ez öt-tíz perc, ami inkább lényeges, hogy lehetőleg ott legyenek az érintettek, legjobb esetben az is, aki elrontotta, de azok igen, akiknél ez potenciálisan előfordulhat (nyilván egy kisebb teamet feltételezve).

Nem mondtam, hogy egy külön dedikált meetinget kell rá összerántani, de a projekt/miniprojekt/feladat lezárása után mindenképp célszerű egy összefoglaló, tanulságokat levonó megbeszélést tartani - ahol a "mit kell másképp csinálni, hogy..." mondatokat is meg kell fogalmazni, és akár a meglévő folyamatleírásokba, munkautasításokba, tervezési elveket/előírásokat tartalmazó doksikba is belerakni. Mindenképp célszerű interaktív, beszélgetős megoldásban gondolkodni, egy levélfolyam kifejezetten szuboptimális szerintem ilyen célra - összefoglaló mehet levélben mindenkinek, ez természetes.

hogy egy külön dedikált meetinget kell rá összerántani, de a projekt/miniprojekt/feladat lezárása után mindenképp célszerű egy összefoglaló, tanulságokat levonó megbeszélést tartani

Egyrészt a két mondatrészt direktben üti egymást, de most is mondod.

Másrészt nem, nem feltétlen kell minden munka után ilyet tartani. Akkor kell ilyet tartani, ha van miről beszélni. Itt (megint, feltételezve, hogy egyébként vannak használható processzek), nem nagyon van miről beszélni, aki beszopta, össze tudja foglalni, le tudja vonni a tanulságokat.

Attól, hogy dedikáltan leülünk, még nem kell egy fél/egyórás meetinget tartani. Az aktuális működési formától függően ha pl. van valami rendszeres meeting, ahhoz hozzá lehet csapni, ha meg nincs ilyen, team-mérettől függően akár informálisan is össze lehet rántani egy gyors találkozót online vagy offline.

Attól, hogy dedikáltan leülünk, még nem kell egy fél/egyórás meetinget tartani. Az aktuális működési formától függően ha pl. van valami rendszeres meeting, ahhoz hozzá lehet csapni, ha meg nincs ilyen, team-mérettől függően akár informálisan is össze lehet rántani egy gyors találkozót online vagy offline.

Javítanivaló 2:

"Ha van listánk, ahol az ilyesmi van"

Legyen ilyen listánk, legyen ott a telepítőknél, hogy mi, hova, hogyan, és legyen,aki a dugdosás után átveszi és minimum szemmel veri :) a késznek mondott installációt. 

"Bélát a főnököt meg, hogy találjon már valahol egy tízezrest egy zacskó normális kábeljelölőre"

Legyen elvárás a normális kábejelölés minden esetben, és az legyen is rendesen használva, legyen a tervezett kialakításnak megfelelően jelölve az összes(!) kábel (ehhez az kell, hogy a terveken is szerepeljenek jelölések), illetve csatlakozó, és a mit hova kell dugni táblázat is jó, ha elkészül - annak birtokában egy idomított csimpánz is el tudja végezni a kábelezést ugye... 

A bruttó fél óra stimmel. 

Hát, egyrészt ezek teljesen esetfüggőek, hogy adott esetben van-e értelmük (milyen gyakran csinálunk ilyet pl), de pontosan ezekre mondtam, hogy ott, ahol kéne lenni listának, meg kéne lenni processznek, hogy hogyan ellenőrzünk, de nincs, ott tök fölösleges ezen rugózni, nem ettől fog hirtelen megjavulni minden, eddig se volt ott kompetens management meg akarat, nem ettől lesz.

És egyébként meg igen jól hozod azt is, hogy valójában csináljunk megnyugtató processzt, mert akkor majd örül a manager, hogy hát itt minden nagyon meg lett tervezve, és csinálva, és előre lerajzolva. Igaz ugyan, hogy 5x annyi idő az egész, mintha a netwörkös lemenne, és on-the-fly felkonfigurálná a switchet mikor megjön (természetesen előtte a lényegi részt átgondolva, de ez egy ilyen esetben kb annyi, hogy hova dugom fel), aztán a többit megcsinálná tisztességesen, aztán ha elbassza, hogy hova kell bedugni, azon továbbra se fog fost se segíteni az előzetes tervezés.

Én híve vagyok a processzeknek, csak az van, hogy processzből is ugyanolyan könnyű szart engineerelni, mint bármi másból. Pont ugyanúgy legacy posfányfos lesz belőle, mint a kódból, ha minden szart is beledobálunk még menet közben.

Alapvetően teljesen igazad van: van, ahol ez nem is működhet(ne) másként, de gyanítom, hogy ez hely a Zyxel/Netgear alapján nem olyannak tűnik. Amivel még gond sincs feltétlenül, tudni kellene a körülményeket.

Másrészt az nem hibázik, aki nem dolgozik. Persze, kábelezés után vissza lehetett volna követni minden porton, hogy megfelelő Mac cím látszik-e stb, de ez nem feltétlenül az az erőforrás, amit jelen esetben megérne. Igen, hasznos és kell a dokumentáció, de tegye fel a kezét, aki Zyxel/Netgear helyen kellően vaskossal találkozott. Még olyan helyeken sem feltétlenül van, ahol nemcsak illene, hanem kellene is, hogy legyen.

LACP beállítás esetén alapvető ellenőrzés, hogy minden linken összeáll-e, ha nem, akkor keresni kell az okát. Itt kicsit bonyolította a helyzetet, hogy az STP rögtön levágott valamit, de ez nem kellene indokolná az LACP ellenőrzésének elhagyását, amiből rögtön kijött volna a hiba oka. Azaz nekem úgy tűnik, hogy ez leginkább a felvető kolléga tanuló "pénze" volt LACP/STP témakörben. Amivel szintén nincs gond, valamivel valamikor  el kell kezdeni, senki nem úgy lépett pályára, hogy minden tudás és fogás birtokában lenne.

Gond akkor lenne, ha ezzel valamilyen explicit kárt okozott volna, mely esetben felmerül a felelősség kérdése, de ez esetben sem feltétlenül a téma felvető a felelős, de túl sok lehetőség lehet, melyeket szerintem felesleges találgatni.

Alapvetően egyetértek persze. Így kéne csinálni.
Sokszor azon bukik el egy ilyen próbálkozás hogy egymástól nem függő csapatok dolgoznak egymás után.
És akkor az első csapat megcsinálta a melót, azt a megrendelő átvette (úgy ahogy) aztán jön a következő csapat aki szív a szarral.
Mint egy átlagos építkezés ...

Igen. Ebben az esetben az átvétel módja (ha egyáltalán befolyásolható) az egyik kérdés, a következő pedig az, hogy ha ilyen ismeretlen dolgot veszel át, akkor mit érdemes átnézni a tényleges munkakezdés előtt (pl. hogy legalább a gerinchálózati pontok helyükön vannak-e). Persze ez a felvetés most gonoszság részemről, mert már ismert a root cause, de akkor is.

Tapasztalatom szerint a legnagyobb baj az RCA-nál, hogy nem merik igazán felásni, nem csak kapargatni a felszínt.
1. Nincs kiviteli dokumentáció / terv. Semmi. "Minek az?" címszóval.
2. Mindig utólag, a kivitelezéshez képest jelentős késéssel (napok, hetek) próbálják meg fejből összerakni, hogy ki mit csinált. Így jön össze egy a valóságtól távol álló "dokumentáció". Kilóra azért megvan.