Сегментирование Vlan управления

[Butch3r]

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

 

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

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

 

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

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

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

ну вот я скинул свой самый "жирный" влан. В других поменьше, где-то по /24.

[s.lobanov]

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

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

 

Best practice - готов поделиться. L3/MPLS in-band mgmt - там всё понятно, у них лупбэки. Относительно L2-устройств(свитчи, РРЛ, радио, всё что угодно L2) там так: на каждый агрегационный свитч свой mgmt-vlan. Если L2-агрегация кольцом и какой-нибудь stp, то переделывать это на всякие LAGG или увольняться, там всё равно ничего толком работать не будет. На доступ так - если кольцо, то mgmt-vlan на кольцо, на каждый свитч будет бесполезно, всё равно умрёт всё кольцо. Если звезда, то mgmt-vlan на порт агрегации, всё равно длинные цепочки никто в здраве уме строить не будет из-за проблем с питанием. Работает железобетонно.

 

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

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

 

port-isolation не спасает от того, когда у вас снизу приходит мак шлюза (из-за петли или из-за proxy-arp абонента, который "случайно" попал в mgmt-влан). вообщем port-isol это не тоже самое, что настоящие вланы. ещё port-isolation хреново работает на многих d-link'ах и не только, часть трафика всё равно проходит (что идёт через CPU устройства, на котором включен port-isolate), как следствие - мак-таблица разбухает в mgmt-влане, ну дальше все знают что происходит на мелких свитчах с большой мак-таблицей

[Butch3r]

А когда у вас в этом кольцо-влане что-то начинает флудить, то вы едете на место? Или начинаете на свой страх и риск тянуть флуд до того места, где можно воткнуть снифер?

[s.lobanov]

В сторону доступа на кластере - per-vlan loopdetect.

 

А ничего, что хрень работает с каким-то периодами (раз в секунду, например). И вы же наверное auto-recovery настраиваете? А потом ищите почему у вас иногда "что-то мигает на мониторинге"...

[darkagent]

port-isolation не спасает от того, когда у вас снизу приходит мак шлюза

Так никто ж не говорит ограничиваться полумерами ;)

Рано или поздно все приходят к аналогичной или схожей с вашей best practice схеме. Зависит лишь от употребленного количества корвалола за время эксплуатации сети :D

[s.lobanov]

А когда у вас в этом кольцо-влане что-то начинает флудить, то вы едете на место? Или начинаете на свой страх и риск тянуть флуд до того места, где можно воткнуть снифер?

 

Что значит флудить? Что именно вы имеете ввиду? Например, с абонентского порта прилетает 100мбит/с бродкаста с data-vlan, рассыпается stp или что-то ещё? Всё зависит от ситуации, но при нормальном дизайне атаки со стороны абонентского порта не влияет на mgmt и даже на других абонентов. Когда глючит ПО/hw, то тут по ситуации, в каких-то случаях xconnect-ом всё говно можно стянуть себе и посмотреть

[s.lobanov]

port-isolation не спасает от того, когда у вас снизу приходит мак шлюза

Так никто ж не говорит ограничиваться полумерами ;)

Рано или поздно все приходят к аналогичной или схожей с вашей best practice схеме. Зависит лишь от употребленного количества корвалола за время эксплуатации сети :D

 

ну так-то да. когда покупаешь какую-нибудь говносеть со 100500 маками в mgmt-влане, то чтоб хоть немного можно было поспать, нужно включить port-isol на первое время. Правда быстро всплывут l2-vpn-ы, построенные вланам в предела свитча агрегации, но это уже нюансы...

[zi_rus]

да ну, какое-то странное понятие "дороже". У нас инженера на окладе и то, что он поработает - да это же хорошо :)

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

[Butch3r]

А когда у вас в этом кольцо-влане что-то начинает флудить, то вы едете на место? Или начинаете на свой страх и риск тянуть флуд до того места, где можно воткнуть снифер?

 

Что значит флудить? Что именно вы имеете ввиду? Например, с абонентского порта прилетает 100мбит/с бродкаста с data-vlan, рассыпается stp или что-то ещё? Всё зависит от ситуации, но при нормальном дизайне атаки со стороны абонентского порта не влияет на mgmt и даже на других абонентов. Когда глючит ПО/hw, то тут по ситуации, в каких-то случаях xconnect-ом всё говно можно стянуть себе и посмотреть

ну ранее в теме говорили что всё в одном л2 и может всё потухнуть. Вот мне и интересно как это.

 

А ничего, что хрень работает с каким-то периодами (раз в секунду, например). И вы же наверное auto-recovery настраиваете? А потом ищите почему у вас иногда "что-то мигает на мониторинге"...

Именно. Кольцануло, заблочилось. Мониторинг алармит. Зашёл инженер, увидел в логе запись и разбирается с проблемой

[s.lobanov]

ну ранее в теме говорили что всё в одном л2 и может всё потухнуть. Вот мне и интересно как это.

 

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

 

может и другие сегмент задеть, если убьёт CPU точки терминирования (если нет хороших защит)

[purecopper]

У нас, так сложилось, в mgmt vlan не более 50 устройств (всего на сети порядка 500 коммутаторов). Отдельный vlan для управления Wi-fi точек и прочего управляемого оборудования.

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

Ну что я могу сказать, работает это всё ... да нормально работает :) ( я не в коем случае не говорю, что так надо делать. Наоборот - так НЕ надо делать, да и уже запланированы работы по уменьшению L2 MGT сегментов, но тем не менее).

[myst]

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

 

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

 

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

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

А OOB обычно подразумевает и vrf и минимум возможных сервисов. И да, если у свища снесет крышу, сегментация вам не слшиком поможет.

 

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

 

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

Вот именно. У нас было точно так же. (В ISP) и никаких казусов небыло.

[andryas]

Ну у меня в управляющем вилане более 600 маков, звезда, всё тотально сегментировано от ядра до доступа, проблем 0.

На управление стоит отдельный DGS-3120-24SC, он готов принять ещё более 10 тыщ устройств :)

[s.lobanov]

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

А OOB обычно подразумевает и vrf и минимум возможных сервисов. И да, если у свища снесет крышу, сегментация вам не слшиком поможет.

 

Ну а как вы себе представляете OOB для тысяч домовых свитчей? Т.е. для управления каждым свитчом нужно ещё 1(2) волокно? Понятно, что в нормальный access это DSLAM и OLT, а все домовые свитчи это унылое говно, но реальность российских условий такова, что все ставят тысячи свитчей в жилые дома.

 

Ну у меня в управляющем вилане более 600 маков, звезда, всё тотально сегментировано от ядра до доступа, проблем 0.

 

всё до первого случая. если у вас его ещё не было, что ж, вам повезло

[andryas]

всё до первого случая. если у вас его ещё не было, что ж, вам повезло

 

Может быть :)

Что за случай? У меня вообще непотопляемая сеть :)

[myst]

всё до первого случая. если у вас его ещё не было, что ж, вам повезло

 

Может быть :)

Что за случай? У меня вообще непотопляемая сеть :)

Да люди просто незнакомы с принципом разумность и достаточности. Безопасность и меры бывают как недостаточны, так и явно избыточны. Вот тут какраз второй случай.

[DRiVen]

в управляющем вилане более 600 маков, звезда

Фото агрегации не покажете?

[Butch3r]

в управляющем вилане более 600 маков, звезда

Фото агрегации не покажете?

звезда не означает, что все 600 устройств включены с одного узла :)

[andryas]

Фото агрегации не покажете?

 

У меня десятки таких узлов :) Обычные D-Link'и, ничего интересного.

[DRiVen]

звезда не означает, что все 600 устройств включены с одного узла :)

А тогда это композит, дерево, со всеми вытекающими. Или вы считаете, что звезда это все, что не кольцо?

Edited June 13, 2016 by DRiVen

[vlad11]

Господа, о чем спорите?

Роутинг в влане управления тоже может быть.

[myth]

Есть ли в этом смысл...

[s.lobanov]

Конечно нет, лучше надеяться на русский(и видимо, ещё и украинский) авось. Живут же сейчас свитчи в одном влане и пусть живут. А переделывать сеть будем только тогда, когда печалька случится. Типичный стиль работы "решения проблем по мере их поступления"

[andryas]

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

 

Какая может случится фатальная печалька, при тотальной сегментации? Управляемый коммутатор видит себя и сервер управления. Сервер управления видит всех.

[s.lobanov]

andryas

Я уже писал выше - сбои ПО/hw свитчей, закольцовка порта (например, при работах на оптике), сбой ПО на свитчах из-за большого кол-ва левого бродкаст, который может возникнуть когда часть свитчей отсохла (по питанию, например), в арпе они ещё живы, а в мак-таблице уже нет (время жизни arp > время жизни fdb). Я сталкивался со всеми этими случаями, к сожаленью, port-isolation не решает всех проблем большого vlan