2011-06-30

Nortel bemelegítés

Mostanában barátkozgatunk, én meg a kikukázott Nortelek. Azért nem egy felhőtlen kapcsolat ez, már az elején sem volt minden rendben. Életem első Nortel eszköze egy viszonylag friss, jelenleg ugye már Avaya márkanév alatt futó Nortel 5510-24T volt kb. két hete, előtte soha semmilyen Nortel kütyüt nem piszkáltam, leszámítva egy Nortel 1010-es VPN routert, ami ugyan nem a cégé volt, de zörgött a ventillátora, ezért belenéztem, és kiderült, hogy egy Celeron 300-as van benne (persze, hogy mások is észrevették már ezt: van, aki Slackware-t futtat rajta). De vissza a tárgyhoz, szóval az első Nortel switchem marhára nem akart konzolon életjelet adni, próbálgathattam én sebességet állítgatni vagy bármi mást, nem sok visszajelzést adott. Persze ilyenkor elkezd guglizni az ember, de mindenütt csak annyit írtak, hogy 9600/8/N/1, szóval mennie kellett volna. A kábelemben is biztos voltam, de azért kipróbáltam egy Cisco AP-n, az természetesen azonnal működött a Minicomban. Az 5510-es sem úgy nézett ki, mint amit ütöttek-vertek volna mindenféle kiégett adminok, szóval gyanús volt, hogy valami disznóság van a konzolkábel körül, lehetséges, hogy annyira különc a Nortel, hogy más lábkiosztást használjon?

Van a fiókomban egy-két apróság, épp az ilyen estekre, többek közt olyan RJ45-DB9 átalakító is, ami nem megy a "rendes" eszközökkel, na majd most bizonyíthat, gondoltam. Így is lett, ez az Avocent Cyclades out-of-band konzol appliance-hez való RJ45-DB9 átalakító mindent megoldott a Nortel 5510-zel kapcsolatban, és még csak forrasztani sem kellett.

A Cisco, HP, 3Com, Huawei, Fortigate stb. eszközökhöz való DB9 átalakító így néz ki (3-4. oszlop, további részletek a cisco.com-on):

Console Port (DTE) RJ-45-to-RJ-45 Rollover Cable RJ-45-to-DB-9 Terminal Adapter Console Device
Signal RJ-45 Pin RJ-45 Pin DB-9 Pin Signal
RTS 1 8 8 CTS
DTR 2 7 6 DSR
TxD 3 6 2 RxD
GND 4 5 5 GND
GND 5 4 5 GND
RxD 6 3 3 TxD
DSR 7 2 4 DTR
CTS 8 1 7 RTS

A működő RJ45-DB9 átalakító (Cyclades) lábkiosztásáról némi multiméteres bohóckodás után következőt derítettem ki:

RJ-45 PIN DB-9 female
8 4
7 4
6 3
5 7
4 5
3 2
2 1, 6
1 8

Igazából csak az RJ45 3, 4, 6-os (DB9 2, 5, 3) lábakra van szükség, és ha összevetjük a legfelső táblázattal, akkor láthatjuk, hogy a Cisco eszközökön is ugyanezek a lábak vannak használatban, csak épp a TXD helyett RXD, illetve RXD helyett TXD van rákötve, a Nortel Install Guide szerint ugyanis a Nortel eszközökön a konzol port kivezetések a következők szerint alakulnak:

PIN # Signal
1 Not used
2 TXD
3 RXD
4 Not used
5 GND
6 Not used
7 Not used
8 Not used
9 Not used

2011-06-03

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.

2011-06-02

Hogyan készüljünk fel hat nap alatt az IPv6 napra?

Régi kedvencem Ivan Pepelnjak szlovén kolléga, illetve ez így túlzás, hogy kolléga, hiszen ő több Cisco Press-es szakkönyv szerzője, igazi networkös veterán, és semmiképp sem állunk egy szinten. Mindenesetre a blogját szeretem olvasgatni, és a mai posztja egyértelműen olyan, ami szerintem a magyar szakmabeliek számára is tanulságos: hogyan tákoljunk össze valamit a soron következő IPv6 napra kevesebb mint egy hét alatt, ha a PR-esek hirtelen úgy döntenek, hogy részt kell vennünk a hype-ban?

Az Ivan posztjában belinkelt prezentációból a kedvencem az F5 Big-IP-s dolog, az F5-öt gondolom nem nagyon kell bemutatni, load balancer és data center interconnection témában igen otthonosan mozgó cégről van szó, akik mostanában elérhetővé tették fontos termékük, az F5 Big-IP Local Traffic Manager Virtual Editionjét (VE) VMware infrastruktúrára, és ebből a VE-ből elérhető egy trial kiadás (korlátozás: 90 nap, 1Mb/s áteresztőképesség).

No, az egészben az a lényeg, és ez az Iván által a túléléshez javasolt receptek egyike, hogy használjuk a Big-IP-t IPv6-to-IPv4 átalakításra. A rendszer egyébként képes load balancingra IPv6-ról IPv4-es szerverek felé is (nem akarok hülyeséget mondani, de mintha tavaly valamilyen előadáson hallottam volna, hogy a Facebook F5 Big-IP vasakkal biztosítja az IPv6-os jelenlétét). Szóval a VE trialt csak a meglévő IPv4 szerverek elé kell tenni, IPv6-on csatlakoztatni a publikus hálózathoz, majd a megfelelő AAAA rekordokat  felvenni DNS-ben még június 8-a előtt. Gányolás a legfölsőbb szinteken, lehet, hogy megért volna egy "legalja" címkét is :)