arp(7) модуль ядра Linux для ARP

ОПИСАНИЕ

Этот модуль ядра реализует Address Resolution Protocol (протокол разрешения адресов), определённый в RFC 826. Протокол предназначен для преобразования аппаратных адресов второго уровня (Layer2) в адреса протокола IPv4 в соединённых напрямую сетях. Как правило, пользователю не приходится работать с этим модулем непосредственно, исключая случаи его настройки — модуль используется другими протоколами ядра.

Процесс пользователя может получать пакеты ARP через сокеты packet(7). Кроме того, существует механизм управления кэшем ARP из пространства пользователя с помощью сокетов netlink(7). Таблицей ARP также можно управлять с помощью ioctl (2) из произвольного сокета AF_INET.

Модуль ARP поддерживает кэш отображения аппаратных адресов в протокольные адреса. Размер кэша ограничен, поэтому старые и мало используемые записи удаляются. Записи, помеченные как постоянные, не удаляются никогда. Кэшем можно управлять непосредственно, с помощью ioctl-вызовов. Работа кэша может быть настроена с помощью интерфейсов /proc, описанных ниже.

Если в течение некоторого времени (см. /proc интерфейсы ниже) не подтверждается корректность (positive feedback) существующей записи кэша, то она считается устаревшей. Подтверждение может быть получено от более высокого уровня, например, при получении TCP ACK. Другие протоколы могут выполнить подтверждение, используя флаг MSG_CONFIRM при вызове sendmsg(2). Если подтверждения нет, то ARP пытается повторить запрос. Сначала он пытается запросить обновлённый MAC-адрес у локальной службы arp app_solicit раз. Если получить адрес не удалось, а старый MAC-адрес известен, то посылается адресный запрос ucast_solicit раз. Если и после этого адрес определить не удалось, то по сети посылается новый широковещательный ARP-запрос. Запросы посылаются только при наличии данных в очереди для отправки.

Linux автоматически добавляет динамическую запись proxy arp, когда система получает запрос адреса, для которого она производит пересылку и если proxy arp включён на принимающем интерфейсе. При наличии маршрута отказа (reject route) добавление proxy arp не производится.

Вызовы ioctl

Для всех сокетов AF_INET доступно три ioctl-вызова. В качестве параметра ожидается указатель на структуру struct arpreq.

struct arpreq {
    struct sockaddr arp_pa;      /* адрес протокола */
    struct sockaddr arp_ha;      /* аппаратный адрес */
    int             arp_flags;   /* флаги */
    struct sockaddr arp_netmask; /* сетевая маска адреса протокола */
    char            arp_dev[16];
};

Вызовы SIOCSARP, SIOCDARP и SIOCGARP соответственно устанавливают, удаляют и считывают отображение ARP. Для установки или удаления отображений ARP процесс должен иметь мандат CAP_NET_ADMIN или эффективный UID, равный 0.

Поле arp_pa должно быть сокетом AF_INET, а arp_ha должно иметь тот же тип, что и тип устройства, указанный в arp_dev. Поле arp_dev — строка с именем устройства, оканчивающаяся нулем.

arp_flags
флагзначение
ATF_COMПоиск окончен
ATF_PERMПостоянная запись
ATF_PUBLАнонсировать запись
ATF_USETRAILERSТребуются Trailers
ATF_NETMASKИспользовать маску сети
ATF_DONTPUBНе отвечать

Если установлен флаг ATF_NETMASK, то должно быть указано корректное значение arp_netmask. Linux 2.2 не поддерживает сетевые записи proxy ARP, поэтому для удаления существующих записей proxy arp это значение должно быть равно 0xffffffff или 0. Флаг ATF_USETRAILERS считается устаревшим и не должен использоваться.

Интерфейсы /proc

ARP поддерживает /proc интерфейсы для настройки общих параметров или параметров конкретного сетевого интерфейса. Настройка осуществляется путём чтения или записи файлов /proc/sys/net/ipv4/neigh/*/*. Для каждого сетевого интерфейса в системе существует соответствующий каталог в /proc/sys/net/ipv4/neigh/. Настройки в каталоге «default» используются для всех новых создаваемых устройств. Если не определено явно, то считается, что время указывается в секундах.
anycast_delay (начиная с Linux 2.2)
Максимальное значение задержки в тиках (jiffies) до ответа на сообщение об объявлении соседей (neighbor solicitation message) IPv6. Поддержка anycast пока не реализована. Значение по умолчанию — 1 секунда.
app_solicit (начиная с Linux 2.2)
Максимальное количество попыток послать запрос через сетевое соединение (netlink) ARP-службе в пользовательском пространстве до возврата к использованию многоадресных запросов (см. mcast_solicit). Значение по умолчанию — 0.
base_reachable_time (начиная с Linux 2.2)
Если адрес был найден, то значение записи в диапазоне времени между base_reachable_time/2 и 3*base_reachable_time/2 будет считаться не устаревшим. Запись будет считаться правильной более длительное время, если будет получено подтверждение от протоколов более высокого уровня. Значение по умолчанию — 30 секунд.
base_reachable_time_ms (начиная с Linux 2.6.12)
Тоже, что и base_reachable_time, но время задаётся в миллисекундах. Значение по умолчанию — 30000 миллисекунд.
delay_first_probe_time (начиная с Linux 2.2)
Задержка до первого запроса после того, как запись стала считаться устаревшей. Значение по умолчанию — 5 секунд.
gc_interval (начиная с Linux 2.2)
Частота очистки кэша от устаревших и некорректных записей. Значение по умолчанию — 30 секунд.
gc_stale_time (начиная с Linux 2.2)
Частота проверки наличия устаревших записей. Если запись считается устаревшей, то перед тем, как данные будут посланы, адрес снова проверяется. Значение по умолчанию — 60 секунд.
gc_thresh1 (начиная с Linux 2.2)
Минимальное количество записей, хранимых в кэше ARP. Если количество записей меньше этого значения, то очистка кэша производится не будет. Значение по умолчанию — 128.
gc_thresh2 (начиная с Linux 2.2)
Мягкое ограничение максимального количества записей в кэше ARP. Если это значение будет превышено более, чем на 5 секунд, то будет произведена очистка кэша. Значение по умолчанию — 512.
gc_thresh3 (начиная с Linux 2.2)
Жёсткое ограничение количества записей в кэше ARP. Если это значение будет превышено, то будет произведена очистка кэша. Значение по умолчанию — 1024.
locktime (начиная с Linux 2.2)
Минимальное время хранения записи в кэше в тиках. Предотвращает замусоривание кэша при наличии более одного возможного отображения (в общем случае, из-за неправильной настройки сети). Значение по умолчанию — 1 секунда.
mcast_solicit (начиная с Linux 2.2)
Максимальное количество попыток определить адрес с помощью многоадресной/широковещательной передачи. Если адрес не будет обнаружен, то он будет помечен как недоступный. Значение по умолчанию — 3.
proxy_delay (начиная с Linux 2.2)
Задержка до proxy_delay тиков между получением ARP-запроса на известный proxy ARP-адрес и ответом. Предназначена для предотвращения перегрузки сети. Значение по умолчанию — 0.8 секунды.
proxy_qlen (начиная с Linux 2.2)
Максимальное количество пакетов для адресов proxy ARP, которые могут быть отправлены в очередь . Значение по умолчанию — 64.
retrans_time (начиная с Linux 2.2)
Задержка перед повторением запроса в тиках. Значение по умолчанию — 1 секунда. Этот файл устарел, используйте retrans_time_ms.
retrans_time_ms (начиная с Linux 2.6.12)
Задержка перед повторением запроса в миллисекундах. Значение по умолчанию — 1000 миллисекунд.
ucast_solicit (начиная с Linux 2.2)
Максимальное количество попыток послать адресный запрос перед запросом службы ARP (см. app_solicit). Значение по умолчанию — 3.
unres_qlen (начиная с Linux 2.2)
Максимальное количество пакетов, которые могут быть поставлены в очередь протоколами других сетевых уровней для передачи по каждому неопределённому адресу. Значение по умолчанию — 3.

ВЕРСИИ

В Linux 2.0 в структуру struct arpreq было включено поле arp_dev и изменены номера ioctl. Старые ioctl были удалены в Linux 2.2.

Поддержка записей proxy arp для сетей (маска сети не равна 0xffffffff) удалена в Linux 2.2. Вместо этого было реализовано автоматическое определение ядром всех доступных узлов через другие интерфейсы (если на интерфейсе включена пересылка и proxy arp).

Интерфейсы neigh/* не существовали до версии Linux 2.2.

ДЕФЕКТЫ

Значения некоторых настроек указаны в тиках, длительность которых зависит от архитектуры компьютера и версии ядра; смотрите time(7).

Не существует способа отправить подтверждение из пользовательского пространства. Это означает, что протоколы, ориентированные на соединения и реализованные в пользовательском пространстве, будут создавать избыточный ARP-трафик, так как ndisc будет вновь и вновь запрашивать MAC-адрес. То же относится и к некоторым протоколам ядра (например, NFS через UDP).

В этой странице дано описание возможностей IPv4, а также общих возможностей IPv4 и IPv6.