A LAN mint szolgáltatás

Már az előző poszt is esélyes volt a legalja címkére, de ott a mókolási faktor sokat emelt rajta, ez viszont tipikus legalja lesz, valahogy nálam ez gyakran a kiszervezéssel párosul. Van két telephelyünk messze-messze, ahol a LAN-t eszközöstül, mindenestül szolgáltatásként vesszük egy helyi IT-s cégtől. Ez teljesen rendben lévőnek hangzik, elvileg ugye a szerződésben definiálva vannak a szolgáltatási szintek (SLA), reakcióidők, felelősök stb. ezt a szolgáltatást legalább öt éve igénybe vesszük, bizonyos időközönként automatikusan megújul, az azért mindenesetre furcsa, hogy a pontos részleteket a network team nem ismeri, illetve az utóbbi időkben kiderültek érdekes dolgok. Mentségünkre szóljon, hogy senki nincs már a cégnél, akinek köze lehetett ennek a szerződésnek megkötéséhez, és valahogy a pozíciók átadása-átvétele körül elsikkadtak a részletek.

Az egyik ilyen dolog, hogy a szolgáltató reakciói alapján meg voltunk győződve, hogy legjobb esetben is csak 5/8-as támogatást várhatunk tőlük nem túl sebes megoldási időkkel. Bizonyos WAN átszervezések kapcsán az egyik említett telephelyen szükség volt némi LAN változtatásra, új VLAN-ok, link subnetek, ilyesmi, és sehogy nem tudtuk a karbantartási ablakot beletuszkolni az 5/8-as munkaidőkeretbe. Szóval már épp azon gondolkodtunk, hogy megkérjük a LAN szolgáltató céget, hogy vállaljanak az 5/8-as időkereten kívül munkát, amikor a főnököm főnöke közölte a szerződésre hivatkozva, hogy bizony 7/24 Gold++++  supportunk van, bármikor kérhetünk módosításokat.

Voltak azonban korábban is gyanús jelek: tavaly bekértem tőlük mindkét telephelyről a layer2-es dokumentációt, mert semmit nem találtam ezekről a site-okról, de azt válaszolták, hogy ilyesmi nekik sincs, viszont tudnak készíteni, ha kérjük. Különösebb gondolkodás nélkül rávágtam, hogy kérjük, bár már akkor sem értettem, hogyan tudnak támogatni olyasmit, amiről alapvető dokumentációk hiányoznak. No, el is készült a kért anyag, mivel nem túl nagyok a telephelyek, 2-300 port mindkettő, a layer2-es ábrák eszközökkel, VLAN színekkel, IP-kkel együtt is csupán 2 oldalt tettek ki. Egy hónap múlva jött egy belsős telefon, hogy milyen szolgáltatást kértem ettől a cégtől, és hol van az általuk küldött dokumentáció, merthogy dokumentáció címén egy 1000 euró + forgalmi adós tételünk van. Mondanom sem kell, azóta is nagy becsben tartjuk azt a PDF-et, mind a két oldalát.

Ezek után már azon cseppet sem csodálkoztam, amikor jöttek az újabb telefonok, hogy a konfiguráció módosításáért, akkor is, ha az csak egyetlen sor, száz eurót számolnak fel, a több ezer eurós havidíjon felül. Ilyenből is gyűjtöttünk egy párat az elmúlt időszakban.

A legjobb viszont mostanában történt, az egyik ilyen kiszervezett LAN-os telephelyen a felhasználók elkezdtek panaszkodni, hogy szakadozik a kapcsolatuk, hálózati problémáik vannak. A WAN hibakeresés semmilyen gondot nem mutatott, sőt, WAN szempontból kivételesen jó helyzetben van az említett telephely mind sávszélességet, mint késleltetést illetően, csomagvesztésről pedig gyakorlatilag nem volt historikus adat a monitorozó rendszerben, így hamar előkerült a LAN, mint lehetséges hibaforrás. Igen ám, de mi nem férünk hozzá az ottani eszközökhöz, így hibajegyet nyittatunk a szolgáltatónál, részletes hibajelenségekkel, időpontokkal, user kontakt információkkal stb. Ez történt egy pénteki napon. Aznap a hibajegy megnyitásán túl sokra nem jutottak (7/24-es support, néhány órás elhárítási idővel!). A következő hét elején már állt a bál, mert a probléma még mindig élt, megoldás sehol, mi meg csak a kezünket tudtuk széttárni, hiszen az adott telephelynek még a közelében sincs  networkös, az eszközöket pedig nem akartuk újraindíttatni hátha van valami a logokban. Ekkor már direkben megadtuk a szolgáltató elérhetőségét a felhasználóknak is, és végül sikerült nekik szerdára (!) kihívatni egy hálózati mérnököt. A mérnök kijött, szétnézett a rendezőhelyiségekben, tett néhány megjegyzést arra vonatkozólag, hogy 10+ éves eszközökön fut a LAN (amit ők szolgáltatnak), és hogy látott egy-két kósza hub-ot is, meg hogy milyen kevés log-ot tudnak tárolni ezek az öreg eszközök, majd elment úgy, hogy nem volt megoldás. Naivan azt gondoltam, hogy átnézi majd legalább a trönk portok konfigurációit, az STP beállításokat, vagy végez valamilyen tesztet, hoz esetleg gyártóspecifikus szoftvert, amivel adatokat gyűjt, leszűkíti a probléma forrását bizonyos eszközre, eszközökre, vagy hogy egyáltalán csinál valamit, bármit. A végén a mérnök távozása után maguk a felhasználók lokalizálták a probléma forrásaként az egyik switchet, majd arról átköttettek mindent az ottani IT-s sráccal más eszközökre. Máig nem tudjuk, mi baja lehetett annak a switchnek. Arra azért kíváncsi lennék, mennyit fizethettünk a kiszállásért, csak gyanítom, hogy ez ismét az ezer eurós kategória lehetett...

Ez az esemény viszont végre beindított valamit: döntés született arról, hogy ennek a cégnek mennie kell, és insourceolva lesz a LAN, mert ezt a szolgáltatási szintet lazán megugorjuk belső erőforrásokkal, több országnyi távolságból is. Azt már végképp nem értem, hogy miképp és miért, de mindkét telephelyen kiderült, hogy raktárban állnak öt év körüli Nortel eszközeink az 5000-es szériából, 8000-es szériából, nem is kevés, összesen kb. 1300 portnyi, szóval van miből kukázni -- enyém a megtisztelő feladat, hamarosan utazhatok. Addig is fel kell szívnom magam Nortel (mostanában Avaya) CLI-ből, legalább az olyan alap témákban mint a VLAN, STP, naplózás, SNMP, port security, basic routing, DHCP relaying, stacking, firmware kezelés, mert annyira nem mozgok otthonosan Nortel/Avaya fronton, viszont néhány hét múlva már rutinosan kell mennie.

NAT444 dual stack modell az átálláshoz

Újabb modell az IPv6 átálláshoz, ami jelenleg nincs még fent a Wikipedián sem: NAT444. Persze annyira azért nem új (januári), és forradalmi dolgokat nem érdemes várni tőle, leginkább maga az elnevezés volt újdonság nekem még most, májusban is. Ahogy az is, hogy a NAT64 mintájára egyre több helyen lehet olvasni NAT44-ről is, ami nem más, mint a megszokott IPv4 NAT, aminek ugye mindkét oldalán IPv4-es címek vannak, innen a 44. No, a NAT444 lényegében ugyanez, csak kétszer: az IPv4-es csomagoknak két NAT táblán kell átküzdeniük magukat, az első a szolgáltató által biztosított IPv4/IPv6 dual stack végberendezés, a második pedig az LSN (Large Scale NAT) vagy más néven CGN (Carrier Grade NAT) eszköz a szolgáltatónál. Rendes NAT444-es ábra sem volt sehol, így rajzoltam egyet én:

Bár nincs belső információm a hazai szolgáltatóktól, azért szemernyi kétségem sincs afelől, hogy ebből a modellből az LSN/CGN rész előbb-utóbb meg fog valósulni az otthoni felhasználók számára, vagy akár olyasmit is elképzelhetőnek tartok, hogy a szolgáltatók drágábban adják majd az LSN/CGN nélküli előfizetéseket mint a szolgáltatói NAT-os és/vagy IPv6-os előfizetéseket. Ami viszont a dual stack végberendezések (SOHO router) tömeges elterjedéseset illeti, itt azért vannak kétségeim, évtizedes távlatban bizonyára reális lehet, hogy a felhasználók jelentős százalékánál megjelennek ilyen eszközök.

Visszatérve a NAT444-re: komoly hátránya, hogy viszonylag bonyolult CPE eszközre van szükség ahhoz, hogy a végfelhasználó hozzáférhessen mind az IPv4-es, mind IPv6-os erőforrásokhoz (ez az átmenet alatt az alapvető elvárás), ráadásul ehhez a végfelhasználó eszközein (PC, notebook, egyéb kütyük) is dual stack kell, hogy fusson.

Cisco IOS Netflow ingress, egress, v5, v9

Korábban íram már egy postot Netflow ügyben, az egyik MPLS-szolgáltatónk sok-sok vesződség után sem tudta felkonfigurálni a routerét úgy, hogy az a WAN interfészéről mind a bemenő mind a kijövő forgalomról tudjon információt adni. Mennyire bonyolult egy ilyen dolog? Hát, annyira azért nem... Teljes, jól működő beállításra példa:

router(config)#interface FastEthernet 0/0
router(config-if)#ip route-cache flow
router(config-if)#exit
router(config)#interface FastEthernet 0/1
router(config-if)#ip route-cache flow
router(config-if)#exit
router(config)#ip flow-export destination 10.10.10.10 9999
router(config)#ip flow-export source FastEthernet 0/0
router(config)#ip flow-export version 5
router(config)#ip flow-cache timeout active 1
router(config)#ip flow-cache timeout inactive 15
router(config)#snmp-server ifindex persist

Az interfészenkénti "ip route-cache flow" parancsot minden olyan interfészen ki kell adnunk, amelyen az általunk figyelni és elemezni kívánt forgalom át fog haladni. Mindegyiken. Ennek az az oka, hogy az alapértelmezett Netflow v5 csak a bejövő adatokról gyűjt és továbbít bizonyos időközönként összesített forgalmi információt (flow-t). Ha tehát a routeremben pl. csak az Fa0/0 és az Fa0/1 interfész forgalmaz, akkor az Fa0/1 bejövő adatairól alapból lesz információm, viszont az Fa0/1 kimenő adatokról csak akkor, ha engedélyezve van a Netflow az Fa0/0-n is, és az Fa0/0 bejövő adatait tudja majd a Netflow collector szoftverem az Fa0/1 kimenő forgalom adatainak előállításához felhasználni. Vagyis minden releváns, a forgalmunk által érintett interfészen engedélyeznünk kell a Netflow-t, különben nem azt fogjuk kapni, amire számítunk.

Az "ip flow-export destination" globális konfigurációs módbeli paranccsal állítható be a Netflow forgalom célja, itt kell megadni azt az IP-t vagy hostnevet és portszámot ahol a Netflow adatokat gyűjtő szoftverünk (collector) fülel. A collectornak küldött csomagokban a forrás IP cím annak az interfésznek az elsődleges IP-je lesz, amelyet az "ip flow-export source" után megadunk.

Az "ip flow-export version" egyértelmű, az általunk használni kívánt Netflow verziót adhatjuk meg vele, a két leggyakrabban használt verzió az 5-ös és a 9-es.

A következő két parancs a router által kezelt flow-cache ürítésére (a flow-k collectorhoz való elküldésére) vonatkozik. Az "ip flow-cache timeout active" egy aktív, azaz rendszeresen frissített flow-cache bejegyzés maximális élettartamát adja percekben. A cégünknél használt Netflow Analyzer nevű collector például a max. egy perces élettartamot preferálja, az IOS alapértelmezett érték egyébként 30. Az "ip flow-cache inactive timeout" az inaktív flow-kra vonatkozó időzítő, amely a nem frissített (befejeződött az adott típusú forgalom) flow-cache bejegyzések esetén megadja, hogy az inaktív státuszba lépés után még meddig maradhat az adott flow-cache bejegyzés a cache-ben.

Mivel a Netflow collectorok általában SNMP-s hozzáférést is igényelnek kiegészítő információk beszerzéséhez, pl. router adatok, hostnév, interfész adatok, ezért érdemes az SNMP-t úgy beállítanunk a routeren, hogy egy esetleges újraindulás után az interfészeink ugyanazokat az SNMP interfész indexeket kapják (snmp-server ifindex persist).

Persze még van egy-két kanyar. Itt van mindjárt az alinterfészek kérdése. A "ip route-cache flow" engedélyezi a flow-k gyűjtését egy adott fizikai interfészen és annak minden alinterfészén. Ha kizárólag egy alinterfész adataira vagyunk csak kíváncsiak, akkor azt az adott alinterfészen az "ip flow ingress" paranccsal aktiválhatjuk.

A Netflow v5 és v9 közötti egyik fontos különbség, hogy a v5 - ahogy arról már volt szó - csak ingress irányt támogat, míg a v9 használata esetén megnyílik a lehetőségünk az egress irányú flow-k gyűjtésére is, vagyis v9 esetén akár elfelejthetjük azt a v5-nél még obligát szabályt, hogy minden interfészen engedélyeznünk kell a Netflow-t. Az egress irányú flow gyűjtéséhez szükséges az "ip flow-export version 9", illetve az interfészen az "ip flow egress" parancs kiadása.

Nem árt továbbá, ha figyelünk az "ip flow-export source" interfész megadásánál. Ha fizikai interfészt adunk meg, számolnunk kell azzal az eshetőséggel, hogy az interfész (bármilyen okból) leesik. Ekkor a Netflow collectorunk hibaüzenetet küldhet, még akkor is, ha egyébként maga az eszköz elérhető marad alternatív útvonalon. Megoldás? Az ip flow-export source is elfogad loopback interfészt.

Végül pedig, visszatérve a szolgáltatónkra: körülbelül három hét levelezés és 5-6 telefonhívás után feladtam. Egy kivételével minden általuk adott routeren jól működik a Netflow, az az egy pedig, ami továbbra is csak az egyik forgalmi irányról ad flow-kat, úgyis csak egy backup router. Egyszerűen belefáradtam, csináltak ők mindent, volt router újraindítás, IOS frissítés, Netflow konfig törlés és újrakonfigurálás, másik mérnök újra ellenőrizte, majd egy harmadik, egyszer még egy fél órára jól is ment a Netflow még ezen az egy routeren is, de mire elért a szolgáltatóhoz a "most jó, ne keressétek tovább a hibát" üzenet, már továbbléptek. Az utolsó állapot az volt, hogy v9 használata mellett a router minden portjáról jön ingress és egress adat, kivéve azt a portot, amit tényleg figyelni szeretnék. Nem tudom, hogy mi lehet vele baj, nincs rálátásom a konfigurációjukra, lehet, hogy én sem tudnám megjavítani. Persze az emberben mindig ott motoszkál ilyenkor az a fura érzés, hogy esetleg nem is próbálták ezt annyira komolyan megoldani. Akárhogy is, nem számít már.

A legjobb szolgáltató

Alapvetően nem szeretném, ha a blog szolgáltatók vagy termékek fikázásáról szólna, de a mai esetet muszáj megírnom. A cégünknél az összes telephely esetén a külső tűzfalak, illetve a s2s VPN hálózat üzemeltetése ki van szervezve. Nos, ettől a cégtől kerestek ma telefonon, hogy nem érik el az egyik telephelyünkön az eszközüket, és hogy tudok-e erről valamit.

A kérdéses telephelyen kizárólag s2s VPN van, semmilyen egyéb bérelt vonali kapcsolat nem áll rendelkezésre. Kicsit furcsálltam azonban a dolgot, mert a telephelyen lévő monitorozott hostok mindegyike elérhető volt, semmilyen riasztást nem kaptunk kapcsolódó problémákról, szóval, semmi jelét nem láttam annak, hogy bármilyen probléma lenne az ottani tűzfallal vagy a VPN tunnellel.

Nem is volt, az egyetlen gond az volt, hogy a szolgáltatás kb. egy hónappal ezelőtti telepítése óta a külső cég nem készített az adott eszközön magának management VPN tunnelt, pedig ezt annak idején a kollégám nyomatékosan kérte tőlük, épp azért, hogy ne legyen probléma a tűzfal általuk történő adminisztrációjával. Ma viszont valamilyen különös okból kifolyólag észrevették ezt problémát.

Ezek után tehát felhívnak telefonon, hogy valószínűleg megállt az adott telephelyen a szolgáltatásuk, és hogy tapasztalunk-e bármilyen problémát? Mondom a servicedeskesüknek, hogy nem, sőt a VPN és a tűzfal szolgáltatás is üzemel a saját monitorozó rendszereink adatai alapján. "Hm... ez igazán jó hír" - jött a válasz - "Elnézést a zavarásért. Annyit még tudna segíteni, hogy mi a külső IP címe az adott telephelyen az eszközünknek?".

No, az hiszem, ennél a pontnál foszlott szét minden kiszervezett szolgáltatásba vetett hitem, ha volt ilyesmim egyáltalán, hiszen a szolgáltató a szolgáltatásával kapcsolatos alapvető adatokat, dokumentációkat nem ismeri (pl. külső IP cím), nem képes monitorozni azt a saját rendszerivel (management VPN tunnel hiánya), ráadásul a saját eszközével kapcsolatos probléma elhárításához tőlem, az ügyféltől kér segítséget... és persze a negyedév végén mindezért benyújtja a számlát is. Ez a tökéletes üzleti modell, valóságos aranybánya, ilyet szeretnék magamnak én is.