Life long learning. Ez már csak egy ilyen szakma. Szerencsére.
Jó egy hónapja álltam rá arra, hogy rendszeresen tanulok. A hangsúly a rendszerességen van – tanulni eddig is kellett.
A stratégia a következő: reggel tea felrak, elkortyol, internet átfut (email/feed/link). Utána, amennyiben nyugis nap van, ebédig tanulok. Ha zűrös, akkor csak egy órát. Outlookba jegyzetelek, a végén a levelet hazaküldöm.
Napközben az anyag ülepedik… a vérnyomás meg emelkedik… de ez a természetes.
Este rászánok egy órát és a délelőtt átvett anyagból csinálok egy írott jegyzetet. (Nekem ez jön be – leírni kézzel a vázlatot. Egyetemi vizsgára készüléskor a konyhaasztalunkra készítettem apró betűkkel jegyzeteket. A vizsga előtti napon már úgy nézett ki az asztal, mint egy burda szabásminta: vázlatpontok, nyúlfülek, nyilak. A szép nagy asztalon át lehetett tekinteni az egész tantárgy kapcsolatrendszerét – feltéve, ha a takarítónő nem törölte le közben. De ez igen erősen meg lett neki tiltva.)
Honnan jön a témaválasztás? Több méter könyv gyűlt fel a szekrényemben, ezekkel szép módszeresen haladok. De magunk között szólva, jobban szeretek csapongani – ha a reggeli feed olvasás során találok valamit, szívesen indulok el inkább azon a nyomon.
A napokban futottam rá egy témára és a linkek olyan oldalhoz vezettek, melyet véleményem szerint nem jegyzetelni érdemes, hanem értelmezni, összekapni – lefordítani. És persze elkalandozni. De ha ilyet csinálok, miért ne tegyem a blogban?
Ez merőben újdonság lesz, eddig ugyanis IT témakörben csak szívásokról irkáltam. Dehát mindig azt sulykolják, legyünk proaktívak… nosza.

A téma: routolás Exchange organizációban, azon belül is a link state table környéki problémák kezelése.

Kályha… ahonnan elindulunk: routing group (RG).
Azt gondolom mindenki tudja, hogy az Active Directory leánykori neve Exchange 5.x volt. Itt kisérletezték ki a fiúk a később nagyobb léptékben alkalmazott módszereket. Az összefonódás később is jól látható, az Exchange 200x úgy tapad rá az AD-re mint a kígyók Laookon családjára az ismert szoborcsoporton. Rengeteg átfedés van közöttük és akad analógia is szépen. Egyik ilyen a routing group – site analógia. Nagyjából ugyanaz létezésük oka: információs folyam terelgetése. Site esetén ez a replikáció, routing group esetén pedig a levéltovábbítás. Mindkettőre igaz, hogy egy egységen belül nagysebességű kapcsolattal rendelkező gépeknek illik lenniük – póriasan szólva, az a jó, ha egymásba ér a farkuk.

Kitérő: Azért nem csak a kapcsolat sebessége szabja meg a csoportosítást. Ha mixed módú organizációnk van, és szeretnénk több administrative group-ot is bevezetni, szomorúan fogjuk látni, hogy mindegyiknek külön RG kell.

A routing group létezésének értelme: csoporton belül a szerverek orrba-szájba kommunikálnak egymással (ugye, a nagy sávszélesség) – csoporton kívül viszont adminisztrátor által szabályozott módon, konnektorok segítségével. (Imádom ezt a szót: konnektor… konnektor. Azannya. Plasztikus. Fogom az egyik végét és feldugom az Exchange szerverbe. A másik végét meglengetem a fejem fölött és beleállítom valamibe, legyen az bármilyen alkalmazás. És ezt tessék szószerint érteni: az Exchange mind a külvilággal, mind saját magával legnagyobbrészt különböző konnektorokon keresztül kommunikál.)

No, tehát vannak routing groupok, melyeket konnektorok kötnek össze. Nincs megkötve, mennyi; nincs megkötve, hány bridgehead szerver lehet. Szabad a pálya. Ellenben minden routing groupban lennie kell egy routing group masternek. Ő az óvónéni. Ő tud mindenkiről mindent; ő terelgeti a leveleket konnektorról konnektorra (egy kis dombra lecsücsülünk, csüccs); ő rak rendet, ha kitör a balhé. Nem fontos, hogy ő legyen a bridgehead – de fontos, hogy tudjon mindenről.
Mi is ez a minden? Nos, a konnektoroknak állapotaik vannak: ezeket hívjuk link state-nek. És van egy táblázat, amelyikben a routing groupok összes link state információja megtalálható: ez a link state table.

Hosszú, de legalább körülményes bevezetőm végén eljutottam végre ahhoz a vadhoz, melynek természete képezi leginkább ezen cikk mondanivalóját. Huh.

Tudjuk, hogy az optimális route útvonalhoz az RG master a következő információkat használja fel: a konnektor költsége, az üzenet típusa, a különböző tiltások. Logikus, hogy ezeknek szintén bent kell lennie a link state táblában – amellett, hogy a konnektor éppen Up vagy Down.
Ha valaki el akar gyönyörködni egy ilyen táblázatban, javaslom, próbálja ki a winroute programot. Aki nem akar elgyönyörködni benne, az ráfaragott, mert a leírt módszerek közül elég sokban kell használni a programot – és higyjétek el, jobb gyönyörködve, jó hangulatban bogarászni, mint fásultan.

Felmerülhet a kérdés, hogy honnan fog tudni mindenről az RG master? Természetesen a member szerverek folyamatosan tömik feljelentésekkel.

  • A member szerveren lévő levélkezelő mechanizmus, az ún Advanced Queue (önállóan megérne egy cikket) rányalja a kimenő levélre a legközelebbi hop címét. Az infót a lokális link state táblából veszi.
  • A levél visszapattan.
  • A member szerver vár max. 10 percet majd feljelenti a konnektort. Jól.
  • Az RG master down-ba teszi a konnektort a központi link state táblában majd szétküldi azt a member szervereknek.
  • De a member szerverek nem nyugszanak. Sutyiban folyamatosan pingetik a ledőlt konnektort.
  • Tegyük fel, hogy a konnektor visszatér a harcmezőre. A member szerverek, mivel pingetik, észreveszik, boldogan üdvözlik és közlik az örömhírt az RG masterrel.
  • Az RG master blazírtan újra módosítja a link state táblát és ismét szétküldi.

Az egész kommunikáció a 691-es TCP porton történik. Emellett játszik még a 25-ös is – de ez az Exchange-ben mindenhol játszik, lévén ez az SMTP portja. A routing információk küldözgetéséért a Routing Engine Service, röviden RESrvc felel. (Gyakorlati jótanács: ha újra kell indítani, akkor praktikusabb az IISadmin szervízt piszkálni – ez ugyanis újraindítja az SMTP szolgáltatást is, praktikus sorrendben.)

Mi van akkor, ha pont az RG master dől ki a sorból? Értelemszerűen minden member szerver a lokális link state táblát használja, függetlenül attól, milyen változások történnek a nagyvilágban. Aztán egyszer csak visszajön az RG master – akár megjavítják, akár újat húznak fel, akár kinevezik valamelyiket. (System manager, RG, Members, Server, Set as master) Az új főnök körbenéz a nagyvilágban, gyorsan begyűjti a lokális link state táblákat, lekezeli a feljelentéseket, szétküldi a jó táblákat… röviden szólva asztalra csap és gatyába rázza a macska nélkül cincogó egereket. (Gyönyörű.)

Láthatjuk tehát, hogyan működik egy egészséges rendszer. (Ez olyan, mint az ideális – nem létezik. De állandó cél.) A működés ismerete pedig már fél siker a hibajavításhoz.
Milyen eszközöket fogunk használni:

  • Winroute segédprogram. (Igen, mondtam, hogy meg kell szeretni.)
  • Felemelt logolás.
  • Józan ész. (Valahonnan időben szerezzük be.)

A logolást az Exchange System Managerben lehet állítani, a megfelelő objektumokon. Legalábbis a tankönyvek szerint. Érdekes módon, amikor nagy szar van, mindig bele kell turkálni a registrybe és még feljebb csavarni a logolást. (Az ESM csak 5-ös szintig engedi állítani – pedig a legerősebb a 7-es szint.)
A felcsavarás a következőképpen történik: a registry HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services ágában megkeressük a minket érintő szolgáltatást, azon belül leásunk a Diagnostic menübe, megkeressük a minket érintő eseménycsoportot és 7-re állítjuk az értékét.
Arra azért készüljünk fel, hogy ilyenkor olyan 70 szerzetesnyi sebességel íródik a kódex log.

Nem beszéltem még egy érdekességről. Ha elindítjuk a Winroute programot, láthatjuk, hogy minden routing groupnak verziószáma van, [major.minor.user] formátumban.
Meglehetősen magáért beszélők a nevek, de érdemes egy-két apróságot megemlíteni róluk.
Átfogóan nagy – major – változás viszonylag ritkán történik. Ez alatt leginkább olyan változásokat kell érteni, amikor az AD nyúlkál bele az Exchange lelkivilágába. (Megjegyzés: ha a major index 0, az azt jelenti, hogy nincs link state táblás ökörködés -> azaz vagy csak egy routing group van az organizációban, vagy az illető routing group Exchange5.5 alapú – a jó öreg GWART.)
Közepes – minor – változás általában a konnektorokhoz kötődő változást jelent.
A legutolsó szám – user – változását mindenféle szutyok apróságok okozhatják: WMI piszkálta meg az RG mastert, megváltozott a routing group tagsága, át lett nevezve a routing group, elköhögte magát a szerverszoba egere, stb.

És most akkor lássunk konkrét hibajelenségeket és azok lekezeléseit:

1. A member szerver nem látja mesterét

Bizony, ez baj. A fentiek alapján sejthetjük, hogy ilyenkor a lokális link state tábla dolgozik, valamilyen őskori adatokkal.
A jelenséget könnyen felismerhetjük, elég a Winroute-ban a piros X-ekre koncentrálnunk. Ott találjuk, közvetlenül a szerver(ek) neve(i) mellett.
Mik okozhatják? Csupa triviális dolgok:

  • A Routing Engine Service nem fut valamelyik érintett gépen. Vagy fut, csak nem jól.
  • Egy gonosz firewall blokkolja a 691-es portot. Ezt telnettel tudjuk ellenőrizni.
    Emellett konkrétan azt is meg tudjuk nézni, hogy mi a helyzet a 691-es porttal a szervereken. A ‘netstat -a -n’ parancs megmutatja, mely portjaink nyitottak és merrefelé. Member szerver esetén látnunk kell egy kapcsolatot az RG master felé – RG master esetén látnunk kell egy-egy kapcsolatot minden member szerver felé. (Pontosabban, nem csak egyet, két szerver több szálon is kapcsolódhat.)
  • Okozhat problémát a computer felhasználó hibás autentikációja is. (Logikus – ilyenkor a számítógép kiesik a haveri körből.) Érdemes átnézni az eventlogot. Ugyanitt fogjuk megtalálni a transzport hibára utaló jeleket is. (Event kód: 961/962)
  • Elveszhet a bűnös szerver ‘Send as’ jogosultsága. (Elég cifra jogosultsági rendszerben vannak a szerverek; a domainprep létrehoz nekik néhány csoportot és ezekre beállít egy default jogosultságot. Elég könnyű ezt a rendszert felrúgni – bőven elég, ha átrakjuk a csoportokat egy másik OU-ba. Tesztelve.)
    A nyomozáshoz a Microsoft a Regtrace programot ajánlja. Én is ezt tenném a helyükben, tekintve, hogy ez egy nagyon praktikus program – nekik. Mezei halandó sajnos nem tud vele mit kezdeni. (Szépen le van írva, hogyan kell elindítani, hogyan kell paraméterezni, egyáltalán hogyan monitorozza a program a történéseket, miközben reprodukáljuk a hibát, szépen le van az is írva, hol találjuk az eredményként kapott bináris fájlt és hogyan kell azt elküldeni a PSS-nek visszafejtés céljából.)
  • Lehet, hogy a szerver rossz nevet használ a bemutatkozáskor. Elismerem, ez annyira azért nem triviális ok. A szerverek az ún. ServerPrincipalName (SPN) értékkel azonosítják magukat a routing groupban. Ez az érték a szerver Network Adress attribútumának ncacn_ip_tcp változójában tárolódik, megtekinteni illetve módosítani ADSIEdit-tel vagy LDP-vel lehet. Kicsit háklis banda ez a routing group, csak akkor fogadják el a bemutatkozást, ha FQDN formájú a név. Netbios név, IP cím nem megfelelő. Olyan ez, mint a nyakkendő az elit mulatókba.
  • Az, hogy a többiek nem ismerik fel a bűnös szervert, sokféle okból következhet. Lehet jogosultsági hiba, lehet bemutatkozási hiba – és lehet Kerberos autentikációs hiba, mondjuk egy lejárt computer jelszó miatt. Ekkor célszerű az NLTEST segédprogit használni. (Ez igaz általánosan is, minden olyan esetben, amikor netlogon hibára gyanakszunk.) A program használatáról van egy jó leírás. Röviden annyi, hogy el kell indítani a megfelelő paraméterrel – mely paraméterek egy szép nagy táblázatban találhatók és arra vonatkoznak, hogy mire vagyunk kíváncsiak – majd újraindítjuk a Netlogon szolgáltatást és megnézzük, mi került a %windir%\debug\netlogon.log fájlba.
  • Természetesen DNS. Ezt talán mondanom sem kellett volna. Ha a szerverek eltérő tartományokban vannak, meg kell nézni, rendesen megy-e a névfeloldás. A magam részéről megnézném akkor is, ha azonos tartományban vannak. Fontos, hogy a virtuális SMTP szerveren található FQDN megegyezzen a DNS-beli FQDN-nel.
  • Legvégül érdemes elgondolkodni, nem vezettünk-e be mostanában valami elkefélt GPO-t, mely esetleg belepiszkálhatott a korábban részletezett folyamatba.

2. RG mesterek háborúja

Megjelenik a sötét oldal.
Egy routing groupban az az RG master, akiről a szerverek fele+1 szerver azt állítja. Ezt a member szerverek ún. link state attach információk küldözgetésével beszélik meg. Értelemszerűen egy szervernél ő maga lesz a főnök – azaz alaphelyzetben mindig az elsőnek telepített szerver az RG master. Az is marad, amíg az adminisztrátor másképp nem rendelkezik.
Mikor tör ki a háború?

  • Például akkor, ha az adminisztrátor úgy léptet elő RG mesterré egy gépet, hogy az öreg mestert nem lépteti vissza.
  • Az egyik member szerver megőrül és hamis információkat kezd terjeszteni.
  • Hálózati hibák következtében nem érnek célba a link state attach információk, miközben főnökváltás történt.

Mi lehet a teendő? Először is megvizsgáljuk a hálózatot, mennyire atombiztos. Elérhetők-e azok a bizonyos 691/25 portok? Megy-e az AD replikáció? Nem rágta-e el a patkány a vezetéket?
Másrészt magunkba szállunk és végiggondoljuk, nem töröltük-e pusztán szórakozottságból azt az Exchange szervert, amelyik eddig az RG master volt? Esetleg nem léptettünk-e elő egyet úgy, hogy még a régi is megvan?
Ha ez utóbbi esetek egyike történt, akkor az ADSIEdit vagy LDP programokkal gyorsan korrigálhatunk, az üzemzavart meg ráfoghatjuk a napfolt tevékenységre. (Itt található egy írás, hogyan állítható vissza egy véletlenül kigyapált routing group. Azért ne próbáljátok ki éles rendszeren.)

3. Van olyan routing group, amelyik nincs

Felmerülhet a kérdés, hogy ha nincs, akkor hogyan látjuk. Nos, például a Winroute segédprogramból. Mutatja, hogy itt kérem van egy routing group, de a fene se tudja, hogyan hívják és mi ez.
Mondhatnánk, hogy a francot sem érdekli, nem kér enni. Csakhogy ott van. Érvényes routing információkkal. Hogy neki vannak konnektorai. Balszerencsés esetben egészen olcsók – és ilyenkor ebbe az irányba próbálnak menni a levelek. Mely irány nem létezik.
Nyilván törölni kell… de hogyan? Hiszen nem létezik!
Farkába harapott a kígyó.
Ravasz trükkök vannak a rendrakásra.

  • A legelső, hogy megnézzük, olyan felhasználóval vagyunk-e belépve, akinek legalább olvasási jogai vannak az AD konfigurációs névterében? Ha olyan a felhasználó, be tudott-e rendesen lépni? Ha belépett, eléri-e a konfigurációs névteret? Tudom, triviális… de egy autentikációs hiba miatt egyszer kis híján megőrültem egy hasonló szituációban.
    Általában is az egyik legfontosabb hibafelderítési lépés meggyőzödni, hogy egyáltalán fennáll-e a hiba… nem az észleléssel van-e inkább gond?
  • Nos, benne vagyunk az Atyauristens csoportban, közvetlenül az RG master gépen futtatjuk a Winroute-ot, mégis látszik, aminek nem lenne szabad látszódnia. Erre mondják azt városiasan, hogy kaki van a ventillátorban. (A póriast most inkább hagyjuk.)
    A helyzet az, hogy valószínűleg egy törölt routing group-ra vonatkozó bejegyzés beragadt a link state táblába – és a RESvc képtelen kitörölni. Az egyetlen megoldás a tabula rasa – kezdjünk mindent előlröl. Választhatjuk azt is, hogy újratelepítjük az összes Exchange szervert (nemröhög – a Microsoft eszköztárában szerepel ez a lehetőség is), de szerencsére van egy egyszerűbb megoldás is: a bűvös újraindítás. Némi kényelmetlenséget okoz, hogy az organizáció összes szerverét kell egyszerre újraindítani, úgy, hogy először mindenhol az RG master gépek álljanak fel. Kényelmetlen, de ha worldwide organizációnk van, akkor itt a lehetőség néhány potya repülőjegyre.
  • Az előbb hazudtam, de csak a drámai hatás kedvéért. Van egy másik lehetőség is: felhergelhetjük a REMonitor segédprogramot, hogy injection módban működjön. Erről igen jó cikket írt az Exchange gárda, én itt csak összefoglalom.
    Először a rossz hír: a program nem tölthető le szabadon, a Support-tól kell igényelni. Ha megvan, akkor első lépésben be kell állítani a futtatásához szükséges jogosultságot. A fiúk elég sokat vacakolnak ezzel, végül arra jutnak, hogy a legegyszerűbb, ha trükkös módon a local system account nevében futtatjuk. Ez – gondolom – ismerős. Beidőzítünk egy command prompt-ot és az a local system account nevében fog elindulni. Nos, itt csak annyi a probléma, hogy távolról ütemezve a taszkot, az a konzolon fog promptot adni. (Windows2003 esetén no problemo, az ‘mstsc /console’ kihúz a bajból.) Azért nálunk valamivel mások a viszonyok… feltételezem, minden Exchange adminisztrátor azzal kezdte a tevékenységét, hogy az Atyauristen felhasználónak visszaadta a “Send as”/”Receive as” jogokat – ez meg éppen elég a program futtatásához. (Jaj, ne üssenek… nem mondtam semmit…micsoda?… három év vasban?…)
    Ha rendeztük a jogosultsági matyit, akkor végre elkezdhetünk dolgozni. Bemásoljuk a progit a bin könyvtárba, elindítjuk. Kedvesen közli, hogy mely fázisnál jár, mit talált… majd vége.
    Mit is csinált?
     

    • Ha talált beazonosíthatatlan routing group-ot, törölte belőle a szerverek és konnektorok bejegyzéseit.
    • A routing group-hoz tartozó névterek címeibe belebiggyesztette a ‘deleted’ kifejezést.
    • A major indexet megnövelte eggyel.

    Ezzel sikeresen elérte, hogy egyrészt efelé a routing group felé soha a büdös életben nem fog levél kóvályogni, másrészt a link state table is lecsökkent valamelyest – ami nem hátrány nagyméretű organizációk esetében.
    Amit viszont nem ért el, az az, hogy nem tűnik el a rosszindulatú routing group bejegyzés a táblából. Sajnálatosan ezt csak az újraindításos módszer biztosítja.

4. Egy ledőlt konnektor üdének, frissnek látszik

Ilyesmi is előfordulhat. Mondanom sem kell, elég ciki, amikor szembesülünk a ténnyel, megtekintve a Winroute listáját.
Pedig simán előfordulhat.

  • Olyan konnektorunk van, amelyiknél bizonytalan a hídfőállás létezése. Akkor fordulhat ilyesmi elő, ha a konnektorunk pl. DNS-t használ ahhoz, hogy a következő hop-ot meghatározza. Tipikus példa erre egy SMTP konnektor, amelyik nem smarthost-hoz kapcsolódik.

    Megjegyzés: Amikor azt írom, hogy SMTP konnektor, mindig kicsit zavarban vagyok – mert eszembe jut, mennyit agyaltam anno, hogy mi is az a virtuális SMTP szerver és mi is az az SMTP konnektor és tulajdonképpen milyen viszonyban is vannak ezek? Fóti Marci gondolatát beépítve imhol egy plasztikus kép: van az SMTP szolgáltatás, mely tetszőleges számú virtuális SMTP szervert képes üzemeltetni. Az SMTP konnektor pedig tulajdonképpen a virtuális szerverekre vonatkozó SMTP policy.

    De akkor is előfordulhat ez a jelenség, ha az ún Routing Group konnektornál (RGC) a forrás bridgehead rovatba az <any> opciót hagyjuk bent. (Nem akarok most kitérni az egyes konnektor típusokra, mert a cikk lassan kezd fárasztó lenni. Nekem legalábbis meglehetősen.)
  • Smart host esetén sem vagyunk teljesen biztonságban, ha nemrég állítottuk át a távoli bridgehead szerver paramétert.
  • A konnektorunk Exchange5.5 verziójú konnektor vagy a konnektor egyik hídfőállása 5.5-ös szerver. Már tudjuk, ekkor nem játszik a link state table.

5. A konnektor bungee-jumping-ot játszik

Azaz meglehetősen nagy frekvenciával hol ledől (down), hol feláll (up). Lehet, hogy ez egy kellemes szórakozás a konnektor számára, de elég sokba kerül az Exchange rendszernek. Ugyanis a konnektor minden egyes állapotváltása bősz kommunikációt indít el a member szerverek és az RG master között, mire berendezik a megváltozott állapotnak megfelelő link state táblát. Aztán mire befejezik, az a hülye konnektor megint ugrik egyet.
A szóbajöhető okok:

  • Zavar az erőben, a network hülyéskedik. Netmon, vagy Ethereal… izé Packetyzer. Kinek melyik a szimpatikusabb.
  • A konnektorok alatt dübörgő protokoll bolondul meg. Összeakadnak az X.400 protokoll rétegei. Egymásba gubancolódnak az SMTP protokoll alsóbb rétegeiben lévő lábai. A Microsoft szerint ez leginkább a külső fejlesztésű implementációknál fordul elő. Naná.
    A megoldás ebben az esetben is Netmon és barátai.

Illetve létezik egy átmeneti megoldás, úgynevezett körbedolgozás. Van egy patch… mely valamit csinál. Sajnos, hogy mit, az nem derül ki. Csak az, hogy ilyen esetekben tegyük fel.
Pontosabban, eredetileg arra találták ki, hogy amikor Exchange5.5-ről frissítettünk Exchange2000-re és a nagyméretű rendszerinformációs forgalom (ORG_INFO) megakadályozza a levélküldést a lassú vonalon, akkor toljuk a képébe a foltot. Feltételezem, valahogy cseppekben adagolja a változásokat.
Élesebb szemű olvasók valószínűleg észrevehették, hogy itt nem ez a szituáció forog fenn. De ez egy remek folt, most is használhatjuk, csak bele kell túrni egy kicsit a registry-be. (Már vártam.) A HKLM\SYSTEM\CurrentControlSet\Services\RESvc\Parameters alatt kell létrehozni egy AttachedTimeout nevű dword kulcsot, majd értékének beírni egy szimpatikus számot 1 és 604800 között. Nem mondhatjuk, hogy nem kaptunk elég teret fantáziánk kibontakoztatásához.

Nos, a végére értem.
Akit ennél is mélyebben érdekelnek a routolási furfangok, itt talál egy remek letölthető könyvet a témáról.