3620 теряет arpentry ещё быстрее.


800 arp записей не так уж чтобы много для железки такого класса, но дело даже не в этом. Я ловил подобные проблемы на 3612G c 20 arpentry. Самое плохое в том, что при обычной работе эта проблема не проявляется, а инициировать этот баг может кто угодно направив поток пакетов (tcp, udp, icmp (НЕ arp)) на ip, arpentry для которого не существует (и не будет существовать).
Просто тогда теряется смысл использования коммутаторов D-Link как L3 в большинстве мест сети. Представьте себе, что у вас например выделена подсеть /24 (/25, /26, /27 и т.д. )для серверов которые должны быть доступны извне. Шлюзом для этих серверов служит ipif на DGS. Не будете же вы на вашем бордере закрывать/открывать доступ для каждого ip из выделенной подсети в зависимости от доступности конкретного сервера с этим ip. При этом ЛЮБОЙ абонент сети интернет сгенерировав небольшой поток UDP пакетов без проблем может нарушить доступность как до этих серверов, так и до других устройств терминирующихся на этом DGS.
Нехорошо это.


Я бы не назвал поток в несколько мегабит(десятков мегабит) большим. Хотя с точки зрения коммутатора может так оно и есть.

Я бы не стал приумножать масштабы проблемы, так как в реальных сетях такая ситуация практически невозможна. За счет использования включенного cpu_rx_rate_control и увеличения времени жизни в ARP-таблице эффект от ситуации можно практически полностью нивелировать в реальной сети. А атаку злоумышленника, которая производится специально можно вычислить и заблокировать такой трафик на доступе при помощи ACL.

Интересно как же это на доступе можно сделать.

_________________
D-Link User: DGS-3120-24, DGS-3324SR, DGS-3627G, DGS-3612G, DGS-3312SR, DGS-3100-24TG, DGS-3200-10, DES-3200-26, DES-3200-28, DES-3200-18, DES-3528, DES-3526, DES-3028, DES-1228, DES-2108, DES-2110, DES-3326SR, DMC-920, DMC-810.

При помощи ACL по Source или Destination IP.

Чушь. Откуда я знаю на какой ip он решит трафик загнать.

_________________
D-Link User: DGS-3120-24, DGS-3324SR, DGS-3627G, DGS-3612G, DGS-3312SR, DGS-3100-24TG, DGS-3200-10, DES-3200-26, DES-3200-28, DES-3200-18, DES-3528, DES-3526, DES-3028, DES-1228, DES-2108, DES-2110, DES-3326SR, DMC-920, DMC-810.

Заранее узнать нельзя, я и написал, что если это атака, то постфактум можно заблокировать такой трафик уже после анализа.
Обрабатывать трафик абонентов посредством CPU, пока не создана ARP-запись все равно необходимо для нормальной работы сети. А ресурсы CPU, к сожалению, конечны.

Это атакой то язык не поворачивается сказать. Просто клиент шлет трафик на узел которого уже нет.

_________________
D-Link User: DGS-3120-24, DGS-3324SR, DGS-3627G, DGS-3612G, DGS-3312SR, DGS-3100-24TG, DGS-3200-10, DES-3200-26, DES-3200-28, DES-3200-18, DES-3528, DES-3526, DES-3028, DES-1228, DES-2108, DES-2110, DES-3326SR, DMC-920, DMC-810.

При небольшом трафике (тот же пинг) это никак не повлияет на сеть и не стоит забывать, что время жизни ARP записи по умолчанию 20 минут. То есть в случае того же torrent при отключении клиента этого времени более чем достаточно.
Речь по большому счету идет именно о защите от злонамеренной атаки, а не о ситуациях, которые являются обычными для любой сети.

А в случае с сотнями датчиков, которые по udp почти беспрерывно шлют данные а сервер в это время умер.

_________________
D-Link User: DGS-3120-24, DGS-3324SR, DGS-3627G, DGS-3612G, DGS-3312SR, DGS-3100-24TG, DGS-3200-10, DES-3200-26, DES-3200-28, DES-3200-18, DES-3528, DES-3526, DES-3028, DES-1228, DES-2108, DES-2110, DES-3326SR, DMC-920, DMC-810.

так арп запись умерла а датчикам то побарабану, их задача отослать пакеты.

_________________
D-Link User: DGS-3120-24, DGS-3324SR, DGS-3627G, DGS-3612G, DGS-3312SR, DGS-3100-24TG, DGS-3200-10, DES-3200-26, DES-3200-28, DES-3200-18, DES-3528, DES-3526, DES-3028, DES-1228, DES-2108, DES-2110, DES-3326SR, DMC-920, DMC-810.

Так ARP запись то еще живет некоторое время, пока сервер умер (спасет если он не умер, а ребутается).
Да и в таких отдельных критических случаях можно статикой эту запись создать. За все время эксплуатации этой серии каких-то массовых нареканий не возникало, поэтому в реалиях не стоит переоценивать последствия рассматриваемой ситуации.

Теоретически есть еще одна идея, которая позволит минимизировать последствия. Так как cpu_rx_rate_control в случае, если он включен, работает только для очередей 0, 1 и 2, то можно на коммутаторах доступа отдельно приоритизировать ARP трафик, а весь межабонентский трафик отправлять в одну из указанных очередей. Так как межабонентский трафик по умолчанию на CPU не попадает, то и ограничение cpu_rx_rate_control будет фактически работать только для случаев, когда он передается на CPU (например при пропадании ARP записи). Так как ARP приоритизирован отдельно, то он в это ограничение попадать не будет.

Последнее время участились обращения абонентов, маршрутизируемых на 3612 и 3627. Затыки происходят в случае, если ARP запись истекла и клиент со своей стороны начинает арпать, но шлюз его игнорирует. Нагрузка на процессор в это время небольшая, составляет около 25-30%. При этом если на адрес абонента приходит трафик извне и инициатором ARP-запроса является сам шлюз, то запись создаётся и всё начинает работать. Время жизни ARP уже давно подняли до 180 минут, но это на 100% не исключает ситуаций с тем, что запись выпадает по неактивности. На сколько я понимаю проблему полностью исключить не получится, но хотелось бы минимизировать такие случаи. Поэтому вопрос - в какую из COS очередей попадает ARP-трафик в случае, если он никак не маркируется и не приоритезируется? Попробую для начала выключить рх-контроль для этой очереди.

Уважаемые представители Длинка. Вопрос актуален. Вы можете на него ответить?

Уточните, пожалуйста, на какой прошивке наблюдается данная ситуация.