ARP

ARP (Address Resolution Protocol) умеет преобразовывать абсолютно любые адреса в любые канальные адреса. Не обязательно это должны быть протокол IP и протокол Ethernet — адреса, которые преобразуются, могут быть любыми. ARP умеет преобразовывать IP-адреса в Ethernet, но также может работать с любым другим протоколом сетевого уровня и любым другим протоколом канального уровня.

Для того чтобы ARP работал, необходимо, чтобы протокол канального уровня поддерживал широковещательную рассылку (broadcast). То есть чтобы вы могли отправить кадр на канальном уровне, и этот кадр дошёл бы до всех получателей, а получатели могли бы отправить вам ответ.

Собственно говоря, ARP примерно так и делает: он рассылает на всю сеть сообщение — «у кого из вас такой IP, скажите свой MAC». И тот, у кого такой IP, возвращает свой MAC-адрес.

Если посмотреть на формат заголовка, в этом пакете будут поля для совершенно произвольного размера канального адреса и совершенно произвольного размера сетевого адреса. Вы не привязаны к 48 битам канального адреса и не привязаны к 32 битам IP-адреса. ARP умеет работать с адресами любого размера и преобразовывать их между собой.

Принцип работы ARP

Проблема, которую ARP решает, — это упаковка IP-пакета в кадр канального уровня (Ethernet-кадр). Если вы соорудили IP-пакет и хотите отправить его, например, с адреса 10.0.0.1 на адрес 10.0.0.2, вам нужно упаковать этот IP-пакет в Ethernet-кадр. Свой MAC-адрес вы, конечно, можете проставить, а вот MAC-адрес получателя нужно каким-то образом узнать. ARP как раз эту функцию и выполняет.

Принцип работы ARP очень простой:

1. Если вы не знаете, кому на канальном уровне отправить данные, но знаете IP-адрес этого узла, вы отправляете специальный служебный пакет в широковещательном кадре Ethernet с вопросом: «У кого такой IP, скажите свой MAC?»
2. Все узлы его слышат. Все берут и смотрят, про кого спрашивают.
3. Тот, кто видит свой IP в запросе, отвечает: «Это про меня» — и отправляет в ответ свой IP-адрес и свой MAC-адрес.
4. Отправитель получает ответ и теперь знает нужный MAC-адрес.

Буферизация пакетов во время ARP-запроса

Пока вы отправляете ARP-запрос, IP-пакет, который вы хотели отправить, лежит в буфере и ждёт своей очереди.

• TCP: Если вы пытаетесь отправить первый TCP-сегмент в сессии (установить соединение), то до тех пор, пока не получите ARP-ответ, вы можете спокойно ждать. Вы даже не будете повторно отправлять другие пакеты на тот же адрес.
• UDP: Ситуация может быть иной. Приложение может засыпать вас UDP-данными, и вам надо их отправить, но вы не знаете куда. Первый пакет ложится в буфер, второй, третий... а потом буфер забивается, и часть данных UDP может быть потеряна.

Но другого механизма разрешения канальных адресов из IP-адреса в Ethernet (IPv4) у нас нет. Рано или поздно IP-адрес удастся разрешить в MAC.

Требование к канальной среде

ARP может по определению работать только в тех средах, где работают broadcast-рассылки. Если в канальной среде broadcast есть — ARP отработает. Если broadcast нет (например, Frame Relay или DMVPN), то ARP бесполезен — он не сможет доставить один кадр до всех получателей.

Кэш ARP

Естественно, нельзя каждый раз на каждый пакет отправлять дополнительный ARP-запрос. IP-адреса и MAC-адреса меняются не так часто, поэтому можно в течение некоторого времени запоминать ответы. Разумно хранить их в промежуточной таблице — кэше ARP.

Хранить данные пожизненно нельзя: IP-адрес может смениться, MAC-адрес может поменяться. Но в течение разумного времени хранить можно.

Пополнение кэша

Пополнять кэш можно при получении любого ARP-пакета. Запрос и ответ выглядят примерно одинаково — различаются лишь небольшим количеством бит, формат у них одинаковый. Каждый раз, когда вы получаете любой ARP-пакет, в нём в явном виде фигурируют IP-адрес и MAC-адрес отправителя, и вы можете занести их в кэш.

• Когда вы отправляете broadcast-запрос, вы заодно «палите» свой MAC. Все узлы сразу заносят ваш IP и MAC в свой кэш.
• Когда отвечающий вам сообщает свой IP и MAC, вы тоже заносите это в кэш.
• Остальные узлы, возможно, и не услышат ответ (unicast), но вопрос (broadcast) услышат точно все.

Типы записей в кэше

• Динамическая — IP-адрес был успешно разрешён в MAC-адрес через ARP.
• Статическая — запись внесена вручную: «вот такой IP, не надо даже пытаться отправлять ARP, его MAC вот такой». Экономит время.
• Invalid (недействительная) — вы отправили ARP-запрос, но ответ ещё не получили. Нужна для того, чтобы не орать повторно на всю сеть, пока ответ ещё не пришёл. Как только ответ приходит, запись становится динамической.

Время жизни записей

Записи хранятся в кэше не вечно — у каждой есть срок жизни. Этот срок никак не регламентирован стандартом и зависит от ОС и настроек:

Платформа	Время жизни по умолчанию
Cisco	4 часа
Windows	Несколько минут

Можно настроить время самостоятельно:

• Если адреса меняются часто — занижайте время жизни кэша ARP.
• Если адреса меняются редко — увеличивайте, тогда ARP-запросов в сети будет меньше.

Почему broadcast — это плохо

Поскольку ARP использует broadcast, есть смысл минимизировать их количество. Broadcast — это всегда неэффективное использование сети: все узлы напрягаются, считают контрольные суммы, проверяют «а вдруг это мне». А на самом деле большая часть broadcast почти никому не нужна.

Когда вы отправляете broadcast, вы хотите доставить его до одного-двух участников, но просто не знаете, кому именно. А природа broadcast такова, что все начинают напрягаться. Минимизация broadcast позитивно влияет на всю сеть.

Формат пакета ARP

Если мы говорим про IP в привязке к Ethernet (подавляющее большинство случаев), формат будет следующий. Пакет выровнен по границе 32 бит (машинного слова):

Поле	Размер	Описание	Значение для Ethernet + IPv4
Hardware Type (H Type)	2 байта	Тип канальной среды	0x0001 (Ethernet)
Protocol Type (P Type)	2 байта	Тип сетевого адреса	0x0800 (IPv4)
HLen (Hardware Length)	1 байт	Длина аппаратного адреса в байтах	6 (MAC = 48 бит)
PLen (Protocol Length)	1 байт	Длина сетевого адреса в байтах	4 (IPv4 = 32 бита)
Operation	2 байта	Код операции	1 — запрос, 2 — ответ
Sender Hardware Address (SHA)	6 байт	MAC-адрес отправителя	—
Sender Protocol Address (SPA)	4 байта	IP-адрес отправителя	—
Target Hardware Address (THA)	6 байт	MAC-адрес получателя	000000 в запросе
Target Protocol Address (TPA)	4 байта	IP-адрес получателя	—

Заполнение полей при запросе

Когда вы задаёте вопрос «у кого такой IP, скажите свой MAC»:

• SHA — ваш MAC-адрес
• SPA — ваш IP-адрес
• TPA — IP-адрес, который спрашиваете
• THA — заполняется нулями
• Operation — 1 (запрос)

Заполнение полей при ответе

Когда вы отвечаете:

• SHA — ваш MAC-адрес
• SPA — ваш IP-адрес
• THA — MAC-адрес того, кто спрашивал
• TPA — IP-адрес того, кто спрашивал
• Operation — 2 (ответ)

MAC-адрес отправителя фигурирует дважды: один раз в заголовке Ethernet, другой — в заголовке ARP.

Broadcast vs Unicast в ARP

По стандарту:

• Запрос ARP всегда идёт broadcast.
• Ответ ARP должен идти unicast — только тому, кто спрашивал. Это логично: незачем напрягать лишние узлы.

Однако некоторые операционные системы нарушают это правило и ответ тоже отсылают broadcast. Логика такая: если мой IP и MAC кому-то были интересны, возможно, это будет интересно не только спрашивающему. Тогда все узлы обновят свой кэш ARP, и в будущем количество ARP-запросов уменьшится.

Кроме того, существуют расширения к протоколу ARP, при которых запрос может идти unicast, а ответ — broadcast. Жёсткой привязки нет. Но базовое правило: если вы спрашиваете — broadcast, если отвечаете — по-хорошему unicast.

Proxy ARP

Если между отправителем и получателем есть промежуточные маршрутизаторы, обычный ARP не отработает — он работает только в пределах одной широковещательной среды.

Проблема классовой адресации

Рассмотрим ситуацию. Есть узел 10.0.1.1 и узел 10.0.2.2 — они находятся в разных канальных средах.

• Узел 10.0.2.2 поддерживает бесклассовую адресацию и понимает, что живёт в сети с маской /24.
• Узел 10.0.1.1 поддерживает только классовую адресацию. Он видит IP из сети 10.0.0.0 класса A и считает, что маска /8. Значит, 10.0.2.2 должен быть в одной канальной среде с ним.

Узел 10.0.1.1 кричит на всю сеть: «У кого IP 10.0.2.2, скажите свой MAC!» Но 10.0.2.2 находится в другом широковещательном домене и не может это услышать.

Как работает Proxy ARP

Proxy ARP — это когда вместо оригинального получателя отвечает посредник (маршрутизатор).

Маршрутизатор с IP 10.0.1.2/24 получает broadcast-кадр с ARP-запросом «у кого IP 10.0.2.2?». Он понимает, что в сети 10.0.1.0/24 такой вопрос может задать только тот, кто не поддерживает бесклассовую адресацию. И отвечает своим собственным MAC: «Шли всё, что хочешь отправить на 10.0.2.2, на мой MAC».

Узел 10.0.1.1 получает ответ и начинает слать кадры на MAC-адрес маршрутизатора. Маршрутизатор принимает такие кадры, раскрывает их, видит внутри IP-пакет, который ему не адресован, и просто маршрутизирует его дальше — как обычно.

Недостатки Proxy ARP

На каждый IP-адрес, который узел воспринимает как принадлежащий своей сети, создаётся отдельная строчка в кэше ARP. Хотите отправить данные на 10.0.2.2 — получили MAC роутера. На 10.0.3.3 — снова MAC роутера. На каждый IP — одна и та же запись, но всё равно отдельная строка.

Это особенно плохо в случае со статическим маршрутом, где указан только выходной интерфейс без IP следующего шлюза. Тогда на каждый IP-пакет с уникальным адресом назначения роутер будет делать ARP-запрос. Если роутер провайдера поддерживает Proxy ARP, он ответит на все — и кэш ARP разрастётся до огромных размеров.

Представьте: 10 пользователей, каждый запустил торрент и рассылает пакеты на пару тысяч IP-адресов. Получаем 20 000 записей в кэше ARP. На маленьком роутере (Cisco 800) с 256 МБ ОЗУ это может привести к kernel panic из-за нехватки памяти.

Когда Proxy ARP допустим

Proxy ARP — это костыль для определённых ситуаций:

• Вы сознательно разделили IP-сеть на несколько канальных сред.
• У вас VPN-сервер, и вы хотите, чтобы VPN-клиенты получали адреса из той же подсети, что и физическая сеть.
• Физические узлы пытаются найти VPN-клиента через ARP, но в туннельной среде ARP не работает — маршрутизатор отвечает вместо клиента.

Если есть возможность не использовать Proxy ARP — не используйте. Всегда старайтесь делать правильно: один VLAN — одна IP-сеть, VPN-пользователи в отдельной подсети, шлюз по умолчанию (default gateway) настроен явно.

Обнаружение конфликтов адресов

ARP Probe (Address Conflict Detection, RFC 5227)

Если вы назначаете IP-адрес на интерфейс, перед его активацией можно запустить проверку — не занят ли адрес.

Вы отправляете специальный ARP-запрос (ARP Probe):

• Sender Protocol Address — 0.0.0.0 (вы ещё не владеете этим адресом)
• Target Protocol Address — проверяемый IP-адрес
• Operation — 1 (запрос)

Если кто-то ответит своим MAC — значит, адрес уже занят. Вы получите оповещение о конфликте и можете отказаться поднимать этот адрес. При этом у другого узла конфликта не будет, потому что вы адрес так и не заняли.

Gratuitous ARP (ARP Announcement)

После того как вы заняли IP-адрес, нужно дать всем остальным знать об этом. Для этого используется Gratuitous ARP — «безвозмездный ARP». Есть два варианта:

Вариант 1 — запрос (Operation = 1):

• SPA и TPA — ваш собственный IP-адрес
• SHA — ваш MAC-адрес
• THA — 000000
• Отправляется broadcast

По сути, вы спрашиваете сами себя: «У кого мой IP?» Если кто-то ответит — обнаружен конфликт. Если нет — все узлы обновят свой кэш.

Вариант 2 — ответ (Operation = 2):

• SPA и TPA — ваш IP-адрес
• SHA и THA — ваш MAC-адрес
• Отправляется broadcast

Вы ничего не спрашиваете, а просто декларируете: «Это мой IP, вот мой MAC. Получите, распишитесь».

Оба варианта делают примерно одно и то же — обновляют кэш ARP на всех узлах сети. Какой именно режим используется — зависит от операционной системы. Можно совмещать оба: сначала ARP Probe (проверка), потом Gratuitous ARP (объявление).

Родственные протоколы

Reverse ARP (RARP)

RARP — предшественник DHCP (и даже предшественника DHCP — протокола BootP). Делает обратное тому, что делает ARP: кричит на всю сеть «У кого такой MAC, скажите свой IP!»

Сценарий использования: узел знает только свой MAC-адрес и хочет узнать, какой IP ему назначен. Сервер с базой MAC-IP-соответствий отвечает нужным IP-адресом. В реальном мире RARP уже не встречается — он был заменён BootP, а тот развился в DHCP.

Inverse ARP (InARP)

InARP работает в средах без broadcast (например, Frame Relay). В отличие от обычного ARP, который реагирует «по запросу», InARP отрабатывает сразу при инициализации соединения.

Когда интерфейс включается и вы опознаёте доступные DLCI (канальные адреса), вы сразу рассылаете во все них сообщение: «Мой IP вот такой». Все узлы узнают, какой IP живёт за каким канальным адресом, и когда им потребуется отправить данные, они уже будут знать адрес.

Не путайте Reverse ARP и Inverse ARP:

• RARP — из MAC-адреса получить IP-адрес (предшественник DHCP).
• InARP — отправить свой IP во все известные канальные адреса при инициализации (используется в Frame Relay).

SLARP (Serial Line ARP)

SLARP — протокол, не использующий формат пакета ARP, несмотря на название. Это подпротокол цисковской реализации HDLC (не путать со стандартным HDLC — они не похожи). Решает задачу управления базой соседей в serial-соединениях: помогает узнать и назначить IP-адрес соседу. Работает только с IP-адресами, канальные адреса в Serial Link не нужны.

NDP (Neighbor Discovery Protocol)

NDP — это аналог ARP, но для IPv6. Более эффективен: вместо broadcast использует multicast на группу узлов, у которых последние 3 байта IP-адреса совпадают с искомым. С большой вероятностью такое сообщение дойдёт только до одного узла — того, у которого действительно нужный IP. В худшем случае 2-3 узла получат запрос — всё равно лучше, чем broadcast на всех.

Демонстрация на оборудовании Cisco

Для демонстрации используются два устройства на базе Cisco IOS: роутер и L3-коммутатор, связанные по IP.

Просмотр кэша ARP

Router# show ip arp

В кэше видны две записи:

• 10.0.0.4 — наш собственный адрес (знаем свой MAC, не нужно орать на сеть)
• 10.0.0.1 — адрес соседа, возраст записи 119 минут (из 240 максимальных по умолчанию)

Добавление статической записи

Router(config)# arp 10.0.0.5 dead.bif0.0005 arpa

После этого в show ip arp появляется запись без указания возраста (статическая) и без привязки к интерфейсу.

Очистка кэша и наблюдение ARP в Wireshark

После команды clear arp и перезапуска интерфейса в Wireshark видны следующие события:

1. Gratuitous ARP — устройство объявляет свой новый IP (10.0.0.6) и MAC, Operation = 2 (ответ), Target MAC = FF:FF:FF:FF:FF:FF.
2. ARP Request — при попытке пинга 10.0.0.1: запрос с нашим MAC и IP (10.0.0.6), Target IP = 10.0.0.1, Target MAC = 00:00:00:00:00:00, Operation = 1.
3. ARP Reply — узел 10.0.0.1 отвечает своим MAC-адресом, Operation = 2.
4. ICMP — после получения ARP-ответа начинаются пинги (request code 8, reply code 0).

Первый ICMP-пакет теряется, пока ARP не успел отработать — это видно по «точке» вместо ответа.

ARP Probe при назначении адреса

При переназначении IP-адреса на интерфейсе отправляется ARP-запрос, где Sender IP = 0.0.0.0, а Target IP — тот адрес, который проверяется. Это механизм Address Conflict Detection.

Итоги

ARP — полезный и несложный служебный протокол, без которого работа IP поверх Ethernet была бы невозможна. Без него пришлось бы прописывать все MAC-адреса статически на каждом узле.

Основные моменты:

• ARP разрешает IP-адреса в MAC-адреса через broadcast-запросы
• Результаты кэшируются на ограниченное время
• Proxy ARP — костыль для случаев, когда одна IP-сеть разнесена по разным канальным средам
• Gratuitous ARP — механизм объявления своего адреса и обнаружения конфликтов
• ARP Probe — проверка, не занят ли адрес, перед его назначением
• В IPv6 роль ARP выполняет более эффективный NDP

ARP — не единственный служебный протокол. Для работы IP в Ethernet также нужны DHCP, ICMP и другие.