Malá domácí síťka aneb sešli se

Vánoce jsou tady. Probíhá nejen výměna různých nemocí a virů kolujících v zimním období mezi lidmi, ale i informací v počítačových sítích. A proto je třeba mít dobře nastavenu i domácí síť...


Jak jsme přijeli k rodičům mé milé ženy na Vánoční svátky, tak už na své nasazení čekal nový ADSL modem, který bylo třeba vyměnit za starý a dosluhující Vigor 2600Ge. K tomu Ježíšek ještě nadělil novou tiskárnu Epson PX710W. Samozřejmě síťovou. Mimochodem za těch cca 50 EUR mi to přišlo jako docela dobrá koupě.

Když jsem se tak díval do DHCP tabulek, tak jsem v nich viděl celkem osm zařízení:

• síťová tiskárna
  
• můj mobil Nokia E52 (služební)
  
• můj druhý mobil HTC Desire s Androidem
  
• můj notebook
  
• tři notebooky příbuzných
  
• stolní PC
  

A bude hůř! Zatím jsem jediný s mobily s podporou WiFi. A další technologie jako multimediální centra, IP set-top-boxy čekají za dveřmi. Ledničky, sporáky, krby a ponožky doufám ještě chvíli posečkají.

Nicméně jsem zabodoval. Možnost tisknout a skenovat s notebookem v obýváku, bez jediného drátu, připojený přes WiFi. Odborník jásá, laik žasne. Nakonfiguroval jsem poměrně rychle systémy s Linuxem/Ubuntu a o něco déle trvala konfigurace Windows. Ve Windows jsem zase poměrně snadno rozchodil podporu skenování, u Linuxu budu muset ještě problematiku nastudovat. Dokonce jsem zajistil tisk i z mého Androida přes program CyPria. CyPria si tiskárnu sama našla a nakonfigurovala.

Ještě taková drobnost - ADSL modem DLINK DSL-2641R dodával slovenský T-COM. K zařízení není možný admin přístup, pouze tzv. User access. Tento typ přístupu v nastavení ADSL umožňuje definovat jen jméno a heslo pro přihlášení v T-COM síti a samozřejmě LAN/WLAN nastavení. Jak se mi podařilo zjistit, tak je to úmyslný krok slovenského T-COMu. Zjistit nějaké bližší parametry ADSL není možno, jediná indikace funkčnosti ADSL je zelená ikonka nebo indikátor na čelním panelu modemu. Kdyby někdo hledal, jak získat admin přístup, tak se může podívat zde.

Ale jasně, já T-COMu naprosto rozumím.

Pěkný konec roku.

Update 30.12.2010 večer: Už to začíná - připojil jsem deváté zařízení a to Nokii C6, kterou má švagrová. Tak nějak mi přišlo, že ovládání Androida je výrazně lepší než ovládání C6. Takto Nokia spláče nad výdělkem...

Update 31.12.2010 odpoledne: další příbuzný je čerstvým majitelem zařízení IPhone.

Celý článek......

ASR 1000 po rozbalení...

Jak jsem psal v létě, tak jsme pořídili pro počítačovou síť VŠB nové hraniční směrovače ASR 1000. Na podzim nám byly dodány, takže už můžu popsat první praktické zkušenosti. Není to žádná recenze, berte tento text také jako uhlazenější poznámky, které mohou být k užitku i jiným, ať už při plánování nebo při samotné konfiguraci směrovačů.

ASRka, jak je budu familiárně v tomto blogu nazývat, jsou boxy postavené na Linuxovém jádře, kde běží jako jeden proces IOS-XE. My jsme je pořídili jako 4-slotové šasi s route procesorem RP1, třemi 10Gbps XFP rozhraními a dvěma zdroji. K tomu FW a FPI licence.

Do 4-slotového šasi jsem šel proto, že je možno vyměnit i route procesor, což poskytuje možnost v budoucnu směrovač modernizovat. U dvouslotového šasi ve fixed variantě route procesor vyměnit nelze, i když má v ceně nějaké gigabitové porty. U ne-fixed varianty máme stejně poměrně velký limit na porty a rozšíření. Z našeho pohledu jsou důležité 10Gbps porty a jejich počet. A větší šasi už jsou bohužel drahé. Směrovače budou v pozicích hraničních směrovačů, takže počet jejich portů bude omezen na nějaké menší množství. Součástí dodávky jsou palety z tvrdého dřeva, za což Ciscu se sousedem děkujeme :).

Protože směrovače jsou dva a mají se funkčně zálohovat, tak nebylo potřeba pořizovat druhý route procesor (RP). Pořízení druhého RP by navíc stálo další finance, kterých teď nikdy dost. Oba směrovače budou umístěny ve dvou lokalitách - Poruba a EkF.

Konfigurace IOS-XE je v podstatě stejná jako v klasickém IOSu, takže základní konfigurace není třeba nijak zvlášť upravovat.

Šikovná věc je to, že samotný IOS je provozován jako proces. To umožňuje realizovat softwareový statefull switchover. To se hodí např. při upgrade, nebo když potřebujete provést reload IOSu. Když jsem si s tím hrál, tak to vypadalo funkčně. Bližší informace viz příkazy show redundancy a redundancy force-switchover, výpadek dostupnosti byl cca 3s. Nicméně to vypadá rozumně jen pro případ pádu/problémů s IOSem. ISSU na jednom RP vyžaduje v některých případech reload.

Naše obě sestavy jsou zcela identické a jsou osazeny třemi 10Gbps porty. Jeden port je zapojen dovnitř sítě, druhý směrem do sítě CESNET2 (Internet). Na třetí bude s největší pravděpodobností připojen L2 přepínač Cisco Catalyst 2960, který de-facto rozšíří konfiguraci směrovače o gigabitové porty. I když to není technicky optimální, tak je to funkční a levnější řešení, než kupovat modul do směrovače.

A pokračování zase někdy příště :-)

Celý článek......

Přepínače Cisco NEXUS 5000 II.

Dnes tedy o tom, jak jsme přepínače Cisco Nexus 5000 zapojovali...


Nexusy jsou velké. Tedy lépe řečeno hluboké. Ano, jsou vysoké 1U, ale nepočítejte, že se vlezou do racku, kde máte 6500. Ano, opravdu počítejte s metrovým rackem. Takže jsem je musel položit na stůl. Jak je vidět, tak FEXy (=Nexus 2000) už mají "normální" rozměry (jeden FEX je položen vlevo na jednom Nexusů).

Nenechte se mást monitorem a klávesnicí na fotce. Ty patří k serverům umístěným za stolem. I když v Nexusech je Linux, tak se k přepínačům přistupuje přes normální konzolový přístup (9600N1). Nexusy mají management Ethernet port, který se v konfiguraci tváří jako mgmt0 a nelze jej použít k ničemu jinému.

Všiměte si těch černých Twinax kabelů. Mají omezení na 5m a obsahují metalický kabel a jejich konce jsou SFP+ rozhraní, které rovnou vložíte do Nexusů, popř. do SPF+ portů síťových karet. A jejich cena je velmi nízká v porovnání s jinými alternativami. Bez problémů jsem je používal na propojení Nexusů, FEXů i koncových serverů.

Nexusy mají pouze SFP+ porty. I když jsem se dočetl, že ve vybraných portech Nexusů lze provozovat klasické SFPčka, tak se mi to bohužel nepodařilo zprovoznit.

FEXy jsou pěkný koncept. Prostě vezmete jedno (údajně) hloupé zařízení a prohlásíte ho za modul hlavního přepínače. Ten modul spojíte s hlavním přepínačem jedním nebo více 10Gbps okruhy. A aby byl celý systém odolnější proti výpadkům, tak lze FEXy připojit ke dvěma Nexusům. Konfiguruje-li se nějaký port, příslušného modulu, tak se musí nakonfigurovat na obou Nexusech. Žádná výměna informací o konfiguraci portu FEXu zde neexistuje. Při ztrátě spojení FEXu s jedním z Nexusů začne FEX spolupracovat se záložním Nexusem a koncové zařízení je stále dostupné. Prakticky jsem to zkoušel, pár paketů se ztratilo, ale konvergence byla rychlá. Alespoň z pohledu IP sítě.

Cena FEXu je, co se týče ceny na port, výrazně nižší než u jiných Cisco alternativ. Ať už se porovnávají 1Gbps L2 přepínače (Catalyst 2960) nebo 10Gbps (Catalysty 4900).

VPCčka jsou plně funkční, s těmi k žádným problémům nedošlo. Ve zkratce - dvě zařízení se vůči jinému zařízení (tedy druhé straně port channelu) tváří jako jedno zařízení. Není to zcela optimální z hlediska výběru nejkratší cesty v L2 síti. V praxi dochází ke stavům, kdy rámec pro koncové zařízení připojené k přepínači NEXUS2 je posíláno v datovém spoji k zařízení NEXUS1. NEXUS1 pak pošle rámec na NEXUS2. K tomuto jevu dochází proto, že na odesílajícím přepínači je rozdělování provozu realizováno klasickou hash funkcí (obvykle src-dst-ip) a podle toho je rámec poslán příslušným spojem. Odchozí provoz z Nexus přepínačů je už pak posílán nejkratší cestou tak, jak ji vypočte SPT protokol.

Největší neznámou pro mě byly otázky kolem Fiber Channelu (FC). Trochu jsme se potrápili s HW zapojením karet (díky J.Benešovi vyřešeno :-). Server byl připojen do FEXu, diskové FC pole pak bylo duálně připojeno přímo do dvou Nexusů. Málem jsme testování FC nestihli, ale dva dny to R.Slíva testoval ze strany serveru a diskového pole a nevyjádřil nespokojenost :-) Jak se dívám na obrázek, tak FC pole není ve schématu zakreslené. Z CNA karet byly realizovány dva spoje, které by měly být v ideálním případě ukončeny na dvou FEXech, které jsou duálně připojeny ke dvěma Nexusům.

A protože se mi nechce schéma zapojení překreslovat, tak přikládám fotku zapojení.

Nexusy do datového centra mi přišly jako docela rozumné zařízení. V našem případě máme po sálech datacentra rozmístěno dvanáct L2 přepínačů. Některé jsou 10/100Mbps, některé 10/100/1000Mbps, jejich oddělená správa také není zcela ideální. Zapojením dvou přepínačů a několika FEXů bychom dosáhli lepší škálovatelnosti. A při nasazení 10Gbps portů nevidím v podstatě v portofoliu Cisca alternativu.

Celý článek......

Přepínače Cisco NEXUS 5000 I.

Tak jsme se domluvili s firmou Cisco a dostali jsme zapůjčeno k testování zařízení Cisco Nexus 5000. Teď je důležité to celé prodrátovat a spustit...


Tak jsme dostali, jako perspektivní univerzita :-), zapůjčeno zařízení Cisco Nexus 5000. Přepínače Cisco Nexus 5000 jsou určeny do datových center a tedy primárně jsou určeny pro připojení serverových systémů. Oproti klasickým L2 přepínačům umí ještě pracovat s technologií FCoE a lze k nim připojit i FC pole. Tedy žádná hračka domů nebo do normálního rozvaděče. Tomu propojení Ethernetenu a Fiber Channelu se říká konvergovaný ethernet.

Myšlenka konvergovaného ethernetu spočívá v použití jediné CNA karty v serveru, což má uspořit místo, kabelář a energii (všichni chceme být zelení, že?). CNA znamená Converged Network Adaptér. Tato karta má integrován řadič, který se v OS tváří jako FC řadič. Zároveň se karta tváří jako dvě klasické 10Gbps síťové karty. Samotná karta má dvě rozhraní, které lze připojit ke dvěma zařízením a posílá ethernetové rámce. Některé klasické, jiné jsou FC zabalený do ethernet rámce. Není tedy potřeba k serveru připojovat kabeláž počítačové sítě a zároveň kabeláž SAN sítě.

Naše sestava byla poskládána ze dvou zařízení Nexus 5020 a k dispozici máme tři FEXy a dva FC moduly, do každého Nexusu jeden. FEX znamená Fabric EXtender a je to fajn věc. Ta zařízení nemají z pohledu správy sítě v podstatě žádnou logiku a lze si je představit jako moduly, které jsou fyzicky připojeny jednou nebo více 10Gbps trasami.

Nexusy umí i technologii VPC - Virtuální Port-Channely. Na první pohled výborná věc. Jiné zařízení připojíte dvěma okruhy ke dměma Nexusům, ale pro to zařízení se bude jednat o jeden port-channel. S ním pak můžete pracovat jako s klasickým port-channelem. Nexusy se mezi sebou domlouvají a vůči tomu zařízení se tváří jako jedno zařízení. Uvnitř se ale každý Nexus chová jako samostatný přepínač, řídí se svými MAC address tabulkami, tak nečekejte žádný balancing vzhledem k tomu druhému zařízení. Takže zcela jistě vznikají v síti asymetrie a koncová zařízení je vhodné rozkládat na oba Nexusy.

Tak uvidíme, co vše zvládnou v provozu... :-)

Celý článek......

Kam se ztratily řetězy?

Loni jsem se připravoval na výstup na nějaký štít ve Vysokých Tatrách. Nerad chodím sám, takže mi to vyšlo až letos. Vybral jsem si Koprovský štít.

Vyrazili jsme v 6:30 ráno autem z Bánské Bystrice. Provoz na cestách byl poměrně slabý, takže okolo osmé jsme už vyrazili z parkoviště na Štrbském plese směr Popradské pleso.

Počasí přálo, šlapalo se dobře, i kešku jsem stihl odlovit. Když jsme došli až na vrchol, tak jsem se těšil na řetězy, které tam byly při mém posledním výstupu. Ale ouha, řetězy nikde! Tak nevím, jestli vrchol je už bezpečnější, že řetězy nejsou třeba?





Výhled z vrcholu stál za to. Bylo jasno a tak šlo vidět až na střední Slovensko. Trochu mě mrzelo, že jsem si neudělal kvůli technickým problémům s TrekBuddym track log.

Cestu zpět jsme si zpestřovali konzumací borůvek, vodu jsme doplnili v horských potocích, síly... síly nebylo kde doplňovat.

GPSka dnes selhala podruhé. Autem jsme se po cestě zpět zacyklili, ale mapa pod sedadlem spolujezdce opět zajistila návrat na tu správnou cestu.

Celý článek......

IPv6 v bezdrátových sítích

V počítačové síti VŠB, kde postupně nasazujeme IPv6, provozujeme také bezdrátové sítě. V těchto sítích ale IPv6 v současné době dostupné není. Popíši technické důvody, pro které doposud IPv6 v bezdrátových sítích není dostupné a také technické kroky, které je potřeba realizovat pro vyřešení této situace.


IPv6 je oproti IPv4 je navrženo přeci jen trochu jinak, nelze si představovat, že IPv6 má jen delší adresy. Z našeho pohledu implementace IPv6 v bezdrátových sítích je důležité to, jakým způsobem se v IPv6 síti volí směrovače a konfigurují adresy. IPv6 adresu lze získat přes DHCPv6, ale bohužel ne všechny OS mají DHCPv6 klienta dostupného a funkčního. Proto je potřeba v současnosti podporovat i tzv. autokonfiguraci. Autokonfigurace je navržena tak, že směrovač v příslušné síti oznamuje prefix příslušné sítě (prvních 64 bitů adresy) a stanice si následně podle určitých algoritmů zvolí druhou polovinu adresy (druhých 64 bitů).

Směrovače v IPv6 síti nejsou stanicemi získávány přes DHCPv6 (to dokonce není ani podporováno), ale samy se v síti propagují. K dispozici mají také tři druhy priorit - malá, střední a vysoká. Je ovšem důležité si uvědomit, že tyto RA (Router Advertisements) jsou rozesílány na multicastové IPv6 adresy.

Po tomto úvodu se můžeme podívat na síť VŠB. Ta je postavena na řídicích modulech bezdrátové sítě. Jednotlivé přístupové bezdrátové body jsou z řídicích modulů řízeny a veškerý provoz APček je posílán na tyto řídící moduly prostřednictvím tunelů. To umožňuje velmi rychlé rekonfigurace celé bezdrátové sítě. A to nejen v LAN VŠB. Díky tomuto centralizovanému modelu mohou být shodné služby poskytovány např. v rekreačním středisku Desná, které je připojeno do Internetu prostřednictvím ADSL.

Aby mohly být RA přeposílány na AP, je nutné, aby řídicí moduly podporovaly IPv6 multicast. To programové vybavení našich řídicích modulů Cisco WiSM umožňuje. Takže to vypadá, že nasazení IPv6 v bezdrátových sítích nic nebrání. Ale opak je pravdou. Pokud totiž zapojíte do takové sítě stanici, která se začne propagovat jako směrovač, tak začnou problémy s ostatními koncovými stanicemi. A "vyrobit" takovou stanici je poměrně jednoduché - stačí mít Windows Vista/7 s nastaveným sdílením připojení.

A protože Cisco Wireless Controller nemá podporu pro filtrování RA (RA Guard), tak se musíme spolehnout na to, že taková stanice se nám v síti neobjeví. Naděje sice umírá poslední, ale při tomto rozsahu bezdrátové sítě je brzký konec nadějí v podstatě jistý. V naší síti, kde máme okolo 250 APček, je ve špičkách připojeno zhruba 800-900 uživatelů. Mezi těmito uživateli se běžně našlo 8-9 stanic, které měly nastaveno sdílení připojení a dělali v síti "nepořádek".

Cisco slíbilo, že doplní funkci RA Guard ve fázi 2 (fáze 1 je implementovaná, fáze 2 probíhá), ale pouze u modulů postavených na řadě 5500. Druhá fáze má být dokončena v 2011/Q3-4. A ještě před dvěma lety se prodávaly moduly řady 4400, které samozřejmě máme i my...

A jaké je tedy řešení pro tento případ? V prvé řadě je potřeba používat nejvyšší možnou prioritu pro RA našeho oficálního směrovače. Tím snížíme pravděpodobnost, že objeví-li se v síti cizí směrovač, že stanice jej použije. Druhým nutným technickým krokem je zprovoznění zneplatňovače RA. To je program, který poslouchá na síťovém rozhraní, a zaznamená-li RA od zařízení, které nemá v seznamu platných směrovačů, tak okamžitě pošle do sítě zneplatnění tohoto oznámení. Tím docílíme toho, že než stačí stanice tuto cestu použít, tak je zneplatněna.

Toto řešení vypadá funkčně, v poloprovozním režimu na vybraných částech bezdrátové sítě se osvědčilo, takže předpokládám, že s novým semestrem jej nasadíme v celé síti. Návrh je takový, že u každého z obou řídicích modulů bude umístěn jeden "zneplatňovač". Tím řešíme jednak zálohu pro případ výpadku a také zajištění doručení zneplatnění, protože oba servery budou umístěny v různých částech metropolitní sítě. Nicméně stále je to jen workaround, který fixuje jen důsledky.

A jak je tento zneplatňovač postaven? Je jím linuxový systém, který podporuje 802.1Q a zneplatňování realizuje program RAMON. Tento přístup lze samozřejmě aplikovat i u pevných sítích. Ale v nich máme přeci jen trochu více možností. Ty zkusím ale rozebrat jindy.

Tento režim plánuji provozovat minimálně následující rok. Přibližně za rok budeme řešit další problém související s rozvojem - nedostatečná redundantní kapacita řídicích modulů vzhledem k provozovaným APčkům. V tu dobu budeme muset řešit buď upgrade nebo doplnění řídicích modulů a při volbě platformy jistě bdueme přihlížet ke kvalitě implementace IPv6. Na každý pád čekám, že Cisco se pohne s rozvojem IPv6 v oblasti centralizovaných bezdrátových sítí kupředu.

Celý článek......

Projekt Easyworld

Na konci roku 1999, těsně před Vánoci, jsem dostal nabídku pracovat na jednom zajímavém projektu. Cílem bylo vytvořit Internetový obchodní dům EasyWorld. V té době takových obchodů moc nebylo. Projekt financovala německá firma a hlavní vývoj probíhal v ČR.


V těch letech to byla poměrně velká Internetová aplikace, navíc ještě vyvíjená v Ostravě. Německá firma měla vyvinutý v té době produkt, který umožňoval generovat WWW stránky a také seznam zboží. Obojí mělo být z programu přímo exportovatelné přímo do prostředí EasyWorldu. Ten program pro Windows napsal a udržoval nějaký německý student, který kvůli tomu přestal studovat fyziku.

Já měl mít na starosti všechny systémové věci toho projektu. Od zapojení sítě, síťových prvků až po správu a konfiguraci všech serverů v projektu použitých. Práce to byla poměrně rozsáhlá, bylo potřeba vyřešit zastupitelnost a tak se do projektu zapojil ještě kamarád Karel, který se mnou tehdy dělal na výpočetním centru VŠB.

Termíny byly naprosto šibeniční. Všichni jsme měli jsme dva měsíce na to, abychom rozjeli projekt, navrhli technická řešení a ta zprovoznili v nějaké předváděcí verzi. Po těch dvou měsících byla plánována výstava ve Švýcarsku (rozsahem něco jako Invex) a tam jsmě měli ten obchod prezentovat a také byla naplánovaná televizní reklamní kampaň. Programátorům jsem tehdy vůbec nezáviděl. V té době jsem ještě trochu více programoval, takže jsem jim dělal ještě konzultace okolo PHP (tedy ve verzi RC4). My s Karlem jsme při vývoji museli řešit nasazení PHP4, sladění s Oraclem, což se ne vždy dařilo. Ve finále jsme tak trávili u serverů odpolední a noční hodiny. Vzdálené přístupy tehdy nebyly moc reálné, kapacita linky vývojového centra byla tuším 64kbps a doma jen dial-up. Večerní autobusové linky domů jsem znal nazpamět :-)

Z pohledu sítě byla celá sestava složena ze směrovače (Cisco 3660), L2 přepínače Cisco Catalyst 2950. Zadavatel měl poměrně velká očekávání, takže jsme navrhli do sítě ještě i load-balancer Radware WSD-Pro, který obsluhoval celkem tři aplikační servery. Tehdy se podle dodavatele počet těchto zařízení dal spočítat na prstech dvou rukou, takže bylo zajímavé se s tím zařízením setkat a nasadit.

Na přelomu února a března jsme naložili dva servery do auta a vyrazili s kolegou Pavlem na týdenní výlet do Švýcarského Curychu. Celodenní cesta proběhla celkem dobře. Jen se občas ještě lehce orosím při vzpomínce na noční dálniční půlkilometrové couvání po přejetí exitu. Tehdy jsem to Pavlovi vážně nerozmluvil. Instalace a konfigurace systému na výstavišti nakonec proběhla dobře a tak největší technický problém celé akce byla demontáž přístrojové desky auta, za kterou zapadl parkovací lístek výstaviště :-). Trochu jsem měl obavy jak budu řešit bez rozumné konektivity nějakou špatnou funkcionalitu projektu, ale naštěstí vše běhalo bez problémů. Byli jsme zapojeni za nějakým NATem, přístup ven byl jen k webu, dovnitř se nebylo možné spojit ani SSH tunely.

Po instalaci stánku i samotné aplikace firma pozvala celý výstavní tým na večeři do restaurace. Po celodenní práci to bodlo. Kručící žaludek se po náročném dni hlásil o slovo. Večeře se k mé smůle odehrála v Mexické restauraci, kde snad i obyčejný chleba byl ostrý. Já ostré opravdu nemusím, takže jsem se musel spokojit s chlebem :-) Výstava skončila dobře, ve vývoji se mohlo pokračovat. Na zpáteční cestě jsem udělal ještě jednu životní zkušenost - je zbytečné chodit k McDonaldovi, človek se tam stejně nenají :-)

Do provozu by celý systém byl v ČR nasazen nejprve v Ostravském uzlu komerční části sítě CESNET. Tato síť byla následně prodána Contactelu. Vzpomínám si na setkání nad celým clusterem spolu s novými, rychle najatými, obchodníky Contactelu. Celá sestava se tedy sestávala ze tří aplikačních serverů, jednoho management serveru, jednoho HP serveru s databází Oracle, směrovače, přepínače a load-balanceru. Tehdy chtěl dodavatel mít garantovány z dnešního pohledu směšné 2Mbps (linka do Contactel uzlu byla 8Mbps) a dokonce za to byl připraven zaplatit. Ale obchodníci Contactelu se nám smáli a říkali, že 2Mbps je moc a stejně nám to nikdo nenabídne. Nabídka přišla o měsíc později tehdy začínající GTS. Takže Contactel splakal nad výdělkem a sestava se přesunula na GTS. Já už od té doby neměl sestavu přímo pod rukama (tj. jedna síťová karta mého osobního PC nebyla zapojena do interní sítě clusteru :-) a vzrostly mi tak výrazně latence.


Ke konci roku jsme připravili přesun celého clusteru do sítě v Mnichově. Pro samotný přesun HW jsme připravili dva servery, které převzaly dočasně všechny důležité funkce. Všechno zařízení se naložilo do dodávky a odvezlo se do Mnichova. Do Mnichova jsme vyrazili s Karlem a šéfem projektu Honzou. Servery jsme vyložili, zprovoznili, synchronizovali a nakonec přepojili do ostrého provozu.

Návštěva ISP v Mnichově byla zajímavá. Žádné malé místnosti 5x5m, ale obrovské sály 50x30m, dlouhé chodby a velké monitorovací centrum, kde se mi podařilo se oficiálně v pozdních večerních hodinách navštívit a pokecat s operátory.

Projekt skončil podobně jako některé další v té době. Po asi třech letech firmě došly finance a projekt ukončila. I nějaké drobné nám tehdy nebyly vyplaceny, ale to vem čert. Ta atmosféra při vývoji byla obrovsky inspirující, zažít opravdu těsnou spolupraci celého týmu. To jsou věci, které člověk ocení.

Celý článek......

Když nejde hospodář na střechu aneb nejede nám síť

Říká se, že když nejde hospodář na střechu, tak střecha jde k hospodáři. Zatím marně přemýšlím nad pěknou transpozicí tohoto přísloví do světa IT. A na toto přísloví jsem si vzpoměl, když jsem za poslední měsíc řešil dva technické problémy. Oba byly vyústěním dlouhodobého podceňovaní stavu IT.


I přes uvedené dva příklady si myslím, že outsourcing IT má na světě své místo. Ono nakonec je stejně všechno o samotných lidech a jejich přístupu, bez ohledu jsou-li přímo nebo nepřímo zaměstnaní.

Příběh první - server odolávající zubu času

Bylo nebylo, asi v roce 2003 mě kontaktoval jeden pán (řekněme Novák) z jedné IT firmy. Potřeboval pomoci se situací v jedné ne úplně malé společnosti, které zajišťují provoz IT. Hořekoval, že všichni úředníci stojí a čekají, až opět server pojede. Tak jsem se pustil do zjišťování stavu. Linuxový server s instalovanou Sambou najednou přestal jet. Při fyzické obhlídce jsem zjistil, že v rohu zastrčené obstarožní PCčko je plné prachu. Už si přesně nepamatuji na skutečný problém, ale vybavuje se mi, že to bylo pravděpodobně fsck, které se muselo při bootování OS spustit ručně. Některé datové disky byly formátovány na EXT2, některé na FAT. Na CDROMce ušetříme, tak u serveru být nemusí. Klasika. Zálohy už dávno nefungovaly. Heslo roota samozřejmě nikdo neměl. Zásadní problém a zprovoznění napraveno během nedlouhé chvíle. Patnáct úředníků jásalo, že může opět pracovat, dalších patnáct vzdychlo, že opět musí pracovat :-)

Schůzka s vedením společnosti byla zajímavá. Doporučil jsem, aby si koupili pořádný server s HW RAIDem. Tehdy to vycházelo tuším na cca 60-80 tisíc Kč. To však bylo v rozporu s plánovanými investicemi do IT. Ke konci roku si pan totiž ředitel kupuje za tuto částku nový notebook. A protože končí rok, tak v květnu by snad mohli dát něco dohromady.

Střih. Nacházíme se v roce 2010, počátek léta. Volá mi pan Novák, jestlipak si pamatuji na server v té společnosti. No jasně, já si pamatuji věcí... :-) "Tak ten server odešel. Asi disky." Přežil, chudák, v té konfiguraci dvoje či troje povodně, ale věkem sejdeme nakonec všichni. "Musíme s tím něco co nejrychleji udělat, firma musí šlapat!". Podařilo se mi obnovit datový svazek, ale samotný systém už ne. Takže jsem systém celý nainstaloval a zprovoznil. Firma se plácla přes kapsu a zcela nový 80GB disk (cena 1TB disku v r.2010 nedosahuje 2 tis. Kč - poznámka autora pro naše potomky) doplnila o vyřazené PCčko některého z úředníků. Firma se za těch pár let rozrostla. Síťaře nepotěší pohled na několik SOHO přepínačů zapojených do série, blikající všemi barvami v krásném prostředí husté kabeláže... Rytířovo srdce však začne bušit a klást si otázku - je v té zadrátované džungli nějaká Síťová Růženka? A server...? Ten se reinkarnoval. Jo, RAID... jasně, probereme to... A pokud neumřeli, tak to asi probírají dodnes.

Příběh druhý - dokud se směruje, ještě se neumřelo

Jako každou pohádku, tak i tuto začnu slovy bylo nebylo... Bylo nebylo, v jednom městě byla jedna nejmenovaná společnost, obchodující docela úspěšně na Internetu. A tuto společnost napadlo, že by měla zabezpečit svou síť, serverové služby, mít duální připojení, firewall... I pořídilo se příslušné technické vybavení. Příjemné bylo, že shodu na technickém vybavení a zejména na financích za toto vybavení, se podařilo najít poměrně rychle. To nebývá vždy pravidlem :-) Vše šlo přes firmu, která hodně IT věcí naší společnosti outsourcovala. Vše bylo nainstalováno, zprovozněno.

A po zhruba čtyřech-pěti letech se ozvala ona outsourcující firma s tím, že potřebují něco velmi naléhavě změnit (konkrétně IP adresy). Na celém řešení (dva směrovače, jeden Linux v pozici serveru) se po dobu jejich služby nic nového neudělalo a nic nestalo. A uptime 1260 dní potěší oko každého admina :-) Po jisté anabázi se mi na systémy podařilo přihlásit (kdeže se ztratila u firmy má odevzdaná dokumentace?). Změnily se nameservery, úplně se změnil čas (NTP nedosažitelné), špatně fungující resolving u web serverů... Hlavně, že to sype^H^H^H^Hjede!

Jeden směrovač firma zresetovala do továrního nastavení tak, že ho nedokázala zprovoznit. A tak ho raději odložila a nahradila starším modelem Linksys (hlavně, že to aspoň směruje!).

Změny se udělaly. Outsourcující firma dostála svým závazkům (vždyť se o to stará), klient je spokojen. Administrátora přeci nebudeme přeplácet, udělal jen to, co je třeba. A administrátor si říká, komu není rady, tomu není pomoci.

Závěr

A tak, milé děti, jako v každé pohádce, i zde skončilo všechno dobře... Vždy se najde nějaký rytíř, co zachrání princeznu před zlým drakem. Dobrou noc děti... :-)

A pro ty, co je ještě nespí, nabízím oblíbenou ukolébavku mého bývalého vedoucího kroužku kybernetiky Jardy Kroczka.

Celý článek......

Těžko na cvičišti, lehko na bojišti

Včera byla na jedné z našich lokalit provedena revize elektrických rozvodů. Elektrikáři jsou šikovní. V podstatě vždy tato operace poškodí zdroj nějakého z našich prvků. Obvykle to bývají zdroje APček. Tentokrát byl "vylosován" jiný prvek, zdroje APček se jim zdály asi málo :-) Odnesl to agregační přepínač Cisco Catalyst 3750, respektive jeho zdroj.


Po plánovaném výpadku dopoledne naběhla část sítě, ale ve 12:03 mi volali, že je poškozen zdroj u jednoho agregačního přepínače. Vzdychl jsem, podíval jsem se na hodinky (tedy na čas na IP telefonu), poděkoval jsem osudu, že jsem už po obědě, a jal se konfigurovat nový přepínač. Naštěstí jsem měl stejný typ přepínače na stole. Minulý týden jsem totiž testoval nový IOS 12.2(53) a některé nové IPv6 vlastnosti.

Konfigurace byla hotova během chvilky. Ještě jsem ji trochu upravil, zabalil jsem napájecí a konzolový kabel (to je takový ten bleděmodrý, co nechávám i tak pro jistotu v každém rozvaděči :-). Radek na mě houkl, že ta reakce je celkem rychlá a že bych to měl měřit.

To dodalo jinak zcela běžnému servisnímu zásahu jiný náboj. I když výpadek nepostihoval o prázdninách téměř žádné uživatele, tak jsem vyrazil, nasedl do auta (ano, soukromá jízda) a odjel přes celé město na EkF. Papírově je to 13km, dobře 20 minut cesty autem. Kousek od budovy, kam jsem mířil, sídlí i školka mé dcery. Tak jsem dceru vyzvedl. Poté jsme zamířili do příslušného rozvaděče, následovala demontáž, montáž. Zde se ukázalo, jak prozíravě jsem si přibral pomocníka. To se hodí, když se demontuje ne úplně lehký prvek ve výšce dvou metrů a existuje někdo, kdo podá šroubek nebo šroubovák... Potom už proběhlo přepojení kabelů a v 13:16 byl podle monitoringu provoz obnoven.

Lehce mě ještě překvapily nějaké drobné změny v novém IOSu, to jsem už v klidu nastudoval a doladil doma.

Čas 1:13 mezi přijetím informace o výpadku a zprovozněním je celkem slušný, že? Teď už jen vyřešit RMA...

Celý článek......

Plánujeme nové hraniční směrovače

Svůj první blogový příspěvek začnu technickým tématem. O tom, jak je realizováno redundantní připojení počítačové sítě VŠB k síti CESNET2 a jaké jsou plány. A krátce také o tom, jak působí na výběr a nasazování technologií i netechnické vlivy.


Když jsme konečně dostali v půlce července rozpočet, tak jsem mohl naplánovat nákupy a k nim vázané práce pro zbytek roku. Oproti jiným létům došlo k přidělení financí o několik měsíců později. Ale koneckonců lepší nějaký rozpočet než žádný. Pravděpodobně bude nutné původní plán práce na celý rok muset modifikovat, protože byl původně tvořen s beznadějí, že žádná nová zařízení pořizována nebudou.

Oblastí, které je potřeba řešit, je více a finance jsou, jako obvykle, omezené :-). Takže finální volba padla na upgrade hraničních směrovačů počítačové sítě. Po zhodnocení požadavků a technických možností byly vybrány směrovače Cisco ASR1000.

Počítačová univerzitní metropolitní síť je postavena tak, že má dva hraniční směrovače. Primární hraniční směrovač je umístněn v hlavním areálu univerzity. Druhý, záložní, je pak v centru města, na Ekonomické fakultě. Zde je asi největší technický problém stávajícího řešení. V pozici záložního hraničního směrovače je velmi staré zařízení Cisco Catalyst 6500 se Sup2 (pořízeno bylo v roce 1998). Technické problémy záložního hraničního směrovače spočívají v tom, že je osazen poměrně malým množstvím paměti, takže nelze ani provést upgrade IOSu, nepodporuje IPv6, je omezeno na gigabitová rozhraní a pořádná podpora FW je v podstatě nulová.

V současné době provoz univerzity ve špičkách přesahuje 1 Gbps a ještě se nestalo, že by přestal provoz s novým semestrem nenarostl :-) Proto primární připojení na síť CESNET2 je realizováno 10Gbps trasou.

Dovolím si odbočku k časovým termínům nasazení. V jiných létech se vědělo, že rozpočet bude a tak se od počátku plánovaly práce a potřebné technické prostředky. Letos to s rozpočtem oddělení CIT vypadalo všelijak. A tak mi po přidělení prostředků bylo jasné, že má-li se stihnout VŘ, zároveň alespoň nějaké práce a k tomu dovolené všech zainteresovaných, tak je třeba výrazně zabrat. VŘ tak bylo připraveno za zhruba týden. Do dvou měsíců by mělo být ukončeno a potom máme zhruba 6-8 týdnů na dodávku zařízení. Tedy v listopadu ta zařízení budou na univerzitě. Následně budou zařízení připravována, testována a ve finále nasazena do pilotního provozu.

Ale opravdu velké změny je možno dělat tak v posledním prosincovém týdnu. Trochu to sice komplikuje fakt, že je nařízena povinná dovolená. Bez výjimek. Poslední prosincový týden obvykle nasazuji nové verze programového vybavení na aktivní prvky. Počet změn v tom kritickém týdnu musí být úměrný jak náročnosti technických změn, tak obvykle i naplánovaným rodinným aktivitám. No, tak asi budeme jako ostatně každý rok, pracovat ve svém volném čase :-) Nicméně ostré nasazení se posune odhadem do zkouškového období, protože v běžném provozu je riziko dopadu na uživatele výrazně větší. Uživatelů máme odhadem přes deset tisíc a vždy se bohužel najde někdo, kdo je změnou postižen.

Ale zpět k technickému řešení. Do pozice hraničního směrovače byl vybrán čistokrevný směrovač Cisco ASR1000. Tedy zařízení, které je na trhu zhruba 2-3 roky a jeho pořízení se jeví perspektivně. Po nějaké době úvah a počítání bylo vybráno řešení postavené na čtyřslotovém šasi, se třemi 10Gbps porty. Dva 10Gbps porty budou zapojeny dovnitř sítě, jeden pak směrem do sítě CESNET2. Základní vlastnosti byly rozšířeny o firewall feature set a podařilo se to zkombinovat s podporou Flexible Packet inspection. Deklarovaná propustnost je 10Gbps, ale je předpoklad, že kombinace FW, FPI, ERSPANu částečně propustnost sníží. Přesto by tato propustnost měla poskytovat dostatečnou rezervu a to i do budoucna.

Finančně to řešení vyšlo nakonec velmi dobře. A nenechte se mást dostupnými GPL cenami :-)

A jaké nové služby toto řešení přinese uživatelům? Konečně bude nasazen plnohodnotný stavový filtr, který bude realizován na obou hraničních směrovačích, bude k dispozici dostatečná zálohovaná konektiva. Budou eliminovány uživatelsky asi nejviditelnější problémy s protokolem FTP. Také budeme mít zcela zálohován nejen IPv4, ale také IPv6 provoz. Víte vůbec na co vše už dnes IPv6 používáte aniž o tom víte? Ale o tom někdy příště.

Až nám směrovače dojdou, tak o nich i o jejich nasazení povím více.

Takže všem přeji dobrou konektivitu :-)

Celý článek......