Jump to content
Калькуляторы

Сегментация VLAN управления

Есть глобальный (на всю сеть) VLAN 100, который терминируется на ядре и в котором заведены mgmt-интерфейсы разных железок.

Количество железок уже приличное, подумываю о том, чтобы сеть управления сегментировать.

Но при этом у меня сейчас есть значительное удобство в однотипности настроек. То есть любую железку я могу перенести в любое место сети и она будет доступна для управления без каких-либо настроек.

Есть два вопроса.

 

1. Есть 24-портовые коммутаторы агрегации. Терминировать управление думаю на них. Причем я бы хотел сегментировать каждый порт агрегации. Как это можно сделать?

Можно, конечно, завести 24 VLAN (со 101 по 124), которые и терминировать; в каждом порту агрегации будет соответствующий VLAN управления. Но тогда про переносимость можно забыть, на каждой железке нужно будет прописывать VLAN, соответствующий месту, в которое она предназначена.

А можно ли это сделать на одном VLAN? Скажем, по прежнему везде будет прописан VLAN 100, но терминироваться он будет не на vlan-interface, а, так сказать, на vlan-port-interface (с учетом того, что на порту ходит тэгированный трафик). Или я хочу невозможного?

 

2. Допустим п.1 будет решен (либо я откажусь от сегментирования на портах). Но тогда возникает еще и проблема IP-адресации. Я, опять таки, не хочу прописывать IP-адрес под место, в которое будет устанавливаться железка (т.к. железка может переноситься). И не очень хочу переходить на DHCP, т.к. а) не все железки имеют dhcp-client для управления и б) могут глючить, это не так надежно, как статика.

Решением было бы автоматическое создание маршрутов /32 на каждую железку. Но это довольно простые железки, они как правило динамическую маршрутизацию не поддерживают (даже RIP).

Я опять хочу невозможного или это можно решить?

Share this post


Link to post
Share on other sites

1. А зачем из крайности в крайность? Или один влан на всю сеть или влан на каждый порт. Сделайте логическое деление по районам и дайте туда разные вланы управления.

2. Super-vlan \ ip unnumbered arp-poll.

Share this post


Link to post
Share on other sites

Вообще нужно отказаться от влана управления. Если весь абонентский трафик и так идет уже во влане, то зачем дополнительно городить влан для управления, когда можно управлять и без него - абоненты туда все равно не попадут=)

 

Поэтому разделяйте сеть на сегменты, в каждый выдавайте свою уникальную подсеть. Если вдруг одну железку перенесли из другого сегмента, просто временно переносите нужный IP адрес в ту сторону и изменяете адрес на тот, который используется в этом сегменте, после чего возвращаете адресацию в прежний вид.

 

Например:

 

Сегмент 1 - 10.0.1.1/24

Сегмент 2 - 10.0.2.1/24

Сегмент 3 - 10.0.3.1/24

 

Допустим перенесли железку из 3 в 1, на сегмент 1 ставите адрес 10.0.3.1/24 а с 3-го сегмента его временно выключаете.

Share this post


Link to post
Share on other sites

ip unnumbered без proxy-arp + traffic segmentation, и можно спать спокойно.

Вообще нужно отказаться от влана управления.

0fb123a43745.jpg

Share this post


Link to post
Share on other sites

2. Super-vlan \ ip unnumbered arp-poll.

А можно пояснить второй пункт?

Помоему он для обратной задачи предназначен.

Он позволяет приземлять разные VLAN на одном IP-интерфейсе. А мне скорее нужно приземлять одинаковые VLAN (с разных портов) на разных IP-интерфейсах.

Или я не так совет понял?

 

Вообще нужно отказаться от влана управления.

Я может быть не все знаю по сетям, но я же не идиот.

Зачем так толсто троллить?

Share this post


Link to post
Share on other sites

2. Super-vlan \ ip unnumbered arp-poll.

А можно пояснить второй пункт?

Помоему он для обратной задачи предназначен.

Он позволяет приземлять разные VLAN на одном IP-интерфейсе. А мне скорее нужно приземлять одинаковые VLAN (с разных портов) на разных IP-интерфейсах.

Или я не так совет понял?

 

То есть, Вам нужен таки не один шлюз для железок, а несколько? Почему бы не сделать один + ip unnumbered?

 

Допустим перенесли железку из 3 в 1, на сегмент 1 ставите адрес 10.0.3.1/24 а с 3-го сегмента его временно выключаете.

Жесть, вообще. Или я не так совет понял?

Share this post


Link to post
Share on other sites

То есть, Вам нужен таки не один шлюз для железок, а несколько? Почему бы не сделать один + ip unnumbered?

Несколько не нужно, нужно изолировать сегменты по L2 (при том, что mgmt vlan у них одинаковый).

Может быть предложенное решение и подойдет, надо будет проверить.

Share this post


Link to post
Share on other sites

Несколько не нужно, нужно изолировать сегменты по L2 (при том, что mgmt vlan у них одинаковый).

Может быть предложенное решение и подойдет, надо будет проверить.

А цели то какие? Чего хотите добиться и/или от чего хотите избавиться с помощью сегментирования то?

Что поддерживают ваши коммутаторы агрегации что можно использовать для достижения ваших целей?

Share this post


Link to post
Share on other sites

Прямо сейчас необходимости особой нет, это скорее подстраховка.

Чтобы в случае флуда/шторма/глюков в сети проблемы за пределы сегмента не вылезали.

А то пару раз бывали случаи, как после грозы DES-3200 на всю сеть спамил.

На агрегации QTECH 3900 и SNR-S3750, SNR вроде бы ip unnumbered умеют, QTECH умеет PVLAN.

Share this post


Link to post
Share on other sites

Вообще нужно отказаться от влана управления.

*Картинка с фейспалмом.

Советую тебе отказаться от подобных советов.

Share this post


Link to post
Share on other sites

Вообще нужно отказаться от влана управления. Если весь абонентский трафик и так идет уже во влане, то зачем дополнительно городить влан для управления, когда можно управлять и без него - абоненты туда все равно не попадут=)

А если я буду флудить арпом на вайрспиде? Насколько быстро скукожится железка и все плюшки, если они софтовые?

Edited by pppoetest

Share this post


Link to post
Share on other sites

Прямо сейчас необходимости особой нет, это скорее подстраховка.

Чтобы в случае флуда/шторма/глюков в сети проблемы за пределы сегмента не вылезали.

А то пару раз бывали случаи, как после грозы DES-3200 на всю сеть спамил.

На агрегации QTECH 3900 и SNR-S3750, SNR вроде бы ip unnumbered умеют, QTECH умеет PVLAN.

Тут как бы зависит от того на каком уровне сегментировать хотите.

Если используются кольца и STP то, на мой взгляд, нужно использовать разные вланы для каждого кольца и настраивать MST. Если кольца в пределах одного агрегатора и вланы управления по L3 приземляются на агрегаторах то на разных агрегирующих коммутаторах управляющие вланы могут повторяться но с разными ip подсетями. Ну и т.д. и т.п. .

Как то так.

А "вроде бы" и "умеет" обычно не достаточно. Сколько ip интерфейсов поддерживают коммутаторы? Я к тому что возможности существующего оборудования могут не позволить вам реализовать все хотелки.

Share this post


Link to post
Share on other sites

Если используются кольца и STP то, на мой взгляд, нужно использовать разные вланы для каждого кольца и настраивать MST.

Колец нет и не будет.

Используется звезда, есть гирлянды, но постепенно ликвидируются.

 

Сколько ip интерфейсов поддерживают коммутаторы?

255 интерфейсов, 32к маршрутов.

Это все-же L3-коммутаторы, для моей задачи их возможностей должно хватить с избытком.

Share this post


Link to post
Share on other sites

Есть глобальный (на всю сеть) VLAN 100, который терминируется на ядре и в котором заведены mgmt-интерфейсы разных железок.

В ядре вешаете ingress и egress acl с разрешенными MAC-ом сервера управления ну и еще какие вам там нужны. А в агрегации и доступе вешаете сегментацию. Это, кстати, работает достаточно эффективно не только для VLAN управления, но и для VLAN доступа.

Share this post


Link to post
Share on other sites

Вообще нужно отказаться от влана управления.

Я может быть не все знаю по сетям, но я же не идиот.

Зачем так толсто троллить?

 

Попробуйте объяснить все же, для чего нужно управление в 100, 1001 и т.п. вланах, когда можно его гонять просто так?

 

Допустим перенесли железку из 3 в 1, на сегмент 1 ставите адрес 10.0.3.1/24 а с 3-го сегмента его временно выключаете.

Жесть, вообще. Или я не так совет понял?

 

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

 

Вообще нужно отказаться от влана управления.

*Картинка с фейспалмом.

Советую тебе отказаться от подобных советов.

 

Могу предположить что вы еще представитель "старой закалки" =)

 

Вообще нужно отказаться от влана управления. Если весь абонентский трафик и так идет уже во влане, то зачем дополнительно городить влан для управления, когда можно управлять и без него - абоненты туда все равно не попадут=)

А если я буду флудить арпом на вайрспиде? Насколько быстро скукожится железка и все плюшки, если они софтовые?

 

А если все будут в одном влане управления, не скукожится? Вы можете на мегакрутой железке в центре создать 3 влана управления с разными или одинаковыми номерами, и раскидать их по разным частям сети, на каждый повесите свой уникальный адрес подсети.

Share this post


Link to post
Share on other sites

Могу предположить что вы еще представитель "старой закалки" =)

В данном случае это звучит как комплимент.

Да, я старой закалки, да я немного понимаю в безопасности и много понимаю в архитектуре сетей.

Посему предложение "отказаться от влана управления" звучит как адов бред.

 

А если все будут в одном влане управления, не скукожится?

 

А с чего бы оно "скукожилось"?

Для влана управления очень легко применяются отдельные политики роутинга и фильтрации.

Share this post


Link to post
Share on other sites

В данном случае это звучит как комплимент.

Да, я старой закалки, да я немного понимаю в безопасности и много понимаю в архитектуре сетей.

Посему предложение "отказаться от влана управления" звучит как адов бред.

 

Раньше сети строили на коммутаторах, изначально все были не управляемые, потом стали появляться L2, но стоили больших денег, постепенно стоимость снижалась и все перешли на их поголовное использование. При этом их возможности заключались лишь в том, что могли добавлять данные во вланы, тем самым изолируя абонентов друг от друга. Если бы управляемые коммутаторы L3 стоили так же дешево, то везде ставили бы их, и часть функций переложили на 3 уровень.

 

Поэтому мне вообще не понятно, зачем управление выносить в отдельный влан? Какой смысл всей этой затеи, кроме проблем? Почему нельзя производить управление просто по порту (во влане 1 как его еще используют в терминологии коммутаторов), ведь если весь абонентский трафик ходит по своим вланам, то упаковка служебного так же во влан вообще абсурдна.

 

 

А с чего бы оно "скукожилось"?

Для влана управления очень легко применяются отдельные политики роутинга и фильтрации.

 

Что мешает применять эти же политики без влана, или по влану номер 1?

Share this post


Link to post
Share on other sites

Что мешает применять эти же политики без влана, или по влану номер 1?

Тебе списком?

Ты разницу междуй л2 и л3 вообще понимаешь?

Share this post


Link to post
Share on other sites

Здравый смысл в этом есть.

Можно использовать для влана управления нетегированный влан.

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

Плюсы данной схемы - можно установить любой коммутатор в любом месте, хоть из коробки и спокойно его настроить.

 

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

Вуаля - получаем несколько вланов управления.

На конечных железках это будут просто дефолтные вланы без тега. Железки можно переносить как угодно и куда угодно,доступ к ним будет, в том числе доступ и из коробки.

Трафик абонентов пойдет в других вланах, уже с тегом и в влан управления он попасть не должен.

 

P.S. А много у вас железок? У нас в одном влане управления живут около 1000 коммутаторов доступа и ничего. Это же коммутаторы, а не клиенты, флуда от них нету.

Share this post


Link to post
Share on other sites

Можно использовать для влана управления нетегированный влан.

Нельзя.

Однажды от скачка напряжения коммутатор глюкнул, сбросил все настройки и превратился в хаб.

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

А использовал бы я для управления нетегированный трафик, то все абоненты бы попали в него.

 

Это же коммутаторы, а не клиенты, флуда от них нету.

Флуда нет, пока от грозы или скачка напряжения не глюкнет.

Или пока не выявится ошибка в конфигурации, пропускающая флуд.

Share this post


Link to post
Share on other sites

Можно использовать для влана управления нетегированный влан.

Нельзя.

Однажды от скачка напряжения коммутатор глюкнул, сбросил все настройки и превратился в хаб.

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

А использовал бы я для управления нетегированный трафик, то все абоненты бы попали в него.

 

Это же коммутаторы, а не клиенты, флуда от них нету.

Флуда нет, пока от грозы или скачка напряжения не глюкнет.

Или пока не выявится ошибка в конфигурации, пропускающая флуд.

Это удобно, свитч настраивать просто - скормил ему по ДХЦП адрес и слил на него прошивку + автогенеренный конфиг.

Для небольших сетей это по-моему вполне допустимо.

Но это не отменяет того что это все таки отдельный влан.

 

В моей практике "охабливания" свитчей не было пока пока что.

 

Отказаться от влана управления - не понял если честно, это что ли в клиентский влан вешать управление свитчем? или Л3 на дом (можно и так но гимморойно же)

Share this post


Link to post
Share on other sites
Однажды от скачка напряжения коммутатор глюкнул, сбросил все настройки и превратился в хаб.

Вот никогда такого не было.

Умирать - умирают, а конфиги еще не разу не сбрасывали.

 

Ну допустим такое случилось. Десяток абонентов попали в влан управления. И что? Шанс того что эти абоненты сразу начнут гадить и кольцевать близка к нулю.

А еще через час туда доберутся ремонтники и поменяют свич.

Share this post


Link to post
Share on other sites

Умирать - умирают, а конфиги еще не разу не сбрасывали.

У меня было дважды.

 

И что?

Например то, что большинство железок управляется по telnet, и логин/пароль передается открытым текстом.

Share this post


Link to post
Share on other sites

Вообще нужно отказаться от влана управления.

Я вот эту фразу вообще понять не могу. Как можно избавиться от VLAN управления, если вы в любом случае создаете абонентские VLAN. Он ведь в любом случае будет. Возможно имеется ввиду, что VLAN упралвения вы хотите сделать нетегированным, но он ведь все равно будет. Отказаться от него не получится.

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

Share this post


Link to post
Share on other sites

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

Элегантно, ничего не скажешь.

Сбросить коммутатор на старом месте в дефолт, поставить в новое и залить новый конфиг в чистую память,- такой вариант теперь кажется мне не таким уж и танго с бубном. В сравнении с тем, что Вы предлагаете. Вопрос: всякий раз, когда переносите шлюз в другой управляющий влан с целью перенастроить один единственный коммутатор, 200+ коммутаторов в предыдущем сохраняют связность с шлюзом, учитывая, что сетка в каждом влане - /24?

 

Поэтому мне вообще не понятно, зачем управление выносить в отдельный влан? Какой смысл всей этой затеи, кроме проблем? Почему нельзя производить управление просто по порту (во влане 1 как его еще используют в терминологии коммутаторов), ведь если весь абонентский трафик ходит по своим вланам, то упаковка служебного так же во влан вообще абсурдна.

Можно использовать для влана управления нетегированный влан.

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

Плюсы данной схемы - можно установить любой коммутатор в любом месте, хоть из коробки и спокойно его настроить.

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

использовал бы я для управления нетегированный трафик, то все абоненты бы попали в него
Флуда нет, пока от грозы или скачка напряжения не глюкнет.

То есть, оно в теории можно, но на идеальной сети. Поверьте, нет никакой нужды оставлять дефолтный влан access-ом на портах, которые должны быть trunk. Случись что в этом влане, все коммутаторы пропадут из вида системы мониторинга и техучета (если она есть) и будет паника. А потом искать, какой дебил неисправную мыльницу/медик воткнул и где именно (например)? А бывают ещё и не такие курьёзы.

 

скормил ему по ДХЦП адрес и слил на него прошивку + автогенеренный конфиг

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this