Address Resolution Protocol или ARP появился в далеком 1982 году.
Ближайшей аналогией работы протокола ARP является обычная школьная перекличка на уроке физкультуры. Учитель называет фамилию, кто-то отзывается. В журнал ставится точка – ученик на месте.
Точно так же работает протокол. Компьютер спрашивает у сети: «У кого адрес 192.168.1.1?» Кто-то отзывается «Я» и называет свой MAC. Эта пара IP-MAC сразу сохраняется в локальном кэше источника запроса. Быстро и лаконично.
У такой простоты есть и обратная сторона медали, но об этом поговорим в следующий раз.
В статье рассмотрим обычную сеть на базе Ethernet и IPv4. В IPv6 вместо ARP работает Neighbor Discovery, а на каналах «точка-точка» разрешение MAC-адреса может вообще не требоваться. Если интересно, пишите в комментариях, разберем IPv6 и Neighbor Discovery в следующих темах.
Начнем с вопроса, который я часто слышу от студентов:
Зачем нужен ARP, если у каждого устройства есть IP-адрес?
Зачем нужен ARP
Разрыв между IP и MAC
Давайте немного вспомним основы технологии Ethernet, которая лежит в основе создания локальных сетей.
Ethernet ничего не знает про IP.
Кадр Ethernet адресуется только по MAC-адресу. Для сетевой карты это будет адрес, зашитый производителем на заводе. Без дополнительных навыков мы даже не сможем его изменить.
MAC-адрес нужен для доставки данных внутри одного широковещательного домена. Коммутаторы и сетевые карты работают именно с MAC'ами.
IP-адрес – это уже штука логическая, назначаемая администратором на сетевом уровне. Он нужен для маршрутизации, чтобы пакет дошел из одной сети до другой.
И тут возникает проблема. IP-пакет от источника упаковывается в Ethernet-кадр. В заголовке кадра есть поля Source MAC и Destination MAC, но нет IP. Значит, отправитель должен знать MAC получателя, чтобы построить кадр.
И вот тут на сцене появляется протокол ARP, который выступает в роли переводчика. Он позволяет динамически определить MAC-адрес следующего узла и заполнить поле Destination MAC в Ethernet-кадре.
Почему не обойтись одним IP
Можно ли было сделать так, чтобы коммутаторы работали с IP вместо MAC? Теоретически это возможно. Но тогда коммутаторы превратились бы в маршрутизаторы. Им пришлось бы анализировать IP-заголовки и строить таблицы маршрутизации внутри своей сети. Звучит не очень логично.
Сегодня Ethernet и IP решают разные задачи. IP определяет путь между сетями, а Ethernet доставляет кадр в пределах локального сегмента. ARP связывает эти два механизма.
Что происходит до ARP
Перед отправкой данных в сеть ядро операционной системы должно ответить на вопрос «Куда передавать пакет?».
Здесь возможны несколько вариантов для ARP:
адрес находится в локальной подсети – ARP ищет MAC самого получателя;
адрес находится в другой сети – ARP ищет MAC следующего шлюза;
маршрута нет – ARP вообще не запускается.
Механизм маршрутизации сначала выбирает выходной интерфейс и IP-адрес следующего узла. Затем ARP сопоставляет этому IP-адресу MAC-адрес. Порядок преобразования адресов описан в RFC 826.
Получаем, что ARP переводит в MAC не обязательно IP конечного получателя. Он ищет IP следующего узла, которому должен быть передан Ethernet-кадр.
Как устроен обмен: Request и Reply
ARP Request или начало переклички
Компьютеру нужно отправить пакет, но MAC получателя неизвестен. Он формирует ARP-запрос со следующими полями:
- Операция: Request (код 1) - Отправитель IP: мой IP - Отправитель MAC: мой MAC - Целевой IP: IP получателя - Целевой MAC: 00:00:00:00:00:00 (не знаем)
И шлет это широковещательным запросом (broadcast): ff:ff:ff:ff:ff:ff. Все устройства в локальной сети получают кадр. Если целевой IP совпадает с адресом хоста, то хост отвечает. Если нет – молча отбрасывает.
Возможен вариант, когда ARP Request является unicast. В этом случае система проверяет адрес уже известного соседа.
ARP Reply или отклик
Устройство с нужным IP формирует ARP-ответ:
- **Операция:** Reply (код 2) - **Отправитель IP:** мой IP - **Отправитель MAC:** мой MAC - **Целевой IP:** IP запрашивавшего - **Целевой MAC:** MAC запрашивавшего
И шлет отклик напрямую запрашивавшему. Потому что в запросе был MAC отправителя, так что отвечать можно сразу на него.
Стенд в GNS3
Дальше будем показывать на стенде в GNS3:
За облаком находится Ubuntu 26.04.
Стенд выбран в таком формате, потому что его просто воспроизвести в домашних условиях. Мне не нравится работать с Cisco 3745 в роли Ethernet-switch, он не слишком стабильно себя ведет, поэтому в сети работает обычный коммутатор.
Если интересно, напишите в комментариях, соберу стенд на базе реальных коммутаторов Cisco 2960/3560/3750 и Eltex MES2324/2424.
Сразу приведу таблицу с IP- и MAC-адресами:
Устройство | Интерфейс | IP-адрес | MAC-адрес |
Виртуальный шлюз Hyper-V | - | 172.25.32.1 | 00:15:5d:6d:4c:3d |
Ubuntu | eth0 | 172.25.47.226/20 | 00:15:5d:67:6f:01 |
vESR | gi 1/0/5 (e0) | 172.25.43.109/20 | 0c:11:31:38:00:00 |
Cisco R2 | gi 0/0 | 172.25.38.168/20 | ca01.0580.0008 |
Начинаем изучать ARP на практике на примере Ubuntu.
ARP и Ubuntu
Начнем с того, что ARP работает только после выбора маршрута. Используем команду ip -4 route get, которая не отправляет пакеты. Она показывает решение ядра о маршрутизации. Поле dev указывает выходной интерфейс, src – выбранный IP-адрес источника, а via – следующий шлюз. Строка cache означает, что показан результат поиска маршрута для указанного адреса.
Синтаксис команды:
ip -4 route get <IP-адрес назначения>
В моем случае:
jetcry@ubuntu-2604:~$ ip -4 route get 172.25.38.168 172.25.38.168 dev eth0 src 172.25.47.226 uid 1000 cache jetcry@ubuntu-2604:~$ ip -4 route get 8.8.8.8 8.8.8.8 via 172.25.32.1 dev eth0 src 172.25.47.226 uid 1000 cache jetcry@ubuntu-2604:~$
В первом случае маршрут должен быть непосредственно через eth0. Во втором появится via 172.25.32.1. Это значит, ARP будет искать MAC шлюза, а не 8.8.8.8. Если интересно, то синтаксис ip route get можно посмотреть в документации.
Просмотр таблицы ARP
Продолжаем современной командой для просмотра таблицы ARP на Ubuntu:
ip neigh
На самом деле дальше возможны два варианта команды:
ip neighbor
и
ip neighbour
Они равнозначны. Я не стал выбирать и ввел только первые символы:
jetcry@ubuntu-2604:~$ ip neigh 172.25.32.1 dev eth0 lladdr 00:15:5d:6d:4c:3d REACHABLE 172.25.43.109 dev eth0 lladdr 0c:11:31:38:00:00 STALE jetcry@ubuntu-2604:~$
Команда показывает две известные Ubuntu пары IP-MAC на интерфейсе eth0. Виртуальный шлюз сейчас находится в состоянии REACHABLE, а vESR в состоянии STALE.
Переходим к расшифровке состояний ARP-кеша.
Состояния ARP на Ubuntu
Жизненный цикл записи Linux имеет следующие состояния:
INCOMPLETE– разрешение еще выполняется, MAC неизвестен;REACHABLE– достижимость недавно подтверждена;STALE– MAC известен, но подтверждение устарело. Запись все еще можно использовать;DELAY– система ждет подтверждения от протоколов верхнего уровня перед проверкой;PROBE– выполняется активная проверка;FAILED– попытки разрешения или проверки закончились неудачно;PERMANENT– статическая запись.
По умолчанию базовое значение REACHABLE составляет 30 секунд, а фактический интервал выбирается в пределах от 15 до 45 секунд. Первая проверка после перехода к проверке соседа обычно откладывается на пять секунд.
Просмотрим таймеры Linux командами:
sysctl net.ipv4.neigh.eth0.base_reachable_time_ms
и
sysctl net.ipv4.neigh.eth0.delay_first_probe_time
В моем случае:
jetcry@ubuntu-2604:~$ sysctl net.ipv4.neigh.eth0.base_reachable_time_ms net.ipv4.neigh.eth0.base_reachable_time_ms = 30000 jetcry@ubuntu-2604:~$ sysctl net.ipv4.neigh.eth0.delay_first_probe_time net.ipv4.neigh.eth0.delay_first_probe_time = 5 jetcry@ubuntu-2604:~$
Уточню, что base_reachable_time_ms – это не время жизни записи в таблице, а период, в течение которого достижимость считается подтвержденной.
Покажем смену состояний записи ARP в реальном времени командой:
ip -4 monitor neigh
Результат:
jetcry@ubuntu-2604:~$ ip -4 monitor neigh 172.25.32.1 dev eth0 lladdr 00:15:5d:6d:4c:3d STALE 172.25.32.1 dev eth0 lladdr 00:15:5d:6d:4c:3d PROBE 172.25.32.1 dev eth0 lladdr 00:15:5d:6d:4c:3d REACHABLE
Результаты изменения состояния будут отображаться в течение времени. Я прервал команду примерно через пару минут.
Запись шлюза последовательно перешла из STALE в PROBE. После успешной проверки стала REACHABLE, потому что Linux снова подтвердил доступность соседа.
ARP – невидимая основа ICMP
Для следующей диагностики ARP совместно с ICMP настраиваю два подключения к виртуальной машине Ubuntu через PowerShell и SSH. В первом окне я буду выполнять команды. Второе окно будет выводить результаты диагностики через tcpdump. Команда во втором окне не будет меняться:
sudo tcpdump -ni eth0 -e 'arp or icmp'
Здесь:
-n запрещает разрешение имен;
-i eth0 выбирает интерфейс;
-e показывает Ethernet-заголовок и MAC-адреса.
Выполняю из первого окна пинг до IP-адреса Cisco:
PING 172.25.38.168 (172.25.38.168) 56(84) bytes of data. 64 bytes from 172.25.38.168: icmp_seq=1 ttl=255 time=22.8 ms 64 bytes from 172.25.38.168: icmp_seq=2 ttl=255 time=10.2 ms … jetcry@ubuntu-2604:~$
Фрагмент диагностики tcpdump:
jetcry@ubuntu-2604:~$ sudo tcpdump -ni eth0 -e 'arp or icmp' … 10:09:48.068533 00:15:5d:67:6f:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.25.38.168 tell 172.25.47.226, length 28 10:09:48.081095 ca:01:05:80:00:08 > 00:15:5d:67:6f:01, ethertype ARP (0x0806), length 60: Reply 172.25.38.168 is-at ca:01:05:80:00:08, length 46 10:09:48.081128 00:15:5d:67:6f:01 > ca:01:05:80:00:08, ethertype IPv4 (0x0800), length 98: 172.25.47.226 > 172.25.38.168: ICMP echo request, id 47418, seq 1, length 64 10:09:48.091298 ca:01:05:80:00:08 > 00:15:5d:67:6f:01, ethertype IPv4 (0x0800), length 98: 172.25.38.168 > 172.25.47.226: ICMP echo reply, id 47418, seq 1, length 64
Видим, что перед ICMP работает ARP.
При отсутствии готовой ARP-записи ICMP-пакет ожидает завершения ARP-обмена. В моем примере от отправки ARP Request до получения Reply прошло около 12,6 мс, после чего ICMP Echo Request был отправлен практически сразу.
Получаем, что первый пинг может быть медленнее остальных или вообще не дойти.
После этого проверяем записи:
jetcry@ubuntu-2604:~$ ip neigh 172.25.32.1 dev eth0 lladdr 00:15:5d:6d:4c:3d DELAY 172.25.43.109 dev eth0 lladdr 0c:11:31:38:00:00 STALE 172.25.38.168 dev eth0 lladdr ca:01:05:80:00:08 STALE jetcry@ubuntu-2604:~$
В таблице появилась новая запись, соответствующая нашей Cisco.
Полезные команды при работе с ARP
Начнем с команды удаления ARP-записи:
sudo ip -4 neigh del <IP-адрес> dev <интерфейс>
Удаляю запись Cisco:
jetcry@ubuntu-2604:~$ sudo ip -4 neigh del 172.25.38.168 dev eth0
Проверяю:
jetcry@ubuntu-2604:~$ ip neigh 172.25.32.1 dev eth0 lladdr 00:15:5d:6d:4c:3d REACHABLE 172.25.43.109 dev eth0 lladdr 0c:11:31:38:00:00 STALE jetcry@ubuntu-2604:~$
Можно использовать команду:
sudo ip neigh flush all
Но надо учитывать, что она затрагивает все интерфейсы и обе версии IP.
Затем установим статическую запись ARP. Для этого нам потребуется утилита arp из пакета net-tools, который можно установить через:
sudo apt update sudo apt install net-tools
Синтаксис команды:
sudo arp -s <IP устройства> <MAC устройства>
В моем случае для Cisco:
sudo arp -s 172.25.38.168 ca:01:05:80:00:08
После этого:
jetcry@ubuntu-2604:~$ ip neigh 172.25.32.1 dev eth0 lladdr 00:15:5d:6d:4c:3d REACHABLE 172.25.43.109 dev eth0 lladdr 0c:11:31:38:00:00 STALE 172.25.38.168 dev eth0 lladdr ca:01:05:80:00:08 PERMANENT jetcry@ubuntu-2604:~$
Обратите внимание на изменение статуса у записи на PERMANENT.
Следующая команда позволит проверить соседство только через ARP.
Сначала установим утилиту arping:
sudo apt install arping
После этого вводим саму команду:
sudo arping -c 2 -I eth0 172.25.38.168
Использование sudo здесь не ошибка, потому что arping формирует ARP-кадры напрямую. Ему требуется привилегия ядра Linux CAP_NET_RAW, которая разрешает процессу самостоятельно формировать сетевые пакеты и кадры. Она нужна arping, поскольку программа отправляет ARP-запросы напрямую, минуя обычные сетевые механизмы приложений.
На моем стенде в первом окне ввожу команду:
jetcry@ubuntu-2604:~$ sudo arping -c 2 -I eth0 172.25.38.168 ARPING 172.25.38.168 60 bytes from ca:01:05:80:00:08 (172.25.38.168): index=0 time=1.953 msec 60 bytes from ca:01:05:80:00:08 (172.25.38.168): index=1 time=10.057 msec --- 172.25.38.168 statistics --- 2 packets transmitted, 2 packets received, 0% unanswered (0 extra) rtt min/avg/max/std-dev = 1.953/7.134/10.057/3.673 ms jetcry@ubuntu-2604:~$
Диагностика во втором окне:
10:17:40.805995 00:15:5d:67:6f:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 58: Request who-has 172.25.38.168 tell 172.25.47.226, length 44 10:17:40.807927 ca:01:05:80:00:08 > 00:15:5d:67:6f:01, ethertype ARP (0x0806), length 60: Reply 172.25.38.168 is-at ca:01:05:80:00:08, length 46 10:17:41.807188 00:15:5d:67:6f:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 58: Request who-has 172.25.38.168 tell 172.25.47.226, length 44 10:17:41.817206 ca:01:05:80:00:08 > 00:15:5d:67:6f:01, ethertype ARP (0x0806), length 60: Reply 172.25.38.168 is-at ca:01:05:80:00:08, length 46
За две секунды arping отправил два широковещательных ARP Request и получил от Cisco два адресных Reply.
Переходим к Eltex.
ARP и Eltex vESR
Просмотр своего MAC-адреса
Для просмотра MAC-адресов своих интерфейсов воспользуемся командой:
sh int status
Фрагмент вывода на моем vESR:
vesr# sh int status Interface Admin Link MTU MAC address Last change Mode State State (d,h:m:s) -------------------- ---------- ----- ----- ----------------- ------------- ------------ gi1/0/5 Up Up 1500 0c:11:31:38:00:00 00,00:05:55 routerport … vesr#
Таблица ARP
Затем проверяем таблицу ARP:
show arp
На моем vESR:
vesr# show arp Interface IP address MAC address State Age(min) --------------- --------------- ----------------- --------------- ---------- gi1/0/5 172.25.32.1 00:15:5d:6d:4c:3d stale -- gi1/0/5 172.25.43.109 0c:11:31:38:00:00 -- -- gi1/0/5 172.25.47.226 00:15:5d:67:6f:01 stale --
ARP для конкретного IP-адреса
Запись для конкретного IP-адреса:
vesr# show arp ip-address 172.25.47.226 Interface IP address MAC address State Age(min) --------------- --------------- ----------------- --------------- ---------- gi1/0/5 172.25.47.226 00:15:5d:67:6f:01 stale --
Удаление записи ARP
Удалим запись о MAC-адресе для IP 172.25.47.226 (моя Ubuntu):
clear arp-cache ip-address 172.25.47.226
Проверим таблицу ARP для этого адреса:
vesr# clear arp-cache ip-address 172.25.47.226 vesr# show arp ip-address 172.25.47.226 Interface IP address MAC address State Age(min) --------------- --------------- ----------------- --------------- ---------- gi1/0/5 172.25.47.226 -- failed -- vesr#
Обратите внимание на изменившийся статус записи – failed.
Статическая запись ARP
Создадим статическую запись командой:
ip arp <IP-адрес> <MAC-адрес> <тип интерфейса> <номер интерфейса>
В моем случае:
configure ip arp 172.25.47.226 00:15:5d:67:6f:01 gigabitethernet 1/0/5 end commit confirm
После этого обратите внимание на state:
vesr# sh arp Interface IP address MAC address State Age(min) --------------- --------------- ----------------- --------------- ---------- gi1/0/5 172.25.32.1 00:15:5d:6d:4c:3d stale -- gi1/0/5 172.25.43.109 0c:11:31:38:00:00 -- -- gi1/0/5 172.25.47.226 00:15:5d:67:6f:01 permanent -- vesr#
Запись получает статус permanent.
Ситуация полностью повторяет таблицу состояний ARP на Ubuntu.
Таймер ARP
Можно посмотреть таймер для ARP на интерфейсе командой:
show arp configuration <тип интерфейса> <номер интерфейса>
У меня:
vesr# show arp configuration gigabitethernet 1/0/5 Globally configured ARP reachable time is 160000 msec Interface ARP reachable time, msec --------------- ------------------------- gi1/0/5 160000 vesr#
Таймер установлен в значение 160 секунд.
Как сказано в документации, установить таймер ARP на данном интерфейсе можно командой
vesr(config)# ip arp reachable-time <время таймера в мс>
Установим таймер на 20 секунд:
configure ip arp reachable-time 20000 end commit confirm
Что видит Ubuntu, когда vESR пингует Cisco?
Я удалил статическую запись ARP для Cisco и запустил пинг до нее. Посмотрим, что отобразится на Ubuntu:
vesr#ping 172.25.38.168 !!!!! vesr#
На Ubuntu видим:
jetcry@ubuntu-2604:~$ sudo tcpdump -ni eth0 -e 'arp or icmp' tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 10:37:37.269401 0c:11:31:38:00:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.25.38.168 tell 172.25.43.109, length 46
Больше ничего нет. Следующие пакеты целенаправленно шли на Cisco.
Мы закончили рассматривать основные команды на vESR, переходим к следующему вендору.
ARP и Cisco
Просмотр MAC интерфейса
Посмотреть MAC интерфейса можно с помощью:
show interfaces GigabitEthernet0/0 | include addr
На моем 7200:
R2#show interfaces GigabitEthernet0/0 | include addr Hardware is 82543, address is ca01.0580.0008 (bia ca01.0580.0008) R2#
Таблица ARP
Команда для просмотра IPv4-записей в таблице:
show ip arp
Команда show arp исторически может отображать записи и для других сетевых протоколов.
R2#show ip arp Protocol Address Age (min) Hardware Addr Type Interface Internet 172.25.32.1 30 0015.5d6d.4c3d ARPA GigabitEthernet0/0 Internet 172.25.38.168 - ca01.0580.0008 ARPA GigabitEthernet0/0 Internet 172.25.47.226 7 0015.5d67.6f01 ARPA GigabitEthernet0/0 R2#show arp Protocol Address Age (min) Hardware Addr Type Interface Internet 172.25.32.1 30 0015.5d6d.4c3d ARPA GigabitEthernet0/0 Internet 172.25.38.168 - ca01.0580.0008 ARPA GigabitEthernet0/0 Internet 172.25.47.226 7 0015.5d67.6f01 ARPA GigabitEthernet0/0 R2#
Поля в выводе команд:
- Protocol – всегда Internet (IPv4).
- Address – IP.
- Age – время с момента последнего обновления (в минутах). Пустое поле (-) означает адрес собственного интерфейса или статическую запись.
- Hardware Addr – MAC.
- Type – ARPA (стандартный Ethernet). Может быть SNAP, SAP и другие, но в современных сетях почти всегда ARPA.
- Interface – через какой интерфейс видим.
ARP для конкретного IP-адреса
Если я хочу посмотреть запись для конкретного IP-адреса:
R2#show ip arp 172.25.47.226 Protocol Address Age (min) Hardware Addr Type Interface Internet 172.25.47.226 7 0015.5d67.6f01 ARPA GigabitEthernet0/0
Статическая запись ARP
Настроим статическую запись на уровне конфигурирования:
configure terminal arp <IP-адрес> <MAC-адрес в формате XXXX.XXXX.XXXX> arpa
В моем случае:
configure terminal arp 172.25.47.226 0015.5d67.6f01 arpa
Обратите внимание, как изменится вывод команды sh arp:
R2#sh arp Protocol Address Age (min) Hardware Addr Type Interface …. Internet 172.25.47.226 - 0015.5d67.6f01 ARPA
После этого при пинге с Cisco на Ubuntu нет предварительного широковещательного запроса в сеть:
R2#ping 172.25.47.226 !!!!! R2#
Первые пакеты на Ubuntu:
jetcry@ubuntu-2604:~$ sudo tcpdump -ni eth0 -e 'arp or icmp' 10:58:28.768369 ca:01:05:80:00:08 > 00:15:5d:67:6f:01, ethertype IPv4 (0x0800), length 114: 172.25.38.168 > 172.25.47.226: ICMP echo request, id 3, seq 0, length 80 10:58:28.768396 00:15:5d:67:6f:01 > ca:01:05:80:00:08, ethertype IPv4 (0x0800), length 114: 172.25.47.226 > 172.25.38.168: ICMP echo reply, id 3, seq 0, length 80
Удаление записи ARP
Удалим статическую запись командой:
no arp 172.25.47.226 0015.5d67.6f01 arpa
Проверяем таблицу ARP:
R2(config)#no arp 172.25.47.226 0015.5d67.6f01 arpa R2(config)#do sh arp Protocol Address Age (min) Hardware Addr Type Interface Internet 172.25.32.1 7 0015.5d6d.4c3d ARPA GigabitEthernet0/0 Internet 172.25.38.168 - ca01.0580.0008 ARPA GigabitEthernet0/0 Internet 172.25.43.109 5 0c11.3138.0000 ARPA GigabitEthernet0/0 R2(config)#
Больше нет записи об этом MAC-адресе.
Она появится, если мы снова запустим пинг до Ubuntu:
R2#ping 172.25.47.226 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.25.47.226, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 8/19/32 ms R2#sh arp Protocol Address Age (min) Hardware Addr Type Interface Internet 172.25.32.1 8 0015.5d6d.4c3d ARPA GigabitEthernet0/0 Internet 172.25.38.168 - ca01.0580.0008 ARPA GigabitEthernet0/0 Internet 172.25.43.109 5 0c11.3138.0000 ARPA GigabitEthernet0/0 Internet 172.25.47.226 0 0015.5d67.6f01 ARPA GigabitEthernet0/0
После удаления записи Cisco сначала пришлось определить MAC-адрес Ubuntu с помощью ARP. Пока выполнялся ARP-обмен, первая попытка ping завершилась без ответа и была обозначена точкой. Следующие четыре попытки выполнялись уже с готовой ARP-записью.
Таймер ARP
Посмотреть таймаут интерфейса можно командой:
show interfaces GigabitEthernet0/0 | include ARP
У меня:
R2#show interfaces GigabitEthernet0/0 | include ARP Encapsulation ARPA, loopback not set ARP type: ARPA, ARP Timeout 04:00:00
Изменить таймер на интерфейсе можно через несколько команд:
configure terminal interface GigabitEthernet0/0 arp timeout <значение таймера в секундах> end
По умолчанию Cisco использует 14 400 секунд, то есть целых четыре часа. Cisco предупреждает, что слишком короткий таймер увеличивает ARP-трафик. Синтаксис просмотра, очистки, статических записей приведен в официальном руководстве Cisco.
В качестве примера изменим таймаут на 20 секунд:
configure terminal interface GigabitEthernet0/0 arp timeout 20 end
Итоги
Протокол ARP – это фундамент работы сетей на IPv4. Он решает только одну задачу, переводит IP в MAC. На нем работает все, что упаковывается в кадры Ethernet.
Перед каждым первым пакетом к новому соседу или шлюзу система делает одно и то же:
1. Смотрит в ARP-кэш.
2. Если нет записи – шлет ARP Request.
3. Ждет ARP Reply.
4. Только потом отправляет ICMP, TCP, UDP, … (нужное выбрать).
В нашем примере ICMP выступает просто в роли полезной нагрузки, которую ARP позволяет доставить.
Еще отмечу, что запись в кэше ARP живет не вечно. У каждой платформы свой взгляд на то, сколько именно времени отвести на каждую строчку в ARP-таблице.
Конечно, таймеры разных платформ нельзя сравнивать напрямую. В Linux значение base_reachable_time_ms определяет период подтвержденной достижимости, но не время удаления записи. Eltex задает базовый интервал обновления динамической записи, Cisco изначально использует четырехчасовой тайм-аут ARP-кэша.
Такие значения на сетевых устройствах выбраны из-за того, что частая очистка ARP-таблицы будет создавать лишний широковещательный трафик.
ARP – это простой и быстрый протокол. Но у его простоты есть и обратная сторона.
Вспомните школьную перекличку. Учитель не проверяет, кто отозвался. В следующей статье мы разберем ситуацию, когда на перекличке появится самозванец.
