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

cisco, juniper, linux, QoS, troubleshooting

Ping QoS

Оставить комментарий

Клиент жалуется, что при ICMP запросе на коробку сбрасывается маркировка, причем с SNMP такой проблемы нет.
Пример SNMP:

Коробка действительно ответила с корректным QoS, происходит это благодаря настройки: snmp-server ip dscp 16 .

C ICMP не все так радужно, QoS сбрасывается в BE:

По умолчанию OS на ICMP отвечает с тем же QoS с каким к нему пришел IP пакет, пример для linux, тоже самое для коробок Cisco/Juniper/etc, Linux:

Отправил «серый» пакет, ответ также в BE:

Отправляем «цветной»:

Пример для Juniper:

Адрес управления коробки находится в GRT, и трафик на нее приходит уже без MPLS меток, а с EXP трафиком проблем нет, значить кто-то на входе/выходе делает перемаркировку.На вышестоящей коробке в сторону нашей PE проблем нет, посмотрим на PE MPLS-ые интерфейсы и их настройки QoS на входе:

По умолчанию сбрасывается в BE:

Тикает счетчик перемаркировки:

Настраиваем trust:

Перемаркировка прекратилась:

Проверяем:

 

arp, cisco, juniper, linux

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: