Пожалуйста вышлите инструкцию.

Выслал

Вышлите, пожалуйста, инструкцию мне на почту.

Выслал

добрый день, а можно и мне инструкцию? аналогичные симптомы на 3627
спасибо

Тоже прошу выслать инструкцию. Спасибо.

будте добрый вышлтите и мне.

_________________
Ua,Onetelecom ISP

Выслал

Итак. Нашел у себя третий DGS-3627G, который начал некоторых абонентов гнать через CPU и подрезать на cpu_rx_rate_control. Главный вопрос к D-Link - я так понимаю высланные рекомендации вовсе не решают исходной проблемы - верно? Планируется ли ее решить прошивкой?
Для справки: в одной точке 3627G был заменен на 3620-28SC - проблема ушла.
Также заметил, что на проблемных коммутаторах количество арп записей >=2600. Хотя есть и точки, где записей больше, а проблем нет.

Это рекомендации для диагностики. При необходимости нужно отключать cpu_rx_rate_control для определенной очереди.

А где же тогда ответ на главный вопрос - как пакеты, которые идут транзитом, вдруг оказываются в очереди CPU коммутатора, если они должны пройти через TCAM, не пролетая всем комплектом через CPU? Подтвержден ли этот баг и будет ли он исправлен?

О каких именно пакетах идет речь?

О чем идет дискуссия? О том, что cpu_rx_rate_control начинает подрезать пакеты, которые шли транзитом, а не самому коммутатору. То есть смотрим к примеру трассировку к абоненту при помощи mtr (абонент маршрутизуется через DGS-3627G). С включенным cpu_rx_rate_control для "здорового" абонента - я вижу задержку и потерю на хопе DGS-3627G и вижу хоп абонента без потерь и с нормальной задержкой. В какой-то сферический момент (по моим наблюдениям - как правило при количестве записей в arp-таблице >=2600 - но это наблюдение пальцем в небо пока) появляются "нездоровые абоненты" - глядя на трассу mtr я вижу потери как на хопе коммутатора - так и на абоненте - причем сопоставимые как по величине задержки, так и по величине потерь. clear arptable - и абонент снова здоров. Мой субъективный вывод - пакеты для абоненты шли не через TCAM, а почему-то все подряд ломились через CPU, в связи с чем и резались как cpu_rx_rate_control, так и cpu_interface_filtering. Проблема прощупана уже на трех ДГСах в разных точках сети. Проблема пока, к счастью, не воспроизвелась на 3620.
Прошу поправить мою логику, если я где-то не прав. А также, ответить на вопрос о причинах подобного поведения железяки.

Естественно при трассировке идет обращение к CPU коммутатора. Для этого как раз и сделали функционал cpu_rx_rate_control, чтобы убрать ограничение в 64к для неприоритетного трафика предназначенного процессору. На маршрутизацию клиентского трафика, который через CPU не проходит (в отличие от трассировки) это никак не влияет.

Хорошо. Давайте смотреть так. Вот трасса, когда абонент здоров и весел:

в данном состоянии Ваши слова подтверждаются делом - на коммутаторе как и положено забегают пакетики в CPU и подрезаются, а абонент пингуется чисто.
Когда абонент "болен":

как видим пинг идентичен на обоих точках. При этом можно, например, создать правило cpu access profile задропав ICMP - и абонента будет совсем не видно, хотя его трафик туда ходить не должен. Примечательно - с самого коммутатора в это время абонент пингуется чисто:

И само собой отключение cpu_rx_rate контрол облегчает ненадолго ситуацию - в связи с тем, что CPU начинает обрабатывать пакеты в полной мере, даже те, которые не должен - но вместе с этим нагрузка на CPU возрастает в 3-4 раза и иногда уходит в 100%.
После clear arptable вот это:


превращается вот в это:


Так более понятно?

PS: Это касается не только пинга - у абонента аналогично интернет не работает в принципе - ибо и другой трафик не пролазит так, как должен.