[Butch3r]

У меня управление живет в отделом vrf'е

Воот, и сегментировать это дело смысла 0.

мы у себя сегнтировали, только по типу оборудования: радио отдельный влан, доступ отдельный, кластеры/крупные узлы отдельный и тд

Ну это имеет чисто косметический смысл, практического собо нет кмк.

согласен

[s.lobanov]

ничем. особого смысла сегментировать MGM на 300 устройств нет.

 

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

 

L2-сегментация как mgmt, так и data должна быть максимально возможной (сегменты должны быть минимально возможного размера)

Какая например неприятность в изолированном MGM vlan? Где исключительно static routing и все?

 

Свитч сошёл с ума, умер stp(перестал пропускать bpdu), возникла петля в mgmt-влане. Или свитч сошёл с ума(превратился в ёлку), абонентский трафик попал в mgmt-влан(а у абонента proxy-arp), особенно если mgmt-влан не тегированный. Ошибка конфигурации stp/прочего L2-говна. Ещё был прикольный случай, когда РРЛ тупо возращала трафик обратно(какая-то внутренняя петля в её свитче), в том числе mgmt. Это реальные случаи из моего опыта когда я работал в ISP, то, что сходу вспомнил.

 

Меня всегда поражает самонадеянность админов, считающих что в mgmt-влане ничего никогда не случится. Защита должна быть всегда многоуровневой, это как с безопасностью сервисов. Пароль/ключ, ACL, mgmt VRF, хотя наивные админы, считают что достаточно только одного из этого трёх - поставил пароль/ключ на ssh, выставил его голой жопой в инет и сидишь довольный.

 

P.S. я бы уволил myst только за одну мысль засунуть 300 девайсов в один влан, за некомпетентность. О том, что нельзя помещать много девайсов в один влан даже на CCNA рассказывают и приводят миллион доводов почему так лучше не делать.

[myst]

ничем. особого смысла сегментировать MGM на 300 устройств нет.

 

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

 

L2-сегментация как mgmt, так и data должна быть максимально возможной (сегменты должны быть минимально возможного размера)

Какая например неприятность в изолированном MGM vlan? Где исключительно static routing и все?

 

Свитч сошёл с ума, умер stp(перестал пропускать bpdu), возникла петля в mgmt-влане. Или свитч сошёл с ума(превратился в ёлку), абонентский трафик попал в mgmt-влан(а у абонента proxy-arp), особенно если mgmt-влан не тегированный. Ошибка конфигурации stp/прочего L2-говна. Ещё был прикольный случай, когда РРЛ тупо возращала трафик обратно(какая-то внутренняя петля в её свитче), в том числе mgmt. Это реальные случаи из моего опыта когда я работал в ISP, то, что сходу вспомнил.

 

 

P.S. я бы уволил myst только за одну мысль засунуть 300 девайсов в один влан, за некомпетентность. О том, что нельзя помещать много девайсов в один влан даже на CCNA рассказывают и приводят миллион доводов почему так лучше не делать.

 

зачем вообще STP в MGM? no span vlan xxx например. Я бы уволил s.lobanov за полное непонимание что такое MGM и что там вообще в принципе может находиться.

 

Меня всегда поражает самонадеянность админов, считающих что в mgmt-влане ничего никогда не случится. Защита должна быть всегда многоуровневой, это как с безопасностью сервисов. Пароль/ключ, ACL, mgmt VRF, хотя наивные админы, считают что достаточно только одного из этого трёх - поставил пароль/ключ на ssh, выставил его голой жопой в инет и сидишь довольный.

А вот эту мысль вообще непонятно как Вы родили. Необходимость CoPP например и метод организации MGM вообще никак не пересекаются.

[s.lobanov]

myst

Если у вас свитчи в кольце (мне эта схема тоже не очень нравится, но она весьма популярна), то у вас всё равно будет stp/его аналог. именно про это кейс идёт речь. А no span vlan XXX это вообще cisco-specific, а cisco на доступе это как бы не самый распространённый случай. Либо вы enterprise-админ(тогда вам нечего делать на этом форуме), либо очередной мухосранск-телеком-админ, делающий говно-нетворки

 

А вот эту мысль вообще непонятно как Вы родили. Необходимость CoPP например и метод организации MGM вообще никак не пересекаются.

 

Ещё как пересекаются. Вот прям тривиальный пример. Чтобы повесить полноценный ACL на telnet-server на ASR9k нужно использовать CoPP. Команды типа telnet/ssh server ACL XXX во многих железках это полное говно и работают на уровне приложения. https://net-labs.in/2014/07/31/telnet-access-list-%D0%BD%D0%B0-cisco-ios-xr-asr9k-xrv-crs/ . Т.е. либо CoPP, либо чем-то внешним закрывать, что не всегда возможно, если железка сама по себе ASBR/внешний фаервол

[myst]

myst

Если у вас свитчи в кольце (мне эта схема тоже не очень нравится, но она весьма популярна), то у вас всё равно будет stp. именно про это кейс идёт речь. А no span vlan XXX это вообще cisco-specific, а cisco на доступе это как бы не самый распространённый случай

Всем привет. Имеется L2 сеть. В ней есть управляющий Vlan - там живут управляемые коммутаторы, точки доступа. Всего около 300 хостов. Возник вопрос - чем это чревато и не пора ли сегментировать все это дело? Если пора, то чего умного почитать для реализации оного на Eltex MES3124F?

Где хоть слово про кольцо? М?

no span vlan XXX это вообще cisco-specifi

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

 

приложения. https://net-labs.in/2014/07/31/telnet-access-list-%D0%BD%D0%B0-cisco-ios-xr-asr9k-xrv-crs/

Мы говорим и говорили в изначальном посте про l2, каким боком тут ASR c XR вылезло решительно непонятно.

[s.lobanov]

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

 

Ага. Много вы знаете non-cisco свитчей с per-vlan stp?

[s.lobanov]

Где хоть слово про кольцо? М?

 

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

[myst]

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

 

Ага. Много вы знаете non-cisco свитчей с per-vlan stp?

Juniper например.

[s.lobanov]

Мы говорим и говорили в изначальном посте про l2, каким боком тут ASR c XR вылезло решительно непонятно.

 

Я привёл пример про многоуровневость защиты для обеспечения надёжности/безопасности. Тут тоже самое. Недостаточно поместить управление в отдельный vlan (и vrf). Нужен дополнительный ряд мер против устройств, которые начали генерить в сеть мусор (по причине кольца, криворукого монтёра или из-за сбоя ПО/hw), наиболее важное здесь это именно сегментация по vlan, чтобы не потерять управления всеми устройствами сразу. Надо ещё 50 раз повторить эту мысль, чтоб она стала понятна?

 

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

 

Ага. Много вы знаете non-cisco свитчей с per-vlan stp?

Juniper например.

 

На доступе? и много вы знаете ISP с jun-ами на доступе, стоящих сотнями/тысячами, а не в десятке БЦ? И кстати, емним stp instance-ы они в MX-ах, в EX-ах вроде не было, не помню, но сути дела это не меняет. per-vlan stp это редкость, а не обыденность типа этого бреда:

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

[myst]

Я привёл пример про многоуровневость защиты для обеспечения надёжности/безопасности. Тут тоже самое. Недостаточно поместить управление в отдельный vlan (и vrf). Нужен дополнительный ряд мер против устройств, которые начали генерить в сеть мусор (по причине кольца, криворукого монтёра или из-за сбоя ПО/hw), наиболее важное здесь это именно сегментация по vlan, чтобы не потерять управления всеми устройствами сразу. Надо ещё 50 раз повторить эту мысль, чтоб она стала понятна?

Криворукие монтеры у вас свичи конфигурят? или всетаки порты в шате по-молчанию? Если нет - это проблемы кривого дизайна.

На доступе? и много вы знаете ISP с jun-ами на доступе, стоящих сотнями/тысячами, а не в десятке БЦ? И кстати, емним stp instance-ы они в MX-ах, в EX-ах вроде не было, не помню, но сути дела это не меняет. per-vlan stp это редкость, а не обыденность типа этого бреда:

У меня тоже как бы далеко не сотни свичей, хоть и не ISP, но вообще никаких проблем с MGM ниразу за много лет не испытывал.

[s.lobanov]

Криворукие монтеры у вас свичи конфигурят? или всетаки порты в шате по-молчанию? Если нет - это проблемы кривого дизайна.

 

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

[s.lobanov]

У меня тоже как бы далеко не сотни свичей, хоть и не ISP, но вообще никаких проблем с MGM ниразу за много лет не испытывал.

 

Вы даже себе представить не можете какой ад творится в ISP. Персонал малоквалифицированный, монтёры могут всё что угодно перепутать, оборудование дешёвое говно аля des-1210-28/ME/B2, у которого может конфиг слететь просто так или зависнуть из-за слабого БП и т.д. и т.п. Поэтому защит нужно как можно больше на уровне конфигов. И на самом доступе и на агрегации и на ядре

 

Расскажите как оно в enterprise'е, я там никогда не работал админом, интересно послушать. У вас там 1000 свитчей в одном влан?

[NiTr0]

Даже если нет колец, то какой-нибудь монтёр может случайно петельку сделать, особенно если на свитче есть combo-порты

 

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

[s.lobanov]

NiTr0

и такое тоже было :) но с комбо-портами оно ещё проще. если б в ящик полез, то 100% бы нарукожопил ибо никогда не работал монтёром и с пассивкой вообще

[Butch3r]

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

 

p.s. У нас в раздевалке прям объявление весит "Монтажникам думать запрещено!".

[s.lobanov]

Butch3r

Т.е. вы сторонник схемы единого mgmt vlan в ISP? Ок. Сколько у вас устройств в одном vlan (mgmt)?

[VolanD666]

Поэтому как это связано с сегментированием - не ясно.

Я вот тоже не понял. Ну будет у вас на промежуточном свиче не один управляющий влан, а несколько. Ну дык и их также можно запортачить. Или я чего-то не понимаю?

[Butch3r]

Butch3r

Т.е. вы сторонник схемы единого mgmt vlan в ISP? Ок. Сколько у вас устройств в одном vlan (mgmt)?

di mac-address vlan 4002 c
This operation may take a few minutes, please wait......

 ---  756 mac address(es) found  ---

 

Я вот тоже не понял. Ну будет у вас на промежуточном свиче не один управляющий влан, а несколько. Ну дык и их также можно запортачить. Или я чего-то не понимаю?

тут речь про то, что когда на районе А кольцанут управляющий влан, то на районе Б об этом не узнают (всмысле по управлению свичи там не отвалятся)

[VolanD666]

Да все от схемы зависит ИМХО.

[s.lobanov]

Butch3r

Ну смотрите, из-за того, что у вас в mgmt-влане 756 устройств, у вас любые работы стоят дороже за счёт того, что нужно что-то делать до и после работ, любых, даже на сраном свитче доступе.

И чё, у вас реально не было проблем в mgmt-влане из-за того, что где-то случилась печалька и все устройства недоступны?

[EShirokiy]

VolanD666, если строиться звездой:

управление агрегацией в отдельный vlan, управление доступом создаем на агрегации и делим по /26-/27-/28. Случись петля или неприятность в управлении доступом, то можно просто порт погасить или vlan удалить. При относительно узких масках проще найти проблему.

Для колец я бы выделил отдельный vlan на кольцо, с маской /27-/28.

[tehmeh]

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

Но сколько best practice? Мы вот по старинке на VLAN сетку /24, ну разумеется там не все 250 устройств.

[Butch3r]

Butch3r

Ну смотрите, из-за того, что у вас в mgmt-влане 756 устройств, у вас любые работы стоят дороже за счёт того, что нужно что-то делать до и после работ, любых, даже на сраном свитче доступе.

И чё, у вас реально не было проблем в mgmt-влане из-за того, что где-то случилась печалька и все устройства недоступны?

да ну, какое-то странное понятие "дороже". У нас инженера на окладе и то, что он поработает - да это же хорошо :). Работы на доступе - ничего мы не выключаем, так как топология звезда. И на узле 1 SFP - тут при всём желании не натворишь делов. В сторону доступа на кластере - per-vlan loopdetect.

 

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

 

Раньше, когда мы стоилисль на старых свичах - такие проблемы бывали.

 

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

 

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

Но сколько best practice? Мы вот по старинке на VLAN сетку /24, ну разумеется там не все 250 устройств.

а что плохого в этих маках? трафик то они не генерируют

[darkagent]

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

таки что вам мешает убить эту самую широковещательность? по-моему port-isolation/traffic segmentation сейчас есть чуть ли даже не в самых убогих китайских мыльницах.

[tehmeh]

а что плохого в этих маках? трафик то они не генерируют

 

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

То есть речь не идёт о том, что это вызывает проблемы, но это их точно не уменьшает и повышает риски. Вероятность есть всегда.

 

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

таки что вам мешает убить эту самую широковещательность? по-моему port-isolation/traffic segmentation сейчас есть чуть ли даже не в самых убогих китайских мыльницах.

Это делается и так, как и storm-control'ы и прочее. Речь опять же за комплексный подход, я тут с s.lobanov согласен, но просто интересно, кто сколько в один VLAN пускает.