RARP, TFTP, BOOTP, DHCP, protokół zarządzania siecią SNMP.
RARP (RFC 903).
Protokół RARP (Reverse Addreess Resolution Protocol) umożliwia przyznawanie numeru IP na przykład bezdyskowym stacjom roboczym. Zadaniem RARP jest odczytanie adresu sprzętowego karty sieciowej oraz wysłanie zapytania o adres IP. Zapytanie (odpowiedni pakiet RARP) jest wysyłane w formie broadcast na poziomie warstwy łącza (zatem nie jest przekazywane przez rutery). Odpowiedź jest wysyłana przez serwer RARP w formie pakietu RARP (typu unicast). Można uruchomić więcej serwerów RARP w sieci lokalnej (dla zwiększenia niezawodności). Zwykle tylko pierwsza odpowiedź jest brana pod uwagę. Powoduje to jednak zwiększenie ruchu w sieci.
Format pakietu RARP jest podobny do formatu pakietu ARP. Różnica polega na tym, że w polu typ ramki w zapytaniach i odpowiedziach RARP jest wartość 0x8035, natomiast pole op ma wartość 3 w zapytaniach i 4 w odpowiedziach.
Serwer RARP generuje odpowiedź na podstawie pliku zawierającego odwzorowanie adresów sprzętowych na adresy IP (np. /etc/ethers).
TFTP (RFC 1350).
TFTP (Trivial File Transfer Protocol) jest prostym protokołem wymiany plików, bazującym na UDP (w przeciwieństwie do FTP, który opiera się na TCP). TFTP jest używany do ładowania systemu operacyjnego na stacjach bezdyskowych w systemach Unix.
TFTP umożliwia przesyłanie plików w obydwie strony, zawiera mechanizmy kontroli zagubionych i powtórzonych pakietów. TFTP nie zawiera mechanizmów autentykacji (logowania, uwierzytelniania), dlatego w wielu implementacjach umożliwia dostęp tylko do wybranego katalogu - zawierającego pliki niezbędne do uruchomienia systemu operacyjnego na stacji bezdyskowej.
Zaletą TFTP jest jego prostota, implementacje mogą być łatwo wpisywane do pamięci ROM.
BOOTP (RFC951, dodatkowo RFC 1084, 1123, 1542)
Wady wcześniej opisanego RARP:
odpowiedź RARP zawiera mało informacji (tylko adres IP),
RARP daje stałe odwzorowanie adresów sprzętowych na IP (oparte na tablicach),
RARP używa adresu sprzętowego, nie przenosi się między ruterami.
BOOTP (BOOTstrap Protocol) używa UDP oraz IP. Umożliwia za pomocą jednego komunikatu uzyskanie takich informacji, jak przydzielony komputerowi adres IP, adres rutera, adres serwera BOOTP, maski podsieci.
W jaki sposób serwer BOOTP wykorzystuje UDP do komunikacji z komputerem, który nie zna swojego adresu IP?
Klient no ogół wykorzystuje adres ograniczonego rozgłaszania do przesłania swojego zapytania.
Przypomnienie: adres ukierunkowanego rozgłaszania to adres, który w części sieci ma poprawny adres sieci, natomiast w części hosta ma same jedynki. Adres ograniczonego rozgłaszania (lub inaczej adres rozgłaszania w sieci lokalnej) składa się z 32 jedynek (255.255.255.255), adres ten jest wykorzystywany do rozgłaszania w sieci lokalnej zanim komputer dowie się jaki jest jego adres IP oraz adres sieci.
Adresy IP rozgłaszania w miarę możliwości są odwzorowywane na sprzętowe adresy rozgłaszania.
Serwer na podstawie swojego pliku konfiguracyjnego przydziela adres IP (pliki takie można nazwać statycznymi, zmieniają się na ogół rzadko). Adres ten może być rozgłoszony, lub - lepiej - serwer powinien mieć możliwość modyfikacji lokalnej tablicy ARP. Powód: normalnie po przydzieleniu IP, do komputera powinna być przesłana odpowiedź serwera. ARP powinien rozgłosić zapytanie „kto ma podany IP?”, ale komputer docelowy nie odpowie, gdyż tego adresu jeszcze nie zna. Dlatego potrzebna jest modyfikacja pamięci ARP. Dodatkowe niebezpieczeństwo - IP klienta może odrzucić datagram.
BOOTP wymaga od UDP ustawiania sumy kontrolnej. Ponadto dodaje własne mechanizmy sprawdzania czy datagramy nie zaginęły. Po wysłaniu komunikatu uruchamiany jest zegar, jeśli po ustalonym czasie nie nadchodzi odpowiedź, komunikat jest retransmitowany. Czasy oczekiwania są pseudolosowe (aby zmniejszyć prawdopodobieństwo kolizji w sieci po np. zaniku zasilania, gdy więcej komputerów startuje).
Format komunikatu BOOTP
Pola są ustalonej długości, odpowiedzi mają ten sam format co prośby. Serwer nasłuchuje na porcie 67, klient ma przydzielony port nr 68.
Standardowo klient wypełnia wszystkie pola, które zna.
Bity:
0 8 16 24
Operacja 1=zapytanie, 2=odpowiedź |
Typ sprzętu (technologia sieciowa) |
Dł. adr. sprz. (6 w Ethernecie) |
Etapy (używane przez rutery) |
Identyfikator transakcji (określany przez klienta, zwracany przez serwer, pozwala na identyfikację odpowiedzi od serwera w przypadku odpowiedzi rozgłoszonej) |
|||
Sekundy (klient wpisuje czas od wystartowania systemu) |
Nie używane |
||
Adres IP klienta (na początku klient przesyła same zera. Jeśli klient zna już swój numer, to go tu wpisuje; - gdy np. wysyła pytanie o pliki startowe) |
|||
Twój adres IP (tu serwer zwraca przydzielony adres IP) |
|||
Adres IP serwera (może być wypełnione przez klienta, wówczas tylko ten serwer odpowie. W tym polu serwer zwraca swój IP. |
|||
Adres IP rutera (używany gdy zapytania do serwera BOOTP przekraczają bramy) |
|||
Adres sprzętowy klienta (16 oktetów - wypełnia klient) |
|||
Nazwa węzła serwera (64 oktety, wypełnia serwer lub klient - jeśli chce informacji od konktretnego serwera)
|
|||
Nazwa pliku startowego (128 oktetów. Klient wysyła nazwę, np. Unix, serwer odsyła pełny adres pliku)
|
|||
Dane specyficzne dla firmy (64 oktety). Pierwsze cztery oktety to 99.130.83.99 („magic number”) ... Pole dane specyficzne dla firmy mogą zawierać wpisy składające się z oktetu „typ wpisu”, oktetu „długość wpisu” oraz określonej liczby oktetów wartości wpisu. Obecnie w polu tym mogą być przesyłane maski podsieci. |
|||
Zadanie: znajdź w RFC 1700 (Assigned numbers) jaki powinien być typ (liczba) wpisu określającego, że w polu „danych specyficznych dla firmy” będzie przesłana maska podsieci.
Procedura startu systemu z użyciem BOOTP jest dwuetapowa. W pierwszym etapie serwer BOOTP przesyła informacje potrzebne klientowi do pracy w sieci oraz do wystartowania wybranego systemu operacyjnego (patrz pole „nazwa poliku startowego. W drugim etapie wykorzystywany jest inny protokół - TFTP do skopiowania pliku obrazu pamięci w danym systemie.
DHCP (Dynamic Host Configuration Protocol, RFC 1541, 1533, 1534(współpraca z BOOTP), nowsze 2031, 2032)
Wadą BOOTP jest statyczny sposób przydzielania numerów IP.
Przydział dynamiczny umożliwia pracę (ale nie jednoczesną) kilku (wielu) komputerów z przydzielonym jednym numerem IP.
Serwer DHCP wykorzystuje trzy metody przypisywania adresów:
przydział statyczny IP do danego komputera (ustawienie „ręczne”),
automatyczny przydział statyczny przy pierwszym starcie komputera i kontakcie z serwerem,
przydział dynamiczny, w którym serwer wynajmuje adres IP na określony czas.
DHCP umożliwia budowanie autokonfigurujących się systemów.
Stany klienta DHCP (najważniejsze przejścia):
Konwencja etykietowania krawędzi:
[ ] oznacza brak komunikatu,
komunikat otrzymany od serwera / komunikat wysłany
Serwer definiuje trzy zegary: czasu wynajmu, czasu odnawiania oraz czasu przewiązywania (mogą być jawnie określone bądź domyślne). Zegary te są startowane u klienta w stanie „Powiązanie”.
Format komunikatu DHCP:
Większość pól jest taka jak w komunikacie BOOTP.
Bity:
0 8 16 24
Operacja |
Typ sprz. |
Dł. adr. sprz. |
Etapy |
Identyfikator transakcji |
|||
Sekundy |
Znaczniki (używany jest tylko najstarszy bit w celu zażądania odpowiedzi typu rozgłaszanie sprzętowe) |
||
Adres IP klienta |
|||
Twój adres IP |
|||
Adres IP serwera |
|||
Adres IP rutera |
|||
Adres sprzętowy klienta (16 oktetów) |
|||
Nazwa węzła serwera (64 oktety. Tu mogą się znaleźć opcje, jeśli pole nie jest używane standardowo)
|
|||
Nazwa pliku startowego (128 oktetów. Tu mogą się znaleźć opcje, jeśli pole nie jest używane standardowo)
|
|||
Opcje. Tu specyfikowany jest typ komunikatu DHCP (kod (53), Długość (1), Typ (1-7)) (zmienna długość) ...
|
|||
DHCP serwer można zainstalować w Windows 2000 serwer.
Windows 2000 obsługuje dynamiczne zmiany w DNS (po otrzymaniu IP od serwera DHCP). DNS będzie omawiany na jednym z kolejnych wykładów.
Protokół zarządzania siecią (intersiecią) SNMP (RFC 1157 + sporo innych, dot. m.in. nowszych wersji i różnych szczegółów).
SNMP (Simple Network Management Protocol) jest protokołem wykorzystywanym do zarządzania różnymi elementami sieci (np. hostami, ruterami, mostami, koncentratorami). Składniki oprogramowania sieciowego, obsługujące komunikaty zarządzania elementami sieci nazywają się agentami. Zarządzanie siecią realizowane jest przy pomocy sieciowej stacji zarządzającej (komputer dedykowany lub z zainstalowanym odpowiednim oprogramowaniem). Agenci i systemy zarządzające należą do tzw. communities. Tylko członkowie jednej community mogą się ze sobą komunikować.
SNMP wykorzystuje protokół UDP i porty 161 (element sieciowy z agentem SNMP) oraz 162 (zarządzający).
Podstawowym sposobem działania programów zarządzających jest odczytywanie i zapisywanie wartości pewnych zmiennych z bazy danych MIB (Management Information Base). RFC 1213 (MIB II) określa, jakie zmienne powinny być przechowywane w elementach sieciowych. Typy i struktury zmiennych określane są przez SMI (Structure of Management Information RFC 1155).
Przykłady zmiennych:
Nazwa |
Kategoria |
Znaczenie |
sysUpTime |
system |
Czas od uruchomienia systemu |
ifNumber |
interfaces |
liczba interfejsów sieciowych |
ipDefaultTTL |
ip |
standardowy TTL |
ipInReceives |
ip |
liczba otrzymanych datagramów |
ipOutNoRoutes |
ip |
liczba błędów trasowania |
ipRoutingTable |
ip |
tablica rutowania |
tcpInSegs |
tcp |
liczba otrzymanych segmentów TCP |
udpInDatagrams |
udp |
liczba otrzymanych segmentów UDP |
SMI określa typy zmiennych (proste, struktury).
Przestrzeń nazw MIB - przestrzeń globalna zarządzana przez ISO i ITU, zapewnia globalną unikatowość.
Organizacja hierarchiczna:
root |
|||||||||
itu(0) |
iso(1) |
iso+itu(2) |
|||||||
|
org(3) |
|
|||||||
|
dod(6) |
|
|||||||
directory(1) |
internet(1) |
experimental(3) |
|||||||
|
mgmt(2) |
private(4) |
|||||||
|
mib(1) |
enterprise(1) |
|||||||
system(1) |
interfaces(2) |
ip(4) |
icmp(5) |
tcp(6) |
udp(7) |
311 (Microsoft) |
|||
|
|
|
|
|
|
||||
Każda nazwa rozpoczyna się od identyfikatora, np.:
iso.org.dod.internet.mgmt.mib.ip
równoważny identyfikator liczbowy: 1.3.6.1.2.1.4
Dla zmiennej ipInReceives:
iso.org.dod.internet.mgmt.mib.ip.ipInReceives
równoważny identyfikator liczbowy: 1.3.6.1.2.1.4.3
W komunikatach każda zmienna zakończona jest sufiksem. Dla zmiennych prostych (nie strukturalnych) sufiksem jest 0. Dla tablic sufiks może składać się z pewnych elementów pól przechowywanych w tablicach, np. może to być numer IP („doklejony” do identyfikatora).
Komunikaty SNMP
SNMP definiuje następujące komunikaty wymieniane między zarządzającym a agentem:
get-request pobierz wartość zmiennych (zmiennej).
get-next-request pobierz wartość następnej zmiennej (ułatwia przeglądanie tabllic).
set-request ustaw wartość zmiennej (zmiennych).
get-response odpowiedź wysyłana od agenta do stacji zarządzającej.
trap zawiadom stację zarządzającą o określonym zdarzeniu.
get-bulk-request (SNMP2) pobierz większą porcję danych.
inform-request (SNMP2) prześlij informacje z jednej stacji zarządzającej do drugiej.
Format komunikatów SNMP.
Komunikaty SNMP nie używają stałych pól określonej długości. Stosują specjalny język zapisu ASN.1. W zapisie tym są stosowane kody słów kluczowych. Przykład (RFC1157).
W Windows 2000 można zainstalować oprogramowanie realizujące SNMP (agentów) w Windows components, Management and monitoring tools. W W2K nie ma standardowych rozbudowanych programów zarządzających (dostarczane są przez innych producentów).
Jednak w Windows 2000 Server Resource Kit znajduje się program SNMPUTIL, który umozliwia kontakt z agentami i wykonanie operacji get, get-next.
snmputil command community object_id.
Sieci komputerowe wykład 9.
1
DHCPREQUEST
(minął czas przewiązywania - stand. 87,5% czasu wynajmu)
[ ] / DHCPREQUEST
(minął czas odnawiania - stand. 50% czasu wynajmu)
[ ] / DHCPRELEASE
(skasowanie wynajmowania)
DHCPNACK
LUB skończył się czas wynajmu
DHCPACK / [ ]
DHCPNACK / [ ]
DHCPACK / [ ]
DHCPACK / [ ]
[ ] / DHCPRQUEST
DHCPOFFER / [ ]
[ ] / DHCPDISCOVER
ODNÓW
PRZEWIĄŻ
POWIĄZANIE
PROŚBA
WYBIERZ
INICJUJ
Wyszukiwarka