Rackforest leállt?

Fórumok

Látom megy a főoldaluk és a hup is.

Viszont az ügyfélportáljuk leállt. Valamint a VPS-em is.

Du. már láttam furcsa hálózati forgalom emelkedést. Most is azt láttam mielőtt lehalt.

Átálltam tartalék szerverre.

Hozzászólások

hol megy hol nem megy, most megy nálam

jah, munkaidő végével még valaki kirúgta a routerből a kábelt, ma már másodszorra. sok vpsből pár látszik, de a többsége nem. 

ügyfélszolgálat, tech telefonon szokás szerint elérhetetlen. facebookra, twitterre egy betű status infot nem raknak ki...

~ubuntu, raspbian, os x~

Hálózati eszköz meghibásodása miatt folyamatban van a hálózati forgalom átterhelése más eszközökre.

Az esetről várhatóan a Rackforesttől megszokott módon, korrekt post-mortem tájékoztatást fogunk kapni...

Mar megint ?

Ez van ha fillerekert akarsz embert, kapsz csak az pont olyan is lesz.

Kitartast elvtarsak!

http://karikasostor.hu - Az autentikus zajforrás.

- hosting: elmúlt két hétben már kétszer tűnt el a külföldi kapcsolatuk a hostingolt gépünkről - egyiket sem vették észre, mindkettőt reportolnom kellett, és legalább 4-6 órán át nem volt routing

- vps: ma 2x volt kimaradás, nem 1-2 perces

 

Ennek ellenére tényleg jók, teljes körú a tájékoztatás, de jöbben örülnék, ha a hosting és a VPS is stabilan működne, és nem az utólagos tájékoztatásnak kellene örülnöm...

Hasonlokeppen erzek, Rackforest elott a T-nel voltunk, mindket helyen szervereket berlunk (bereltunk).

Mindenben fenyevekkel a T elott jarnak, berszerverek ajanlatai, ugyfelkezeles, tajekoztatas, versenykepes arak, kommunikacios szinvonal, rugalmassag, stb. Szo szerint egy masik dimenzio a T utan, felfoghatatlan a kulonbseg.

Viszont a T-nel 5 ev alatt nem volt annyi muszaki kimaradas mint a Rackforestnel 1 ev alatt. Szoval ez a resze igencsak elszomorit :(

Viszont a T-nel 5 ev alatt nem volt annyi muszaki kimaradas mint a Rackforestnel 1 ev alatt.

De nem is azonosak a pénzügyi és humán erőforrások. A kiscégek one-man-show jellegűek, a nagyok meg tele vannak vészhelyzeti tervekkel, melegtartalékokkal, és (igaz hogy alig megfizetett de) nagy létszámú humánerőforrással. 

Azért a T eléggé csapnivaló. Nekünk mondjuk a szemünkbe hazudtak szerződéskötéskor, és amikor jeleztük a T központja felé, előléptették azt, aki ezt csinálta. Amúgy pedig a 4 órás hardver hibaelhárítási garanciájuk úgy működik, hogy a hardveres szakember reggel 9-re jár be dolgozni, azaz hajnali 5 előtt akkor sem tudnák betartani a szerződést, ha akarnák.

Amikor ez kiderült, mi akkor jöttünk el.

De a RackForest-en kívül nem igazán tudok még egy szolgáltatót, aki hibaelhárítási garanciát vállal, nem hogy 2 órásat! Tehát, ha innen menni kell, nem tudom, hova lesz az oda ...

Vannak operátorok 24x7, nem tartom kizártnak, hogy ők is sok mindent meg tudnak csinálni. Akár úgy, hogy valami hardveres szaki ügyeletben van, akit fel lehet hívni elakadás esetén és ha kell, akkor be is megy. Ezenkívül lehetnek egyéb megoldások is, például gyártói vagy egyéb támogatás. De nem védeni szeretném őket, én is hallottam már one-man-show üzletet a T részéről (kicsit más területen), csak ez így számomra azért is furcsa, mert ha "a" szakember elmegy szabira, akkor akár 2 hétre csökken a rendelkezésre állás? Persze nem kizárt, de eléggé hihetetlen, akár más is lehet a háttérben.

Nekem az elmúlt 18 évben pozitív a tapasztalatom (Petőfi Sándor utca, majd Dataplex), egyszer volt egy keményebb leállás (sok éve), egy kisebb akadás, azon kívül gyakorlatilag semmi. Ha kellett valami, gyorsan és használhatóan reagáltak. Úgyhogy így általánosságban nem jelenteném ki, hogy csapnivaló. Nem azért, mert védeni szeretném őket, csak ezt így nem tartom fairnek.

hat azert ejjel nincs egy gyors reagalasuk. este 8-10 korul kertem egy kabel atkotest, ejjel 3-kor jott a level hogy megcsinalta. nemtudom addig mit csinalt, aludt vagy ugyfelezett, vagy a napkozben eltolt feladatokat csinalta  :/

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Nekem este/éjjel is volt gyors reagálású tapasztalatom. Lehet, hogy lassú is volt, nem emlékszem minden esetre, de összességében nincs bennem olyan tüske, hogy micsoda vacak társaság. Ezenkívül hálózatilag a két említett probléma volt mindössze, tápellátással nem volt még gond.

Rossz napja mindenkinek lehet, hibák szintén mindenhol lehetnek, nem állítom, hogy biztosan minden tökéletes, de a vacak/csapnivaló kategória biztosan nem igaz. Persze az is lehet, hogy ez a csapnivaló kategória és ehhez szoktam hozzá, de a hozzászólások nem ezt tükrözik. Ettől függetlenül szurkolok a Rackforestnek, hogy fejlődjenek ahol lehet és tudnak.

a one-man-show eleg gyakori pedig, es nem azert mert darabszamra nem lenne tobb ember, hanem mert vagy az adott speci szakterulethez osszesen 1 ert komolyabban, vagy pedig nincs semmi rendesen dokumentalva (es/vagy agyon van trukkozve.kokanyolva minden) es csak 1 ember igazodik ki rajta. az ilyenkor nyaralni is csak bekapcsolt telefonnal mehet... mert ott lennie fizikailag altalaban nem szukseges, de csak o tudja iranyitani a munkalatokat, akar a vilag tulso vegerol.

Minden nagy multinal minden csapatban vannak ilyen 1manshow-k. Akiket kb. lehetetlenség kirúgni, vagy ha igen akkor szopás lesz mert senkinek nem adja át a melót tisztességgel. Illetve senki nem is akarja átvenni tőle a melót mert évek/évtizedek alatt megutáltatta magát minden körülötte levő kollégával. A rocksztárstatusz miatt mindenki utálja mint a szart, de mivel érinthetetlen, a főnökségnél is csontig be van nyalva, a vele 1 szinten levők nem tudnak vele mit kezdeni. Morálromboló rákos burjánzás, és sajnos mindenhol van belőlük. Jóérzésű és kevésbbé törtető kevésbbé arrogáns emberek menekülnek ezeknek a közeléből. A hasonló szociopata seggfejekkel (szigorúan más más részlegéről ugyanannak a cégnek, mert hazai pályán már vetélytárs lenne) mondjuk jól megértik egymást, persze vigyázva h. a másik ne nyomja le őket a saját területén.

Minden nagy multinal minden csapatban vannak ilyen 1manshow-k. 

A managment idiótizmusa az oka ennek a jelenségnek, mert nincs is idő rendesen megtervezni, átgondolni, dokumentálni semmit.

A főnököm azzal vezetett fel egy projektet, hogy "neked ez csak újjgyakorlat". A projekt 8 társosztályt érint, 3 kontinensen. 2 hónap után azt mondta, hogy már rosszúl van amikor erről a projektről hall, úgyhogy zárjam le még aznap! Mondanom sem kell hogy még mindíg ezen is dolgozunk, de amikor eljutunk egy "éppen hogy működik" állapotba, akkor úgyis lezérjuk a projektet dokumentáció nélkül. Amit tehetünk, hogy a levelezést archíváljuk, hogy később azért könnyebb legyen kitalálni, hogy mit csináltunk?

Mindazon által a kicsi cégeknél méginkább jellemző ez magatartás, mert ott aztán még emberhiány is van. Jóesetben van egy mérnök és néhány operátor.

az fel sem merült benned, hogy vannak olyan szakemberek, akik inkább elmennek a multitól és megcsinálják a saját one-man-show-jukat?
Az az 1 ember aki ottmaradt, pedig nem feltétlen rockstar - de cserébe Ő sem tudja nyugodtan kivenni az éves 4-6 hét szabadságát?
(de értem - anélkül, hogy személyeskednék - mindenki magából indul ki...)

Adatok stimmelnek, kalkulus rendben. De akkor ki csinalja meg a xyz dolgot, amikor nem vagyok gep elott? :) es :(

Cserebe 150e Ft-tal tobb a fizum mintha sima dolgozo lennek. Ez jo volt egy darabig, de mar nincs kedvem hozza, penz mar nem szamit (tfh. igy is egy sport bmw-vel jarok kb. sehova), de cserebe mar nem is tudom mi az a kikapcsolódás.

Sztem mas cegeknel is lehet ilyen helyzet. 

Volt ilyenhez szerencsém, hogy 2-3 fővel ment a keményen 7x24-es rendelkezésre állás - egyszerű volt a megoldás: váltottam más céghez, úgyhogy jópár éve már nincs kötelezően készenlét - az más, hogy a munkahelyemen a kollégák szabadságom alatt is számíthatnak rám - ahogy én is rájuk - de az a természetes, hogy csak akkor keressük azt, aki szabin van, amikor olyan szinten "ég a ház", hogy más lehetőség nincs. Emberileg és szakmailag is jól felkészült csapat kell hozzá - akiknek az és elég, ha nagy gond esetén kapnak egy néhány mondatos iránymutatást, hogy "merre keressék a tűzcsapot" :-)

sajnos egy komolyabb switch nem csak ugy tud meghibasodni, hogy kialszanak a fenyek es megall...  izgalmasabb amikor a spanning-tree megzakkan, vagy osszekeverednek a vlanok, esetleg valami vedelmi mechanizmus (bdpuguard stb) random lekapcsolgat trunk portokat. de olyat is lattam mar, hogy csak bizonyos mac cimek nem mentek at a switchen, a monitorozo rendszer es az lacp/stp igen, igy random leszakadtak szerverek mikozben minden jonak tunt.

es akkor layer3-rol meg nem is beszeltunk, meg olyan advancedebb datacenter featurek mint mpls, vxlan stb

Egy eszkoz hiba fejreallit majdnem mindent akkor az bizony nemjo

Az a baj, hogy a technológiák nem olyanok az IT-ban, hogy minden eszközhibát ki lehessen küszöbölni (jellemzően nem a "beszart a hw, megállt a cucc" a gond, mert arra vannak jó megoldások, hanem az, amikor az eszköz látszólag csinál valamit, tehát a tartalék nem fog beugrani helyette, de nem látja el jól a feladatát). Ezért kell jó monitoring rendszert kiépíteni, hogy ha valami nem jó, azt ne a tünetekből meg a telefonáló ügyfelek reakcióiból vegyük észre.

Én személyesen 2x beszéltem velük pénteken, délben és este. 

Milyen fontos szolgáltatások? Van olyan szolgáltatás aminél elő van írva hogy legyen kötelező BCP és még tesztelni is kell időnként hogy tud e működni ha elvész az elsődleges. Tapasztalatom szerint ott sem egyértelmű a folyamatos szolgáltatás. 

"Ennél kevésbé fontos szolgáltatás" esetén pedig nincs ilyen vállalás ugye, ez arra van bízva aki üzemelteti. Van aki a felhő alapú gigaszolgáltatókban bízik és azoknál csinál kvázi globális szolgáltatást. Van aki DNS alapú több szolgáltatós elosztást csinál és ezt beépíti az árba.

Tehát elhiszem, nem értétek el őket egyszer sem aznap ezért nem tudtatok semmit se csinálni gondolom nem okozott akkora gondot hogy ezen "fontos" szolgáltatásokat átvigyétek, vagy nyeljetek egyet és azt mondjátok "egyelőre nem tudunk semmit a partner szolgáltató ahol vesszük a szolgáltatást nem tudott választ adni"

A fenti egyébként egy nagy cloud alapú szolgáltatónál elég könnyen bejön, mert ugyan mindenki dolgozik a probléma megoldásán, de a meglévő erőforrás ellenére sem adnak ki tájékoztatást, mert nem akarnak olyat mondani ami később hülyeségnek bizonyul. Ugyan ezt nem keverném ide, de lásd fastly esetét ezen a héten.

hova költözzenek a fontos szolgáltatások

Ha egy van belőle, akkor az nem fontos szolgáltatás. Nekem volt szolgáltatásom, aminek egy része az OVH leégett adatközpontjában volt, nyünnyögött miatta kicsit a menedzsment rendszer, hogy baj van, de egy röccenés nem volt a kiszolgálásban, pár órával később, amikor kiderült, hogy leégett a picsába és nem fogják visszakapcsolni, felhúztam hat új VPS-t másik DC-ben, a Puppet-nek megmondtam, hogy "Öl!" és a Puppet megcsinált mindent, az adatok átmigrálódtak a többi adatközpontból és át kellett írnom kézzel kettő IP címet, amikor lement mindez. És nem mondanám, hogy drága, 3 live DC 90 EUR, 2 backup DC 30 EUR, Amazon Route 53 5 EUR, külső check 5 EUR, az összesen 130 EUR, 45 ezer pénz havonta.

Ha nincs ilyened és egy helyen van minden, akkor nem fontos a szolgáltatás, csak van olyan ügyfél aki minden fillért egyenként megbasz és közben elvár egy always-on architektúrát és van olyan szolgáltató, aki fillérekért ad 99,95% rendelkezésre állást, aztán meg elolvasod az ÁSZF-et és látod, hogy a rendelkezésre állás a teljes szerverparkra vonatkozik, nem az egyes szerverekre, illetve ezen túlmenően a szolgáltatás kiesés időtartamára eső, havi bérleti díj arányos részét jóváírja. Mit is jelent ez? Azt hiszed, hogy vettél egy 99,95% rendelkezésre állású szervert mondjuk egy évre 120 ezer forintért, ami maximum 4,5 órát fog állni, a valóság meg az, hogy ha áll egy évben 7 - azaz hét - napot, de a szerverpark meg minden amúgy megy, akkor maximum visszakapsz 2500 forintot, vagyis 117.500 forintért vettél 98% rendelkezésre állást és mindez teljesen jogszerű, csak tudni kell olvasni szerződést.

sub

A hsz alja mehetne minden klódhírdetés alá a figyelmeztetés részbe, hasonlatosan a gyógyszerreklámok hírdetései alatt (HD csatornán érdemes 1-1 ilyet kimerevíteni és hüledezni ott miket írnak pl. a csoda  csupatermészetes összetevős szaroknál), vagy a kofidisz-provident reklámok alá (a tájékoztatás nem teljeskörű, v. a reklám nem befektetési tanácsadás, stb.).

Valójában nem is ez szokott lenni a fő gond, hanem a wishful thinking.

Kicsit talán az is, de nagyrészt szerintem ezek az irreális elvárások abból gyökereznek, hogy nem olvassák el a szerződést és persze a szolgáltató is igyekszik fényezni magát, mert ha nem írja le nagy betűkkel a landing page elejére, hogy 99,95 százalékos a rendelkezésre állás, akkor a fillérbaszó ügyfél megy ahhoz a szolgáltatóhoz, amelyik leírja nagy betűkkel a landing page elejére, hogy 99,95 százalék a rendelkezésre állás, persze fillérekért. Az ÁSZF-ben meg általában ugyanaz van, hogy a vállalt állásidőn felül visszaadják az arányos havidíj 1-5x részét.

Aztán meg, amikor beüt a baj, akkor jön az, hogy "tartani a hátunkat az ügyfelek felé", pedig azért azon a háton valóban van mit ütni, ha simán átment a végfelhasználóig az, hogy 99,95 százalék a rendelkezésre állás, holott egy példányban fut a szolgáltatás és a használt technológia nem is támogatja a high-availability lehetőségét...

Persze, vannak jó sokan, akik nem is értik ezt a HA dolgot, volt cég, ahol az egyik komponensért felelős csapatnak hetekig kellett magyarázni, hogy nem azért kell abból a dologból három-három két külön adatközpontban, mert egy nem bírná a terhelést, hanem azért, mert magas rendelkezésreállást szeretne az üzlet és hiába bírja egy darab node is a terhelést, ha az bármiért megáll, akkor minden áll, ha meg minden áll, az sok pénzbe kerül. Ez wishful thinking, hogy elég abból egy? Szerintem simán balfaszok.

Ezért szokásom például az, hogy egy ilyen rendszerben a fejlesztői és teszt környezetben is óránként 5 percet áll egy-egy node és néha megy a reset is egy-egy node-nak, hogy csúnyán álljon le, néha elfogy a hely, néha elfogy a memória, néha elfogy a CPU (aka Chaos Monkey és Toxiproxy). Ha ettől valami megborul, azt meg kell javítani, nem pedig félni attól, hogy jajj, mi lesz, ha megáll vagy újraindul egy node vagy valamilyen erőforrás elfogy. Azért HA, hogy ezeket kibírja, annak semmi értelme, hogy felkészülünk egy tökéletes üzemszerű működésre, aztán az első botlástól felborul az egész a picsába és mindenki pingvinezik, hogy miért nem megy és mikorra lesz jó.

Nehéz volt régen a heliocentrizmust betenni a köztudatba, mert a legtöbb embernek semmilyen képe nem volt amihez viszonyíthatta volna az elképzelést. A történelem sokszor ismétli magát főleg az olyanok miatt akik azt gondolják mindent is tudnak és mindent is láttak.

Csak úgy eszembe jutott. 

A tervezett elavulás közbeszólt.

Lenne. Ahogy eddig is volt.

Alább néhány kommentem, ami legalább 5 szavazatot kapott az elmúlt időszakban.

https://hup.hu/comment/2566811#comment-2566811 (15)
https://hup.hu/comment/2633336#comment-2633336 (10)
https://hup.hu/comment/2638865#comment-2638865 (8)
https://hup.hu/comment/2627218#comment-2627218 (6)
https://hup.hu/comment/2627215#comment-2627215 (5)
https://hup.hu/comment/2634036#comment-2634036 (5)

Ezek mind olyan témákban adott kommentek voltak, amikkel kapcsolatban te rögvest az ellenkezőjét képviseled. A multiknak mindig igazat adó, korporatokrata, fősodratú kommentjeidre valahogy mégse jön soha ennyi +1. Csak azokra, amelyikben nekiállsz engem közvetlenül ócsárolni. [1] Ebből is látszik, hogy esetünkben a személyeskedésen túl nem lenne sok értelme a mínuszegyeknek. Az pedig csak annyit mond el rólad és a többi fősodratú személyeskedőről, hogy kognitív disszonanciátok van, ezért inkább a személyt támadjátok, aki felhívja a figyelmet egy rendszer hibáira, aminek a haszonélvező megalkuvói vagytok.

Van egy most nagyon jól hasznosítható funkció a HUP-on. A szavazatot vissza lehet vonni. - Mert felszínes ítélkezés, mert személyeskedő, mert bőven diszkriminatív. Semmit nem árul el, és nem minősít "hajbazer" kollégáról. Viszont a végeredménye átgondolatlanul "troll" és emberi mivoltában megalázó. (Szerintem a HUP-on kommentelők ennél jobb lelkűek, csak az "egy bolond százat csinál" elven nem gondolkodtak, mielőtt szavaztak valami hülyeségre..,) - bocsánat, de ez az én véleményem.  :(

Azert a hup nem egy olyan rettento nagy kozosseg, a rendszeresen kommentelok jelentos reszerol idovel kiderul, hogy mivel foglalkozik, mihez ert nagyon, stb.

Az is kiderul, ha valaki nagyon nem ert valamihez, ennek ellenere rendszeresen hozzaszol. Egy-ket ilyen alkalomnal meg lehetne "felszines" itelkezes, de Hajbi ezt mar reg tullepte.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Szerkesztve: 2021. 06. 12., szo – 19:28

Kb 2 órája jött 3 e-mail tőlük, idekopizom:

Hibajegy száma:             RFTT/2021/NET/00005
Érintett szolgáltatások:    Internet (IP) kapcsolat / Hálózat
A hiba típusa:              Részleges hálózat kiesés
A hiba kezdete:             2021.06.11 10:06:45
A hiba vége:                2021.06.11 10:15:00
A teljes kiesett idő:       00:08:15
-----------------------------------------------------------------------------
Az Ön érintett szolgáltatása:
(...)
-----------------------------------------------------------------------------
A hiba oka, leírása:
A RackForest gerinchálózata VxLAN alapú BGP EVPN control plane-el és helyszínenkénti route reflektorokkal. A hiba a BGP route reflektorokban lépett fel, bizonyos körülmények között egy-egy BGP session memória buffer hibával
megszakadt és újraindult, ennek még nem kellett volna hibát vagy kiesést okoznia, de több esetben ilyenkor véletlenszerűen másik BGP session-ök is megszakadtak. Ennek az eredménye a route reflektorokban egy öngerjesztő processzor túlterhelés lett, mely miatt egy idő után már annyi BGP session szakadt meg ami már túllépte a redundancia tűrőképességét és részleges hálózati kieséseket okozott. Ez a kiesés a RackForest hálózatában véletlenszerűen két hálózati eszköz között 1-2 percre megszakadó kapcsolatok formájában jelentkezett.

A hiba javítása:
A hiba behatárolása után, mivel a hiba önmagától megoldódott, a BGP route reflektorokon csökkentettük a processzor terhelést és elkezdtük a hiba részletesebb vizsgálatát.

Aztán:

Hibajegy száma:             RFTT/2021/NET/00006
Érintett szolgáltatások:    Internet (IP) kapcsolat / Hálózat
A hiba típusa:              Részleges / teljes hálózat kiesés
A hiba kezdete:             2021.06.11 11:01:18
A hiba vége:                2021.06.11 14:14:00
A teljes kiesett idő:       03:12:42
-----------------------------------------------------------------------------
Az Ön érintett szolgáltatása:
(...)
-----------------------------------------------------------------------------
A hiba oka, leírása:
A RackForest gerinchálózata VxLAN alapú BGP EVPN control plane-el és helyszínenkénti route reflektorokkal. Ugyanaz a hiba lépett fel mint az előző (RFTT/2021/NET/00005) hibajegyben, a BGP route reflektorok processzor terhelésének csökkentése nem volt elegendő a hiba ideiglenes megoldásához.

A hiba ismetelten a BGP route reflektorokban lépett fel, bizonyos körülmények között egy-egy BGP session memória buffer hibával megszakadt és újraindult, de több esetben ilyenkor véletlenszerűen másik BGP session-ök is megszakadtak. Ennek az eredménye a route reflektorokban egy öngerjesztő processzor túlterhelés lett, mely miatt egy idő után már annyi BGP session szakadt meg ami már túllépte a redundancia tűrőképességét és részleges valamint teljes hálózati kieséseket okozott.

A hiba első felében (11:01 - 12:40 között) a jelenség ugyanaz volt mint délelőtt, a kiesések a RackForest hálózatában véletlenszerűen két hálózati eszköz között 1-2 percre megszakadó kapcsolatok formájában jelentkeztek.

A hiba második felében (12:50 - 14:14 között) már nagyobb kiesések és két teljes hálózat kiesés (13:16 - 13:18, valamint 13:38 - 13:48 között) jelentkezett.

A hiba javítása:
A hiba behatárolása után, mivel az eddigi megoldások nem vezettek eredményre, a BGP route reflektorokat azonos gyártmányú de dedikált eszközökre költöztettük, továbbá módosítottunk az eszközök control plane védelmi beállításain, nagyobb prioritást biztosítva a BGP protokollnak, növelve ezzel a hálózat stabilitását.

Majd végül (remélhetőleg):

Hibajegy száma:             RFTT/2021/NET/00007
Érintett szolgáltatások:    Internet (IP) kapcsolat / Hálózat
A hiba típusa:              Részleges / teljes hálózat kiesés
A hiba kezdete:             2021.06.11 17:40:30
A hiba vége:                2021.06.11 18:41:00
A teljes kiesett idő:       01:00:30
-----------------------------------------------------------------------------
Az Ön érintett szolgáltatása:

(...)
-----------------------------------------------------------------------------
A hiba oka, leírása:
A RackForest gerinchálózata VxLAN alapú BGP EVPN control plane-el és helyszínenkénti route reflektorokkal. Hasonló hiba lépett fel mint az előző (RFTT/2021/NET/00005+6) hibajegyben, a BGP route reflektorok dedikált eszközökre költöztetése és processzor terhelésének csökkentése nem volt elegendő a hiba végleges megoldásához.

A hiba a Victor Hugo utcai gerinchálózati switchek processzor túlterhelésével kezdődött, később a probléma megoldása közben a BGP route reflektorokban ismételten fellépett a korábbi hiba: Bizonyos körülmények között egy-egy BGP session memória buffer hibával megszakadt és újraindult, és több esetben ilyenkor véletlenszerűen másik BGP session-ök is megszakadtak. Ennek az eredménye a route reflektorokban egy öngerjesztő processzor túlterhelés lett, mely miatt egy idő után már annyi BGP session szakadt meg ami már túllépte a redundancia tűrőképességét és részleges valamint teljes hálózati kieséseket okozott.

A hiba alatt a jelenség ugyanaz volt mint az előző két hiba esetében: A kiesések a RackForest hálózatában véletlenszerűen két hálózati eszköz között megszakadó kapcsolatok formájában jelentkeztek, valamint 17:43 - 18:05 között teljes hálózat kiesés volt tapasztalható.

A hiba javítása:
A hiba behatárolása után, mivel az eddigi megoldások nem vezettek eredményre, a BGP route reflektorokat más gyártmányú dedikált eszközökre fogjuk cserélni, növelve ezzel a hálózat stabilitását. A két route reflektorból
az egyiket az éjszaka (23:00 - 02:00 között) már ki is cseréltük, a tartalék cseréje a következő napokban várható.

Természetesen mindezek mellett felvesszük a kapcsolatot a hibás hálózati eszközök gyártójával, hogy a kérdéses BGP és BGP route reflektor funkciókal kapcsolatos szoftverhibát javítsák, de ez várhatóan nem lesz egy gyors folyamat, e miatt is döntöttünk úgy, hogy más gyártó eszközére cseréljük a problémás berendezéseket.

ez várhatóan nem lesz egy gyors folyamat, e miatt is döntöttünk úgy, hogy más gyártó eszközére cseréljük a problémás berendezéseket

Nagyszerű. A hálózati eszközöknek gondolom azért megkérte rendesen az árát a firmware-fejlesztésen-tesztelésen spúrkodó multi.

anélkül, hogy ismerném az RF belső infrastruktúráját, tfh route reflectornak FRR-t használnak. Eddig VM-ben futott, most kapott bare-metal-t maga alá.
Igaz, hogy az FRR open source, de most konkrétan azt várod Angelo-tól v másik kollégájától, hogy reggelre nézze át a forrást, hogy mi okozhatta a gondot, vagy még azért is morcos vagy, ha nem küldik be rá a patch-et 24 órán belül? :-)

Nem szoktuk titkolni a konkrét eszközök gyártóját és típusát, de már éreztem hogy túl bonyolult lett a hibajegy így is ezért kiszedtem belőle pár dolgot. Ez mindig nehéz hogy mit írjunk le, ha keveset akkor jogos a felháborodás hogy sunnyogunk, ha sokat akkor millió levél jön vissza hogy nem értik. Szóval a plusz konkrétumok:

- Nem hardware hiba volt, az egyszerű, és kb magától megoldódó / helyreálló hiba.

- Szoftver hiba volt ami mindig macerás, gyártótól függetlenül.

- A konkrét SW hibás eszköz egy Centec Networks Goldengate ASIC-os, Centec Networks / FS.com switch amin IP Infusion SW fork fut.

- Miért így cseréltünk ahogyan? Mert ez a gyors megoldás, egy másik eszközre átállni több idő tesztelés és több a hibalehetőség is.

- Már a 2. hibánál felmerült hogy Cisco ASR9K legyen a dedikált route reflektor, de nem volt rá elég idő, legalább egy órával hosszabb lett volna a már így is hosszú hiba. Ugyanígy a Linux + FRR is felmerült, de dobtuk ugyanebből az okból.

- Nem véletlen hogy a 3. hiba után csak éjfél után tudtuk a másik gyártmányú route reflektort berkani, elég sok tesztet kellett előtte még elvégezni. Egyébként Cisco Nexus 9300 lett az új route reflekor, azért mert ennek a tesztelésével jártunk legelőrébb a lehetőségek közül.

 

Csemegének legyen itt az első log sor ami után borult minden:

Jun 11 10:07:45 <ip> BGP-3: <ip> Outgoing [ENCODE] extend attr: The remaining packet buffer (4) is not enough for encoding others attr, length of extend attr = 16

Nem tűnik vészes üzenetnek, de ez után jön a random BGP flappelés.

 

Üdv:

Angelo

Még egy gondolat a SW supportról. Felmerülhet bennetek hogy ja persze, kínai a SW. (A HW mindig kínai, szóval az nem érdekes. :-)

Az eddigi tapasztalatunk az hogy az FS.com-nak egész jó a SW támogatása, a dokumentáció nagyon gyenge, de ha a konkrét hibát megírod nekik, kivizsgálják, külön support szerződés és díj nélkül, és kb 1 hét alatt megvan a debug, és plusz 1 hét múlva kapsz bugfixet, egy olyan SW release-t ami majd további 2-3 hét múlva jelenik meg a gyártó weboldalán.

Konkrétan mi mint RackForest kb 1-1.5 éve kezdtük el tesztelni az eszközeiket, és kb 1 éve használjuk is. A kezdeti időszkban talán 2 SW release is jött ki miattunk. :-) Illetve folyamatban van 1-2 SW feature is amit a mi kedvünkért fognak a SW-be rakni.

Hasonló SW bugfix-el kapcsolatban Cisco-s tapasztalatom van, ott az ASR920 platformon volt egy elég csúnya ASIC programozási hiba, de sokkal lassabb volt a debug és a bugfix SW release is.

Illetve a kedvencem szintén egy nagy cégtől kb 1.5 évnyi levelezés és reklamálás (valamint kb 250MFt elköltése) után: "This is a side effect of a known limitation." Megoldás: "We will update the documentation about this limitation".

De ez mind teljesen mindegy amikor egy SW hibát kb azonnal kellene megoldani, erre nincs idő akármennyire jó supporod van akárkitől. Csak a workaround-ok jöhetnek szóba.

Visszakanyarodva az eredeti kérdésre, igen az FS.com-os IP Infusion-ban érzésre több a SW hiba mint más nagyobb brand gyártóknál, de a nagyobb cégeknél is estem már pofára ilyen esetekben. (És ahogyan írtam van hogy közlik, hogy nem is javítják a hibát.) A tanulság hogy mindent alaposan le kell tesztelni mielőtt élesbe menne, de sajnos a terheléssel és skálázhatósággal kapcsolatos dolgokat nem igazán lehet letesztelni előre.

Üdv:

Angelo

Update: A félreértések elkerülése végett, az FS.com kb olyan matricagyár mint a HP. :-) Nem minden FS.com switchen van IP Infusion, és nem mindegyik Centec ASIC-es. Itt konkrétan az S8050 és S5850 eszközökről van szó, ezekben ugyanaz a bináris sw image fut. Ezeknek a gyártója és SW fejlesztője a Centec Networks.

Mondjuk bennem a partoldalról felmerül a kérdés, hogy BGP route reflektort miért egy switch processzorán akarunk futtatni, "normál" x86-os szerver helyett... jó, persze, azt mondjuk értem, hogy így elvileg van rá support, míg ha Linuxon futtatok valami open source cuccost, akkor arra annyira nagyon nincs.

mivel ennyire mélyen nem írták le a belső infrastruktúrát, én inkább azt feltételezem, hogy a RR eddig VM-en futott, n db (nem dedikált CPU-val) aztán kapott y db  dedikált CPU-t (amikor kiderült, hogy kevés) majd végül fizikai vasat.

A másik része, hogy attól, hogy opensource - nem jelenti, h nincs rá support...

Általában egy tankönyvi VxLAN topológiában a TOR (Top of Rack) switchek a Leaf eszközök, és az aggregáció a Spine, és a Spine-ra rakják rá a BGP route reflector funkciót. Nagyon ritka hogy ne a hálózati eszközön fusson a BGP RR.

Nagyon sok gyártó nem szereti / támogatja ha nem az ő SW-ük a BGP RR. Pl Nexus switchek, FRR-es BGP RR-el, ez nem igazán támogatott hivatalosan.