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.
Hej, a może wspomnisz coś o Gratuitous ARP chyba że będziesz jeszcze rozwijał ten temat ?
Hej, temat ARP będę na pewno jeszcze rozwijał, natomiast postaram się na dniach coś dopisać do tego artykułu na temat gratuitous ARP 🙂 Dzięki
Artykuł uzupełniony o Gratuitous ARP 🙂
Good Job 😉
Bardzo dobre artykuły. Super strona.
Dzięki! Cieszymy się, że się podoba 🙂
Źródło skąd zostało przepisane informacje odnośnie GARP-a:
https://wiki.wireshark.org/Gratuitous_ARP
Przepisane? Serio? Link do źródła jest dobry, faktycznie z tej wiki zaczerpnąłęm informacje dotyczące działanie GARPa bo było to najlepsze podsumowanie jakie znalazłem. Całość przełożyłem na polski oraz zobrazowałem przykładem. Także z tym \”przepisywaniem\” to bym się mimo wszystko zastanowił. Gdyby tak podchodzić do tematu to nie pownniśmy w ogóle pisać o sieciach – wszystko już zostało kiedyś opisane, takimi czy innymi słowami.
Hej, pomyliles czas aging-time mac z ARP cache timeout. Dla arp wynosi z tego co pamietam 240 min.
Hej Leon, dziękuję za wyłapanie tego bardzo poważnego błędu i poinformowanie mnie o tym! Poprawiłem stosowny fragment w artykule.
Cześć 🙂
GARP nie jest wykorzystywany do wykrywania duplikatów adresów. Do tego są używane zapowiedzi i sondy ARP (probe i announcement ARP). Książkowy błąd powielany w szkołach i po forach.
Pozdrawiam!
Dziękujemy za feedback! Staramy się unikać błędów jak tylko się da, ale na szczęście gdzie Autor nie może tam Czytelnik pomoże 🙂
Co w przypadku jeżeli ustawie na routerze w ARP inny IP do adresu MAC a w serwerze DHCP przypisze do tego samego MACa inne IP? Mam router TP-LINK Archer C2 i mam tam mozliwość ustawienia stałego IP w DHCP i powiązania w ARP dla MAC/IP.
Hej Mariusz! Pozwolę sobie sparafrazować pytanie bo chciałbym się upewnić czy je dobrze zrozumiałem: mamy komputer o adresie MAC AA:AA (dla uproszczenia) i na serwerze DHCP dajemy mu statyczne przypisanie IP 192.168.0.1. Z kolei na routerze dajemy statyczny wpis w ARP, który wiąże MAC AA:AA z innym IP – 192.168.0.2. Tak to rozumiem.
W takiej sytuacji wg mnie nie będzie to miało wpływu na działanie w sytuacji kiedy inne hosty będą chciały spingować 192.168.0.1 – każdy host ma wszakże własną tablicę ARP (odpyta się sieci \”Who has 192.168.0.1?\” i AA:AA odpowie). Natomiast jeżeli byśmy chcieli spingować 192.168.0.1 z routera, to router również powinien wysłać ARP request i w tablicy ARP routera obok statycznego tłumaczenia 192.168.0.2 na AA:AA powinien się pojawić dynamiczny wpis asocjujący ze sobą IP 192.168.0.1 i MAC AA:AA. Generalnie wydaje mi się, że to zadziała, ale żeby potwierdzić musiałbym to przeładować.
Dlaczego komputery nie mogą się komunikować po adresie IP tylko potrzebują do wysłania pakietu adresu MAC? Przecież wysyłają ramkę do wszystkich hostów i ten właściwy się odzywa podając swój adres MAC. Czy nie wystarczyłaby odpowiedź, że został znaleziony bez podawania adresu MAC?
Cześć Darek. Bardzo celne pytanie. W zasadzie obylibyśmy się dziś bez adresacji w warstwie drugiej. Pamiętajmy, że jest to konstrukt z czasów gdy współdzielone segmenty sieci Ethernet były powszechne. Zachował się on do dziś tylko dlatego, że cały czas staramy się utrzymać kompatybilność wstecz 🙂
To nie do końca prawda jeśli w ogóle jakaś prawda. MAC ma głebsze znaczenie. Akceptacją ipków zajmuje się system operacyjny, mac leży nizej i pozwala ominąć ten problem. Czy np ICMP używa adresu IP? Pisanie że mac się uzywa tylko z powodów kompatybilości jest niezrozumieniem tematyki sieci.
tfu omawiany arp miał być nie icmp
Polemizowałbym. Mój argument odnosi się do tego, że gdyby dziś projektować działanie sieci od podstaw, to najprawdopodobniej doszlibyśmy do wniosku, że adresacja w warstwie drugiej jest zbędna. Nie twierdzę, że jest zbędna w obecnych realiach – L2 ma zbyt szerokie zastosowanie i jest \”wplątane\” w zbyt wiele mechanizmów działania sieci by się go pozbyć. Ale marzyć zawsze można 🙂 Wydaje mi się, że powyższe przemyślenia wynikają właśnie ze zrozumienia tematyki sieci 😉