wyklad 13

Sieci komputerowe
Inicjowanie działania
i autokonfiguracja
wykład 13
protokoły BOOTP i DHCP
rok ak. 2004/2005
Agata Półrola
Katedra Informatyki Stosowanej UŁ
[email protected]
http://www.math.uni.lodz.pl/~polrola
Zapotrzebowanie
Rozwi zanie:
Ka dy komputer doł czony do sieci
TCP/IP musi zna swój adres IP aby móc
wysyła i odbiera datagramy;
Uzyskanie potrzebnych informacji mo e
nast pi w drodze interakcji klient – serwer
Potrzebny jest zatem protokół
umo liwiaj cy komputerowi uzyskanie
adresu IP (i ewentualnie innych
potrzebnych informacji) od wiadcz cego
odpowiedni usług serwera
do poprawnej
komunikacji potrzebuje
równie : maski podsieci, adresu routera,
adresu serwera DNS
W niektórych przypadkach informacje te
nie s pami tane przez komputer (przykład:
stacje bezdyskowe)
Rozwi zanie I: protokół RARP
Rozwi zanie II: protokół BOOTP
Pierwsze rozwi
zanie tego rodzaju to
(omówiony ju ) protokół RARP
Protokół BOOTP (Bootstrap Protocol)
został opracowany jako alternatywa dla
RARP
Klient i serwer komunikuj si u ywaj c
protokołu UDP (i IP), zatem
oprogramowanie obsługuj ce t
e by zaimplementowane
komunikacj mo
jako program u ytkowy
Wady:
działa na niskim poziomie, u ywanie go wymaga
bezpo redniego dost pu do sprz tu sieciowego
odpowied RARP zawiera mało informacji (tylko
adres IP którego ma u ywa klient)
u ywa do identyfikacji klienta adresu
sprz towego, co mo e by problemem w sieciach,
w których adresy sprz towe nie s stałe
Protokół BOOTP – c.d.
Komputer – klient BOOTP wysyła swoj
pro b u ywaj c adresu ograniczonego
rozgłaszania (255.255.255.255)
bezpo rednia komunikacja ograniczona jest zatem
do sieci lokalnej
Serwer odsyła odpowied klientowi
u ywaj c adresu ograniczonego rozgłaszania
albo
wykorzystuj c adresu sprz towy klienta
otrzymany w zapytaniu BOOTP
nie jest potrzebne dostosowywanie oprogramowania
do specyfiki konkretnej sieci (rozwi za sprz towych)
Protokół BOOTP – c.d.
Poniewa komunikacja bazuje na UDP, wi c nie
ma gwarancji dostarczenia komunikatów
Odpowiedzialno za poprawny przebieg
komunikacji spoczywa na kliencie
Gubienie datagramów obsługiwane jest
w standardowy sposób: klient wysyłaj c pro b
uruchamia zegar, je li nie otrzyma odpowiedzi
w odpowiednim czasie, to wysyła pro b
ponownie
Protokół BOOTP – c.d.
Protokół BOOTP – c.d.
operacja
Protokół BOOTP – c.d.
etapy
Protokół BOOTP – c.d.
operacja – pro ba (1) czy odpowied (2) (pro by
i odpowiedzi maj ten sam format)
typ sprz tu, długo adresu sprz towego – jak
w protokole ARP (Ethernet – typ 1)
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 zwi ksza
warto pola
identyfikator transakcji – liczba u ywana przez
klienta do powi zania odpowiedzi z pytaniem
sekundy – liczba sekund jaka upłyn ła od momentu
rozpocz cia przez klienta procedur startowych
dł.adr.sprz.
identyfikator transakcji
sekundy
nieu ywane
adres IP klienta
twój adres IP
adres IP serwera
adres IP routera
adres sprz towy klienta (16 oktetów)
nazwa serwera (64 oktety)
nazwa pliku startowego (128 oktetów)
obszar opcji (64 oktety)
BOOTP wymaga u ywania przez UDP sum
kontrolnych
BOOTP wymaga od IP przesyłania pro b
i odpowiedzi BOOTP z ustawionym bitem
„nie fragmentuj”, aby mo na było obsłu y
równie klientów maj cych zbyt mało
pami ci na zło enie datagramu
BOOTP obsługuje wielokrotne odpowiedzi –
przetwarzana jest tylko pierwsza
typ sprz tu
adres IP klienta i dalsze pola – główne dane
w komunikacie. Klient wypełnia wszystkie pola które
zna, pozostałym nadaje warto zero.
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 otrzymały zapytanie
Protokół BOOTP
mo e by! u ywany tak e przez klientów
znaj cych ju swoje adresy IP, np. w celu otrzymania nazwy
pliku startowego. W takim przypadku wypełniaj oni pole
adres IP klienta.
Je li w pro bie BOOTP pole adres IP klienta jest zerowe,
to w odpowiedzi serwer odsyła mu adres IP umieszczony
w polu twój adres IP
Protokół BOOTP – c.d.
W przypadku, gdy celem klienta jest znalezienie pliku
z obrazem systemu, który miałby by u niego
załadowany, protokół BOOTP umo liwia wykonanie
dwuetapowej procedury startowej:
Protokół BOOTP – c.d.
BOOTP dostarcza klientowi danych pozwalaj cych znale obrazu systemu (pole nazwa pliku startowego)
klient pobiera plik startowy o podanej nazwie, u ywaj c
innego protokołu (plik ten mo e by umieszczony na innym
serwerze ni serwer BOOTP)
pole obszar opcji umo liwia przesłanie przez
serwer pewnych dodatkowych informacji:
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)
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 długo ci i pewna liczba oktetów b d cych
warto ci " elementu.
opcje pozwalaj na przesłanie np. maski podsieci,
bie
cego czasu, nazwy klienta, adresów IP routerów
itp.
Protokół BOOTP – c.d.
Rozwi zanie III: protokół DHCP
Protokół BOOTP został zaprojektowany z my l o wzgl dnie stałym rodowisku, w którym ka dy
host jest podł czony na stałe do sieci:
administrator tworzy na serwerze plik konfiguracyjny
BOOTP, okre laj cy zestaw parametrów BOOTP dla
ka
dego klienta
klient identyfikowany jest zazwyczaj na podstawie
adresu sprz towego przysłanego w pytaniu. Pozwala
to serwerowi odesła odpowiednie dane pobrane
z powy
szego pliku
BOOTP umo liwia szybkie okre lenie konfiguracji
hosta na podstawie jego identyfikatora, ale
konfiguracja jest zapisana w pliku i zawsze taka sama
W przypadku zmieniaj cego si rodowiska (np.
ró ne komputery przeno ne doł czane do sieci)
protokół BOOTP nie jest wystarczaj cy
Problem pojawia si równie , je eli adresów IP
w danej sieci jest zbyt mało na to, by przydzieli
stały adres ka demu komputerowi, ale liczba
komputerów pracuj cych równocze nie jest
zazwyczaj mniejsza (posiadana pula adresów
mogłaby by wi c w danej chwili wystarczaj ca)
Pojawia si potrzeba dynamicznej konfiguracji
Protokół DHCP – c.d.
Protokół DHCP – c.d.
Dynamiczne konfigurowanie w złów umo liwia
protokół DHCP (Dynamic Host Configuration
Protocol)
DHCP rozszerza BOOTP na dwa sposoby:
Klient rozgłasza pro b DHCP, u ywaj c adresu
ograniczonego rozgłaszania.
Komunikacja klient – serwer bazuje na protokole UDP
Je li po wysłaniu pro by klient nie dostanie odpowiedzi,
to ponawia pro b
Serwery DHCP w sieci lokalnej oferuj klientowi adresy
IP; klient negocjuje z odpowiednim serwerem
wypo yczenie wybranego adresu
Adres jest wypo yczany na pewien ustalony czas (zale
ny
od specyfiki sieci i potrzeb klienta)
Pod koniec czasu wynajmu klient musi albo
wynegocjowa przedłu enie czasu wynajmu, albo
zwróci adres
Protokół DHCP – c.d.
Je li klient nie uzyska adnej odpowiedzi przed upływem
czasu wynajmu, to musi przesta u ywa adresu i
rozpocz starania o nowe IP
Przy nast pnym doł czeniu do sieci klient mo e poprosi o przydzielenie tego samego adresu który miał poprzednio
(je li go zapami tał)
Wynajem adresu mo na zako czy przed czasem (klient
informuje serwer e ju nie b dzie korzystał z
przydzielonego IP)
Podobnie jak w BOOTP, serwer DHCP nie musi si znajdowa w sieci lokalnej; mo
na u y serwera
po rednicz cego, który przeka
e pro b serwerowi DHCP
umieszczonemu w innej sieci fizycznej, a po otrzymaniu
odpowiedzi przeka
e j klientowi
Protokół DHCP – c.d.
Wi kszo pól komunikatu DHCP jest taka sama jak
w BOOTP
%
zamiast pola nieu ywane wyst puje pole znaczniki.
Nadanie pierwszemu bitowi tego pola warto ci 1
oznacza, e klient prosi o rozgłoszenie odpowiedzi
(zazwyczaj serwer odsyła j bezpo rednio do klienta
korzystaj c z adresu sprz towego zawartego w
pro bie)
Pole opcje ma taki sam format jak w przypadku
BOOTP i uwzgl dnia wszystkie opcje u
ywane
w tamtym protokole. Dodatkowe opcje umo liwiaj
np. okre lenie typu komunikatu DHCP (pro ba o
przydział adresu, pro ba o przedłu enie wynajmu itp)
„r czna” konfiguracja przydziału
administrator ustala w pliku konfiguracyjnym, jaki adres ma
otrzymywa ! dany klient (jak w BOOTP)
konfiguracja automatyczna
klient wł czaj c si do sieci wysyła pro b o przydzielenie
adresu IP
serwer wybiera wolny adres IP z puli adresów do przydziału
i odsyła go klientowi
Protokół DHCP – c.d.
DHCP obsługuje trzy metody przydziału
adresów:
umo
liwia przesłanie wszystkich potrzebnych
klientowi informacji w jednym komunikacie
pozwala przydzieli klientowi adres w sposób
dynamiczny i na krótki czas:
gdy komputer podł cza si po raz pierwszy do sieci serwer
przypisuje mu adres IP; przy kolejnych podł czeniach klient
otrzymuje zawsze ten sam adres
przydział dynamiczny
serwer „wynajmuje” adres klientowi na okre lony czas
Protokół DHCP – c.d.
Staranie o przedłu enie wynajmu rozpoczynane jest po
upływie 50% czasu. Klient wysyła do serwera pro b o przedłu enie zawieraj c obecne IP, mo e te
zasugerowa czas przedłu
enia. Serwer mo e si zgodzi lub nie.
Je li serwer nie wyrazi zgody na przedłu enie wynajmu,
klient musi przesta u
ywa tego adresu i rozpocz starania o nowe IP
Je li klient wysłał pro b o przedłu enie, ale nie
otrzymuje odpowiedzi, to po upływie 87,5% czasu
wynajmu zakłada, e serwer jest nieosi galny i
rozpoczyna procedur przewi zywania adresu – stara si skontaktowa z innym serwerem DHCP w sieci lokalnej
i uzyska od niego potwierdzenie wynajmu tego adresu
Protokół DHCP – c.d.
operacja
typ sprz tu
dł.adr.sprz.
etapy
identyfikator transakcji
sekundy
znaczniki
adres IP klienta
twój adres IP
adres IP serwera
adres IP routera
adres sprz towy klienta (16 oktetów)
nazwa serwera (64 oktety)
nazwa pliku startowego (128 oktetów)
opcje (zmienna długo # $ )
Protokół DHCP – c.d.
Protokół DHCP mo e (ale nie musi)
współpracowa z DNS (starsze wersje
serwerów DNS nie umo liwiały w ogóle
takiej współpracy)