Наша сеть плоская L2.
В какой-то момент нам нужно (я хочу, но это не является строго моей обязанностью) начать VLAN, поскольку у нас, очевидно, будет происходить много разговоров, и недавно один из наших брандмауэров достиг своей таблицы arp. предел (возможно, брандмауэр имеет низкий предел таблицы ARP, но мы находимся там, где мы с этим).
Итак, как вы придумаете методологию для VLAN вниз вашей локальной сети?
В нашем случае мы являемся одним сайтом, но размером с небольшой город (думаю, кампус, я думаю).
У нас есть довольно типичная локальная сеть со спицами и парой основных коммутаторов, к которым граничные коммутаторы подключаются, некоторые напрямую, некоторые через оптоволоконные и медные преобразователи.
Наш крайний набор представляет собой смесь Procurve's, Prosafes, некоторых старых Baystacks и т. Д.
Большинство наших клиентов используют DHCP, некоторые используют статические IP-адреса, но мы могли бы справиться с ними, сетевые принтеры также используют статические IP-адреса.
Насколько я понимаю, существует множество вариантов VLAN в зависимости от физического местоположения в кампусе, т. Е. Любые пограничные коммутаторы в зданиях A и B используют VLAN xx, или это может быть обусловлено другими факторами.
Проще говоря, я не делал этого раньше, и легко погружаться и делать вещи быстро, а потом сожалеть об этом.
Как бы вы пошли об этом, пожалуйста?
источник
Способ, описанный @minarnhere, - это абсолютно верный путь, а не просто разделить его по функциональности, добавить факторы безопасности, физическое расположение и количество хостов, а также разделить вашу сеть на столько VLAN, сколько требуется на основе всех этих факторов.
При условии наличия соответствующих коммутаторов и маршрутизаторов наличие множества VLAN не требует затрат, и преимущества огромны, если все спланировано правильно, накладные расходы администратора также минимальны. Не ограничивайте себя искусственными ограничениями в отношении помещения всех студентов или преподавателей или любой группы пользователей или хостов в одну VLAN. Почему вы все равно хотите это делать? Помните, что трафик может контролироваться только на уровне 3, поэтому разделите вашу сеть, чтобы вы могли ограничивать и контролировать трафик между VLAN, у вас нет шансов с трафиком внутри VLAN.
Классический способ проектирования локальной сети кампуса состоит в том, чтобы разделить сеть на Access, Distribution и Core. Многие коммутаторы уровня 2 доступа, каждый из которых переносит трафик из одной или нескольких VLAN, будут подключаться к нескольким коммутаторам уровня 3, которые направляют трафик на небольшое количество основных коммутаторов уровня 3.
Все ваши хосты должны быть подключены к уровню доступа, который разделен на VLAN на основе факторов, описанных выше. Каждая VLAN уровня доступа должна, где это возможно, быть ограничена одним физическим коммутатором (это правило необходимо нарушать, только если у вас есть серверы с двумя домами, которым может потребоваться переключение на другой коммутатор в той же VLAN). Помните, что каждая VLAN является широковещательным доменом, и вы хотите максимально ограничить широковещательный трафик для каждого из них. Подумайте об использовании только / 24 подсетей для вашего уровня доступа, зачем вам> 250 хостов в одном широковещательном домене?
Там будут какие-то, очень, очень мало, обстоятельства, когда VLAN необходимо распространение на несколько коммутаторов, но это будет очень, специалист управления коммутатором может быть один (но это спорно), существует очень мало других.
Хорошей отправной точкой будут ваши серверы. Если они находятся в одном и том же физическом месте (комната, а не здание), то вы можете разделить их на VLAN на основе функциональности, но в противном случае будет достаточно одной VLAN на ~ 200 хостов. Очевидно (?) Серверы, обращенные к Интернету, должны быть сами по себе, желательно физически отделены, сетью, защищенной от кампуса (разработка DMZ сама по себе является другой специализацией, поэтому я не буду вдаваться в подробности). Внутренние серверы также должны быть разделены на серверы, предназначенные для использования студентами, и серверы, предназначенные только для внутреннего администрирования, и соответствующим образом разделить их на VLAN. Если некоторые серверы принадлежат определенным отделам (например, HR), тогда, если вам может понадобиться контролировать трафик к этим серверам, рассмотрите возможность использования VLAN только для них.
Если серверы распределены, то поместите их в отдельные VLAN в зависимости от местоположения и функциональности, поэтому им не нужно находиться в одной VLAN просто «потому что они являются серверами» или просто «потому что они все веб-серверы».
Переходя к вашим студентам и сотрудникам. Для начала каждый отдельный порт или точка доступа, которая доступна или может быть доступна не ИТ-специалистам, должна рассматриваться как угроза безопасности, и весь трафик, исходящий оттуда, должен рассматриваться как ненадежный. Поместите ваши классы в VLAN на основе возможного количества хостов и, в зависимости от обстоятельств, групп пользователей, но не делайте ошибку, доверяя определенным портам, если преподаватели должны получить доступ к вашей сети администратора из класса, тогда им следует дать тот же метод доступа (VPN?), как если бы они были дома или в общественной кофейне.
Беспроводная сеть должна находиться на отдельных VLAN от проводных, но с теми же ограничениями, если этого можно избежать (но иногда это невозможно), не помещайте все точки доступа в VLAN, охватывающую весь кампус, разделите их, используя ту же методологию и по той же причине, что и проводная.
IP-телефоны должны, как ни удивительно, удивлять, находиться в разных VLAN-сетях от всего остального, это облегчается на некоторых моделях (в моем опыте Cisco) тем, что телефон ведет переговоры с коммутатором доступа для передачи трафика в соответствующую VLAN, но для этого, очевидно, требуется, чтобы коммутатор быть настроенным правильно.
В дизайне ЛВС есть еще много всего, но вышесказанное - это начало. И, наконец, что касается DHCP, используйте его для каждого хоста, включая серверы и принтеры, у обоих из них должны быть статически назначенные IP-адреса на основе их MAC-адресов. Область (или области действия) для первых не должна иметь запасных адресов, это в некоторой степени предотвращает случайное подключение устройств к VLAN-серверам, но, и это также относится к принтерам, дело в том, что у вас есть централизованное управление устройствами и любые изменения рассматриваются централизованно, а не полагаться на инженеров, блуждающих по кампусу, чтобы получить правильные адреса.
Хорошо, пока достаточно, надеюсь, это немного поможет.
источник
Как отметил Крис С. VLAN и подсети - это разные вещи. НО, мы просто назначили отдельную подсеть и область DHCP для каждой VLAN в кампусе нашей школы. Каждое здание имеет свою собственную область VLAN / Подсеть / DHCP. Это значительно упрощает управление, но может не сработать, если у вас более обширный кампус, чем у нас. Мы также используем отдельные VLAN для управления коммутаторами, физические серверы, VOIP-телефоны, беспроводные сети учеников, беспроводные классы, лаборатории учеников, виртуальные серверы, бизнес-офис, SAN, VPN. По сути, мы достаточно малы, чтобы любая возможная дифференциация получала свою собственную VLAN. (У нас всего до 25 сетей VLAN, и я начал создавать новые подразделения только потому, что хотел изолировать определенные группы от остальной части сети ...)
Создание отдельных подсетей для каждой VLAN может быть расточительным, но это упрощает управление и позволяет легко конвертировать IP -> VLAN в вашей голове, если вам когда-либо понадобится это сделать.
Мы используем 10.xxx для IP-адресов, поэтому VLAN1 получает 10.1.xx, VLAN8 получает 10.8.xx и т. Д. Каждая VLAN, которая нуждается в DHCP, получает свою собственную область, но мы не создаем области для VLAN, которые в них не нуждаются, например, Управление коммутатором.
источник