ARP-трафик: причины, нормы и диагностика

ARP (Address Resolution Protocol) используется в IPv4-сетях для определения MAC-адреса устройства по его IP-адресу. Когда серверу необходимо обратиться к устройству в локальной сети, он отправляет ARP-запрос, после чего получает ответ с MAC-адресом.
Наличие ARP-трафика на сетевом интерфейсе является нормальным явлением. Небольшое количество ARP-запросов регулярно возникает при работе сервера, обновлении ARP-кэша, взаимодействии с шлюзом и другими устройствами сети.
Повышенное количество ARP-пакетов может быть связано с большим количеством устройств в одном L2-сегменте, виртуализацией, сетевым сканированием, ошибками конфигурации или сетевыми петлями.

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

Когда серверу необходимо отправить пакет другому устройству в локальной сети, он должен знать MAC-адрес получателя.
Например, сервер хочет обратиться к адресу:
192.168.1.10
Но MAC-адрес этого устройства ему неизвестен. Тогда сервер отправляет ARP-запрос:
Who has 192.168.1.1?
Who has 192.168.1.2?
Who has 192.168.1.3?
...
Tell 192.168.1.5
Устройство с адресом 192.168.1.10 отвечает:
192.168.1.10 is at AA:BB:CC:DD:EE:FF
Полученный MAC-адрес сохраняется в ARP-кэше, поэтому повторно выполнять запрос для каждого пакета обычно не требуется.

Почему на интерфейсе появляется ARP-трафик

Наличие ARP-трафика может появляться по нескольким причинам:

• обращение сервера к новым IP-адресам в локальном сегменте;
• истечение времени жизни записей ARP-кэша;
• большое количество устройств в одном L2-сегменте;
• работа виртуальных машин и контейнеров;
• сетевые проверки и мониторинг;
• изменение MAC-адреса устройства;
• перезапуск сетевого интерфейса;
• изменение сетевой конфигурации;
• работа DHCP;
• проблемы с ARP-кэшем или сетевой инфраструктурой.

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

Как посмотреть ARP-трафик

Для просмотра ARP-пакетов можно использовать tcpdump.
Например:
tcpdump -ni eth0 arpЕсли интерфейс называется ens18:
tcpdump -ni ens18 arp


Для более подробного вывода:
tcpdump -ni ens18 -vv arp

Проверка ARP-кэша

Текущие ARP-записи можно посмотреть командой:
ip neigh


Основные состояния:

• REACHABLE — устройство недавно было доступно;
• STALE — запись существует, но давно не подтверждалась;
• DELAY — ожидается подтверждение доступности;
• PROBE — выполняется проверка устройства;
• FAILED — устройство не удалось обнаружить.

Когда большое количество ARP может быть проблемой

Небольшой объём ARP-трафика обычно не оказывает заметного влияния на производительность сервера.
Проблема может возникнуть, если наблюдается аномально большое количество ARP-запросов, например тысячи или десятки тысяч пакетов в секунду.

Возможные причины:
1. Большой L2-сегмент
В одном broadcast domain находится большое количество устройств.
2.  ARP scan
Какое-либо устройство сканирует диапазон IP-адресов:
Who has 192.168.1.1?
Who has 192.168.1.2?
Who has 192.168.1.3?
...
3.    Сетевая петля
Ошибки в L2-конфигурации могут приводить к существенному увеличению broadcast-трафика.
4.    Проблемы с виртуализацией
Большое количество VPS/VM на одном bridge или vSwitch может создавать значительный ARP/broadcast-трафик.
5.    Проблемы с ARP-кэшем
Если записи постоянно удаляются или не сохраняются, устройства могут чаще выполнять ARP-запросы.
6.    Неверная сетевая конфигурация
Например, ошибки с VLAN, bridge, gateway или маской сети.

ARP и нагрузка на CPU

Сам по себе ARP-трафик обычно не является причиной высокой загрузки процессора.
Однако при очень большом количестве ARP-пакетов их обработка может создавать дополнительную нагрузку на:

• сетевой стек Linux;
• CPU;
• виртуальный switch;
• bridge;
• firewall;
• conntrack;
• гипервизор.

Поэтому при наблюдении высокой нагрузки важно не просто смотреть на наличие ARP, а определить реальную интенсивность трафика.
Например, несколько десятков ARP-пакетов в секунду обычно не представляют проблемы. Совсем другая ситуация — тысячи или десятки тысяч ARP-запросов в секунду.

Как определить источник ARP-трафика

Для диагностики удобно использовать:
tcpdump -ni eth0 arpЕсли необходимо увидеть только ARP-запросы:
tcpdump -ni eth0 'arp[6:2] = 1'Для ARP-ответов:
tcpdump -ni eth0 'arp[6:2] = 2'Можно также сохранить трафик для последующего анализа в Wireshark:
tcpdump -ni eth0 -w arp.pcap arpПосле запуска выполнения команды tcpdump будет запущен и будет записывает весь ARP-трафик с интерфейса eth0 в файл arp.pcap. Оставьте его работать, например, 60 секунд, затем нажмите:  Ctrl+C
После этого появится статистика вида:



После этого файл arp.pcap можно открыть в Wireshark и определить:

• кто отправляет ARP-запросы;
• какие IP-адреса запрашиваются;
• какие MAC-адреса отвечают;
• насколько часто отправляются запросы;
• присутствует ли необычная активность.

Заключение

ARP-трафик является нормальной частью работы IPv4-сети. Наличие ARP-пакетов на сетевом интерфейсе само по себе не свидетельствует о неисправности. 
При диагностике необходимо оценивать:

• количество ARP-пакетов в секунду;
• соотношение запросов и ответов;
• IP-адреса, которые запрашиваются;
• MAC-адреса отправителей;
• состояние ARP-кэша;
• наличие VLAN/bridge/vSwitch;
• количество виртуальных машин в сегменте;
• наличие сетевых сканирований или L2-петель.

Главный критерий — не сам факт наличия ARP-трафика, а его объём и характер.