Sieci komputerowe to w dużym uproszczeniu nic innego jak zbiór współgrających ze sobą protokołów. To właśnie interakcje między nimi pozwalają nam na przeprowadzenie skutecznej komunikacji w obu kierunkach. We wczesnych fazach nauki sieci poznajemy zazwyczaj modele sieciowe OSI oraz TCP/IP i dowiadujemy się, że najpowszechniejszym protokołem warstwy drugiej stosu sieciowego jest Ethernet. Ethernet z kolei opiera swoje działanie w bardzo dużym stopniu na ARP, któremu dziś przyjrzymy się nieco bliżej.
ARP, czyli Address Resolution Protocol to jeden z kluczowych protokołów umożliwiających nam komunikację w sieciach rozgłoszeniowych, których to koronnym przedstawicielem jest Ethernet. Technologia ta mocno wyewoluowała od momentu powstania w 1976 roku lecz podstawowe zasady nadal pozostają te same. Zaczęliśmy od łączenia naszych urządzeń kablami koncentrycznymi, zastępując je następnie hubami aż doszliśmy do stanu obecnego, w którym główny punkt przyłączeniowy do sieci stanowią przełączniki (switche). We wszystkich tych scenariuszach używany jest protokół ARP. Ba! Stosowany on jest nawet wtedy gdy połączymy dwa komputery kablem bezpośrednio ze sobą. Spójrzmy na przykład:
Upraszczamy nasz scenariusz jak tylko się da. Nie mamy tutaj do czynienia z serwerem DHCP, a adresy IP ustawione są statycznie. W obu przypadkach jako adres bramy domyślnej wpisano 192.168.1.10, ale jest to w tym przykładzie nieistotne ponieważ oba te urządzenia znajdują się w tej samej podsieci. Komunikacja za pośrednictwem bramy domyślnej nie będzie zatem wymagana. Ponadto adresy MAC zostały uproszczone w sposób, który pozwoli nam swobodniej analizować przykładowy scenariusz.
Gdy komputery zechcą się ze sobą skomunikować to wiemy, że zostanie utworzony pakiet IP zawierający adres źródłowy Klienta 1 oraz adres docelowy Klienta 2 (zawsze wychodzimy z założenia, że adres warstwy 3 – IP – jest znany). Pakiet IP następnie zostanie zenkapsulowany w ramkę Ethernet w celu dostarczenia jej za pośrednictwem segmentu sieci w warstwie drugiej. Stworzona ramka będzie zawierała adres źródłowy Klienta 1 oraz adres docelowy Klienta 2.
I tutaj pojawia się pytanie – skąd Klient 1 wie jaki jest docelowy adres MAC Klienta 2? W tym momencie z odpowiedzią przychodzi właśnie protokół ARP. Spójrzmy na przykład, w którym Klient 1 chce spingować Klienta 2:
Wiadomośc ICMP Echo (niebieska) jest w takiej sytuacji enkapsulowana w pakiet IP (zielony) – oba adresy (źródłowy i docelowy) są znane. Pakiet IP jest z kolei enkapsulowany w ramkę Ethernet (żółty) gdzie Klient 1 zna jedynie swój własny źródłowy adres MAC. Spróbujmy spingować Klienta 2:
I widzimy, że ping działa! Ale jak? W jaki sposób Klient 1 poznał adres MAC Klienta 2?
W tle zadziałał ARP. Przyjrzyjmy się jego działaniu.
Każde urządzenie sieciowe (router, switch, komputer, drukarka, telefon…) posiada w pamięci strukturę nazywaną tabelą ARP. Tabela ta jest bardzo prosta i zawiera mapowania adresów IP na odpowiadające im adresy MAC. Większość wpisów w tej tabeli będzie się pojawiała dynamicznie w procesie, który omówimy sobie już za chwilę. Mamy natomiast również możliwość umieszczania wpisów w tej tabeli ręcznie – będą to wtedy wpisy statyczne.
Na dowolnym hoście z systemem Windows możemy wyświetlić tablicę ARP za pomocą komendy arp -a:
Na przełącznikach i routerach Cisco działających na systemie IOS odpowiednikiem tej komendy będzie zazwyczaj show ip arp:
Wróćmy do naszego przykładu. W momencie, w którym chcemy spingować Klienta 2, Klient 1 sprawdza zawartość swojej tabeli ARP. Jeżeli jest to pierwsza od dłuższego czasu próba komunikacji między tymi hostami to tabela ta nie będzie zawierała odpowiedniego wpisu, który powiedziałby nam jaki jest adres MAC Klienta 2:
W takiej sytuacji Klient 1 wysyła w sieć ramkę ARP Request na adres docelowy MAC FF:FF:FF:FF:FF:FF. Widzimy zatem, że jest to ramka rozgłoszeniowa (broadcast). Ramka ta trafi więc do wszystkich hostów w domenie rozgłoszeniowej (jeżeli mamy sieć zbudowaną w oparciu o przełączniki to ramka ta rozpropaguje się po całej sieci LAN). Od tego momentu zacznę przedstawiać adresy MAC w formie skróconej żeby się nam wszystko ładnie zmieściło na obrazkach. ARP Request w naszym przykładzie będzie wyglądał następująco:
Komunikat ARP Request (czerwony) zawiera w sobie informację o tym dla jakiego adresu IP (Target IP) poszukujemy odpowiadającego adresu MAC. Zauważ proszę, że pole Target MAC jest wypełnione na tym etapie samymi zerami.
Tak sformatowany ARP Request trafia do wszystkich hostów w danej domenie rozgłoszeniowej. W naszym przykładzie sprawa jest prosta, albowiem odbiorca może być tylko jeden. Każdy host, który otrzyma ARP Request zagląda w jego zawartość i sprawdza czy Target IP jest jego własnym adresem IP. Jeżeli są one identyczne to host ten zwróci odpowiedź – ARP Reply. Klient 2 otrzymując ARP Request zauważy w polu Target IP swój własny adres IP więc wygeneruje ARP Reply, wyglądający następująco:
Widzimy powyżej, że wygenerowana zostaje ramka od Klienta 2 do Klienta 1 (kolor żółty). Ramka ta zawiera komunikat ARP Reply (kolor czerwony), w którym mamy uzupełnioną informację o adresie MAC Klienta 2. Powoduje to, że gdy Klient 1 otrzymuje ARP Reply to dodaje on stosowne mapowanie do swojej tablicy ARP:
Dzięki protokołowi ARP Klient 1 posiada teraz kompletną informację potrzebną do wysłania pakietu ICMP Echo i spingowania Klienta 2:
Zauważ proszę, że Klient 2 będzie w stanie z powodzeniem natychmiast wysłać odpowiedź na pinga (ICMP Reply) ponieważ najprawdopodobniej będzie już posiadał w swojej tablicy ARP mapowanie IP na adres MAC dla Klienta 1. Jakim cudem? Dowiedział się tego mapowania w momencie gdy otrzymał omawiany w tym artykule ARP Request od Klienta 1 😉 Ponadto wszystkie potrzebne informacje do udzielenia odpowiedzi zwrotnej na pinga znajdują się również w otrzymanym ICMP Echo. Jak widzisz, urządzenia sieciowe non stop analizują to co otrzymują i wyłuskują potrzebne im informacje, w dynamiczny sposób wypełaniając m.in. tabelę ARP.
Na koniec ważna informacja: wpisy w tabeli ARP wygasają po czasie, który określamy jako cache timeout. Wartość ta może się różnić w zależności od urządzenia więc warto ją sprawdzić, ale generalnie w przypadku systemu IOS jest to 240 minut. Urządzenie sieciowe odlicza zatem czas dla każdego wpisu od 0 do 240 minut, a w przypadku pojawienia się na porcie jakiegoś ARP requestu licznik dla odpowiadającego mu wpisu się zeruje (źródło).
W tym miejscu bardzo istotna przestroga – nie mylmy wygasania wpisów w tablicy adresów MAC (aging-time – na większości urządzeń domyślnie 300 sekund) z wygasaniem wpisów w tablicy ARP (cache timeout). Dlaczego o tym piszę? Ano dlatego, że sam popełniłem te faux pas w tym artykule, na co zwrócił uwagę w komentarzach Leon (dziękuję!).
Gratuitous ARP (GARP)
ARP może być przydatny nie tylko w procesie opisanym wcześniej w tym artykule i ma też inne zastosowania. ARP w takich przypadkach określamy jako „gratuitous” (wymowa) czyli „nieuzasadniony”. Nazwa może być trochę myląca bo gdy już poznasz zastosowania GARPa to zauważysz, że są one jak najbardziej uzasadnione. Do mnie osobiście dużo bardziej trafia tłumaczenie słowa „gratuitous” jako „dobrowolny”.
Ale co z tym GARPem? W ramce GARP mamy do czynienia z sytuacją, w której adres IP źródłowy i docelowy są identyczne i odpowiadają adresowi IP hosta wysyłającego ramkę. Ponadto adres docelowy MAC jest ustawiony jako broadcast (FF:FF:FF:FF:FF:FF):
Na tak wysłaną ramkę urządzenie źródłowe nie otrzyma zatem żadnej odpowiedzi… ale inne urządzenia ją zauważą i będą mogły wykorzystać zawarte w niej informacje! I właśnie w tym szczególe tkwi przydatność Gratuitous ARP. Zastosowania takiego mechanizmu mogą być (co najmniej) cztery:
- wykrywanie konfliktów IP – jeżeli host otrzyma ramkę GARP zawierającą adres źródłowy IP identyczny z własnym to będzie wiedział, że ma do czynienia ze zduplikowanym IP w sieci,
- aktualizowanie tabeli ARP urządzeń w sieci, co ma największe zastosowanie w przypadku różnego rodzaju klastrów. Przykładem niech tu będzie sytuacja, w której mamy klaster dwóch serwerów. Jeden jest aktywny, a drugi działa jako backup (jest zsynchronizowanym duplikatem). Aktywny serwer ma IP 192.168.1.254 oraz adres MAC CC:CC. Z kolei serwer backupowy ma adres MAC DD:DD i sprawdza za pomocą dowolnego mechanizmu keepalive (np. pingiem) czy aktywny serwer „żyje”. Gdy aktywny serwer padnie, to serwer backupowy przejmie adres IP 192.168.1.254 i wyśle GARP zawierający IP 192.168.1.254 oraz adres MAC DD:DD. W ten sposób pozostałe urządzenia w sieci zostaną poinformowane o zmianie która nastąpiła,
- proaktywne informowanie przełącznika o tym na jakim porcie się znajduje dany host,
- stwierdzanie problemów sprzętowych po stronie hosta – za każdym razem gdy host „podnosi” interfejs na karcie sieciowej to wysyła GARP aby poinformować inne urządzenia w sieci o swojej obecności. Jeżeli widzimy, że dany host bardzo często wysyła gratuitous ARP to może to oznaczać problemy z okablowaniem bądź kartą sieciową hosta, która z jakichś przyczyn ulega resetowaniu.
