Проектирование ЛВС

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

Вопрос дальности, производительности и необходимости управлять

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

Можно мыльницы на управляемые малопортовые коммутаторы поменять

Да, вариант такой тоже рассматривал, но что то мне кажется это будет дорого. Слишком много их менять придется. А в бюджете меня 100% ограничат.

Прежде чем что-то советовать, интересно узнать масштаб.
Например сидит у тебя 1000 человек. Прорубишь ты в стенке дыру метр на метр, протащишь туда 1000 кабелей по 100 метров, поставишь 200 коммутаторов...
Сетку не штормит? Может просто потихоньку менять уроверь сохо хотя бы на бизнес? В месяц по одному.

Ну нет, не 1000. 3 этажное здание, на втором этаже хостов 40-50 примерно. На третьем ~20. Первый - 4-5 максимум.

Пока с сеткой особых проблем не было, но угнетает ее неэстетичность и костыльность с этими бесконечными мыльницами. Да и не поуправлять ею толком. Я даже port security включить не могу, не говоря уже о делении на vlan или внедрении 802.1x, ибо насколько я понял там нужен 1 device per port(могу ошибаться).

Теортически нет препятствий прокинуть кабеля и на 100 метров,
но стоит ли их кидать под каждый комп на такие расстояния?

А почему нет ? Но не 100, конечно, а чуть меньше, из расчёта на длину патчкордов ещё.

Похоже на мою старую работу, гори она огнем. Просто берешь несколько серьезных коммутаторов по 24-52 порта, стекирование будет очень даже кстати. Тогда с VLAN будет легче рулить. Расстояния по логике должно хватать, ну если не хватит, найдешь чем удлиннить. Ну и как уже говорили выше, стоять это должно в одном месте с резервным питанием АВР, нормальной пожарной безопасностью и температурным режимом. Т.е. 3-4 свича всего нужно. А всю мелочь повыкидывать. Не совсем понятно откуда 9000+ маков если хостов меньше сотни. Ну и да, нужно будет тянуть кабели к каждому хосту. Ну и бест практис нужно все это хозяйство пропустить сначала через патч-панели. Ну как-то так для затравки.

А денег сколько дадут на модернизацию?
Хватит тебе на полноценное шасси, или придётся стекировать?
Сетка должна быть 100FE, или 1GE?

Присоединяюсь в выше отписавшимся. Если хватает длинны то в одно место заводим (серверную). Если нет, то промежуточные в отдельном месте. На вопрос " тянуть до каждого компа?" отвечу да.
ЗЫ Когда-то давно разгребали такое барахло, свичи и хабы под столами пользователей валялись, один умер (тетя маша чайник вместо него включила) и трындец всем кто за ним, чем-то старый вариант коаксиала с репитерами напоминало.

Не знаю как сейчас с этим обстоит дело, но на старых длинках port security очень глючная штука.

Большое спасибо всем. Теперь понял от чего отталкиваться. Насчет бюджета - пока не факт что вообще разрешат этим делом заниматься, ведь с точки зрения неспециалиста все работает же. Попробую убедить что безопасность и управляемость сети оставляет желать лучшего. Плюс проблема в том что фактически прокладкой кабелей занимается другой отдел и поддержат ли они эту идею тоже вопрос. Скажут го сам прокидывай:) Я хоть и сисадмин, но прокладкой кабелей в этом качестве никогда не занимался, да и времени не хватит на это.

И если не затруднит, посоветуйте какие свичи лучше брать? Надо 48 портов, думаю 100Mb хватит, но если 1Gb не сильно дороже, то можно и их. И чтоб все стандартные фичи были и какая-никакая стабильность при скромном бюджете.

Здравствуйте, а что Вы хотите получить на выходе? Какие требования к ЛВС (скорость, безопасность, управляемость, etc). Другими словами, что не устраивает в данный момент?

Это я к тому, что есть старое админское правило - «работает - не трогай» ;).

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

Пока с сеткой особых проблем не было

И зачем ее тогда трогать?

но угнетает ее неэстетичность и костыльность с этими бесконечными мыльницами.

Извините, но это не аргументы, а эмоции. Костыльность - это когда что-то из характеристик ЛВС не удовлетворяет, а изменить не получается. А Вы сами пишете, что проблем нет.

Я даже port security включить не могу, не говоря уже о делении на vlan или внедрении 802.1x, ибо насколько я понял там нужен 1 device per port

А есть потребность? Для бизнеса это какие даст преимущества в Вашем случае?

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

Буду рад ошибиться.

сами пишете, что проблем нет

Ну смотря что считать проблемами. Сетка не отваливается - это да. В остальном я уже писал что это практически полностью неуправляемая инфраструктура. И если следовать устоявшимся на этом объекте практикам, то все это будет дальше нарастать как снежный ком. Нужно ли управлять инфраструктурой и улучшать ее устойчивость к сбоям, проникновениям? Ну профессия обязывает. Если руковдство скажет нет, то как говорится «мое дело предложить...» Постелить себе соломку все равно стоит, чтобы потом не было претензий по плохой работе сети.

Это для начала. Потом уже буду смотреть в сторону VLANов и прочего.

Чет с последовательностью не оч.

А как правильно? Настраивать свичи до их покупки? Эх, не таких советов я просил...

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

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

До покупки свичей нужно продумать

Ну это само собой. Спасибо, посмотрю что там у цисок.

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

Вот Вы пишете - VLAN, 802.1x, port security - насколько эти требования соответствуют потребностям бизнеса? Начнем с VLAN. Вы уже продумали как и по каким принципам планируете разбивать сеть? И как это скажется на рабочих процессах? Хостов у Вас немного, все они, в принципе, вполне могут уживаться в одной сети. Что Вы хотите достичь разделением? И не создаст ли это проблем для пользователей, которые Вам же и придется решать? Аналогичный вопрос к 802.1x - авторизацию кого и к каким ресурсам Вы планируете прикрутить? Есть ли в этом потребность? Как сейчас решается задача авторизации и какие преимущества для рабочих процессов даст внедрение 802.1x? Port security - Вы реально сталкивались со сменой MAC-адресов со стороны пользователей? Или цена утечки данных настолько высока, что стоит принять превентивные меры?

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

Соответственно, Вы должны четко представлять (и доступным языком изложить эту информацию Вашему работодателю) как именно модернизация сетевой инфраструктуры улучшит эффективность работы организации в целом. Потому что «управляемость инфраструктуры» с точки зрения владельца бизнеса - пустые слова. Управлять ей - Ваша работа, Вам за нее платят деньги, и предложение потратить энную сумму на повышение управляемости (облегчение вашей работы) вряд ли вызовет энтузиазм. А вот экономическое обоснование - мы сегодня вкладываемся в инфраструктуру, а завтра, за счет ускорения таких-то бизнес-процессов зарабатываем дополнительные деньги, будет встречено совсем по-другому.

зарабатываем дополнительные деньги

Есть еще «не потеряем». Надеюсь вы меня правильно поняли. Иногда вложения не только для увеличения прибыли, но и для того что бы не потерять существующую.

Есть еще «не потеряем». Надеюсь вы меня правильно поняли. Иногда вложения не только для увеличения прибыли, но и для того что бы не потерять существующую.

Верно. Но согласитесь, в данной теме обсуждается не этот случай. Речь-то идет о внедрении новых технологий (VLAN, port security, 802.1x) в сеть, без проблем функционирующую без них.

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

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

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

Кстати, полезная штука - зеркалирование портов. В пределах одного коммутатора умеют, наверное, любые управляемые сейчас. Но есть полезный вариант с общим VLAN, в который трафик зеркалируется. То есть, включаешь зеркалирование на любом коммутаторе в сети, а трафик летит в сторону порта, где включено что-то с tcpdump. Тут надо уже смотреть спецификации. У SNR вот есть, к примеру (но по моделям, всё равно, стоит проверять).

И если не затруднит, посоветуйте какие свичи лучше брать?

Циску посмотреть посоветовали, смотрю. Но вполне функциональны и надёжны оказались SNR, а цена существенно ниже. Недавно Eltex помотрел, но про надёжность сказать не могу. По возможностям даже побольше, чем у SNR, но вряд ли эти различия интересны не для оператора.

Большое спасибо всем. Теперь понял от чего отталкиваться.

Ещё:

ГОСТ Р 53245-2008 Информационные технологии. Системы кабельные
                  структурированные.
                  Монтаж основных узлов системы. Методы испытания

ГОСТ Р 53246-2008 Информационные технологии. Системы кабельные
                  структурированные. Проектирование основных узлов
                  системы. Общие требования

И если не затруднит, посоветуйте какие свичи лучше брать? Надо 48 портов, думаю 100Mb хватит, но если 1Gb не сильно дороже, то можно и их. И чтоб все стандартные фичи были и какая-никакая стабильность при скромном бюджете.

Не стоит с самого начала вкладывать в заведомо устаревшее оборудование(100 мегабит). Для коммутаторов доступа вполне подходит линейка SB у цисок, какой-нибудь SG200-50. Дальше у тебя будет ядро, на нем же можно повесить внутреннюю маршрутизацию - нужно нормальное железо.

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

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

на нем же можно повесить внутреннюю маршрутизацию

Что-то сомневаюсь, что ему там надо L3.

Он собирается внедрять vlan, надо же их как-то соединять.

Он собирается внедрять vlan, надо же их как-то соединять.

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

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

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

Интересно, как именно вложения в СКС могут «окупить» ущерб от шифровальшика? ;)

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

А, вот Вы о чем. Сложно сказать, так это, или нет, не зная ситуации, но в том случае, если Вы правы, усилия админа и бюджет компании в первую очередь должны быть направлены на решение программных проблем. Согласитесь, что при наличии в сети «шифровальщика на дырявой самбе» внедрять VLAN и прочие сетевые технологии как-то странно...

Вроде как бест практис делить офис или по этажам, или по комнатам, или по отделам.

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

Писать acl на подсети куда проще, чем реализовывать логику защиты на конечных сервисах.

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

Согласитесь, что при наличии в сети «шифровальщика на дырявой самбе» внедрять VLAN и прочие сетевые технологии как-то странно...

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

Извиняюсь, не могу редактировать сообщения. Спасибо еще раз всем кто помог. Пока все откладывается на неопределенное время. Но мне эта тема все равно очень интересна, потому если у кто еще есть чем поделиться - буду рад :) По свитчам я более менее понял, а вот как с маршрутизаторами? Обычно я ставлю какой нибудь *nix дистр на роутер. Почти не имел дела с нормальными hw роутерами. В каких случаях они будут лучше? Как у них дела с поддержкой VPN(ovpn в частности)?

Прошу прощения, но это я не Вам писал. Прекрасно понимаю, что к Вашей проблеме тот пост никакого отношения не имеет. И уж тем более, не считаю Вас, или еще кого-то глупее себя.

Успехов, Сергей.

3 зашифрованных компа с данными - циска сб, разве нет?

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

Бизнес обычно не требует объяснения всех применяемых технологий. Он просто хочет, чтобы все работало. А дальше начинается компетентность тех директора.

Зависит от количества маршрутизируемого траффика и функционала коммутаторов уровня ядра.

На нормальных коммутаторах сейчас идёт достаточный л3, чтобы не заниматься установкой софтовый роутеров и выжиманием из них производительности.

Софтовые остаются как пограничники, как раз там и востребованны впн. И трафика там намного меньше.

3 зашифрованных компа с данными - циска сб, разве нет?

Как поможет циска, если пользователь перешел по сомнительной ссылке в браузере?

Впрочем, предлагаю завязывать с этой темой - автор недвусмысленно написал, что он против оффтопа здесь.

Он просто хочет, чтобы все работало.

Угу, только вот по словам автора и так все работает (с точки зрения бизнеса).

А дальше начинается компетентность тех директора.

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

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

Не согласен. Тех. дир./админ видя существующие проблемы может положить «на стол» свои предложения, другой вопрос что не редко это игнорируется(не воплощается в жизнь) по тем или иным причинам (в основном финансовым).
Давайте рассмотрим тривиальную задачу, бэкапы. Ведь с точки зрения бизнеса (как получения ежедневной прибыли) эти вложения не приносят прибыль как таковую, а только какие-то расходы.
Представим контору в вакууме, работает 10 лет и вот полного трындец все еще не произошло, приходит админ с предложением, «ребята у вас все плохо, есть не илюзорная возможность пролюбить все данные, надо н-цать денег для создания системы бэкапа» - как это рассматривать? У бизнеса в этом небыло потребности. Более того, он и сам не знает что может получить нихилые потери в случае «бальшого бам». А может и не получить. Это как подушка безопасности в машине, можно ездить N лет и ниразу не понадобиться, но вот на N+1 «внезапно выстрелит».

Не согласен. Тех. дир./админ видя существующие проблемы может положить «на стол» свои предложения...

Хм, и с чем Вы несогласны, если я пишу тоже самое? Ключевая фраза в Вашем утверждении - «видя существующие проблемы».

Т. е. отталкиваться надо именно от проблем, а не от существующих технологий. Причем проблем именно с точки зрения бизнеса (организации бизнес-процессов).

Представим контору в вакууме, работает 10 лет и вот полного трындец все еще не произошло, приходит админ с предложением, «ребята у вас все плохо, есть неилюзорная возможность пролюбить все данные, надо н-цать денег для создания системы бэкапа» - как это рассматривать? У бизнеса в этом не было потребности.

Вот именно для того, чтобы таких ситуаций не было, и нанимается хороший админ/тех. директор (зависит от размеров конторы).

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

Более того, я Вам скажу сейчас совсем уж дикую с точки зрения админа вещь - бывают ситуации, когда бекапы вообще не нужны. Я лично видел такие конторы - компьютеры используются там как Internet-терминалы, а все бизнес-процессы идут IT-независимо. Сгорел диск - не вопрос, нужную информацию можно и с телефона найти в Сети... И зачем такой компании тратиться на инфраструктуру бекапов?

Более того, он и сам не знает что может получить нихилые потери в случае «бальшого бам». А может и не получить.

Вот, именно об этом я и пишу - работа админа/тех. директора, только что пришедшего в компанию, должна начинаться именно с изучения основных бизнес-процессов, их завязки на существующую IT-инфраструктуру. А не бросаться внедрять новые технологии ЛВС, бекапов и т. п....

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

Это как подушка безопасности в машине, можно ездить N лет и ниразу не понадобиться, но вот на N+1 «внезапно выстрелит».

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

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

Как поможет циска, если пользователь перешел по сомнительной ссылке в браузере?

ограничит область заражения

IMHO, компетентность тех. директора как раз и заключается в том, чтобы развивать IT-инфраструктуру организации в соответствии с текущими бизнес-процессами с учетом перспективы. А не просто стараться выбить денег для внедрения новых технологий.

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

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

Это верно только в том случае, если часто «приходится бегать и чинить сбои». Если все работает без сбоев (я таких сетей видел очень много во всяких НИИ), то большого смысла в модернизации нет.

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

Это философский вопрос ;). Замечу только что с такой психологией:

«Админа эти все вопросы волновать не должны, он должен думать в первую очередь о себе.» Ваш админ никогда не вырастет до уровня тех. директора ;).

ограничит область заражения

Вы же понимаете, что это не решение проблемы?

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

Да, конечно. Но это справедливо только для достаточно крупных организаций, у которых, как минимум, есть позиция тех. директора ;). И в этих случаях админы вообще не занимаются выбором технологий. А реализуют указания тех. директора ;). Как Вы и пишите, по бест практис ;).

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

Вы же понимаете, что это не решение проблемы?

почему нет? мало неизвестных дыр?

Да, конечно. Но это справедливо только для достаточно крупных организаций, у которых, как минимум, есть позиция тех. директора ;). И в этих случаях админы вообще не занимаются выбором технологий. А реализуют указания тех. директора ;). Как Вы и пишите, по бест практис ;).

Тех директора бывают выходцеми из разных технологий. Какой-нибудь бывший внедренец ЕРП не сможет сделать архитектуру сети.

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

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

Это верно только в том случае, если часто «приходится бегать и чинить сбои». Если все работает без сбоев (я таких сетей видел очень много во всяких НИИ), то большого смысла в модернизации нет.

А я работал в НИИ. И не сказал бы что «работает и без сбоев». Все эти «свич через свич и хабом погоняет» и при учете что обычно в таких местах и сетка раскидана абы как... не добавляет радости при поиске неисправности. Что-то в духе тааак у нас глючит в комнате 301, а откуда у нас к ней сеть идет... эмм... наверное из комнаты 205... ой не не оттуда... Или, а что у нас глючит-то? может свич в комнате 407?, не не он... мля какая-то падла на витуху стол поставила... Или до банального тетя Маша поливала цветочки и залила «коробочку с лампочками».
Сюда же добавить что обычно большой зип держать не дают, вот и получается сгорел один, потом второй, зип закончился, сгорает третий вот и думай потом кого временно без сети оставлять.

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

ограничит область заражения

Вы же понимаете, что это не решение проблемы?

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

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

Истина. Я уже где-то здесь описывал один случай, хоть он и не касается ИТ да и автоматизацию только частью затрагивает. Дано насос, бааальшой такой насос у которого полетел емним твиндиск(а может устройство плавного пуска, не помню), много лет у руководства выбивают денег на новый, каждый раз ответ «денег нет», и в одну прекрасную ночь при запуске вышибает подстанцию, гаснет свет у жены ввп (ну и естессно у всех их соседей тоже) ввп был где-то в поездке, далее все разворачивалось очень быстро, жена ->ввп «вова у меня свет погас», и по цепочке вниз, сроки за которые «появились деньги», купили и смонтировали, не то что твиндиск(или плавный пуск) - низкочастотник!!! - просто поразили :)

Какой-нибудь бывший внедренец ЕРП не сможет сделать архитектуру сети.

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

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

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

Тут дело не в экономии. Моя позиция очень проста - прежде, чем тратить какие-то деньги/собственное время и усилия нужно четко представлять, что мы собираемся получить в результате. 7 раз отмерь, один раз отрежь ;).

Потому что потом спросят по всей строгости и про экономию никто не вспомнит.

Спросить могут по-разному. Но чтобы этого не было, надо заранее планировать все изменения. И главное, соотносить их с реальными потребностями бизнеса.

А я работал в НИИ.

Я до сих пор работаю ;).

И не сказал бы что «работает и без сбоев». Все эти «свич через свич и хабом погоняет» и при учете что обычно в таких местах и сетка раскидана абы как... не добавляет радости при поиске неисправности. Что-то в духе тааак у нас глючит в комнате 301, а откуда у нас к ней сеть идет... эмм... наверное из комнаты 205... ой не не оттуда... Или, а что у нас глючит-то? может свич в комнате 407?, не не он... мля какая-то падла на витуху стол поставила... Или до банального тетя Маша поливала цветочки и залила «коробочку с лампочками».

Бывает и так :). Но Вы же не стали создавать правильную СКС? А знаете, почему? Потому что в том же НИИ есть 1000 и 1 способ потратить деньги, любой из которых принесет большую пользу для работы, чем создание правильной СКС.

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

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

Да, тут могу Вам только посочувствовать :(. Мне в этом плане везло - и в НИИ, и в частных конторах приходилось иметь дело с командами энтузиастов, которые переживали за общий результат и совместными усилиями его достигали. Люди, невписывающиеся в команду, долго в коллективе не задерживались.

Так что у меня принципиально другое отношение к пользователям.

В случае заражения, это вполне годное решение.

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