A Szegedi Tudományegyetem gerinchálózati fejlesztései [E83]
Dombos Kálmán, Pásztor
György, Sára Attila
Szegedi Tudományegyetem
Számítóközpont
1. Előzmények
Az SzTE - mint ismeretes - nem campus-jellegű; épületei "szétszórva" helyezkednek el a városban. Ezért már korábban is sok problémát okozott az épületek közti nagy sebességű gerinc megválasztása és megvalósítása. Mivel privát hálózat építésére csak az egymáshoz közeli épületek között nyílt mód, a távolabbi épületek esetén csak az adathálózati szolgáltatók lehetőségeire támaszkodhattunk. Ezt az állapotot érzékelteti az 1. ábra.
1. ábra: A SzTE
gerinchálózat sémája
Az SzTE központi kapcsolóeszköze egy Cisco Catalyst 6509. Ehhez kapcsolódnak a közeli épületek privát rész-hálózatai, valamint a szolgáltatói hálózat a távoli épületek bekötésére.
Korábbi szolgáltatói gerinchálózatunk egy FR/ATM hálózat volt, melyet a Vivendi Telecom Hungary üzemeltetett. Ezt azonban már több helyen "kinőttük" (az FR végpontok maximális sávszélessége 1920 kbps). Mindenképpen keresnünk kellett egy nagyobb sávszélességű gerinchálózati megoldást is. Ezért 2002-ben pályázatot írtunk ki kis- és nagysebességű gerinchálózati szolgáltatásra.
2. Az új szolgáltatói gerinchálózat
A beérkezett ajánlatok értékelése során kiderült, hogy az FR végpontok üzemeltetési költsége abszolút értékben is annyira megközelítené a FastEthernet végpontokét, hogy érdemesebb minden végpontra a nagysebességű gerinchálózatot választani. Ezáltal az FR/ATM kapcsolat lemondható.
A pályázat nyerteseként a MATÁV Rt. kiépített és üzemeltet az SzTE számára egy tisztán optikai gerinchálózatot, melynek aggregációs kapcsolóeszköze egy Catalyst switch. (A gerinchálózat elnevezése a MATÁV Rt. terminológiája szerint: "Közeli Végpont" szolgáltatás.) Jelenleg 28 db FastEthernet végpont kapcsolódik hozzá. Az összegyűjtött forgalom 2 db GigaEthernet linken kapcsolódik az Egyetem központi Catalyst-6509 switch-éhez (2. ábra). A szolgáltatás további részleteiről (pl. a hálózat menedzselése, üzemeltetési tapasztalatok stb.) a MATÁV Rt. nyújt tájékoztatást.
2. ábra: Közeli Végpont
szolgáltatás sémája
A itt alkalmazható végponti routerek specifikus feladatai a következők:
ˇ
A szolgáltató felőli full duplex 100 Mbps sebesség fogadása.
ˇ
A helyi, gyakran még koaxiális hálózathoz való illeszkedés.
ˇ
A helyi, esetenként több IP alhálózat routolása.
Mivel a korábbi végponti eszközök nem voltak alkalmasak a szolgáltató felőli full duplex FastEthernet fogadására, új céleszközök beszerzésére pedig egyelőre nem telt, valódi végponti routerek helyett a feladatot ideiglenesen Linuxos, PC alapú eszközökkel oldottuk meg (3. ábra).
3. ábra: A szolgáltatói
gerinchálózat megvalósítása
3. Linuxos, PC alapú routerek
A Linuxos routerekkel kapcsolatos követelmények és megoldandó problémák:
ˇ
Központi adminisztráció.
ˇ
Egyszerű konfiguráció.
ˇ
Statikus routing.
ˇ
Esetlegesen több interfész kezelése.
ˇ
Routing tábla bővíthetősége.
ˇ
Helyi módosítás lehetősége.
ˇ
Hálózati monitoring (MRTG).
ˇ
Interfész statisztika készítése.
ˇ
Nem a számítóközpont által üzemeltetett routerek monitoringjának
lehetősége.
A fent vázolt problémák
(központi management és konfiguráció lehetősége) megoldását egy olyan
konfigurációs fájl létrehozásában láttuk, amelyben minden egyes router összes
adata benne van. E konfigurációs fájl alapján készül egy olyan image, amely a
routerek ramdiszkjének kezdeti tartalma lesz. Így elérhető például az is,
hogy a gép indulása után a merevlemezt kikapcsolhassuk a hosszabb élettartam
érdekében.
Mivel minden ,,router"
ugyanazzal a kezdeti tartalommal indul, valamilyen módon tudnia kell, hogy
milyen IP címeket, ill routingot kell beállítania. Ez a hozzárendelés a
hálózati kártyákat fizikailag azonosító MAC címek alapján történik.
A szemléleteség kedvéért
lássunk egy részletet ebből a központi konfigurációs fájlból:
!mrtghost!pcr01
!mrtglabel!01!ÁOK Fogászati
és Szájsebészeti Klinika
!ifname!eth0
#pcr01#00A024ACEAD0#160.114.126.6/30#160.114.126.5
!ifname!eth1
#pcr011#00A024ACEB5A#160.114.116.126/25
!ifname!eth2
#pcr012#00A024AEB294#160.114.45.254/24
;mrtgdump
Egy kis magyarázat:
Azok a sorok, amelyek #név#MAC#ip/mask#gw vagy
#név#MAC#ip/mask alakúak, egy hálózati kártya adatait írják le.
Ennyi adatból már számolható az interfészhez tartozó hálózati cím (network address) és a szórási cím (broadcast address). Ha gateway címet is
megadunk, akkor alapértelmezett útvonal is beállítódik az adott interfész
betöltésekor.
A monitoring
Az snmp-vel való adatgyűjtés ellen szóltak a következő érvek:
ˇ
Túl sok helyet igényelt volna a ramdiskben az snmp démon, a hozzá
tartozó konfiguráció, valamint a szükséges osztott könyvtárak (shared library).
ˇ
A Linuxos snmp démon implementációknak elég rosz híre van
biztonságtechnikai szempontból.
ˇ
Nehéz lett volna megoldani az interfész adatok külön gyűjtését.
Mivel a távoli management
miatt ssh démon már úgyis fut a gépeken, a monitorozás a következő trükkel
működik. Egy rövid shell-script bejelentkezik a routerre, és egy
egyszerű cat parancsal begyűjti a számlálók adatait a Linux
/proc interfészén
keresztül, majd a monitorozó gép a parancs kimenetét feldolgozza és átadja az
MRTG-nek, ill. egy fájlba is elmenti a begyűjtött adatokat.
Az ssh szolgáltatásra
történő automatikus (batch) bejelentkezést aszimmetrikus rsa kulcspárral
oldottuk meg. Az egyes végpontokhoz való bejelentkezést megkönnyítő
bejegyzések szintén a központi konfigurációs fájlból generálódnak az
ssh(-kliens) konfigurációs fájlba.
MRTG
Feltűnhetett a bemutatott konfiguráció-részletben, hogy egyéb furcsa ,,megjegyzések" is szerepelnek benne, amelyek nem az interfész layer 3 konfigurációjához kapcsolódnak. Ebből a központi adminisztrációs fájlból generálódik minden egyes routerhez egy-egy MRTG konfigurációs fájl, valamint a gépek áttekintő forgalmi- és hiba-statisztikája (4. ábra).
4. ábra:
Áttekintő statisztika és a router linkeket tartalmazó html oldal
Ugyanebből a fájlból generálódik minden routerhez egy html táblázatot tartalmazó oldal (5. ábra), amelyen link található az interfészek adat-, hiba- és csomag-forgalmát szemléltető MRTG oldalakra; valamint diagram készül a CPU terheléséről és a memória telítettségéről. is.
5. ábra: Egy
routerhez tartozó html oldal
A gyakorlat azonban más
nehézségeket is hozott. Egyik ilyen, hogy bizonyos helyekre nem az egyetemi
számítóközpont feladata eszközt biztosítani. A mérést azonban ilyen esetekben
is jó lenne elvégezni. A kulccsal való azonosítás megmaradt, mindössze meg kell
kérni a helyi rendszergazdát, hogy egyrészt hozzon létre egy felhasználót, aki
a már említett cat paranccsal a megfelelő számlálókat tartalmazó
fájlokat kilistáztathatja; másrészt az általunk adott kulcs publikus felét
tegye a megfelelő helyre. Így biztosítja, hogy a scriptünk 5 percenként
ssh-n bejelentkezhessen. Ezt szemlélteti az alábbi részlet:
!mrtghost!karolyi
!mrtglabel!25!Károlyi Kollégium
!mrtguser!mrtg
!ifname!eth0
#karolyi#000000000000#160.114.126.102/30#160.114.126.101
!ifname!eth1
#karolyi1#000000000000#160.114.41.254/24
;mrtgdump
Egyéb helyek monitoringja
Vannak persze ,,kirívó" esetek is, amikor a mérést ezzel a módszerrel nem tudtuk elvégezni, mert a végponton valamilyen célhardver volt (pl. egy Layer 3 tudással rendelkező switch). Ilyenkor a mérést az snmp-n keresztül az MRTG natív módon végezte. Így azonban nem tudtuk a saját interfész statisztikánkat elkészíteni. Mivel ezeket a méréseket is szerettük volna beilleszteni az eddigi táblázatainkba és áttekintő statisztikáinkba, megoldottuk, hogy a hozzájuk tartozó konstans adatokat is elhelyezhessük a központi fájlba. Példa erre:
!mrtgindexstatic!<tr><td>08</td><td><a
href="swady5/swady5.html">BTK </a></td></tr>
!mrtgowstatic!<a
href="swady5/swady5.html">08-BTK</a><br>Utoljára
frissítve: <!--#flastmod
file="data/swady5.net.u-szeged.hu/swady5.net.u-szeged.hu_rmon_10_100_port_12_on_unit_1.rrd"
--><br><img src="cgi-bin/mrtg-rrd.cgi?log=swady5.net.u-szeged.hu_rmon_10_100_port_12_on_unit_1
&cfg=swady5.cfg&png=daily">
!mrtgeowstatic!<a
href="swady5/swady5.html">08-BTK</a><br>Utoljára
frissítve: <!--#flastmod
file="data/swady5.net.u-szeged.hu/swady5.net.u-szeged.hu_rmon_10_100_port_12_on_unit_1_err.rrd"
--><br><img
src="cgi-bin/mrtg-rrd.cgi?log=swady5.net.u-szeged.hu_rmon_10_100_port_12_
on_unit_1_err&cfg=swady5.cfg&png=daily">
Szükség volt arra is, hogy olyan routingot adjunk hozzá egy gép routingtáblájához, ami automatikusan nem következne. (Vagyis nem az interfész IP címéhez tartozó networkbe esik, és nem is a default route/gateway felé kell továbbítani.) Ilyenkor a következő típusú konfigurációt használtuk:
!mrtghost!pcr19
!mrtglabel!19!SZTE Biológia
!ifname!eth0
#pcr19#00A024AD14BD#160.114.126.78/30#160.114.126.77
!ifname!eth1
#pcr191#00A024AE7DF3#160.114.56.254/24
!ifname!eth2
!ifroute!160.114.120.12/30!160.114.120.94
!ifroute!160.114.58.0/24!160.114.120.94
#pcr192#00E029054672#160.114.120.93/30
;mrtgdump
A példában szereplő routernek volt egy harmadik interfésze is, amely IP szempontjából csak egy link network volt egy Cisco router felé. Ez a router pedig bérelt vonali összeköttetésen keresztül nyújtott elérést két környékbeli alintézménynek.
Ebben az esetben a
konfiguráció úgy generálódik, hogy a harmadik interfész "felállása" után a
routinghoz automatikusan két további bejegyzés adódik. A bemutatott példában a
harmadik interfészhez az alábbi generálódik a végponti eszköz /etc/network/interfaces fájljába:
iface eth-00E029054672 inet
static
address 160.114.120.93
netmask 255.255.255.252
network 160.114.120.92
broadcast 160.114.120.95
up route add -net
160.114.120.12 netmask 255.255.255.252 gateway 160.114.120.94
down route del -net
160.114.120.12 netmask 255.255.255.252 gateway 160.114.120.94
up route add -net
160.114.58.0 netmask 255.255.255.0 gateway 160.114.120.94
down route del -net
160.114.58.0 netmask 255.255.255.0 gateway 160.114.120.94
A legutolsó pontban ismertetett extra routing bejegyzés igénye még nem fogalmazódott meg a projekt elején. Az ilyen és ehhez hasonló utólagos igények csak kellő körültekintéssel és átgondolt tervezéssel építhetők be a központi konfigurációs fájlba.
4. A minőségi átvételhez kifejlesztett teszt-eszközök
Külön feladat volt a kiépített vonalak minőségi paramétereinek ellenőrzése az átadás-átvétel során. Ehhez az előzőekben említett végponti eszközökön futtatott saját fejlesztésű szoftvereket használtunk.
A vonalak fizikai szintű átadása után - melyek egy vég-vég csillapítás- és hosszmérési jegzőkönyv átadását jelentették - minőségi átvételként 24 órás tesztelést végeztünk, melynek eredményeit mérési jegyzőkönyvben rögzítettük. A tesztelés során azt kellett megállapítanunk, hogy a szerződésben kikötött paramétereket teljesíti-e az adott végponti kapcsolat. (Például a szerződésben vállalt maximális BER-érték 10-9, ami 1000 byte-os csomagok esetén másodpercenként legfeljebb 10-5 csomag torzulását vagy elvesztését engedi meg. Miután korrekt BER-értéket mérő műszer nem állt a rendelkezésünkre, azt próbáltuk megállapítani, hogy a különböző terhelési viszonyok mellett az általunk mért fizikai hibás, ill. elveszett csomagok száma alatta marad-e a határértéknek.)
A méréseket azokkal a HP Vectra számítógépekkel végeztük, melyeket egyébként a végponti routereknek szántunk:
Hardver: HP Vectra VL 6/
Processzor: P-II 300MHz-es
Hálózati kártya: 3Com 905BTX 10/100
A Debian csomagban lévő
ping programot igényeinknek megfelelő új funkciókkal láttuk el. Mivel az
egyes mérési szakaszok a 30 perc időtartamot is meghaladták, az átlagos
válaszidő kiszámításához nem volt elegendő a 4 byte-os aritmetika
használata, és ezért 8 byte-ra tértünk át.
A program által kiírt
válaszidő sem volt elegendő információ, hiszen csak a minimális, maximális és átlag válaszidőt írta ki. Mivel mi a 20 ms-on túl visszaérkező
válaszokat hibás csomagoknak minősítettük, szükséges volt azt is tudnunk,
hogy hány ilyen csomag volt, ill. milyen volt a válaszidő eloszlása. Ezért
egy -H
intervallum1, int2,int3... funkciót
valósítottunk meg, mely egy paraméterként megadható válaszidő skálán
hisztogramot készít. A sok végpont miatt automatizálni kellett a mérés
feldolgozását is. A -e
határérték kapcsolóval, a paraméterek táblázatos kiírásával a MS Excel-be
egyszerűen importálható a méréseredmény, valamint megadja azon csomagok
számát, melyek a határértéken túl érkeztek vissza a pingelő számítógéphez.
A válaszidő méréseket különböző forgalmi viszonyok (terhelés, csomagméret) mellett szerettük volna elvégezni, reprodukálható módon. Először "flood" pinggel próbáltunk különböző sávszélességű terhelést generálni, és ezen forgalom mellett másodpercenként ping válaszidőket mérni, de ez nem volt jó. A flood ping - mondhatjuk úgy is, "ami a csövön kifér" ping - gyakorlatilag leköti a gépünk teljesítő képességét (CPU sebesség, hálózati kártya), és emellett nem reális a normál ping válaszideje. Külön forgalomgeneráló programot kellett tehát készítenünk.
Az elkészült TRAFGEN program paraméterei a következők:
-p port Az a port, ahová a program a
csomagokat küldi (port=7 esetén a Linux automatikus válaszcsomagot küld, így
két-irányú forgalom generálódik).
-s
pktsize[,pktsize[...]] Csomagméret,
több szám megadása esetén ciklikusan.
-r
packet/sec rate A generált csomagok
száma másodpercenként.
-t
timetotraf A
csomaggenerálás időtartama.
-c
packet count Az összes
generált csomag száma.
targethost A számítógép, ahova a program a csomagokat
küldi.
Ezek után nem volt más dolgunk, mint a előzőekben leírt programok segítségével egy 24 órás teszt összeállítása.
6. ábra: A teszt környezet
felépítése
Kezdetben a tesztgépekben 5 percenként elmentettük az Ethernet interface forgalmi adatait, 5 percenként az MRTG begyűjtötte ezeket, valamint az SZTE 6509 switch megfelelő portjának forgalmi adatait. Ez nem bizonyult jó ötletnek, mert a mérést zavarta.
A 24 órás tesztet egyetlen script elindításával oldottuk meg, a mérés során tehát a tesztgépekkel nem volt külső kommunikáció (nem "zavartuk" a mérést), az SZTE switch portjaira futtatott MRTG-vel felügyeltük a tesztet (max. 5 teszt futott párhuzamosan). Az ábrán egy 24 órás teszthez tartozó switch-port forgalom látható. Az első "lépcső" a csomagvesztés teszthez, míg a második a késleltetés teszthez tartozik.
7. ábra: Egy 24 órás
teszthez tartozó forgalmi grafikon
Csomagvesztés teszt
A teszt0 gépből 8*30 perces 100, 800, 1472 byte hosszúságú flood-ping csomagokat adtunk ki, és a visszaérkezett csomagok számát, valamint a válaszidő hisztogramját rögzítettük. A teszt1 gépen jelentkező fizikai hibák számát szintén feljegyeztük. A mérések félórás egységekre bontása az esetleges ismétlések és az azonos mérések összevetése miatt volt célszerű.
CSOMAGVESZTÉS MÉRÉS, csomagméret: 1472 byte
2002.10.07_23:08:31
PING testl5 (10.1.0.10): 1472 data bytes
--- testl5 ping statistics ---
14000019 packets transmitted, 14000000 packets received, 0%
packet loss
round-trip min/avg/max = 0.9/1.2/26.4 ms
0 packets in (0;0.3]
0 packets in (0.3;0.6]
10556527 packets in (0.6;1.2]
3443362 packets in (1.2;2.4]
61 packets in (2.4;5.0]
20 packets in (5.0;10.0]
20 packets in (10.0;20.0]
10 packets in (20.0;50.0]
0 packets in (50.0;100.0]
0 packets in (100.0;500.0]
0 packets in (500.0;infin)
A fenti mérési eredményeket úgy értelmezzük, hogy az
elküldött 14 000 019 csomagból 14 000 000-t visszakaptunk, tehát 19
csomag vagy valóban elveszett, vagy a
"flood ping" módszer miatt nem érkezett még vissza, de mi a mérést már
abbahagytuk. Mindenesetre - a legrosszabb esetet feltételezve - elveszettnek
nyilvánítjuk őket. Továbbá 10 csomag 20 ms-on túl érkezett vissza, amelyeket szintén a hibás csomagok közé
soroltunk. Tehát a csomagvesztés ~2*10-6, ami megfelel a szerződésben rögzítettnek.
Azt nem állítjuk, hogy a vonal, illetve a szolgáltató központi eszköz hibája
miatt veszett/késett el a 29 csomag, mert ez a mi eszközeink hibája és a "flood
ping" módszer hibája is lehet.
A test1 gépben tárolt interface adatok egy részlete:
date input
byte input pkt. in. err. Output byte output
pkt. out. err.
:
200210071615 4140827484 60043483 8 4140524950 60040070 0
200210071620 411886034 64029669 18
411569484 64026100 0
200210071625 977605856 68013700 18
977275216 68009978 0
200210071630 1538927554 71966753 23 1538582880 71962877 0
200210071635 2103021814 75939334 23 2102663094 75935303 0
:
A jegyzőkönyv "Csomagvesztés teszt" táblázatában a fenti adatok vannak, kiegészítve a hibahatárral (minden 100 000-ik csomag elveszhet), valamint a külső oldalon detektált fizikai hibák (input error) számával.
Mérési
Jegyzőkönyv
:
Csomagvesztés teszt:
|
|
elküldött
csomag db |
csomag
hossz byte |
átlag
válaszidő ms |
hibás
csomagok db |
hibahatár
db |
fizikai
hiba db |
||
|
|
elveszett |
>20ms |
összesen |
|||||
|
|
184 000 140 |
100 |
0,6 |
140 |
233 |
373 |
1840 |
42 |
|
|
144 000 176 |
800 |
0,8 |
176 |
258 |
434 |
1440 |
63 |
|
|
112 000 209 |
1472 |
1,5 |
209 |
249 |
458 |
1120 |
38 |
|
Össz.: |
440 000 525 |
|
|
525 |
740 |
1265 |
4400 |
143 |
|
|
|
|
|
|
|
|
|
|
:
Késleltetés teszt
A teszt0 gép pingette a teszt1 gépet, 100, 800 és 1472 byte hosszúságú csomagokkal. Rögzítettük a válaszidő hisztogramját, majd e méréseket különböző forgalmi terhelés mellett megismételtük.
A táblázat első oszlopában szereplő szám a generált forgalom mértékét jelenti, zárójelben a forgalomgeneráláshoz használt csomagméret szerepel.
Mérési
Jegyzőkönyv
:
Késleltetés teszt:
|
terhelés Mbps |
elküldött csomag db |
csomag hossz byte |
|
válaszidő ms |
|
elveszett csom. db |
elkésett (>20ms) db |
|
|
|
|
minimum |
átlag |
maximum |
|
|
|
0 |
1800 |
100 |
0,2 |
0,2 |
0,4 |
0 |
0 |
|
0 |
1800 |
800 |
0,6 |
0,6 |
0,8 |
0 |
0 |
|
0 |
1800 |
1472 |
0,9 |
0,9 |
1,1 |
0 |
0 |
|
15(100) |
1800 |
100 |
0,2 |
0,2 |
0,4 |
0 |
0 |
|
15(100) |
1800 |
800 |
0,6 |
0,7 |
9,7 |
0 |
0 |
|
15(100) |
1800 |
1472 |
1,0 |
1,1 |
1,4 |
0 |
0 |
|
15(800) |
1800 |
100 |
1,6 |
2,2 |
2,6 |
0 |
0 |
|
15(800) |
1800 |
800 |
0,6 |
0,6 |
4,7 |
0 |
0 |
|
15(800) |
1800 |
1472 |
0,9 |
2,7 |
8,6 |
0 |
0 |
|
15(1472) |
1800 |
100 |
1,7 |
1,9 |
4,1 |
0 |
0 |
|
15(1472) |
1800 |
800 |
0,6 |
0,6 |
0,7 |
0 |
0 |
|
15(1472) |
1800 |
1472 |
0,9 |
0,9 |
2,8 |
0 |
0 |
|
50(800) |
1800 |
100 |
0,2 |
0,7 |
5,9 |
0 |
0 |
|
50(800) |
1800 |
800 |
0,6 |
1,0 |
2,9 |
0 |
0 |
|
50(800) |
1800 |
1472 |
1,0 |
1,0 |
3,2 |
0 |
0 |
|
50(1472) |
1800 |
100 |
0,2 |
0,9 |
3,0 |
0 |
0 |
|
50(1472) |
1800 |
800 |
0,6 |
1,1 |
3,1 |
0 |
0 |
|
50(1472) |
1800 |
1472 |
0,9 |
1,7 |
3,3 |
0 |
0 |
|
70(1472) |
1800 |
100 |
0,2 |
1,6 |
25,4 |
0 |
1 |
|
70(1472) |
1800 |
800 |
0,6 |
1,9 |
29,1 |
0 |
6 |
|
70(1472) |
1800 |
1472 |
0,9 |
2,0 |
7,3 |
0 |
0 |
|
95(1472) |
1800 |
100 |
0,2 |
2,6 |
160,0 |
0 |
8 |
|
95(1472) |
1800 |
800 |
0,6 |
2,7 |
210,0 |
0 |
6 |
|
95(1472) |
1800 |
1472 |
0,9 |
2,8 |
179,9 |
0 |
3 |
:
A táblázatból kiolvasható, hogy a válaszidő átlaga sehol sem rosszabb 3 ms-nál, és 20 ms-nál később visszaérkező csomag is alig volt.