Перейти к содержимому
Калькуляторы

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

Нельзя.

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

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

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

 

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

 

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

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

 

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

 

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

 

Отказаться от самого влана в понимании, например влан 100 и т.п. Когда можно делать все в дефолтном. Кроме всего можно на группах домов сводить управление через L3 железку, при этом сам трафик L2 пойдет по старой схеме. Тогда при возникновении проблем на сети, с маками например, управление у коммутаторов не пропадет.

 

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

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

 

Как я чуть выше писал, отказаться можно, переведя доступ в интерфейсы управления на уровень L3.

 

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

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

 

Если у вас монтажников пруд пруди то да, можно снять коммутатор, привезти его в центр, там сбросить и потом на новое место, но часто бывает, что нужно подключить новый дом, или поменять сгоревший коммутатор. Монтажники берут новый, ставят его на какой-то хороший дом в качестве апгрейда, а снятый оттуда везут на дом попроще, где со старым неполадка, при этом можно существенно экономить время. Кстати, вместо переноса всей сетки, можно по OSPF перекинуть только один адрес, при этом ничего из мониторинга не пропадет на время перенастройки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Вы меня совсем не читаете.

по сети прокидывается дефолтный влан до аплинк-порта... и после настройки интерфейса в управляющем влане int vlan 1 гасится

 

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

А ещё можно написать скрипт, перенастраивающий остальные коммутаторы на новый шлюз. На время перенастройки. Ну к чему такие костыли?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

И все это за пару часов, пока на точку едет саппорт.

Вы сами в это верите?

 

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

для этого не обязательно переносить шлюз.

Достаточно воткнуть во влан любой интерфейс любой железки. Это может быть сервер с линуксом на борту, или любой L3 коммутатор.

Поднимаем на нем интерфейс в нужном влане, вешаем IP и заходим по телнету прямо с железки.

 

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

В общем и целом согласен но:

1. Мыльницу никто не воткнет, ибо дефолтный влан в акцессе только на uplink/downlink портах. И никто туда попасть не должен.

2. Мониторинг он на тои существует, чтобы искать подобные вещи в том числе.

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

Я не утверждаю что это истина в последней инстанции, я просто предложил топикстартеру вариант.

 

Этот флуд может и во влане управления оказаться,

Кстати вот такое было пару раз.

Свич 3010G от длинка умер и начал флудить в влан управления.

Поэтому мы и от этого не застрахованы к сожалению.

Поэтому местами loopdetect включен и на магистральных downlink портах тоже.

 

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

У нас все коммутаторы для подобных случаев вынуты из коробочки, подписаны как backup, настроены с бекапным конфигом и лежат на полке.

Бекапный конфиг подразумевает уже настроенный влан управления.

Сдох где либо свич - берут бекап и едут (обычно парочка уже в машине лежит).

Поставили - отзвонили. ЗАлезаем на бекапный свич, заливаем нужный конфиг.Все.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Свич 3010G от длинка умер и начал флудить в влан управления

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да у нас их осталось всего пару десятков.

Кстати в общем на них не жалуемся. Не виснут, свое отработали.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

И что?

Вы хоть представляете как не легко перехватывать пароли находясь не между а где то далеко с краю?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Управление без тэга - это минимум небезопасно. Поставил в разрыв тупую железку и получил управление.

Знаешь топологию сети (бывший сотрудник), поснимал ip source guard'ы и прочее.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Управление без тэга - это минимум небезопасно. Поставил в разрыв тупую железку и получил управление. Знаешь топологию сети (бывший сотрудник), поснимал ip source guard'ы и прочее.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Управление без тэга - это минимум небезопасно. Поставил в разрыв тупую железку и получил управление. Знаешь топологию сети (бывший сотрудник), поснимал ip source guard'ы и прочее.

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

Тэг влана, раз уж на то пошло. Отдавать управление в native, а остальной трафик гнать с меткой - это несерьезно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А что у вас на агрегации стоит? Например, у Juniper есть "VLAN Translation" http://kb.juniper.net/InfoCenter/index?page=content&id=KB16755

т.е. на аксесе у вас будет везде 100й влан управления, а на агрегации он будет превращаться в другой, в зависимости от сегмента (порта на агрегации)

поищите что-то подобное у своего вендора,

В крайнем случае, запретите 100й ВЛАН на свичах агрегации, а на ближнем к ядру свиче доступа сделайте физическую петлю между 100м и нужным ВЛАНами, получится то же самое.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У нас клиенты имеют влан на дом, а управление - влан на район.

Еще правда есть отдальный влан на район под юриков и под pppoe (наследство).

И в каждом районе сейчас стоит Микротик 750, для тестов, нестандартных вопросов и т.д.

с него всегда можно "подцепить" перенесенную железку.

Еще есть отдельный влан на управление ядром.

Так безопаснее всего жить.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

И что?

Вы хоть представляете как не легко перехватывать пароли находясь не между а где то далеко с краю?

 

Если в одном l2 сегменте, то какие проблемы? Ведь именно такой сценарий рассматирвается в итоге нештатной ситуации? Юзер запускает под виндой Cain&Abel и после минимума телодвижений лицезреет пароли. А может уже есть и более юзер-френдли инструменты для перехвата с использованием arp-спуфинга.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Юзер запускает под виндой Cain&Abel и после минимума телодвижений лицезреет пароли.

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

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

А если не попал в момент и ушел в магазин за чаем - за это время приедут ребята, поменяют свич, и жди еще 5 лет желания насолить провайдеру.

 

Kein сможет, мы в него верим :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Юзер запускает под виндой Cain&Abel и после минимума телодвижений лицезреет пароли.

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

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

А если не попал в момент и ушел в магазин за чаем - за это время приедут ребята, поменяют свич, и жди еще 5 лет желания насолить провайдеру.

 

Kein сможет, мы в него верим :)

 

Было утверждение, что это сложно. Технически это не сложно. Если угодно, огранизационно, подловить момент, который вообще может никогда не наступить и все такое - вопрос другой.

 

Хотя вот вам вполне реалистичный сценарий. Сижу я дома, хабр какой-нибудь читаю. Бац - инет отвалился. Делаю простейшую диагностику, ну там пинг, arp -a, затем шарк запускаю, т.к. не понял нифига. Вижу прелюбопытные вещи летают в сегменте. Далее cain и пользуюсь моментом. Более того скажу, нечто подобное было в действительности. Не надо сидеть и ждать этого, просто попадется человек, который может быстро соорентироваться в ситуации. Это не так уж невероятно. Вот глюк со сбросом конфига - да, я такое видел только один раз.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну сможет и что дальше? Ради чего все это? Халявный интернетт? Думаю что люди с таким знаниями могут позволить себе 500 руб на интернет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну сможет и что дальше? Ради чего все это? Халявный интернетт? Думаю что люди с таким знаниями могут позволить себе 500 руб на интернет.

 

Могут. Но причина совершенно другая. Просто по приколу, лулзы, "тряхнуть стариной" да и вообще просто потому, что "провайдер лох, гы". Вобщем, ответ лежит в той же плоскости, почему вообще всякое деструктивное и асоциальное поведение бывает столь распространненым. Ну если угодно - детский сад, только жертвам от этого легче не бывает :) Как когда-то на очередной дурацкий взлом анонимусы, кем бы они ни были, сказали - мы сделали это просто потому что можем, а вы ничего не смогли нам противопоставить.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня в одном управляющем vlan было 900 железок. Настроил сегментацию на всех свичах, доступ , аггрегация, ядро. На ядре создал ACL , чтобы всю сеть было видно только с железки L3 и сервера мониторинга, в итоге на доступе маки клиентов + 3 мак из vlan1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Только вот железка в центре получается видит 900 маков? не много?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

если вашу железку пугает 900 маков, стоит задуматься, а не говно ли ваша железка.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

если вашу железку пугает 900 маков, стоит задуматься, а не говно ли ваша железка.

 

Микротик не пугает 900 маков, только это не правильно, нужно вообще все управление сегментировать и маршрутизировать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Так в центре железка-то все 900? При сегментации появляются локальные куски сети, в каждой своя подсеть, в ней свое управление. Таблица маршрутов на то и таблица, что бы раздуваться. А вот блокировать трафик по L2, придумывая костыли, это плохо. Достаточно одному устройству начать флудить, как ляжет все.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Достаточно одному устройству начать флудить, как ляжет все.

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

растянут свой первый влан по всей стране, а потом гонят на вендоров, что оборудование говно

Никто не говорит что расстягивать, а тем более первый влан, есть хорошо. Рисуешь какой-нибудь supervlan/ip-unnumber на какой-нибудь /22, цепляешь к этому делу какие-нибудь 4000-4094 вланы, прокидываешь до железок, сегментируешь, раскидываешь под сотню устройств в влан, и получаешь чистую управляющую сеть на 1к девайсов. При правильной сегментации, в случае появления флуда в управляющем влане, страдает только конечный девайс, и в худшем случае, девайс стоящий перед ним, и не больше. Паразитному/нежелательному трафику в этом влане банально неоткуда будет взяться, если конечно вы его не открываете в общую таблицу маршрутизации для абонов. Казалось бы, что камнем предткновения может стать знаменитая проблема с коллизиями хешей маков, но в случае оборота на девайсе в рамках сотки маков, проявление такой проблемы практически не замечено.

В идеале конечно супер, если в рамках коммутатора бегают только маки его же абонентских портов + 1 мак аплинка, но это не значит что все железки на сети вдруг должны стать L3 и заставлять тот же ospf (который к слову на лоукосте зачастую реализован через жопу, в том числе и на вашем любимом некротике) биться в конвульсиях после малейшего чиха куска сети. И как показывает практика, у L3 лоукоста, зачастую отсутствует какая-либо возможность защиты собственного цпу от нежелательного трафика абонентов - к примеру, владельцам некротиков еще не доводилось испытывать хитрожопых юзверей, пытающихся со спутника влить по всей емкости порта нежелательный мультикаст.

 

А маршрутизируемые связки p2p идеальны между крупными сегментами сети, тут спору нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Экий вы радикал, зачем ж от крайности к крайности?

Плюсую за то, что l3 на лоукасте это плохая идея :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.