plik


ÿþSieci komputerowe wykBad dla II roku Inf. zao w filiii UA w Tomaszowie Maz. 2007/2008 wykBad 8 Agata PóBrola WydziaB Matematyki i Informatyki UA http://www.math.uni.lodz.pl/~polrola Inicjowanie dziaBania i autokonfiguracja protokoBy BOOTP i DHCP Zapotrzebowanie nð Ka|dy komputer doBczony do sieci TCP/IP musi zna swój adres IP aby móc wysyBa i odbiera datagramy; nð do poprawnej komunikacji potrzebuje równie|: maski podsieci, adresu routera, adresu serwera DNS nð W niektórych przypadkach informacje te nie s pamitane przez komputer (przykBad: stacje bezdyskowe) Rozwizanie: nð Uzyskanie potrzebnych informacji mo|e nastpi w drodze interakcji klient  serwer nð Potrzebny jest zatem protokóB umo|liwiajcy komputerowi uzyskanie adresu IP (i ewentualnie innych potrzebnych informacji) od [wiadczcego odpowiedni usBug serwera Rozwizanie I: protokóB RARP nð Pierwsze rozwizanie tego rodzaju to (omówiony ju|) protokóB RARP nð Wady: nð dziaBa na niskim poziomie, u|ywanie go wymaga bezpo[redniego dostpu do sprztu sieciowego nð odpowiedz RARP zawiera maBo informacji (tylko adres IP którego ma u|ywa klient) nð u|ywa do identyfikacji klienta adresu sprztowego, co mo|e by problemem w sieciach, w których adresy sprztowe nie s staBe Rozwizanie II: protokóB BOOTP nð ProtokóB BOOTP (Bootstrap Protocol) zostaB opracowany jako alternatywa dla RARP nð Klient i serwer komunikuj si u|ywajc protokoBu UDP (i IP), zatem oprogramowanie obsBugujce t komunikacj mo|e by zaimplementowane jako program u|ytkowy nie jest potrzebne dostosowywanie oprogramowania do specyfiki konkretnej sieci (rozwizaD sprztowych) ProtokóB BOOTP  c.d. nð Komputer  klient BOOTP wysyBa swoj pro[b u|ywajc adresu ograniczonego rozgBaszania (255.255.255.255) nð bezpo[rednia komunikacja ograniczona jest zatem do sieci lokalnej nð Serwer odsyBa odpowiedz klientowi nð u|ywajc adresu ograniczonego rozgBaszania albo nð wykorzystujc adresu sprztowy klienta otrzymany w zapytaniu BOOTP ProtokóB BOOTP  c.d. nð Poniewa| komunikacja bazuje na UDP, wic nie ma gwarancji dostarczenia komunikatów nð Odpowiedzialno[ za poprawny przebieg komunikacji spoczywa na kliencie nð Gubienie datagramów obsBugiwane jest w standardowy sposób: klient wysyBajc pro[b uruchamia zegar, je[li nie otrzyma odpowiedzi w odpowiednim czasie, to wysyBa pro[b ponownie ProtokóB BOOTP  c.d. nð BOOTP wymaga u|ywania przez UDP sum kontrolnych nð BOOTP wymaga od IP przesyBania pro[b i odpowiedzi BOOTP z ustawionym bitem  nie fragmentuj , aby mo|na byBo obsBu|y równie| klientów majcych zbyt maBo pamici na zBo|enie datagramu nð BOOTP obsBuguje wielokrotne odpowiedzi  przetwarzana jest tylko pierwsza ProtokóB BOOTP  c.d. operacja typ sprztu dB.adr.sprz. etapy identyfikator transakcji sekundy nieu|ywane adres IP klienta twój adres IP adres IP serwera adres IP routera adres sprztowy klienta (16 oktetów) nazwa serwera (64 oktety) nazwa pliku startowego (128 oktetów) obszar opcji (64 oktety) ProtokóB BOOTP  c.d. nð operacja  pro[ba (1) czy odpowiedz (2) (pro[by i odpowiedzi maj ten sam format) nð typ sprztu, dBugo[ adresu sprztowego  jak w protokole ARP (Ethernet  typ 1) nð etapy  maksymalna liczba routerów przez które mo|e przej[ komunikat; klient umieszcza 0; je[li serwer  po[rednik odbierze komunikat i zdecyduje si przekaza go do innej maszyny, to zwiksza warto[ pola nð identyfikator transakcji  liczba u|ywana przez klienta do powizania odpowiedzi z pytaniem nð sekundy  liczba sekund jaka upBynBa od momentu rozpoczcia przez klienta procedur startowych ProtokóB BOOTP  c.d. nð adres IP klienta i dalsze pola  gBówne dane w komunikacie. Klient wypeBnia wszystkie pola które zna, pozostaBym nadaje warto[ zero. nð Je[li klient zna nazw lub adres serwera, to mo|e j umie[ci w pytaniu, wtedy odpowiedzi udzieli mu tylko ten serwer. W przeciwnym wypadku odpowiedzi udzielaj wszystkie serwery, które otrzymaBy zapytanie nð ProtokóB BOOTP mo|e by u|ywany tak|e przez klientów znajcych ju| swoje adresy IP, np. w celu otrzymania nazwy pliku startowego. W takim przypadku wypeBniaj oni pole adres IP klienta. nð Je[li w pro[bie BOOTP pole adres IP klienta jest zerowe, to w odpowiedzi serwer odsyBa mu adres IP umieszczony w polu twój adres IP ProtokóB BOOTP  c.d. nð W przypadku, gdy celem klienta jest znalezienie pliku z obrazem systemu, który miaBby by u niego zaBadowany, protokóB BOOTP umo|liwia wykonanie dwuetapowej procedury startowej: nð BOOTP dostarcza klientowi danych pozwalajcych znalez obrazu systemu (pole nazwa pliku startowego) nð klient pobiera plik startowy o podanej nazwie, u|ywajc innego protokoBu (plik ten mo|e by umieszczony na innym serwerze ni| serwer BOOTP) nð Umo|liwia to klientowi poproszenie o okre[lony system operacyjny (np. UNIX  nazwa ta jest umieszczana przez niego w polu nazwa pliku startowego). Serwer wpisuje w to pole rzeczywist nazw pliku (nazwy plików mog by ró|ne dla ró|nych klientów, np. w zale|no[ci od architektury) ProtokóB BOOTP  c.d. nð pole obszar opcji umo|liwia przesBanie przez serwer pewnych dodatkowych informacji: nð pierwsze cztery oktety nazywane s  magicznym ciasteczkiem (magic cookie) i definiuj format elementów w dalszej cz[ci pola. Standardowy format elementów (opisywany przez ciasteczko o warto[ci 99.130.83.99) to jeden oktet typu, jeden oktet dBugo[ci i pewna liczba oktetów bdcych warto[ci elementu. nð opcje pozwalaj na przesBanie np. maski podsieci, bie|cego czasu, nazwy klienta, adresów IP routerów itp. ProtokóB BOOTP  c.d. nð ProtokóB BOOTP zostaB zaprojektowany z my[l o wzgldnie staBym [rodowisku, w którym ka|dy host jest podBczony na staBe do sieci: nð administrator tworzy na serwerze plik konfiguracyjny BOOTP, okre[lajcy zestaw parametrów BOOTP dla ka|dego klienta nð klient identyfikowany jest zazwyczaj na podstawie adresu sprztowego przysBanego w pytaniu. Pozwala to serwerowi odesBa odpowiednie dane pobrane z powy|szego pliku nð BOOTP umo|liwia szybkie okre[lenie konfiguracji hosta na podstawie jego identyfikatora, ale konfiguracja jest zapisana w pliku i zawsze taka sama Rozwizanie III: protokóB DHCP nð W przypadku zmieniajcego si [rodowiska (np. ró|ne komputery przeno[ne doBczane do sieci) protokóB BOOTP nie jest wystarczajcy nð Problem pojawia si równie|, je|eli adresów IP w danej sieci jest zbyt maBo na to, by przydzieli staBy adres ka|demu komputerowi, ale liczba komputerów pracujcych równocze[nie jest zazwyczaj mniejsza (posiadana pula adresów mogBaby by wic w danej chwili wystarczajca) nð Pojawia si potrzeba dynamicznej konfiguracji ProtokóB DHCP  c.d. nð Dynamiczne konfigurowanie wzBów umo|liwia protokóB DHCP (Dynamic Host Configuration Protocol) nð DHCP rozszerza BOOTP na dwa sposoby: nð umo|liwia przesBanie wszystkich potrzebnych klientowi informacji w jednym komunikacie nð pozwala przydzieli klientowi adres w sposób dynamiczny i na krótki czas: nð klient wBczajc si do sieci wysyBa pro[b o przydzielenie adresu IP nð serwer wybiera wolny adres IP z puli adresów do przydziaBu i odsyBa go klientowi ProtokóB DHCP  c.d. nð DHCP obsBuguje trzy metody przydziaBu adresów: nð  rczna konfiguracja przydziaBu nð administrator ustala w pliku konfiguracyjnym, jaki adres ma otrzymywa dany klient (jak w BOOTP) nð konfiguracja automatyczna nð gdy komputer podBcza si po raz pierwszy do sieci serwer przypisuje mu adres IP; przy kolejnych podBczeniach klient otrzymuje zawsze ten sam adres nð przydziaB dynamiczny nð serwer  wynajmuje adres klientowi na okre[lony czas ProtokóB DHCP  c.d. nð Klient rozgBasza pro[b DHCP, u|ywajc adresu ograniczonego rozgBaszania. nð Komunikacja klient  serwer bazuje na protokole UDP nð Je[li po wysBaniu pro[by klient nie dostanie odpowiedzi, to ponawia pro[b nð Serwery DHCP w sieci lokalnej oferuj klientowi adresy IP; klient negocjuje z odpowiednim serwerem wypo|yczenie wybranego adresu nð Adres jest wypo|yczany na pewien ustalony czas (zale|ny od specyfiki sieci i potrzeb klienta) nð Pod koniec czasu wynajmu klient musi albo wynegocjowa przedBu|enie czasu wynajmu, albo zwróci adres ProtokóB DHCP  c.d. nð Staranie o przedBu|enie wynajmu rozpoczynane jest po upBywie 50% czasu. Klient wysyBa do serwera pro[b o przedBu|enie zawierajc obecne IP, mo|e te| zasugerowa czas przedBu|enia. Serwer mo|e si zgodzi lub nie. nð Je[li serwer nie wyrazi zgody na przedBu|enie wynajmu, klient musi przesta u|ywa tego adresu i rozpocz starania o nowe IP nð Je[li klient wysBaB pro[b o przedBu|enie, ale nie otrzymuje odpowiedzi, to po upBywie 87,5% czasu wynajmu zakBada, |e serwer jest nieosigalny i rozpoczyna procedur przewizywania adresu  stara si skontaktowa z innym serwerem DHCP w sieci lokalnej i uzyska od niego potwierdzenie wynajmu tego adresu ProtokóB DHCP  c.d. nð Je[li klient nie uzyska |adnej odpowiedzi przed upBywem czasu wynajmu, to musi przesta u|ywa adresu i rozpocz starania o nowe IP nð Przy nastpnym doBczeniu do sieci klient mo|e poprosi o przydzielenie tego samego adresu który miaB poprzednio (je[li go zapamitaB) nð Wynajem adresu mo|na zakoDczy przed czasem (klient informuje serwer |e ju| nie bdzie korzystaB z przydzielonego IP) nð Podobnie jak w BOOTP, serwer DHCP nie musi si znajdowa w sieci lokalnej; mo|na u|y serwera po[redniczcego, który przeka|e pro[b serwerowi DHCP umieszczonemu w innej sieci fizycznej, a po otrzymaniu odpowiedzi przeka|e j klientowi ProtokóB DHCP  c.d. operacja typ sprztu dB.adr.sprz. etapy identyfikator transakcji sekundy znaczniki adres IP klienta twój adres IP adres IP serwera adres IP routera adres sprztowy klienta (16 oktetów) nazwa serwera (64 oktety) nazwa pliku startowego (128 oktetów) opcje (zmienna dBugo[) ProtokóB DHCP  c.d. nð Wikszo[ pól komunikatu DHCP jest taka sama jak w BOOTP nð zamiast pola nieu|ywane wystpuje pole znaczniki. Nadanie pierwszemu bitowi tego pola warto[ci 1 oznacza, |e klient prosi o rozgBoszenie odpowiedzi (zazwyczaj serwer odsyBa j bezpo[rednio do klienta korzystajc z adresu sprztowego zawartego w pro[bie) nð Pole opcje ma taki sam format jak w przypadku BOOTP i uwzgldnia wszystkie opcje u|ywane w tamtym protokole. Dodatkowe opcje umo|liwiaj np. okre[lenie typu komunikatu DHCP (pro[ba o przydziaB adresu, pro[ba o przedBu|enie wynajmu itp) ProtokóB DHCP  c.d. nð ProtokóB DHCP mo|e (ale nie musi) wspóBpracowa z DNS (usBugami nazewniczymi) nð (starsze wersje serwerów DNS nie umo|liwiaBy w ogóle takiej wspóBpracy) nð DNS zostanie omówiony na nastpnym wykBadzie Jeszcze o trasowaniu: protokoBy routingu Trasowanie nð Routery dokonuj wyboru trasy na podstawie informacji zapisanej w tablicy tras nð Pytania: nð jakie warto[ci powinny si znajdowa w tablicach tras? nð skd routery maj w tablicach wszystkie potrzebne informacje? Tablice tras nð Ka|dy router rozpoczyna dziaBanie z pewn pocztkow tablic tras, która jest nastpnie aktualizowana je|eli trasy si zmieniaj nð W maBych sieciach wystarczajca jest aktualizacja rczna, w du|ych i szybko si zmieniajcych potrzebne s metody automatyczne Tablice tras  c.d. nð Dotychczas rozwa|any schemat nie zawieraB automatycznej modyfikacji tras (poza ICMP redirect, przesyBanym midzy routerem a hostem, a nie midzy routerami) oraz nie zapewniaB spójno[ci trasowania Rozwizanie z wczesnego Internetu nð Sie szkieletowa nð Routery podzielone na dwie grupy: routery centralne (core / interior routers) i routery zewntrzne (inaczej poboczne, exterior routers) nð Routery centralne komunikuj si midzy sob, tak aby ka|dy z nich miaB peBn wiedz o wszystkich mo|liwych trasach i aby ta wiedza byBa spójna nð Routery centralne nie stosuj tras domy[lnych, gdy| mo|e to prowadzi do nieefektywno[ci komunikacji Rozwizanie z wczesnego Internetu  c.d. nð We wczesnym Internecie  szkielet (routery centralne) stanowiBa sie ARPANET nð Routery centralne byBy zarzdzane przez INOC (Internet Network Operation Center), a poboczne  przez inne (lokalne) organizacje majce dostp do sieci nð Takie rozwizanie nie sprawdza si w sieciach o bardziej zBo|onej topologii (np. utworzenie dwóch sieci szkieletowych komunikujcych si ze sob za po[rednictwem kilku routerów bardzo komplikuje trasowanie) Najpopularniejsze algorytmy obliczania i propagacji tras nð Algorytm wektor - odlegBo[ (vector  distance, Bellman-Ford routing) nð Router pamita w tablicy wszystkie znane mu routery nð Przy starcie tworzy tablic sieci bezpo[rednio dostpnych. nð Ka|dy wpis w tablicy zawiera informacj o odlegBo[ci do danej sieci nð Co jaki[ czas router wysyBa tablic tras do wszystkich bezpo[rednio dostpnych routerów, a one aktualizuj swoje tablice tras zgodnie z uzyskan informacj nð wada algorytmów  wektor  odlegBo[ : konieczno[ wymiany du|ej liczby komunikatów Algorytmy obliczania i propagacji tras  c.d. nð Link-state routing (tzw. SPF, najpierw najkrótsza [cie|ka) nð Algorytmy SPF wymagaj od ka|dego routera peBnej informacji o topologii sieci nð Router testuje stan routerów ssiednich (stan Bcza) i propaguje stan Bcza do wszystkich innych routerów nð Co jaki[ czas router rozgBasza informacje ze stanem wszystkich Bczy. Router otrzymujcy tak informacj modyfikuje stan tras w swojej  mapie sieci i aktualizuje tablic tras obliczajc najkrótsze [cie|ki w uzyskanym grafie (algorytm Dijkstry) ProtokóB GGP nð Wczesny Internet u|ywaB do wymiany informacji o routingu protokoBu GGP (Gateway  to  Gateway Protocol) nð ProtokóB  wektor-odlegBo[ nð ByB u|ywany przez routery centralne nð Nowy router dodawany do systemu otrzymywaB list ssiadów, z którymi wymieniaB informacje nð Wymieniane informacje zawieraBy zbiór par (N,D), gdzie N  sie docelowa, D  odlegBo[ mierzona w  router hops (liczba routerów w drodze do tej sieci) Routing hierarchiczny nð wraz ze wzrostem rozmiaru sieci i liczby routerów obci|enie zwizane z przechowywaniem i przesyBaniem informacji zwizanych z routingiem staje si bardzo du|e nð niemo|liwe jest, aby ka|dy router przechowywaB informacje o caBej sieci globalnej nð potrzebna jest autonomia administracyjna poszczególnych organizacji majcych swoje sieci nð rozwizanie: organizowanie routerów za pomoc systemów autonomicznych Systemy autonomiczne nð System autonomiczny  grupa sieci i routerów pod wspóln administracj nð Routery wewntrz systemu autonomicznego dowolnie zarzdzaj trasami nð Ka|dy system autonomiczny wybiera router lub routery przeznaczone do komunikacji z innymi systemami autonomicznymi. Odpowiadaj one za przekazywanie informacji o osigalno[ci sieci wewntrz  swojego systemu do innych systemów Systemy autonomiczne  c.d. nð Routery odpowiedzialne za komunikacj z innymi systemami autonomicznymi nazywane s routerami zewntrznymi albo brzegowymi (exterior gateways), routery dziaBajce wewntrz systemu  wewntrznymi (interior gateways) Komunikacja midzy routerami zewntrznymi nð Jednym z protokoBów u|ywanych do komunikacji midzy routerami zewntrznymi jest EGP (Exterior Gateway Protocol) nð router mo|e uzgodni z innym routerem, |e bd  ssiadami . tzn. bd wymienia informacje o trasach nð router sprawdza co jaki[ czas czy jego ssiedzi dziaBaj nð ssiedzi wymieniaj komunikaty pozwalajce zaktualizowa tablice routingu. Komunikat taki zawiera list znanych danemu routerowi sieci i odlegBo[ci do nich nð Inny protokóB tego typu  (E)BGP (Exterior Border Gateway Protocol) Komunikacja midzy routerami wewntrznymi nð Grup protokoBów u|ywanych przez routery wewntrz systemu autonomicznego okre[la si nazw IGP (Interior Gateway Protocols) nð PrzykBadowe protokoBy z tej grupy: nð RIP nð HELLO nð OSPF Komunikacja midzy routerami wewntrznymi  c.d. nð RIP  Routing Information Protocol nð implementacja algorytmu wektor-odlegBo[ dla sieci lokalnych nð odlegBo[ mierzona jako  hop count  liczba routerów midzy rozwa|anymi sieciami nð przeznaczony dla niewielkich sieci  odlegBo[ 16 traktowana jest jako nieskoDczono[ Komunikacja midzy routerami wewntrznymi  c.d. nð HELLO nð protokóB bazujcy na algorytmie  wektor- odlegBo[ nð do oceny odlegBo[ci u|ywa opóznieD (tj. czasu potrzebnego na dostarczenie komunikatu za po[rednictwem sieci), a nie liczby routerów po[redniczcych Komunikacja midzy routerami wewntrznymi  c.d. nð OSPF  Open SPF Protocol nð zestandaryzowany protokóB implementujcy algorytm SPF nð wprowadza wiele ulepszeD pozwalajcych na bardziej efektywn komunikacj nð wymiana danych midzy routerami jest autoryzowana (dane wymieniaj tylko routery uprawnione) nð zezwala na abstrakcj szczegóBów sieci fizycznych (krawdz w pamitanym grafie poBczeD mo|e odpowiada przej[ciu przez kilka sieci po[redniczcych; wzeB grafu mo|e by routerem lub sieci) nð pozwala na równowa|enie obci|eD, je[li do danej sieci prowadzi kilka tras o tym samym koszcie nð pozwala na trasowanie  type of service (trasami o maBych opóznieniach, wysokiej przepustowo[ci itp, je[li nadawca tego wymaga)

Wyszukiwarka

Podobne podstrony:
0708z sieciTM w01
0708z sieciTM w06
0708z sieciTM w05
0708z sieciTM w02
0708z sieciTM w09
0708z sieciTM w04
0708z sieciTM w07
0708z sieciTM w03
0708z sk zlm w08
w08 PodstPrzy roznor
W07 W08 SCR
SGE s3 II nst w08
w08
w08 2
0708z sk zlm w07
W08 Fizyka Haran
TPL 3 W08 v1 1

więcej podobnych podstron