ARP

Используя материал http://linux-ip.net/html/index.html

Address Resolution Protocol (ARP) обеспечивает необходимое отображение между адресами канального уровня (MAC-адресами) и сетевого уровня (IP-адресами) машин в сети Ethernet. Linux предлагает управление запросами и ответами ARP через малоизвестные интерфейсы /proc :

• net/ipv4/conf/$DEV/proxy_arp
• net/ipv4/conf/$DEV/medium_id

Отправляя пинг до узла сначала необходимо получить его MAC-адрес. 

~$ ping -c 1 192.168.1.5
PING 192.168.1.5 (192.168.1.5) 56(84) bytes of data.
64 bytes from 192.168.1.5: icmp_req=1 ttl=64 time=3.53 ms

--- 192.168.1.5 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.539/3.539/3.539/0.000 ms

В это время "за кулисами":

[394]:~$ sudo tcpdump -ennqti eth1 arp or icmp
00:0c:29:36:c4:e3 > ff:ff:ff:ff:ff:ff, ARP, length 60: Request who-has 192.168.1.5 tell 192.168.1.11, length 46
00:0c:29:1d:5c:e4 > 00:0c:29:36:c4:e3, ARP, length 42: Reply 192.168.1.5 is-at 00:0c:29:1d:5c:e4, length 28
00:0c:29:36:c4:e3 > 00:0c:29:1d:5c:e4, IPv4, length 98: 192.168.1.11 > 192.168.1.5: ICMP echo request, id 19794, seq 1, length 64
00:0c:29:1d:5c:e4 > 00:0c:29:36:c4:e3, IPv4, length 98: 192.168.1.5 > 192.168.1.11: ICMP echo reply, id 19794, seq 1, length 64

Порядок отсылки пакетов:

1. Узел 192.168.1.11 отсылает ARP-запрос по широковещательному адресу FF:FF:FF:FF:FF:FF в виде "Кто имеет адрес 192.168.1.5, скажи мне 192.168.1.11"
2. На такой широковещательный запрос откликается узел с адресом 192.168.1.5 (не обязательно, что это действительно тот, кто должен быть на самом деле - протокол ARP не обеспечивает должной защиты) и отсылает ARP-ответ, в котором сообщает "192.168.1.5 это 00:0c:29:1d:5c:e4 "
3. на этом обмен ARP-сообщениями завершен, и третий пакет представляет собой уже ICMP_ECHO-запрос
4. ICMP_ECHO-ответ

ARP cache

Если просто, то кэш ARP - это сохраненное сопоставление IP-адреса с адресом канального уровня. Основное назначение - не производить повторно ARP-запросы(ответы) при каждом обмене IP-пакетами. Недостатком является то, что каждый хост поддерживает свой собственный ARP-кэш, который может устаревать, когда некоторый узел был изменен, или некоторый IP-адрес был присвоен другому хосту.
Кэш ARP также известен как таблица соседей (neighbor table). 
 
Просмотреть содержимое кэша ARP Linux можно с помощью:

[430]:~$ sudo arp -i eth1
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.1.11             ether   00:0c:29:36:c4:e3   C                     eth1

[432]:~$ sudo ip neigh sh dev eth1
192.168.1.11 lladdr 00:0c:29:36:c4:e3 STALE

[438]:~$ cat /proc/net/arp
IP address       HW type     Flags       HW address            Mask     Device
192.168.1.11   0x1         0x2         00:0c:29:36:c4:e3     *        eth1

Записи в кэше ARP периодически и автоматически проверяются, если долгое время не используются. Параметр net/ipv4/neigh/$DEV/gc_stale_time (есть много других параметров в net/ipv4/neigh/$DEV) определяет время, по истечению которого запись в кэше становится устаревшей. 

[433]:~$ sudo sysctl net.ipv4.neigh.default.gc_stale_time
net.ipv4.neigh.default.gc_stale_time = 60

Возможные состояния записи в кэше ARP:

Состояние записи	Значение
permanent	никогда не устаревает и не проверяется
noarp	устаревает, но не проверяется
reachable	нормально устаревает
stale	продолжает использоваться, нужна проверка
delay	планируется ARP-запрос, нужна проверка
probe	отправка ARP-запрроса
incomplete	первый ARP-запрос отправлен
failed	не получен ответ на ARP-запрос

Как происходит смена состояния записи в ARP-кэше (хост А хранит запись в своем кэше о хосте В):

1.  до того момента, пока истечет срок хранения записи в кэше, но после того, как узел В отключится от сети - узел А продолжает отсылать Ethernet-фреймы с назначением "MAC-адрес хоста В"
2. запись о хосте В считается достоверной в течении времени  gc_stale_time, по истечению которого состояние записи становится stale
3. заметив в таблице запись в состоянии stale, ядро инициирует проверку записи ARP-запросом в направлении IP-адреса хоста В
4. для проверки ядро сначала отправит ucast_solicit-фреймы до последнего известного адреса хоста В. Если этот вариант не поможет, то ядро отправит широковещательный mcast_solicit-фрейм, прежде чем изменить состояние записи в кэше . После того, как все попытки проверки записи закончатся неудачей, записи присвоится состояние incomplete.

Если после определенного числа mcast_solicit ARP-запросов проверка не удалась, то запись переходит в состояние failed.

ARP suppresion

Полное подавление ARP осуществляется легко - для этого достаточно установить флаг noarp при настройке интерфейса. После это потребуется статическая ARP-таблица.
Отключение ARP:

[440]:~$ sudo ip link set eth1 arp off
[441]:~$ sudo ifconfig eth1 -arp

ARP Flux problem

Когда Linux-хост подключен к сегменту сети с помощью нескольких сетевых карт, может возникнуть проблема соответствия IP-адресов адресам канального уровня, т.к. машина может ответить на запросы ARP от обоих интерфейсов Ethernet. Эта проблема более известна как ARP Flux.
С ядра версии 2.4 решение проблемы - включение параметра arp_filter
с помощью sysctl:

[442]:~$ sudo sysctl net.ipv4.conf.all.arp_filter
net.ipv4.conf.all.arp_filter = 0

C помощью оболочки можно включить фильтрацию сразу на всех интерфейсах:

for i in all eth2 eth3 eth4 eth5 ; do
>echo 1 > /proc/sys/net/ipv4/conf/$i/arp_filter

>done

Proxy ARP

ARP-прокси позволяет маршрутизатору отвечать на ARP запросы в одну сеть, в то время как запрашиваемый хост находится в другой сети. С помощью этого средства происходит "обман" отправителя, который отправил ARP запрос, после чего он "думает", что маршрутизатор является хостом назначения, тогда как в действительности хост назначения находится по другую сторону маршрутизатора. Маршрутизатор выступает в роли уполномоченного агента хоста назначения, перекладывая пакеты от другого хоста.
Регулируется параметром proc/sys/net/ipv4/conf/DEV/proxy_arp. Значение по-умолчанию -- 0 (выключено).