2004
Poznańskie Warsztaty Telekomunikacyjne Poznań 9 - 10 grudnia 2004 Marcin Godlewski
Sławomir Przyłucki Konrad Płachecki Politechnika Lubelska Katedra Elektroniki ul. Nadbystrzycka 38a 20-618 Lublin
godo@politechnika.lublin.pl
POMIARY I MONITOROWANIE RUCHU SIECIOWEGO W OPARCIU O PAKIET MRTG
Streszczenie:
Problematyka pomiarów sieci rozległych jest niezwykle istotna w kontekście modelowania i analizy zachodzących w nich zjawisk jak i przewidywania zmian ich zachowania w wyniku postępu technologicznego i rozwoju usług sieciowych. W szerokiej gamie narzędzi służącym takim pomiarom, ciekawym rozwiązaniem wydaje się być pakiet MRTG (ang. Multi Router Traffic Grapher). Artykuł zawiera podstawowe zasady działania tego pakietu oraz jego potencjalne znaczenie dla tworzenia modeli ruchu opartych o diagramy ruchu lub samopodobieństwo.
1. WPROWADZENIE
Pomiary i modelowanie ruchu w sieciach rozległych, takich jak Internet, jest obecnie przedmiotem zainteresowania znaczącej liczby zespołów badawczych. Jednocześnie, tematyka ta stanowi wielkie wyzwanie z punktu widzenia algorytmów pomiarowych, metod modelowania i symulacji. Powodem takiego stanu rzeczy jest wielka złożoność i różnorodność sieci wchodzących w skład Internetu oraz szybkie zmiany, jakie w nich zachodzą.
Zagadnienie takie jak topologia, własności protokołów bezpołączeniowych i połączeniowych odpowiedzia- lnych za transmisję danych, różnorodność usług generujących ruch, przeciążenia sieci, zagadnienia jakości transmisji i usług, powodują konieczność stawiania wielu pytań i rozwiązywania wielu problemów przez inżynierów zaangażowanych w badania nad metodami pomiarów i symulacji Internetu. W literaturze fachowej proponowanych jest wiele strategii i i rozwiązań prowadzących do bardziej lub mniej złożonych modeli transmisji danych w sieciach rozległych [1], [2]. Do najpopularniejszych zaliczyć można poszukiwanie, na podstawie zgromadzonych danych pomiarowych rzeczywistego ruchu w sieciach pakietowych, stałości w zachowaniu Internetu lub zakresu zmian parametrów ruchu sieciowego, istotnych z punktu widzenia danego modelu. Wiele zagadnień dotyczących tych problemów zostało szczegółowo poruszonych w pracy Vern Paxson [5].
Z powodu złożoności sieci, pomiary ruchu odgrywają ważną rolę w próbie scharakteryzowania zachowania obecnego Internetu a budowane w oparciu o nie modele, pozwalają na przewidzenie skutków, jakie wynikną po wprowadzeniu określonych zmian w jego działaniu.
2. EKSPERYMENT A SYMULACJA
Jest rzeczą istotną , by w trakcie modelowania sieci rozległych, wyraźnie rozdzielić zadania stawiane przed eksperymentem a symulacją. Podczas, gdy pomiary i eksperymenty dostarczają sposobów zrozumienia „rzeczywistego świata”, symulacja i analiza są zarezerwowane dla badania wymyślonego, abstrakcyjnego modelu. Pomiar jest potrzebny w celu sprawdzenia rzeczywistości, często służąc do potwierdzenia przyjętych założeń i hipotez.
Doświadczenia i symulacje są często ważne a nawet wręcz niezbędne przy wdrażaniu nowych rozwiązań i nowych projektów oraz do przewidywania zachowań obiektu rzeczywistego w nowych warunkach.
Eksperymenty odgrywają również kluczową rolę w poznawaniu nowych środowisk i pozwalają ocenić i przewidzieć ostateczną odpowiedź, na przykład na pytanie jak protokoły powinny działać w danym środowisku sieciowym. Jakkolwiek pomiary i eksperymenty posiadają wiele zalet i możliwości, mogą być stosowane tylko i wyłącznie do badań istniejących struktur Internetu i istniejących fizycznie rozwiązań. Nie mogą i nie mają możliwości być użyte do poznania parametrów lub własności projektowanych struktur sieciowych, w tak krótkim jak i długookresowym horyzoncie czasowym. To zadanie jest możliwe do zrealizowania jedynie w oparciu o poprawnie skonstruowany i zweryfikowany model.
Jednym z wielu problemów, z jakim stykają się zespoły badawcze i wdrożeniowe, jest strach przed tym, że nowe, nie przetestowane właściwie rozwiązanie może stać się elementem sieci i co gorsza stać się bardzo popularne (możliwość tzw. „sukcesu katastrofy”). W dzisiejszych czasach, z powodu bardzo dużej ilości i prędkości przesyłu danych oraz szerokiej dostępności sieci, zagrożenie takie staje się coraz bardziej realne. Jest wielce prawdopodobne, że niezupełnie skończone i zweryfikowane rozwiązania mogą się znaleźć w milionie komputerów na całym świecie w przeciągu tygodnia. Jednym z przykładów takiego „sukcesu katastrofy” jest protokół HTTP stosowany przy dostępie do stron WWW. Gdyby projektanci tego rozwiązania wyobraziliby sobie działanie swojego produktu w Internecie i gdyby przebadali konsekwencje przy pomocy symulacji, mogliby znacząco ulepszyć swój projekt, co by zaowocowało wydajniejszym działaniem Internetu.
Opracowanie dobrego modelu do symulacji może pomóc uniknąć takich sytuacji a pomiary
zweryfikować poprawność tych modeli i ewentualnie zmodyfikować ich parametry .
Analiza i symulacja dostarcza możliwości badania sieci rozległych, w tym i Internetu, w odizolowaniu od świata zewnętrznego (ze wszystkimi tego konsekwencjami, zarówno dobrymi jak i złymi). Rola symulacji jest kluczowa, ponieważ pozwala na głębsze poznanie podstawowych praw rządzących Internetem. Niesie jednak ze sobą pewne ryzyko związane z nadmiernym uproszczeniem modeli, co może spowodować pominięcie kluczowych parametrów zachowania Internetu a co za tym idzie bezużyteczność takiej analizy. Dlatego tak jak konieczne jest poznanie wstępne badanego „obiektu”
w wyniku eksperymentu, tak końcowa weryfikacja wyników symulacji też powinna mieć charakter eksperymentalny.
Internet posiada kilka kluczowych własności, które sprawiają, że jest nadzwyczaj trudny do scharakteryzowania, a co za tym idzie, i do pomiarów,
symulacji i opisu za pomocą modeli. Najważniejszą przyczyną sukcesu Internetu jest dominujące znaczenie protokołu IP, który pozwala na połączenie rozmaitych technologii i domen administracyjnych. IP pozwala, aby różne sieci rządzące się odmiennymi prawami mogły działać wspólnie bez przeszkód. Jakkolwiek fakt, że IP maskuje różnice przed użytkownikiem nie oznacza, że je likwiduje! IP ujednolica sieć maskując różnorodność, ale nie ujednolica zachowania. W istocie, wielki sukces, jakim jest ujednolicenie różnych sieci, spowodował, że bardzo trudno jest zrozumieć i opisać jak duże sieci IP się zachowują.
Symulacje są uzupełnieniem analizy, nie tylko przez sprawdzenie jej poprawności, ale również pozwalają na przebadanie skomplikowanych scenariuszy, które byłyby trudne lub wręcz niemożliwe do analizy w inny sposób. Symulacje mogą również grać znaczącą rolę w rozwijaniu intuicji badaczy.
Nie ma wątpliwości, iż symulacje dotyczące Internetu są najbardziej użytecznym narzędziem w zrozumieniu dynamiki transmisji lub odkrywaniu nieprzewidzianych zachowań sieci w trakcie jej użytkowania [2], [5]. Należy jednak pamiętać iż jednym z niebezpieczeństw jest traktowanie wyników symulacji jedynie jako liczby (np.: protokół A jest 23%
wydajniejszy niż protokół B). Ważne nie tylko są pytania czy małe zmiany w modelu mogą wpłynąć na duże zmiany w obserwowanych wynikach, ale również, jakie skutki miałaby mała zmiana w implementacji programowej symulatora na dokładność leżącego u podstaw modelu.
W zależności od tego, co jest przedmiotem badań, można mieć różne wymagania co do cech charakterystycznych symulatora, modeli w nim zaimplementowanych, jak i metod gromadzenia wejściowych danych pomiarowych oraz weryfikacji symulacji. Dla projektów związanych z oceną jakościową istniejących rozwiązań, rozsądnie jest postawić pytanie: alternatywa A czy alternatywa B jest wydajniejsza podczas warunków X. W takim przypadku, należy zdefiniować leżący u podstaw model, sprawdzić lub określić jego implementację w symulatorze, i w wyniku procesu symulacji wykorzystać otrzymane wyniki symulacji w celu pokazania, że alternatywa A jest lepsza o 23% od alternatywy B. Dla badań, interpolujących stan obecny na określony okres w przyszłości, stawiane pytanie brzmi: która z alternatyw, A czy B, jest lepszym wyborem dla np. Internetu za pięć, dziesięć lat. W takim przypadku trudno mówić o weryfikacji ale wobec tego konieczne jest wykorzystanie innych metod i narzędzi do zgromadzenia wiedzy o ewolucji sieci w postaci pomiarów starannie zdefiniowanego zestawu parametrów.
3. PROBLEM SKALI
Drugą kluczową sprawą jest to, że Internet jest duży i złożony. Według ISC (ang. Internet Systems Consortium) w styczniu 2004 roku było ponad 233 miliony komputerów podłączonych do sieci!. Ten rozmiar niesie ze sobą dwie trudności. Po pierwsze zasięg różnorodności wspomniany powyżej jest bardzo rozległy: jeśli tylko mały procent komputerów zachowuje się w nietypowy sposób, to Internet ciągle może zawierać tysiące takich komputerów, często zbyt dużo żeby je pominąć w procesie analizy i symulacji.
Rozmiar także niesie ze sobą palący problem, jakim jest skalowalność rozwiązań. Wiele protokołów sieciowych i mechanizmów świetnie pracuje w małych sieciach zawierających dziesiątki bądź setki komputerów, lub nawet „dużych” sieciach z dziesiątkami tysięcy komputerów, lecz staje się nieprzydatnych kiedy mówimy o dzisiejszym Internecie lub kilka razy większym przyszłym Internecie. Duża skala oznacza, że rzadkie zjawiska będą często pojawiać się w pewnych częściach sieci.
Stwarza to dodatkowe problemy przy próbach pomiarów i modelowania takich zjawisk.
4. ZMIENNOŚĆ W CZASIE
Kolejnym ważnym zagadnieniem jest to, że Internet ciągle drastycznie się zmienia. Na przykład, jak już wspomnieliśmy, w styczniu 2004 roku było w sieci ponad 233 miliony komputerów. W styczniu 1997, siedem lat wcześniej, było tylko 16 milionów komputerów, co wskazuje na 50% wzrost rocznie. Ten wzrost wymusza pytanie: jak duży Internet będzie za 2 lata, pięć lat? Czy pomiary dokonane dziś i oparte na nich modele i symulacje będą wystarczająco miarodajne? A może wspomniany wyżej rozrost Internetu w latach 1997-2004 jest jednorazowy. Jednak dostępne dane przeczą takim wnioskom.
Przedstawiony poniżej przykład ilustruje zależność wysyłanych danych w funkcji w sieci USENET. Skala na osi rzędnych jest logarytmowana.
Rys 1. Wzrost ruchu w sieci USENET.
Prawie idealnie prosta linia wskazuje na charakter wzrostu ruchu w sieci USNET wynoszący 80% wzrost/rok. Kolejny rysunek, rys. 2 pokazuje inną statystykę wzrostu. Przedstawia ilości połączeń wykonanych do Lawrence Berkley National Laboratory (LBNK) każdego dnia od stycznia 1997 do końca grudnia 2000 roku. Skala osi Y jest logarytmiczna. Przykład ten ilustruje tym razem nie wzrost całego Internetu, ale jednej szczególnego miejsca; ale nadal widoczny jest ekspotencjalny wzrost, tym razem około 52% na rok. Potwierdza to znaczenie pomiarów lokalnych, ograniczonych segmentów sieci ponieważ otrzymane w ten sposób wyniki są odzwierciedleniem tendencji obowiązujących w całej sieci rozległej.
Rys. 2 . Ilości połączeń wykonanych do Lawrence Berkley National Laboratory (LBNK) od stycznia 1997
do końca grudnia 2000 roku.
Z drugiej jednak strony, pomiary pozwalające poznać zależność liczby połączeń i czasu w niektórych przypadkach zawodzą. Okazuje się, że często ważniejsze jest, jakie aplikacje generują ruch. Nie są rzadkie przypadki, gdy pojawiają się programy, których działalność przyczynia się do gwałtownego
wzrostu ruchu w sieci, po czym niespodziewanie znikają one ze „sceny”. Rysunek 3. przedstawia liczbę połączeń HTTP w ośmiu punktach zarejestrowanych w LBNL.
Rys. 3. Liczba połączeń HTTP w ośmiu punktach zarejestrowanych w LBNL
Wyraźnie widać, iż usługa WWW nie była znana prawie do końca 1992 roku (dominował inny ruch). Nagle rozpoczął się gwałtowny wzrost: ruch Web zaczął się podwajać co 7-8 tygodni, i trwało to przez dwa pełne lata. Wszystkie przewidywania, co do kształtu przyszłego ruchu powstałe przed 1993 rokiem stały się całkowicie chybione począwszy od 1994 roku, kiedy ruch Web całkowicie zdominował ruch w sieci.
Ponadto, taki gwałtowny wzrost nie był jednorazowym wydarzeniem. Na przykład, w styczniu 1992 roku Mbone – „multicast bone” – do transmisji dźwięku i obrazu przez Internet nie istniał. Trzy lata później generował 20% całego ruchu Internetowego w Digital’s Western Research Lab; 40% w LBNL; i więcej niż 50% w Bellcore. W tym przypadku jednak eksplozja zmniejszyła się i dzisiaj ruch w MBone jest przesłonięty przez ruch Web.
Można zatem stwierdzić, iż ruch w Internecie, ilość połączeń i przesyłanych danych ciągle rośnie a okresowe odchylenia od trendu spowodowane przez popularne w danej chwili aplikacje będą nastręczały trudności w próbach pomiarów ruchu i analizy otrzymanych w ich wyniku danych.
5. MODELOWANIE DYNAMIKI TRANSMISJI
Jednym ze sposobów przedstawienia dynamiki ruchu jest analiza zachowania Internetu jako funkcji zmieniających się parametrów, które z kolei znajdują uzasadnienie w charakterze usług sieciowych i nawykach użytkowników. Drugim ze sposobów ułatwiających modelowanie jest poszukiwanie stałości.
Przez stałość zazwyczaj rozumie się empirycznie dowiedzioną niezmienność, stwierdzoną na podstawie pomiarów w adekwatnym interwale czasowym.
5.1. DIAGRAMY RUCHU
Badania statystyk połączeń prowadzonych na przestrzeni wielu lat badań pokazują, że aktywność w sieci ma ścisły związek z specyfiką aktywności użytkowników sieci. Pierwsze maksimum ruchu pojawia się około 8 rano i jest wywołane rozpoczęciem pracy w urzędach i przedsiębiorstwach. Pomiędzy godziną 15-16 następuje gwałtowny spadek ruchu, ponieważ większość ludzi opuszcza prace. Następne maksimum ruchu pojawia się około godziny 18 i ten natężony ruch trwa do około 22-23. Po tej godzinie następuje spadek aktywności użytkowników sieci a minimum jest osiągane około godziny 2-3 w nocy, gdy większość ludzi udaje się na spoczynek.
Oczywiście w dni wolne od pracy rozkład przedstawia się trochę inaczej gdyż ludzie mają więcej czasu żeby korzystać z Internetu albo wręcz przeciwnie, by od niego odpocząć. Podobne cykliczne zachowania można obserwować w diagramach tygodniowych, miesięcznych i rocznych.
Istnieje wiele odmian diagramów aktywności, np. : rozkłady ruchu uwzględniające typy wykorzystywanych protokołów, czasy trwania połączeń, ilości danych przesyłanych w poszczególnych sesjach., itp.
5.2. SAMOPODOBIEŃSTWO
Długoterminowe korelacje transmisji pakietów w zagregowanym ruchu internetowym są dobrze opisane przez procesy samopodobne [4], [6].
Najbardziej uproszczona definicja samopodobieństwa mówi, że: forma lub proces jest samopodobny, gdy obserwowany w różnej skali czasu lub też przestrzeni zachowuje charakterystyczne dla siebie cechy.
Tradycyjne sposoby modelowania (oparte np. na modelu Poissonowskim lub Markova) przewidują, że długoterminowe korelacje powinny szybko wygasać i w konsekwencji taki ruch obserwowany w dłuższej skali czasu powinien być całkiem płynny. Jednak wiele empirycznych danych wyraźnie pokazuje, że te korelacje nie są bez znaczenia w dłuższej skali czasu.
Dłuższa skala czasu oznacza czas od kilkuset milisekund do dziesiątek minut. Przy dłuższym okresie niestacjonarne efekty, takie jak opisane w punkcie wyżej, stają się bardziej znaczące i modele samopodobne stają się zwyczajnie nieprecyzyjne.
Jednak przy krótszych czasach samopodobieństwo jest bardzo istotne podczas tworzenia modeli.
6. POMIARY I MONITOROWANIE RUCHU SIECIOWEGO
Na podstawie przedstawionych w poprzednich rozdziałach faktów, jasno wynika, iż każdy proces modelowania i symulacji złożonej struktury jaką jest Internet, wymaga starannego przegotowania procesów pomiarów i monitorowania ruchu sieciowego.
Wspomniana wyżej analiza diagramów ruchu czy też analiza i modelowanie ruchu oparte na samopodobieństwie, są doskonałym przykładem znaczenia narzędzi i algorytmów pomiarowych dla poprawności modeli ruchu w sieciach rozległych.
Jednym z bardzo interesujących i elastycznych dla wielu zastosowań pomiarów jest pakiet MRTG (ang. Multi Router Traffic Grapher) [3], [7]. MRTG jest to narzędzie, pozwalajace na monitoring obciążenia na łączach internetowych (zbiera i wyświetla statystyki pochodzące od usługi SNMP [ang. Simple Network Management Protocol], która działa na dowolnym routerze). Może także zostać użyty do monitorowania, np. pracy procesora czy sesji użytkowników. Dane, które są zbierane przez MRTG, gromadzone są w tzw. plikach log i przedstawiane w postaci stron HTML (zawierających również graficzną interpretację pomiarów w postaci wykresów) . Dane, które zostały zebrane, mogą być obrazowane na wykresach dziennych, tygodniowych, miesięcznych lub rocznych. Aby program mógł działać poprawnie, potrzebne jest zainstalowanie obsługi języka Perl.
Pakiet MRTG jest dostępny m.in. na platformach Windows, Linux, FreeBSD, Solaris. Niezwykle wygodną cechą programu MRTG jest to, iż nie musi on pobierać wszystkich informacji za pośrednictwem SNMP, a może korzystać z zewnętrznych źródeł informacji (dane z innych programów).
7. SPOSÓB DZIAŁANIA PAKIETU MRTG
MRTG jest programem, który pobiera dane o wartości monitorowanej wielkości w równych odstępach czasu. W podstawowym trybie pracy, wartości otrzymane z poszczególnych odczytów są od siebie odejmowane. Jest to szczególnie użyteczne w przypadku odczytywania ilości bajtów jakie zostały przesłane przez interfejs sieciowy przy pomocy SNMP.
Otrzymamy wtedy ilość bajtów jaka została przesłana pomiędzy poszczególnymi odczytami. Następnie dla określonego przedziału czasu pomiędzy przedostatnim a ostatnim odczytem obliczana jest średnia wartość transferu, która mówi ile średnio przesyłano bajtów na sekundę. Uzyskamy ją, jeśli podzielmy ilość przesłanych bajtów przez (stałą) wartość czasu, w jakim zostały one przesłane. Wartości jakie są prezentowane przez MRTG są wartościami uśrednionymi, MRTG nie obrazuje nam zmian mierzonej wielkości w każdej chwili.
Po wyliczeniu wartości średnich w odstępach, pomiędzy którymi dokonanywano odczytów, następuje normalizacja. Celem tej normalizacji jest zmiana przedziałów, w których na początku dokonano pomiarów na znormalizowane przedziały – o takiej samej długości, lecz o takim przesunięciu, aby rozpoczynały się np. o równej godzinie.
Wartości znormalizowane zapisywane są w pliku log. Aby uniknąć nieskończonemu rozrastaniu się owego pliku dokonywanie jest łączenie otrzymanych wartości. Na podstawie znormalizowanych wartości, które odpowiadają przedziałom 5 minut rysowany jest wykres dzienny. Wartości z 6 kolejnym przedziałów, po określonym czasie (nieco więcej niż jeden dzień), łączone są w pojedynczą wartość odpowiadającą 30 minutom. Wartości owe z kolei realizują wykres tygodniowy, a po około 8 dniach są scalane w wartości odpowiadające 2 godzinom, które tworzą w rezultacie końcowym wykres miesięczny. Ostatnim etapem łączenia jest tworzenie przedziałów odpowiadających
jednemu dniu, które są przedstawiane na wykresie całorocznym.
Oprócz opisanego powyżej sposobu działania programu, możliwe jest także zrealizowanie pomiarów bez odejmowania wartości mierzonej w konkretnej chwili od wartości mierzonej wcześniej. W dalszym jednak ciągu wartość taka dzielona jest przez przedział czasu. Inaczej rzecz biorąc, odpowiada to sposobowi, który jest domyślny podczas obliczania wartości średniej, z tym że za wartość która była wcześniej przyjmowana jest zawsze wartość zero.
Możliwa jest również rezygnacja z dokonywania jakiegokolwiek obliczania wartości średniej przez program MRTG. Wartości, które otrzymamy z pomiarów nie są od siebie odejmowane i nie są też przez przedział czasu dzielone.
7.1. KONFIGURACJA PAKIETU MRTG.
Plik konfiguracyjny programu MRTG można zmodyfikować samodzielnie w zależności od specyficznych zadań stawianych przed pomiarami lub wygenerować przy pomocy programy cfgmaker.
Plik ten zbudowany jest z części związanej z konfiguracją parametrów globalnych, oraz dotyczącej poszczególnych celów. Tworząc plik konfiguracyjny możliwym staje się również wykorzystanie dodatkowej funkcjonalności MRTG, którą jest reagowanie na przekroczeniu przez mierzone zmienne wartości progowych.
Wspomniane parametry globalne można ustawić wpisując konkretne słowo kluczowe zakończone znakiem „:”, po którym to słowie umieszcza się wartość, która jest przypisana do tego parametru. W przypadku parametrów dla poszczególnych celów koniecznym staje się umieszczenie po słowie kluczowym a przed znakiem „:” w nawiasach kwadratowych wybranej nazwy monitorowanego obiektu – Parametr[<nazwa celu>]:
<wartość parametru>.
7.2. URUCHAMIANIE PAKIETU MRTG W SYSTEMIE LINUX
Najprostszym sposobem okresowego uruchamiania programu mrtg jest użycie systemowego deamona cron. Takie podejście powoduje, że co ustalony czas uruchamiany będzie nowy proces mrtg.
Przy każdym nowym uruchomieniu mrtg wczytywany jest plik konfiguracyjny.
Sposobem, dzięki któremu możemy zmniejszyć obciążenia systemu przez mrtg jest uruchomienie go jako usługi systemowej, czyli daemona. Należy wtedy w pliku konfiguracyjnym dopisać parametr:
RunAsDeamon – uruchamianie MRTG jako deamona
Niezbędne jest również stworzenie skryptu startowego, który będzie uruchomiał naszą usługę podczas startu systemu. Parametrem, który musi zostać ustawiony łącznie z RunAsDeamon jest
Interval – jak często uruchamiać mrtg.
Parametr ten oczywiście warto ustawić jednak nie tylko w trakcie uruchamiania mrtg jako daemon.
Jego aktywacja powoduje również, że nagłówek strony
HTML będzie posiadał informację o długości życia tejże strony. Podobne działanie parametr Refresh, wskazujący po jakim okresie przeglądarka powinna odświeżyć stronę.
W mrtg możliwe jest również wybranie jednego z kilkudziesięciu języków jakie są dostępne, który użyty będzie podczas generacji strony HTML.
Tym parametrem jest :
Language – wybór języka, w jakim będą wyświetlane strony HTML.
7.3. GENEROWANIE PLIKU KONFIGURRACYJNEGO
Zgodnie z informacjami z podrozdziału 7.1, konfiguracja działania mrtg możliwa jest przy pomocy programu cfgmaker. Generuje on plik konfiguracyjny, korzystając z zadanych mu opcji. Jego składnia wywołania jest przedstawiona poniżej:
cfgmaker [[options] [community@]router] [[options]
[community@]router2…]
Program ten umożliwia generowanie wielu plików konfiguracyjnych dla kilku celów równocześnie, ponieważ istnieje możliwość podania równocześnie wielu połączeń jakie chcemy monitorować.
7.4. GENEROWANIE STRONY INDEKSU Kolejnym programem jaki jest dostarczany w pakiecie mrtg jest program indexmaker, służący do generowania stron www tj. indeksu, który zawiera informacje o monitorowanych celach prezentując dla przykładu po jednym wykresie dla każdego celu.
Umożliwia to nawigację po stronach www poszczególnych celów.
Wywołanie programu posiada składnię przedstawioną poniżej:
indexmaker [options] regexp mrtg.cfg [other.cfg]
W miejsce mrtg.cfg podaje się prawidłową ścieżkę do pliku konfiguracyjnego.
8. PRZYKŁADOWE MIERZONE PARAMETRY 8.1. PRZEPUSTOWOŚĆ
Pod określeniem przepustowości kryje się miara możliwości przesyłania danych przez określone urządzenie sieciowe lub łącze. Inaczej można powiedzieć, iż jest to prostu ilość informacji jaka może zostać przesłana w ciągu jednostki czasu. Miara ta wyrażana jest w bitach na sekundę (bps) lub jednostkach pochodnych (kilobit na sekundę, megabit na sekundę). Jest to chyba najczęściej brany pod uwagę parametr QoS.
Przedstawiony przypadek ilustruje najbardziej podstawowe działanie mrtg, jakim jest monitoring obciążenia sieciowego (w tym wypadku na interfejsie eth0). Cel jest zdefiniowany przy pomocy formatu Interface by IP. Maksymalna ilość bajtów została ustalona dla ethernetu na standardową wartość 1250000.
Oś czasu na wykresie rośnie w prawą stronę.
Jednocześnie w pliku konfiguracyjnym została
Rys. 6. Dobowe opóźnienie pakietów do portalu www.wp.pl
ustawioną przezroczystość tła, nie jest także rysowane obramowanie oraz strzałki znajdujące się na osiach.
Zwiększono również ilość poziomych linii oraz zmieniono jednocześnie opis osi pionowej. Na wykresach poniżej przedstawiony został również stosunek ruchu przychodzącego do wychodzącego w procentach. Odpowiada za to opcja dorelpercent. Dla miesięcznego i rocznego wykresu pokazywane są również wartości maksymalne z 5 minut.
Dzięki temu prostemu skryptowi istnieje możliwość sprawdzenia, na których łączach (do jakich operatorów bądź też portali) występuje dość duża degradacja ruchu. Posiadając takie wykresy do kilku dostawców Internetu jesteśmy w stanie ocenić, gdzie występują przeciążenia w sieci i gdzie mogą występować problemy korzystania z Internetu.
Z kolei opcja integer powoduje, że wyświetlane poniżej wykresu wartości bieżące, średnie i maksymalne pierwszej i drugiej zmiennej ( w tym przypadku także procentowego stosunku tych zmiennych) wyświetlane są z zaokrągleniem do wartości całkowitych.
9. PODSUMOWANIE
Problematyka pomiarów sieci rozległych jest niezwykle istotna w kontekście modelowania i analizy zachodzących w nich zjawisk jak i przewidywania zmian ich zachowania w wyniku postępu technologicznego i rozwoju usług sieciowych.
Diagramy ruchu czy też modele samopodobieństwa są podstawowymi narzędziami stosowanymi w celu zrozumienia praw rządzących zagregowanym ruchem sieciowym oraz w celu określenia relacji pomiędzy różnymi parametrami transmisji. W szerokiej gamie narzędzi służącym takim pomiarom, ciekawym rozwiązaniem wydaje się być pakiet MRTG. Jego główną zaletą, oprócz tego iż dostępny jest na zasadach Open Source i może być wykorzystywany na większości dzisiejszych systemów operacyjnych, jest elastyczność w definiowaniu celów i parametrów pomiarów.
Rys. 4. Dobowa przepływność na routerze.
Artykuł nie porusza wszystkich możliwości zastosowania pakietu MRTG, w tym szczególnie przystosowania go nie tylko do pomiarów sieci na 2 i 3 warstwie modelu OSI ale również do monitorowania połączeń na warstwie 4. Mamy jednak nadzieje, że ukazuje przydatność tego narzędzia w procesie tworzenia i weryfikacji szerokiej gamy modeli ruchu w sieciach rozległych.
Rys. 5. Tygodniowa przepływność na routerze.
8.2. OPÓŹNIENIE
Opóźnienie (ang. latency) - czas, jaki zajmuje pakietowi przejście przez dany odcinek sieci. W zależności od potrzeb, możemy rozważać opóźnienie na całym odcinku sieci, przez który transmitowany jest pakiet (od nadawcy do odbiorcy) jak i opóźnienie wprowadzane przez jeden węzeł sieci. W kontekście QoS termin „opóźnienie” oznacza najczęściej czas, który upływa od momentu wysłania pakietu przez nadawcę do momentu odebrania go przez odbiorcę. Do pomiaru opóźnienia można wykorzystać najbardziej powszechny program jakim jest ping. Dzięki niemu można odczytać wartość maksymalną i minimalną opóźnienia do konkretnego hosta.
Poniżej przedstawiony jest bardzo prosty skrypt, który jako dane wyjściowe podaje minimalne i maksymalne opóźnienie w milisekundach do podanego hosta. Dane wyjściowe należy przekazać jako dane wejściowe dla programu MRTG.
10. SPIS LITERATURY
1. R. G. Addie, M. Zukerman, T. D. Neame
“Broadband Traffic Modeling: Simple Solutions to Hard Problems”, IEEE Communications Magazine, August 1998
2. J-C. Bolot, “End-to-End Packet Delay and Loss Behavior in the Internet,” Proc. SIGCOMM '93, pp.
289-298, Sept. 1993.
3. S. Przyłucki M. Godlewski „Open Source tools for the QoS measurements in the IP networks”, Międzynarodowa Konferencja Studentów i Młodych Pracowników Nauki "Telekomunikacja XXI wieku", Kielce 2003
4. W. E. Leland et al., “On the self-similar nature of ethernet traffic (extended version),” IEEE/ACM Trans. Networking, vol. 2, no. 1–15, 1994.
5. V. Paxson, “Measurements and Analysis of Endto- End Internet Dynamics,” Ph.D. Dissertation, University of California, Berkeley, April 1997.
6. Praca zbiorowa, “Self-Similar Network Traffic and Performance Evaluation”, Edited by Kihong Park, Walter Willinger, John Wiley & Sons, Inc., 2000.
7. Pakiet MRTG http://ee- staff.ethz.ch/~oetiker/webtools/mrtg/
