Философия назначения VLAN

10

У меня есть несколько коммутаторов / маршрутизаторов уровня 3, которые все подключены через сеть с маршрутизацией OSPF. Также к каждому коммутатору подключены две другие сети. Я должен назначить VLAN каждой из этих сетей, и я полагаю, что могу просто повторно использовать одни и те же две VLANS на каждом коммутаторе, поскольку весь трафик, выходящий из коммутатора, не маркирован (так как он маршрутизируется, а не по транку VLAN) - есть ли почему я не должен делать это и дать каждой сети разные VLAN? Например:

пример

vlan design

— Raggles
источник

1

Проблемы: а) фактор путаницы, б) беспорядок, возникающий, когда одно из этих звеньев становится магистралью уровня 2. (и это прежде всего интерфейсы уровня 2, если вы их не сделали no switchport)

— Рикки Бим

Кроме того, если все коммутаторы являются Cisco и работают CDP, то это потребует, чтобы даже у непомеченных портов были соответствующие vlans на обоих концах. (хромает, но это будет)

— Рикки Бим

Замечания @ricky отмечены спасибо, однако здесь нет cisco, интерфейсы ospf никогда не будут транками (и они есть no switchport), поскольку они представляют собой географически разнообразные сайты, соединенные через радиооборудование, которое не заботится о vlans.

— Raggles

10

Можно повторно использовать VLAN в сегментах, которые никогда не встретятся на уровне 2.

— bahamat
источник

9

Существует причина: повторное использование идентификаторов VLAN может привести к путанице, особенно в 3 часа утра, когда вы звоните по телефону и должны устранить неисправность.

— Дженс Линк

4

У вас есть более 4000 доступных идентификаторов VLAN. Я спрашиваю вас, есть ли причина, по которой вы должны использовать его повторно? Как сказал @JensLink, вам нужна ясность при устранении неполадок, и повторное использование VLAN ID поможет вам.

— KorXo

2

Я думаю, что это, вероятно, самый подходящий ответ для этой ситуации. Сети никогда не встретятся на уровне 2, и вполне возможно, что через 10 лет у нас будет несколько сотен таких сайтов, что делает перегрузку vlan потенциальной проблемой. Видя, что только один или два человека ответственны за эту путаницу в сети, она должна быть минимальной (и если она сломается в 3 часа ночи, она может подождать до завтрака, пока все не исправится - никаких раздражающих клиентов здесь)

— Raggles

5

Наличие одинаковых идентификаторов vlan на нескольких сайтах с разными IP-подсетями и маршрутизируемыми связями, безусловно, не редкость. И в 3 часа ночи, он также может предотвратить некоторую путаницу , чтобы знать , что ВЛС 15 Ваш принтер ВЛС, независимо переключаться в любое место , вы смотрите ...

— Gerben

@Gerben имеет важное замечание: одно из основных применений vlan - разделять вещи по соображениям безопасности (или пропускной способности), поэтому очень помогает наличие одной и той же VLAN # для одного и того же типа «контента». Таким образом, вы используете эту VLAN # везде, где встречаются одинаковые «учетные данные контента / безопасности» на любом сайте. Таким образом, повторное использование в данном случае помогает убедиться, что они находятся в «правильной» VLAN, и, на мой взгляд, менее запутанно, чем изменение именования VLAN на каждом сайте. Но это не может быть ситуация ОП

— Оливье Дюлак

8

Нет существенных причин использовать разные vlan в вашей ситуации, но некоторые производители (по крайней мере, cisco) рекомендуют использовать этот способ:

например, у нас есть N ветвей, и нам нужно по четыре маршрутизируемых широковещательных домена (LAN) в каждом, давайте их посчитаем:

ответвление 1 = 1 ответвление 2 = 2 ... ответвление N = N

Worstations - IP: 10.N.0.0 / 24, VLAN 100 + N
серверы - 10.N.64.0 / 24, vlan 200 + N
голос - 10.N.128.0 / 24, vlan 300 + N
мгмт - 10.N.192.0 / 24, vlan 400 + N

для сетей с туннельным интерфейсом (как мы) обычно используем сеть 172.16.0.0 с тем же правилом: 172.16.N.0 / 30 - левая сторона кольца (или главная линия вверх) 172.16.N.5 - правая сторона кольцо (или резервный канал связи)

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

Имхо, это хороший способ, потому что вы всегда в одном взгляде знаете, какую сеть филиалов, какой филиал vlan и какой туннель вы ищете.

— pyatka
источник

4

Вот еще один шаг в обратном направлении - причина для повторного использования номеров VLAN, поскольку вы можете. У меня была ситуация, когда я работал с некоторыми некачественными IP-телефонами, которые загружали свою конфигурацию с сервера TFTP, а не из параметров DHCP. Я хотел иметь возможность взять телефон в любом месте и подключиться к любому другому без перенастройки, и телефоны требовали статической настройки IP-адреса и имени файла конфигурации TFTP на телефоне. В файле конфигурации должен быть указан номер VLAN с тегами, к которому должны перейти телефоны.

Итак, чтобы эти ужасные телефоны работали так, как я хотел, мне нужно было сделать так, чтобы голосовая сеть VLAN имела одинаковый номер VLAN в каждом месте. Конечно, я мог бы настроить несколько разных TFTP-серверов и / или конфигурационных файлов, запрограммировать каждый телефон отдельно и перепрограммировать их каждый раз, когда телефон перемещался. Я просто хотел отметить, что может быть много других ситуаций, когда повторное использование номеров VLAN поможет вам решить другую проблему.

— Тодд уилкокс
источник

2

Если, как говорится в комментарии ОП, это географически разные сайты, то повторное использование номеров VLAN действительно имеет смысл. Согласованная схема нумерации VLAN для каждого узла поможет в устранении неполадок и внесении изменений. Тот, кто едет на сайт, чтобы починить или изменить что-то, узнает, например, что VLAN 10 - это всегда данные, а VLAN 11 - это всегда VoIP.

— Рон Мопин

Ваш комментарий должен был согласиться с моим ответом? Тон звучит как несогласие, но содержание в согласии. В то время, когда я писал этот ответ, в большинстве комментариев говорилось, что НЕ следует повторно использовать номера VLAN, и мой ответ должен был привести аргументы в пользу их повторного использования в некоторых ситуациях.

— Тодд Уилкокс

Нет разногласий, нет определенного тона. Я полностью согласен с тем, что вы говорите. Я лишь хотел подчеркнуть в вашем ответе, что вы можете создать согласованную схему для каждого сайта (данные, VoIP и т. Д.) Для отдельных сайтов. Без обид.

— Рон Мопин

О, я не обижался. Я получил отрицательный ответ по этому ответу примерно в то же время, что и ваш комментарий, и не был уверен, был ли он связан с вашим комментарием, а поскольку другие ответы и комментарии изменились за последние шесть месяцев, фраза «альтернативный вариант» читается по-разному. сейчас и может сбить с толку.

— Тодд Уилкокс

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

— Рон Мопин

3

В этом нет ничего технологически неправильного, но это не идеально. С точки зрения дизайна, он подвержен проблемам в будущем. Комментарий Jens Линка является очень точным; Если у вас есть проблема, это усугубит проблему и сложность попытки выяснить, что не так. Это будет еще более усугубляться во время интенсивных, масштабных отключений.

Хотя вы не упоминали о росте сети в своем OP, разумно предположить, что вы в конечном итоге развернете коммутатор ниже по потоку от одного из ваших основных маршрутизаторов. Когда у вас есть совпадающие VLAN-идентификаторы в соседних областях, это исключает возможность (ну, это делает его PITA) двухконтурных подключений к нескольким вышестоящим маршрутизаторам. Возможно, вы не прогнозируете это сейчас, но лучше подготовить условия для будущего успеха, когда это вариант, а не необходимость.

— Райан Фоли
источник