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