Az ELTENET-rõl végig királyi többesben fogok beszélni, de már az elején le kell szögeznem, hogy az ELTENET tervezése és kivitelzése sajnos azóta már távozott kollegáim, Daruházi László és Pintér Ödön érdeme.
Az ELTE területileg eléggé szétszórt, ezért a legváltozatosabb technológiákat kellett alkalmazzuk a különbözõ helyszínek bekötésére. A vonalak ill. campusok elhelyezkedését az alábbi vázlatos ábra mutatja:
Az ELTENET tervezésekor igyekeztünk egy nagy kapacitású és nagy megbízhatóságú magot létrehozni, amely várhatóan a jövö kommunikációs igényeit is kielégíti. Így esett a választás az FDDI-ra, amely 100Mbit/sec sebességet kínál, az üvegszálas technika garantálja az elektromos zavaroktól való mentességet, a gyûrû topológia pedig azt, hogy egy vonal kiesése esetén a gyûrû még zavartalanul mûködik, egy router kiesése esetén csak az adott routerhez csatolt hálózati részek esnek ki, a többi router változatlan sebességgel éri el egymást. Az FDDI gyûrû az ELTE és a SOTE közös projektjének indult, mára két másik intézmény (Az OMIKK és a MedInfo) is csatlakozott. Módosult egy kicsit a technológia is, mára az FDDI egyes ágait ATM-be ágyazva visszük át, így spórolva üvegszálakat. (Az ATM-en az FDDI mellett E1 trunk-ök is vannak, amelyeket a belsõ telefonhálózat kiterjesztésére használunk). Az ATM switchek bridgel-ként mûködnek a három fizikai gyûrû között. Az FDDI mai állapotát az alábbi ábra tartalmazza.
A gyûrûhöz csatlakozó routerekben látjuk el a routerekhez fizikailag közel lévõ ELTE részeket valamint a SOTE épületeket, optikai ethernet segítségével. Az üvegszálakkal anyagi és egyéb okok miatt el nem érhetõ helyszíneket analóg bérelt vonallal illetve mikrohullám segítségével kapcsoltuk be, így az alábbi struktúra alakult ki:
Az ELTENET-hez sok külsõ intézmény is kapcsolódik FDDI, optikai ethernet, vagy bérelt vonal segítségével. Az ELTENET elsõdleges külsõ kapcsolódása a bme.iif.hu routeren keresztül valósul meg , közvetlen optikai etherneten illetve a BME-n keresztül FDDI-on és etherneten keresztül. Ezen kívül van még a Városház utcába, az mta.iif.hu-ba vezetõ 64K-s tartalék bérelt vonalunk.
A felhasználókat a tervezett leállásokról és hibákról news-ban is tükrözött levelelzési listákon tájékoztatjuk. A hálózati szábályzat, a hálózat felépítésérõl és egyes szolgáltatásokról a felhasználó a http://www.elte.hu/eltenet/ címen szerezhet információkat.
A hálózat telepítésekor az alacsony üzemeltetési kötségek elérése volt a cél. Ennek az alábbi technológiákat alkalmaztuk:
Az ELTENET külsõ kapcsolataiban a legnagyobb fennakadásokat a HBONE mag redundancia nélküli tervezése okozta, amikor a Városház utca - Victor Hugó utcai bérelt vonal szakadozása miatt a tartalék 64K-n kellett forgalmazzunk. Néhányszor, a BKE-n lévõ repeatert érintõ áramszünet miatt, elszakadt az ELTE - bme.iif.hu ethernet is, ekkor azonban az egyetemközi FDDI-on és a BME-n keresztüli tartalék út automatikusan belépett, így változatlan sebességû maradt a külsõ kapcsolat.
Itt a hibákat vonaltípusonként írom le
A repeatereknél volt a legtöbb meghibásodás, fõként a tápegységventillátor és emiatt a tápegység ment tönkre, de volt amikor csak egy AUI port illetve fiber modul hibásodott meg.
Egy MGS routerünkben az egyik 2E2S-es kártya ment tönkre, egy másikban az NVRAM felejtette el a tartalmát. Ebben merülnek ki az elmúlt másfél év hardware meghibásodásai.Így a routerek hardware-esen megbízhatónak mondhatók.
A PC-s bridgekkel rossz tapasztalataink vannak, gyakran elestek nagy terhelés illetve sok hibás frame esetén. A Unix, Novell, Win NT alatt üzemelõ PC-s routerek megbízhatóan üzemeltek, a hardware bridge-ekkel sem volt probléma.
Egy ekkora rendszert már nem célszerû a szokott módszerrel, a felhasználó panaszos telefonjára várva üzemeltetni, ezért az ELTE management rendszereket vásárolt. A rendszerek az eszközökbe épített Simple Network Management Protokoll (SNMP) lekérdezési lehetõséget és pollozást (az eszköz elérhetõségének periodikus vizsgálata) használják. Elsöként a Sunnet Manager keretrendszert és a beleágyazott CiscoWorks-öt vásároltuk meg, késõbb a Cabletron cég Spectrum nevû rendszerét. Az ATM managelésére a NewBridge 46020 kódnevû management rendszerét használjuk. Ez utóbbiról itt nem beszélünk, mert csak a NewBridge eszközökkel mûködik együtt, nem a szabványos SNMP-t használja.
A SunNet Manager az alábbiakat tartalmazza:
Összességében nem igazán jól használható, a képességeit többnyire nem nyújtja kielégítõ színvonalon, bosszantó hibákat tartalmaz. Ilyen például az, hogy az event-ek figyelése csak akkor történik, ha a grafikus felület fut, azaz megjelenik egy X terminálon, ami nálunk egy Linux X felülete. Emiatt a Linux X-et lock-ban kell tartani. Egy másik bosszantó dolog, hogy egy SNMP lekérdezés után az eredményablak bezárásával az egész program befejezi mûködését.
A CiscoWorks jobbra sikerült, ennek segítségével sikerült event-eket definiálni, rávenni arra, hogy hiba esetén levelet küldjön. Igaz, hogy a postaládánk elárasztásának elkerülése érdekében egy saját gyártmányú programot is fejleszteni kellett a vonallebegések (ismétlõdõ up/down státusztváltás) csillapítására. Lehetõségünk van a router állapotának lekérdezésére egyszerû MIB változók lekérdezése által, a telnet kapcsolatban megszokott show parancs formátumában illetve csinos grafikus oldalak formájában is. A SunNet Manager Grapher-jének segítségével on-line grafikonban is figyelhetjuk a router ill. egy vonal vagy protokol forgalmát. A Path-Toollal meghatározhatjuk egy adott adatúton a terheltséget, így a szúk keresztmetszet azonnal kiderül. A routerek konfigurációit is egységes környezetben tárolhatjuk, Tacacs servert is találunk benne. SyBase adatbázishoz kapcsolódva tárolatjuk a hálózati eszközeinkre jellemzõ adatokat. A software újabb verzióiban az eszköz grafikus képét is megjeneníthetjük, ahol a ledek állapotát is láthatjuk.
:A Spectum egy jóval bonyolultabb de jóval használhatóbb, objektumalapú rendszer. Ez azt jelenti, hogy a minden eszköznek, vonalnak megfelel egy objektum, amit a Spectrum modell-nek nevez. Ezen modelleket és egymáshoz való kapcsolódásaikat egy adatbázisban tároljuk. A modellekben megtaláljuk az adott eszközre jellemzõ legfontosabb adatokat, melyeket az adatbázishoz kapcsolódva le is kérdezhetünk.
A Spectrum egy szerverbõl (SpectroServer) és több kliensbõl áll. A szerver itt állandóan fut és gyûjti az adatokat, végzi a riasztásokat, függetlenul attól, hogy fut-e megjenítõ kliens. Kliensbõl is több futhat egyszerre, azaz több terminálon is lehet egyidejûleg figyelni a hálózat mûködését.
A szerver tartja karbanazt az adatbázist amely leírja a hálózatot, tartalmazza az egyes Modelleket, valamint az egyes eseményeket (event-ek) és a statisztikákat tartalmaznapló file-okat is. A Szerver végzi az egyes hálozati eszközök (routerek, managelhetô repeaterek, számítógépek stb.) rendszeres pollozását. Az eszközöket alapvetõen SNMP, illetve nem SNMP managelhetõ eszközöknél ICMP (ping) segítséségével ellenôrzi.
Az adatbázishoz alapvetôen a SpectroGRAPH rendszer segítségével
férünk hozzá, de a szerver lehetôséget
biztosít arra is, hogy más (esetleg saját fejlesztésû)
alkalmazással kapcsoldjunk hozzá (script-eket használunk
most, de lehetõség van az adatbázis C programból
való elérésére is.).
Az adatbázis felépítéséhez a Spectrum
felkínál egy ún. AutoDiscovery lehetõséget.
Ez azt jelenti, hogy megadott IP cím tartományban leelenõrzi,
hogy az adott eszköz megfelel-e egy menüben megadott feltételnek
(pl. ha csak a routereket keressük akkor csak azokat jeleniti meg).
A saját adatbázisunk felépítéséhez
is ezt a lehetôséget használtuk. A késõbb
csatlakoztatott eszközöket egyesével is hozzá lehet
adni.
Az adatbázisban minden ún. modell-ként van tárolva.
Ezek a modell-ek parent/children viszonyban állnak egymással,
pl. egy router és annak egy portja. A modellek között
többfajta kapcsolatot is meg lehet adni, így egyszerre lehet
tárolni a hálózat logikai- (melyik router melyikkel
van összekötve) és a fizikai topológiáját
(melyik telephelyen, azon belül melyik épületben, szobában,
rack szekrényben található az adott eszköz).
Az egyes modellekre külön-külön, illetve modelltípusokra
egységesen beálíthatók watch-ok. (A minden,
egy adott típusû modellre definált watch is letiltható
az adott modelleken egyenként.) A watch-ok nem csak eseményfigyelést
jelentenek, hanem logolást és új attribútum
kiszámítását is. Az eseményfigyelés
definiciójáben egy adott model vagy modeltípus
egy vagy több atribútuma értékeinek figyelembe
vételével definiáltunk egy riasztási feltételt.
A feltétel bekövetkezte és/vagy elmúlása
esetén meghívhatunk egy scriptet vagy programot, ami a pl.
riaszthatja a megfelelõ szakambereket. Mi most ezt a lehetetõséget
figyelmeztetõ E-mail küldésére használjuk.
A leggyakrabban a SpectroGRAPH alrendszert használjuk, ezen megjeleníthetôek az egyes eszközök (modellek) és ezek kapcsolata, grafikus formában. A megjelenítés több szintû, a teljes felügyelt hálózatból kiindulva egy adott részhálózat képéhez, az ott aktív eszkökhöz sõt egészen az eszköz MIB-jeihez is eljuthatunk. Lekérdezhetjük természetesen az adott modellrõl az adatbázisban tárolt értékeket is.Ugyanígy lehetõségünk van erre a fizikai topológia szerinti nézetben is. Mindez megszokás után kényelmesen kezelhetõ. Lekérdezhetjük egy adott modell, pl. egy vonal történetét is, amit report formájában ki is nyomtathatunk, ami igen hasznos lehet pl. a szolgáltatónál való reklamációnál a leállások dokumentálására.
A SpecroWATCH alrendszer segítségével követhetjük nyomon, hogy milyen aktív watch-aink vannak, itt definiálhatjuk az újakat, módosíthatjuk a régieket.