throughtheether

4) В разное время появляется множество запросов ARP

Запросы исходят от одного устройства или от разных? Какова примерная интенсивность? Пики такого трафика наблюдаются в произвольные или периодически повторяющиеся моменты времени?

При этом до перехода в VLAN все работало отлично.

До перехода в VLAN - это как? Как была организована сеть? Один L2-домен на все устройства? Какие изменения вносились при "переходе во VLAN"?

Пытался отключать ARP запросы на стороне сервера. ifconfig eth0 -arp, после этого грузил с файла, где прописаны IP адреса телефонов и MAC адрес - как результат все телефоны "отключились" - вернул все обратно.

Телефоны у вас имеют прописанные вручную IP-адреса или получают их автоматически?

Появляется шторм в VLAN сегменте.

Какова интенсивность трафика? Кроме ARP-запросов и UDP-пакетов имеются ли другие значительные компоненты трафика?

Другие рекомендации и замечания:
1) организуйте мониторинг оборудования, если, конечно, не хотите в будущем тратить по нескольку суток на траблшутинг подобных проблем
2) на коммутаторах ограничьте уровень широковещательного (broadcast) и многоадресного (multicast) трафика на пользовательских портах (к которым подключены ПК или телефоны). Функциональность называется "storm control".
3) возможно, в сети временно возникает L2-петля. Из подозреваемых: аппаратные VoIP-телефоны со встроенным коммутатором, клиентские ПК (в случае включения двумя кабелями), WiFi-точки доступа (одновременный бриджинг на точке доступа и на ПК, одновременный бриджинг на двух точках доступа при неправильной настройке)

UPD:
Возникли вопросы по предоставленным вами материалам.
По топологии (ссылка).
1) Горизонтальные линки между коммутаторами (обведены от руки красным цветом) - они действительно присутствуют или это небрежность при составлении топологии?
2) Красной прямоугольной рамкой обведены дублирующиеся адреса - это неточность? Проверьте, нет ли дублирующихся адресов из числа задаваемых вручную.
3) в топологии вы указали центральный коммутатор как DGS-3120. При этом предоставили скриншот настроек некоего DES-3200. Как они соотносятся? В целом, предоставленная вами топология порождает вопросов больше, чем ответов. Если есть возможность, просьба ее переделать в более приемлемом виде (вам самим она может в дальнейшем пригодиться).

По дампам:
4) если есть возможность, просьба в будущем предоставлять дампы в виде .pcap-файлов, их удобнее обрабатывать.
5) по поводу SIP ничего не могу сказать, не специалист
6) по поводу ARP. Интенсивность трафика оценивается около 2000 pps, для ARP, на мой взгляд, это ненормально. Просьба проверить хост с адресом 192.168.20.11. Как именно он подключен? Через телефон? Какова модель телефона? Настройки телефона? К какой порт коммутатора подключен телефон, каковы его настройки? Есть ли в логах телефона или коммутатора коррелирующие с проблемой записи?

UPD2:

Выходил на работу и нашел кое-что интересное:
1. При "шторме" - на сервера Asterisk - проверка командой
arp -a
- не может "связать" некоторые* IP телефоны и MAC-адреса
2. В это же время как раз udp запросы по порту 5060 идут из этих телефонов.
3. Т.е. в какой то момент времени сервер не может понять где находится телефон, телефон пытается отправить запрос на сервак - а сервак не может ответить ему, т.к. не знает где он находится. В итоге получается Шторм.

Логично, что ARP-ответы телефон генерирует в ответ на ARP-запрос, который шлет сервер из-за того, что, например, запись в arp-таблице устарела.
Пара новых идей:
7) вы можете увеличить время жизни arp-записи на сервере, это, предположительно, снизит частоту проявления проблемы. Но имейте в виду, что это значение должно быть меньше времени жизни записи в таблице MAC-адресов коммутатора.
8) кстати, вполне возможно, что на коммутаторе запись с MAC-адресом сервера устаревает, и поэтому фреймы, адресуемые ему, шлются во все порты коммутатора, в том числе в те, которые участвуют в флуктуирующей петле. Проверьте настройки и логи коммутатора, ближайшего к серверу
9) маловероятно, что это является причиной проблемы, но проверьте настройки каждого транка с обеих сторон. В редких случаях (бриджинг разных вланов + коллизии в D-link) это, думаю, может приводить к образованию петель.

Пока, не имея доступа к сети, какие-то дополнительные рекомендации (кроме общих - поискать петлю, проверить все устройства на пути от телефона до сервера) дать трудно.

Есть ли аналог команды show processes cpu sorted на коммутаторах d-link ?

Смотря что вы имеете в виду под аналогом (какая функциональность вам нужна). Утилизацию процессора можно узнать при помощи команды show utilization cpu.

Если вас интересует утилизация процессора каждым процессом, то не думаю, что эти данные возможно получить. Я даже не уверен, поддерживает ли ОС коммутаторов D-link процессную многозадачность.

Скорость на прямую, при подключении кабеля к сетевой карте 40-50 мбит/сек. При подключении через роутер скорость не поднимается больше 20 мбит/сек.

Что такое "скорость"? Как вы ее измеряете? Через speedtest.net и подобные сервисы? Как вы получаете интернет (используется ли VPN или PPPoE)?

Почему так может быть?

Возможные варианты (список неполный):
1) Маршрутизатор не справляется с нагрузкой. Проверьте утилизацию его ресурсов (CPU, память). Возможны также баги в реализации поддержки протоколов.
2) Субоптимальная работа TCP (в случае, если вы пользуетесь результатами speedtest.net). Проверьте настройки MTU и TCP MSS (maximum-segment size), если они есть. Проверьте скорость передачи udp-датаграмм при помощи, например, iperf.
3) Несогласованность дуплекса на каком-либо из портов. Проверьте настройки дуплекса и наличие ошибок на портах.
4) Как частный случай варианта 1), наличие встроенных механизмов "безопасности" (фаерволлы, ids и прочая), утилизирующих ресурсы. Попробуйте их отключить.

Если вы получаете интернет через VPN/PPPoE, то я склоняюсь к первому варианту. Быть может, что маршрутизатор не способен обработать трафик большей интенсивности.
UPD:

Интернет через pppoe. Скорость заметил на торрентах, да и на тестах тоже самое. Данная проблема была не всегда, а появилась совсем не давно. Не прошивал, не настраивал.

В принципе, те же варианты, только в другой формулировке:
1) может быть, маршрутизатор по какой-либо причине перестал нормально функционировать (плохое питание - нестабильная производительность - отбрасывание пакетов, или пробой памяти - нарушение контрольной суммы - отбрасывание пакетов)
2) настройки дуплекса на портах, особенно на WAN-порту маршрутизатора
3) проблемы с MTU также не стоит исключать
4) провайдер или ваш сосед по коммутатору начал слать вам паразитный трафик, маршрутизатор пытается его обрабатывать, что ведет к снижению полезной производительности.
5) провайдер изменил параметры PPPoE, маршрутизатор отреагировал снижением производительности из-за багов в прошивке.

Наиболее полную картину даст сравнение характеристик подключения через маршрутизатор и напрямую (здесь можно изучить интернет-трафик с компьютера при разных вариантах подключения и сравнить его характеристики), изучение характеристик маршрутизатора (количество отброшенных пакетов, ошибки на портах, утилизация ресурсов) и интернет-трафика с его WAN-порта (количество повторных посылок данных, параметры TCP, наличие фрагментации).

Готовых односложных ответов я вам, к сожалению, предоставить не могу. "Домашние" маршрутизаторы мне представляются довольно неудобными в диагностике в силу отсутствия внятных инструментов для этого.

D-Link

Сначала он просто перезагрузился, узнал я об этом от сотрудников которые в этот момент работали, чуть позже он перезагрузился при мне. Никакой закономерности нет, может перезагружаться 3-4 раза подряд через 2-3 минуты, а может весь деь работать как часы и перезагрузиться ночью.

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

UPD:

температура в серверной 18-20 градусов

И что? Вы знаете, что ASIC (специфические микросхемы) иногда до 80 градусов разогреваются?

на счет электролитов, не вижу смысла их проверять, так как коммутатору месяц.

Коммутатору месяц - и что? Где гарантия, что эта ситуация не повторяется в вашем случае?

И еще один вариант - если вышла новая версия прошивки, попробуйте обновить ее.

Я вижу два главных отличия - на 3750 можно установить 10-гигабитные трансиверы в качестве аплинков, также на 3750 более полно (RIP/OSPF) реализована маршрутизация (на 2960s только статические маршруты, около 16, и по-моему надо использовать софт LAN Base, а не LAN Lite, идущий в комплекте)

Полезные ссылки:
3750
2960