Spagetti routing tábla

By JoeP 

Egyik ügyfelünknél beköltözött a nagy Sztochasztikus Vezetékelharapó az informatikai rendszerükbe. Időnként ugyanis az egyik kritikus telephelyükről nem érték el a központi Exchange szervert. Máskor viszont minden tökéletesen ment.
- Máskor tökéletesen ment? - kérdeztem vissza - Akkor hívjátok a networkos emberünket, mert ez nem Exchange hiba lesz.
És dobáltam tovább a dartsokat.

A networkos ember megnézte a routereket, switcheket, tűzfalakat… minden tökéletesen működött. Nem volt mit tenni, meg kellett várni egy üzemzavart. Meg is jött. Networkos ember ismét átnézett mindent. Alles oké. Csak éppen az Exchange szerver se telnet, se icmp szinten nem volt elérhetÅ‘.
Vicces.
Aztán a kolléga tovább vizsgálódott, végül arckarmolás mellett felüvöltött: a rohadt istenit az Exchange szervernek!
Ekkor tettem le a nyílhegyeket. Lehet, hogy mégis érintve vagyok?

Mielőtt továbbmennénk, pár szó a hálózatról. Ez egy országos kiépítettségű hálózat, rengeteg telephellyel, subnettel, dmz-vel. Nem viccelek, a dmz-k mennyiségre kétszámjegyűek, nem ritka a két-három kijárattal bíró subnet sem. Nem is a szétszórt routerek kezelik a route logikát, hanem van középen egy RSP (Route Switch Processor), ő az ész. Meg a default gateway is mindenhol.
És akkor nézzük meg, mi borította ki a kollégát. Kéremszépen, megnézte az Exchange szerver route tábláját - és vagy 187 bejegyzést talált benne. 187 rosszat. Ez már nem volt annyira vicces.
Arra viszonylag hamar rájöttünk, mi történik: jön egy Outlook kliens valamelyik másik subnetből, az Exchange szerver meg felveszi annak a routernek a lábát a route táblába, ahonnan a kliens jött, természetesen a szabályban a kliens IP címe szerepel 255.255.255.255 maszkkal.
De miért is okozott ez a jelenség ekkora problémát?
Az elején mondtam, hogy az a bizonyos telephely borzalmasan kritikus az ügyfél számára. Ergo redundáns bérelt vonal van kihúzva, úgy, hogy a szolgáltatók sem azonosak. Ha ledől az egyik vonal, a routerek automatikusan átváltanak a másikra, az RSP is ennek megfelelően módosítja az útvonalakat. Csakhogy az a szerencsétlen helóta Exchange szerver minderről semmit sem tud, továbbra is a route táblájában lévő, immár fals kijárattal próbálkozik. Miért nem megy el az RSP-hez? Mert a 255.255.255.255 maszk szorosabban illeszkedik a csomagra, mint a default gateway maszkja.

Vadul elkezdtem keresni a neten, de nem igazán tudtam jól megfogalmazni a kérdésemet. Ha legalább a jelenség nevét tudnám. Végső menedékként dobtam egy körlevelet nagytudású, művelt cimboráimnak, hogy ki találkozott már ilyesmivel. Rövidesen meg is jött a válasz. Gömöri Zoli szerint a router dumál vissza a szervernek, hogy van egy rövidebb út Géza, mostantól menj arra, engem meg hagyj ki a buliból. Stone pedig megírta a jelenség nevét és azt, hogy hol lehet kikapcsolni. Imhol:

  • A jelenség - és a kulcs - neve: EnableICMPRedirects
  • Registry ág: HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\

Ha az érték nulla, akkor a szerver magasról leszarja, mit mond a router.
Beállítottuk, az incidens elhárult.
Jöhetett a problémamegoldás. Biztos, hogy nem okoz galibát ez a registry módosítás? Mivel most már volt név a kezemben, körbenéztem. Találtam is egy ajánlást, hogyan védjük szervereinket (D)DOS ellen - hát például úgy, hogy a fenti értéket egyre állítjuk. Oké. Akkor ez a kérdés meg lett válaszolva.
De miért csak mostanában jelentkezett a hiba, régebben miért nem? Nos, kiderült, volt korábban egy RSP csere. A művelet tökéletesen sikerült, az új RSP remekül működött - csakhogy ez az ún. icmpredirect érték defaultban engedélyezett volt minden lábán. A réginél meg nyilván nem.
Azaz, ha biztosra akartunk menni, akkor nem csak az Exchange szerveren kellett beállítani, hogy ne figyeljen arra, mit mond a router - hanem a routeren is, hogy ne molesztálja a hostokat.
Most, és csak most mondhatjuk azt, hogy lekezeltük a problémát… írhatjuk végre a változásigénylést.

By JoeP június 11, 2008 at 23:50  Tags:   Posted in: Windows server

Leave a Reply