throughtheether

На этом устройстве, насколько я понял, можно запустить openWRT, а на openWRT можно писать разные скрипты, вроде такого. Вам остается поменять парсинг лога на какое-то взаимодействие с удаленным сервером (при помощи wget или curl).

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) это, думаю, может приводить к образованию петель.

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

Я бы так решал вашу задачу.

1. Порядка 20-30 IP камер + 2 регистратора.

Все камеры вывести на отдельный коммутатор, туда же подключить NVR, от него L3-линк до офиса, чтобы удаленно на картинки смотреть. Все адреса прописать статически, без DHCP.

2. Рабочая сеть (20-30 компьютеров + принтеры+ 1С и т.д)

По коммутатору на этаж/отдел. DHCP только для пользовательских компьютеров. Использовать вланы.

3. Рабочая сеть wifi
4. Гостевая сеть wifi

По wi-fi не специалист, мой комментарий вряд ли будет полезен. Единственное, под wi-fi выделил бы отдельные префиксы ("подсети"), т.е. не использовал бы бриджинг, если в этом нет необходимости.

Стоит ли разворачивать dhcp на "железе" или воспользоваться win2012 для развертки dhcp?

Думаю, вполне логично использовать DHCP на устройстве, играющем роль маршрутизатора по умолчанию для клиента. Естественно, необходимо корректно назначить IP-префиксы ("подсети"). Целесообразность наличия отдельного DHCP-сервера под вопросом.

Также хотелось бы отметить пару моментов:
1) сетевое оборудование питать через ИБП.
2) отдельный сервер (возможно, виртуальный) под мониторинг всего (ИБП, сетевые устройства, состояние линков)
3) Рано или поздно один из пользовательских ПК создаст L2-петлю (через wi-fi и ethernet в случае бриджевого режима работы wifi; неправильное включение IP-телефона со встроенным коммутатором и т.д.). Необходимо это предусмотреть.

По поводу оборудования: непонятно, для чего нужны гигабитные линки в офисе. Возможно, потребуются гигабитные линки до серверов и NVR. Вместо новых D-link, если бюджет ограничен, я бы использовал б/у коммутаторы линеек catalyst 3560, 2960.

Спасибо, что "призвали" в топик, выражу свое мнение.

Вы привели ссылку

Вот еще одна карта habrahabr.ru/company/cjdns/blog/198428/.

Если честно, мне представляется, что эта ссылка не относится к вашей проблеме. Статья, доступная по ссылке, насколько понял, описывает некую одноранговую сеть на 3 выше уровнях модели OSI, грубо говоря, свой отдельный интернет, с отсутствием цензуры и криптоанархизмом. Вам, теоретически, могла бы пригодиться одноранговая сеть на уровнях 1-2 модели OSI, то есть сеть из Wi-Fi-трансиверов, предоставляющая обычную IP-связность и доступ в интернет.

Однако, в вашем случае, при наличии соответствующей возможности, я бы выбрал кабельные решения (волокно до дома) и лишь в каких-то особых случаях использовал Wi-Fi. Беспроводные решения привносят довольно много потенциальных проблем, а в случае одноранговой (mesh) сети полезная пропускная способность будет делиться между абонентами, в результате итоговое преимущество такого подхода неясно.

он работает только с кадрами и не оперирует ip пакетами?

Любая модель в определенных условиях неверна, любая абстракция имеет "дыры", сквозь которые проглядывает реальность, данная в ощущениях. Это утверждение - пример такой модели.

По вашему вопросу, никто не в состоянии запретить коммутатору анализировать полезную нагрузку (payload) фрейма, которой зачастую и является IP-пакет.

Можете scapy попробовать, но магии ожидать не стоит. И уточните решаемую задачу.

который жалуется на потерю пакетов

Что это значит? Какие именно пакеты теряются, в чем это проявляется?

Как я понял, адрес 81.22.218.1 использует маршрутизатор. Не надо ожидать от маршрутизатора ответа на 100% "пингов" (icmp- или udp- пакетов). У маршрутизатора может быть активна специальная фильтрация (control plane protection policy в cisco-мире), в некоторых случаях неотключаемая.

Строители завели в кабинет один кабель. А нужно работать на двух ПК.

Поставьте коммутатор.

То, чем вы занимаетесь - интересно, остроумно, нестандартно, неподдерживаемо и обязательно в будущем аукнется вам или вашему "наследнику".

Но у меня не получилось получить нужный OIDы для VLAN в Cisco 3750-2

Попробуйте воспользоваться утилитой snmpwalk с OID 1.3.6.1.2.1.2.2.1.2. Если правильно помню, вы должны получить список имен интерфейсов, поищите там свои VLAN.

Если говорить в общем, то решение вашей задачи очень сильно зависит от аппаратной специфики. Есть подозрение, что в соответствующих счетчиках 3750 учитывается только трафик на L3-интерфейс, относящийся к VLAN, а коммутируемый при помощи ASIC трафик не учитывается.

Одного 100мбит кабеля на всех мало, гигабит стоит в 10 раз дороже (без преувеличений, тут монополия у провайдера) и получается так, что оба нужно задействовать.

Не понял, почему нельзя иметь подключение гигабитным портом с ограничением полосы до 200 мбит/с, например. Или они только за порт без полосы в 10 раз больше требуют?

Схема с NAT (практический всегда - двойным) внутри локальной сети представляется яркой, неординарной, трудноподдерживаемой, излишне усложненной.

и на каждом дочернем маршрутизаторе выключить NAT

Да, если маршрутизаторы уровня офисных-домашних (TP-LINK и прочая), то настроить статическую маршрутизацию.

UPD:

1. За сам по себе гигабит в месяц просят в 10 раз больше. Компания столько тратить не хочет.

Я опять не понял, извините. Только за гигабитный порт (с той же полосой 100 мбит/c) просят в десять раз больше? Уточните на всякий случай у провайдера, может, вам дадут 150-200 мбит/c через гигабитный порт за вменяемые деньги.

2. На счет схемы с НАТом - я с вами согласен и с удовольствием выслушаю предложения.

Поддерживаю предложения, высказанные MrJeos . Разве что я бы DHCP оставил только в офисах, а сами офисные маршрутизаторы адресовал статически. По поводу mikrotik тоже поддерживаю, у них появилась весьма доступная модель (hAP lite). Еще посоветовал бы перед подключением второго канала проанализировать текущее потребление. Возможно, достаточно будет просто перераспределить полосу, применив shaping/policing.

3. Да - что? Будет работать такая сеть при учете цитаты про выключенный нат?

Да, будет, после внятной настройки адресации, статической или динамической маршрутизации. Но будьте готовы к тому, что задействовать одновременно два канала доступа в интернет - задача довольно трудная в плане балансировки. У вас вполне может получиться так, что сейчас все работает, а через час потребитель утилизировал львиную долю канала, повлияв на "качество интернета" своих соседей по каналу, и в то же время соседний канал практически не загружен. Это необходимо учитывать.

Вы можете это реализовать при помощи маршрутизации (у всех ПК шлюзом по умолчанию установлен ваш "шлюз", на "шлюзе" - раздающий сервер)

Или можно реализовать схему "router on a stick". Потребуется поддержка port-based VLAN и тэгирования 802.1q на "шлюзе" и коммутаторе. В данном случае у ПК в локальной сети не будет доступа к серверу напрямую.

Также возможны "нестандартные решения" с подменой ARP, но это на любителя.

Может есть какие приспособления для агрегации каналов (2 гбит/с должно хватить с головой)? Или стоит подумать о 10 гбитном линке, но что тогда использовать?

Если есть возможность один гигабитный линк заменить на десятигигабитный линк, то я за этот вариант (см. карточки Intel X540, может кто-то что получше посоветует). Собирая линк из двух (etherchannel, nic teaming, а по сути equal cost multipath), вы, как правило, не ускорите производительность (throughput) одной tcp-сессии (или udp flow).

Но пинг на адрес 127.252 который находится в одной подсети с 127.2/24 не идет.

Почему вы полагаете, что этот хост должен отвечать на пинги?
Кому принадлежит этот адрес (сервер, маршрутизатор)? В любом случае, проверьте на пути следования трафика аксесс-листы (firewall filter), проверьте фильтрацию на фаерволлах, проверьте доступность проблемного хоста по другим протоколам (присылает ли он TCP RST, например, в ответ на TCP SYN), проверьте также его доступность с ближайшего к нему устройства.

Я так и не понял в чем проблема. Если есть какие то советы подскажите

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

Что я делаю я неправильно?

Вам подают фреймы из двух вланов, наверняка тэгированные, а вы пытаетесь их принимать портом в режиме доступа.

Попробуйте так (синтаксис, вероятно, надо будет немного изменить):

Int gi4
switchport mode trunk
switchport trunk allowed vlan add 2045, 2075