Архив рубрики: arp

Static route packet drops

Клиент жалуется на потери ~50%, проверил QoS все ок, далее проверка hop-by-hop, на PE к клиенту:

Тут почему-то два маршрута. Первый «directly connected» второй через обычный NH.

Настройки:

Это явно ошибка при добавлении статики. Коробка балансируем нагрузку, один из пакетов запрашивает ARP (т.к. у нас «directly connected») но на удаленной стороне ему никто не отвечает (ARP запрос на чужую сеть), поэтому пакет попросту дропается. Следующий пакет улетает корректно на адрес NH. Если бы удаленной стороной была например 7600 с настройками по умолчанию на интерфейсе (включен «proxy arp») проблем бы не было.

Удаляем неверный маршрут:

 

clear arp cache

Коллега очистил весь ARP cache на BRAS и «немного ой», временно поднялась загрузка CPU, посмотрим, как это работает, раньше мне это виделось так, очищаем кэш, запись удаляется, прилетает новый пакет генерируется ARP запрос, но это не всегда так:

В RFC нашел следующее:

RFC 826
Another alternative is to have a daemon perform the timeouts. After a suitable time, the daemon considers removing an entry. It first sends (with a small number of retransmissions if needed) an address resolution packet with opcode REQUEST directly to the Ethernet address in the table. If a REPLY is not seen in a short amount of time, the entry is deleted. The request is sent directly so as not to bother every station on the Ethernet. Just forgetting entries will likely cause useful information to be forgotten, which must be regained.

RFC 1122
IMPLEMENTATION:
Four mechanisms have been used, sometimes in
combination, to flush out-of-date cache entries.

(1) Timeout — Periodically time out cache entries,
even if they are in use. Note that this timeout
should be restarted when the cache entry is
«refreshed» (by observing the source fields,
regardless of target address, of an ARP broadcast
from the system in question). For proxy ARP
situations, the timeout needs to be on the order
of a minute.

(2) Unicast Poll — Actively poll the remote host by
periodically sending a point-to-point ARP Request
to it, and delete the entry if no ARP Reply is
received from N successive polls. Again, the
timeout should be on the order of a minute, and
typically N is 2.

Linux:

На всякий случай удаляем текущий ARP cache:

Отправляем трафик чтобы получить ARP:

В дампе все ожидаемо:

Удаляем запись:

ARP трафика нет, поведение интуитивно понятное но не оптимальное (не зависит от режима работы net.ipv4.ip_forward ), очистка ARP cache собственно это и делает:

Cisco IOS:
Изначально ARP cache пустой:

Очищаем:

Дамп трафика, «Frame 5» отправка unicast ARP req, следом «Frame 6» отправка broadcast Gratuitous ARP видимо для обновления кэша своего IP у удаленных машин, «Frame 7» unicast ARP rep от R2.

ARP cache обновился:

Действительно, зачем удалять запись, получать дроп трафика, если можно попытаться обновить, не получили ответа, удаляем.

Если нужно удалить записи, можно положить/поднять интерфейс или выключить/включить ARP на нем.

Juniper, Junos: 14.2:

Отправляет Broadcast ARP req: