Недавно я сменил работу. К тому времени, как я ушел с последней работы, нашей сети было три года, и она была очень хорошо спланирована (по моему мнению). Наш диапазон адресов был разделен на несколько VLAN с самой большой подсетью в диапазоне /22. Это было как по учебнику.
Компания, в которой я сейчас работаю, создавала свою сеть около 20 лет. Она довольно большая, охватывает несколько сайтов и имеет эклектичную смесь устройств. Эта организация использует VLAN только для очень специфических вещей. Я знаю только об одном использовании VLAN на данный момент, и это SAN, которая также пересекает границу сайта.
Я не сетевой инженер, я технический специалист службы поддержки. Но иногда мне приходится делать трассировки сети для отладки проблем, и я поражаюсь количеству широковещательного трафика, который я вижу. Самая большая сеть — это прямая сеть класса B, поэтому она использует маску /16. Конечно, если бы она была заполнена устройствами, сеть, скорее всего, остановилась бы. Я думаю, что в настоящее время эту подсеть используют, вероятно, более 2000 физических и виртуальных устройств, но (в основном) это, похоже, работает. Такая практика, похоже, противоречит всему, чему меня учили.
Мой вопрос:
По вашему мнению и с моей точки зрения - Какое измерение какой метрики скажет мне, что слишком много широковещательного трафика скачет по сети? И какие явные признаки того, что вы, возможно, ступаете по тонкому льду?
Насколько я понимаю, добавляется все больше и больше устройств, и это может означать только больше трафика вещания, поэтому должен быть какой-то порог. Будет ли все становиться все медленнее и медленнее, или эффекты будут более тонкими?
решение1
Нет ничего изначально неправильного в большом широковещательном домене, если он правильно (и безопасно) настроен. Например, использование PVLAN может позволить создавать очень большие сети без особых проблем, поскольку изолированные хосты не видят трафик друг от друга. Аналогично, если сеть относительно статична, соединения очень стабильны и есть элементы управления для блокировки широковещательного/многоадресного/одноадресного флуда, то это можно заставить работать.
Тем не менее, чаще всего сети, которые вы описываете (2000+ хостов), по сути, являются кризисом, который только и ждет своего часа. Некоторые из проблем/предупреждающих знаков могут включать-
Избыточный широковещательный трафик — либо трафик приложений, который распространяется повсюду (например, как в старой школе Windows), либо избыточный трафик ARP и т. д. Подумайте об этом в терминах пакетов в секунду, а не абсолютной пропускной способности — сотни пакетов в секунду фонового трафика поднимаются там. Имейте в виду, что определенные сетевые события (включение или выключение коммутаторов) могут ужасно это усугубить.
Диаметр сети/топологическая стабильность — возникают ли временные петли связующего дерева при определенных условиях (например, перезагрузка устройства)? Какой объем TCN и т. д. вы видите? Двигается ли вообще корневой мост? Сколько коммутаторов физически соединены каскадом?
Как работают отказы связи? Что происходит, если связь падает? Я видел ситуации, когда все было настолько сильно сломано, что топология сети буквально никогда не стабилизировалась, когда выходил из строя резервный канал. Это требовало массовых перезагрузок — ну, точнее, это требовало полной переделки, но это уже отдельная тема.
Падения интерфейса на маршрутизаторах и коммутаторах? Проблемы с буфером? Это также могут быть подсказки.
В целом мосты, пересекающие физические сайты, вызывают непропорционально большое количество проблем. Есть ли веская причина, по которой ваши сайты (или этажи) не могут быть разбиты на маршрутизируемые подсети? Лучшей практикой, безусловно, является маршрутизация там, где это возможно, и мост там, где это невозможно...
решение2
1)
«По вашему мнению и с моей точки зрения»…мнениеи факты (на которых основан этот сайт) смешиваются довольно плохо.
2)
Да, с большим количеством трансляций все становится медленнее. Но с современными сетями (коммутаторы вместо концентраторов и гигабитные скорости) использование более чем полного /24 не должно быть проблемой. Даже /22 должно быть нормально.
Многое зависит от ваших приложений и протоколов. Например, я бы не боялся среднего офиса с сетевыми дисками и до 2000 компьютеров и принтеров.
2b) Cisco, похоже, с этим не согласна. :) Но опять же, Cisco учит, как работают сети классов A, B и C. Об этом следует думать только на уроках истории. А не на современных уроках управления сетями. :)
решение3
Недавно я присоединился к другой компании, где я вижу такую конфигурацию VLAN с большими подсетями, такими как /16 и /22, настроенными частично как DHCP и частично статическими. Также они использовали VLAN 1 и подсети, такие как 192.168.xx, в своей среде. Мы получаем некоторые медленные ответы от какого-то производственного подразделения, которое использует сторонние приложения. Я думаю, что большие широковещательные домены могут быть причиной задержек здесь.