Обновление сетевого оборудования

Сеть работает, 1С открывается, пользователи довольны. Картина встречающаяся сплошь и рядом. Кажется, что жизнь администратора удалась. Именно так думает половина, если не две трети начинающих и достаточно продвинутых системных администраторов. Многие из нас даже не задумываются о том, что стоит в сетевых шкафах в офисе, в лучшем случае контролируя то, что стоит в серверной. Данный подход особо опасен для вашей работы (уволят) и для работы вашей организации (встанет). Если всё работает – пора обновлять оборудование.

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

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

Ответ прост – обновлять оборудование нужно постоянно, циклично, с запасом. Однако, всё зависит от вашей компании, её размера, сферы её деятельности, перспективах её роста и роста локальной сети, что не всегда взаимосвязано между собой, используемых и планируемых к использованию сетевых технологий, бюджета, подходу к выделению средств на ИТ и сотням других факторов. Я предлагаю вам несколько критериев, которые могут оказать помощь в понимании необходимости обновления сетевого оборудования и аргументации обновления перед собственником.

Первый критерий: безопасность

Безопасность бывает внутренняя и внешняя. Внешняя безопасность обычно начинается с роутера, внутренняя со свитча и точек доступа. Если вопрос защиты точек доступа обмусолен многократно, а о защите от интернета знает и младенец, то про защиту LAN портов думают единицы. Ответьте себе на следующие вопросы:
  • Что сможет сделать посторонний человек с ноутбуком, подключённый в LAN порт компьютера бухгалтера и знающий какие-то исходные данные о сети?
  • Насколько вероятно такое подключение?
  • Кого затронет его атака?
Неуправляемые свитчи, свитчи без авторизации и vlan’ов – вот первые кандидаты на замену.

Второй критерий: надёжность

Контрольные вопросы:
  • Сколько лет работает существующее оборудование? Можно посмотреть по счетам на покупку или по дате производства, если документы не сохранились.
  • На сколько лет оно рассчитано? У любого оборудования есть время «наработки на отказ».
  • Каковы потери компании от его внезапного выхода из строя? Здесь нужно оценить количество подключённых человек (включая трансфертных) и стоимость часа их работы.
  • Каков срок замены оборудования и процедура? Одно дело взять резерв с полки. Другое дело пробежать все согласования со счётом на новую железку, подождать 3 дня прихода денег вендору и ещё неделю доставки самой железки.
  • В каких условиях работает оборудование? Одно дело серверный шкаф, другое дело — пыльный потолок.
  • Какое количество оборудования на участке сети? Допустим у вас этаж с 20 пользователями, вся сетевая инфраструктура сводится в единый шкаф, в котором стоит\лежит три свитча по 8 портов. Будет ли надёжна такая схема?


Третий критерий: загрузка и потенциал

Список вопросов:
  • Насколько загружено данное оборудование? Одно дело, если у вас гигабитная сеть, нет IP-видеонаблюдения, нет IP-телефонии и все свитчи подключены к одному свитчу-ядру. Могу вам позавидовать, однако в 70% мелких и средних предприятиях ситуация далека от описанной.
  • Есть ли рычаги для управления загрузкой? У вас полностью управляемая гигабитная сеть и вам просто нужно настроить QoS — вы почти на пляже и можете думать о лете. У вас 100 мегабитная сеть, которая о QoS не слышала? В ближайших планах введение IP-телефонии и IP-видеонаблюдения? Вам скоро будет жарко, вы на пути в пекло ада.
  • Есть ли рычаги для увеличения пропускной способности? Хорошо если у вас есть возможность перетянуть 100 метров кабеля и подключить 100 мегабитный свитч его гигабитным портом в ядро сети. Абсолютно иная ситуация, если ваш 100 мегабитный свитч со своим гигабитными портами может быть связан только с другим 100 мегабитным свитчом, без гигабитных аплинков.
  • Потребуется ли увеличение пропускной способности в ближайший год, три года, пять лет? Если у вас не внедрена IP-телефония и IP-видеонаблюдение, то можете считать, что потребуется, конечно, речь про 100 мегабитную сеть. Хотя и в гигабитной сети при определённых конфигурациях и количестве портов может возникнуть такая потребность. Даже в ситуации отсутствия планов по внедрению IP-технологий стоит задумываться о гигабите — объём передаваемых данных неуклонно растёт.
  • Поддерживает или нет ваше оборудование технологию PoE? Многие не задумываются над этим вопросом, однако ответьте себе, что проще тащить к IP камере провод питания из розетки или запитать её от свитча? Конечно, можно положить в сетевой шкаф пяток сплиттеров, но представьте себе какова будет температура в шкафу и уровень захламлённости. В заключение отмечу, что в современных офисах по PoE могут питаться: Wi-FI точки, IP-камеры, IP-телефоны, считыватели и датчики систем контроля доступа и даже настенные часы.


Четвёртый критерий: производитель оборудования

Зоопарк — отличное место для проведения выходных, особенно сейчас, весной. Если вы любите зоопарк, то вас не смутит наличие в одном шкафу D-Link’а, Planet’а и Cisco. В общем случае подобной неразберихи стоит избегать. Дело в том, что сложно одинаково хорошо и быстро владеть разными прошивками различных производителей. В зоопарке всегда есть шанс наткнуться на различную реализацию одного стандарта вендорами. Настоятельно рекомендую уделить массу времени подбору нужного оборудования одного производителя и проверки совместимости.

Пятый критерий: бюджет

Бюджет является одним из критериев необходимости и скорости обновления сети. Вы – системный администратор. Вы обязаны не решать проблемы, а предупреждать их. Вы обязаны доносить до вашего руководства текущее состояние инфраструктуры и те проблемные места, которые есть. Такой подход обезопасит вас самих от внезапных претензий. Если вы подавали заявку на оборудование и обосновывали его необходимость, то вы смело можете отказывать во внедрении той или иной технологии кустарным способом до приобретения нужного оборудования.

Качественное сетевое оборудование стоит серьёзных денег. Планирование расходов поднимет ваш уровень в глазах руководства и облегчит вашу работу. Если вы планируете покупку 1-2 свитчей в месяц, вам остаётся настроить ровно 1-2 устройства за этот месяц. Это очень плавная и неспешная работа, которая позволяет выбрать оптимальное время для замены устройства, перед этим оставляя вам массу времени на его тестирование и настройку.

Абсолютно иначе смотрится ситуация, когда Вам по тем или иным причинам требуется обновить целый сегмент сети, например из 5-6 конечных устройств. Подобный темп подразумевает подключение более 1 устройства в неделю, что далеко не всегда позволяет вам нормально провести тестирование и настройку и практически никогда не позволяет вам выбрать оптимальное время для физической замены устройства. Т.е. быстрая замена устройств либо вызывает прерывание работы части сотрудников, либо заставляет работать сотрудников ИТ отдела во внеурочное время (выходные/после окончания рабочего дня).

С точки зрения выделения средств всё выглядит следующим образом: В случае планового обновления оборудования — это плановая трата ХХ рублей на протяжении УУ месяцев, которая закладывается в бюджет наравне с закупкой канцелярии. В случае обновления оборудования для реализации технологии — эта сумма превращается в сумму реализации технологии. В свою очередь подобное может заставить компанию отказаться от перспективной технологии(ZZ), так как заморозить УУ*ХХ+ZZ рублей сразу может быть фатально для основного бизнеса.

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

Сначала деньги тратят на установку аналогового видеонаблюдения. Потом на установку нормального сетевого оборудования в связи с выходом из строя старого либо внедрением IP-телефонии. Потом на покрытие ущерба от ЧП, так как на аналоговой записи оказывается не видно лица виновника, либо не видно совсем ничего, потому что была гроза и всё в помехах, потом на установку цифрового видеонаблюдения.

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

Планируем свои действия

Описанная задача для многих кажется невыполнимой. Выбить денег на ровном месте? Сложно, но необходимо! Прежде всего вам и вашей компании.

Всё начинается с плана. Предлагаю вам стандартный план, который позволит вам понять откуда начать.
  1. Составляем карту сети. Какой коммутатор куда подключён, каким каналом.
  2. Инвентаризируем коммутаторы. Сколько портов\сколько текущих пользователей\сколько потенциальных пользователей. Тип коммутатора и его возможности.
  3. Узнаём планы руководства по развитию фирмы, применению ИТ технологий, существованию в данном офисе.
  4. Подбираем оборудование с запасом. Здесь требуется подобрать оборудование с запасом по возможностям и портам. Желательно как можно более новое, чтобы его выпуск не прекратился через три месяца после начала проекта.
  5. Готовим план прокладки новых проводов к ядру сети (рассчитываем стоимость и оптики тоже!).
  6. Готовим план постепенной замены оборудования. План должен выглядеть примерно так:
    • Январь – замена центрального коммутатора. Плюсы: повышение надёжности работы все сети и доступа к серверной.
    • Февраль – замена коммутатора серверной, установка запасного коммутатора. Плюсы: повышение надёжности работы серверов, исключение точки отказа путём применения горячей замены.
    • Март – установка нового роутера. Плюсы: повышение уровня безопасности сети от внешних атак.
    • Апрель – установка нового свитча на 2 этаже. Плюсы: выделение «название подразделения» в отдельный vlan.
    • И так далее.
  7. Отдаём планы на экспертизу знакомым, либо на форум, либо в аудиторскую компанию для предотвращения детских ошибок, которые часто не принимаются в расчёт по причине привязанности к условиям конкретной компании, а не стандартам.
  8. Получаем заключение от независимых экспертов в том или ином виде. Корректируем свои планы.
  9. Готовим доклад перед руководством и получаем либо одобрение, либо отказ. В случае одобрения – повышаем свой профессиональный уровень, в случае отказа – снимаем с себя ответственность за сбои сетевого оборудования.


На этом всё.
Поделиться публикацией

Комментарии 116

    +1
    если у вас гигабитная сеть, нет IP-видеонаблюдения, нет IP-телефонии и все свитчи подключены к одному свитчу-ядру. Могу вам позавидовать

    А я бы посочувствовал. Навернулся свитч-ядро, и капут. Надобно сразу два ставить. Даже не в горячий резерв, а на параллельную работу.
    выделение «название подразделения» в отдельный vlan.

    Зачем?
      0
      Чтоб всей бухгалтерии разом перекрыть контактик, например.
        +2
        Вообще-то фен-шуй велит, чтобы фильтрация запросов в интернет осуществлялась на основе логина, а не IP адреса компьютера или префикса.
          0
          Сетевики о логинах ничего не слышали и слышать не желают.
          Но вообще доступ в интернет закрывается не адресами, а действительно проксей с AD аутентификацией.
            0
            Даже ASA уже позволяют в ACLях указывать логины…
              0
              Ошибаетесь — там опять же ip адреса.
              Архитектура построена так: на домен контроллер или компьютер в домене ставиться агент, который смотрит логи сервера AD на предмет логина. В логах пишется примерно так «user test1 logged on computer testcomp1» после этого агент по DNS смотрит ip адрес testcomp и скидывает инфу о соответствии логина ip адресу на ASA.
              Итого АСА, принимая первый пакет от пользователя, сверяет его с имеющейся в ней базе login-ip и пускает или не пускает.
                0
                Речь про то, что IP адреса в явном виде не указываются в конфигурации. Будут применяться те политики доступа, что назначены конкретному юзеру.
                  0
                  Неа. ASA оперирует только ip адесами. И если злоумышленник знает адрес пользователя с полными правами ему ничего не стоит установить любую сессию.
                    –1
                    А кто-то уже отменил защиту от спуфинга? Ну там uRPF, IP source guard и т.д.? Боюсь, у злоумышленника пупок развяжется спуфить адрес даже при общении в пределах VLANа.
                      0
                      Смысла спуфить, если на порту включен port-security?
                        0
                        Port-security спасет от массового флуда с подменой source mac, но вот от подмены ip адреса не защитит никак.
        0
        Мы сдаём некоторые помещения в аренду дружественной компании. Мне очень не нравится, когда там по ошибке втыкают свой DHCP, да и пользователям сети это тоже не нравится.
        Физика устроена таким образом, что мы вынуждены держать сети вместе, чтобы их правильно разнести и нужно управляемое оборудование.
        Хотя с подразделением в влан я возможно перегибаю. Но компанию в влан — однозначно.
          0
          Хотя с подразделением в влан я возможно перегибаю. Но компанию в влан — однозначно.

          Тут уж надо бы даже не VLANами, а VRFами разделять, с файрволом посередке… А если вопрос ограничения доступа не стоит, то есть простейшие механизмы, позволяющие исключить такие атаки. DHCP snooping, IP source guard, DAI и так далее. Суммарно: невозможно поднять свой DHCP сервер, невозможно настроить на компьютере адрес статически, невозможно арп спуфингом нарушить работу сети у других и т.д.
            0
            Управляемое оборудование же способно справиться с DHCP за портом, за которым его не должно быть
            0
            Ну например для того чтобы сократить размер широковещательных доменов, на случай бродкастовых штормов.
              0
              Мимо. «Размер широковещательных доменов на случай штормов» сокращают «географически», т.е. ограничить количество устройств, видящих каждый VLAN. В этом плане создавать новые VLANы на тех же устройствах бесполезно. Все равно шторм разойдется на всем сетевом железе, загадит все аплинки и выжрет ресурсы всех свитчей.
              Ну а что до уменьшения количества броадкастов — в современных 100мб сетях 500 компьютеров на VLAN не создаст никаких проблем, суммарный широковещательный трафик будет лишь десятки, край — сотни килобит.

              Но я главным образом имел в виду «зачем разделять пользователей по VLANам на основе подразделений?». Обычно принято дробить по диапазонам портов. Я вот люблю в модульных коммутаторах делать по VLANу на слот (48 портов обычно).
                0
                Ну вот кому-то нравится по отделам сокращать географисески. Тем боле в цискиных курсах так рекомендуется.

                Штормы бывают не от количества устройств, не редки ситуации когда подыхающая сетевушка ставит сеть раком.
                  0
                  Ну вот кому-то нравится по отделам сокращать географисески.

                  «Создадим на тех же свитчах еще один VLAN» не считается.
                  Штормы бывают не от количества устройств

                  А я писал иное?
                  И storm control на аксессных портах никто не отменял…
            +6
            ИМХО раздуваете панику. Во-первых «что может сделать… воткнувшись в порт бухгалтера»… А вы лучше спросите, что он может сделать оказавшись рядом со столом бухгалтера, на котором печать ООО лежит. Во-вторых, гигабитный core при нескольких 100Мбитных access покрывают нужды компании сильно с головой.

            Обычно проблемы начинаются, когда активка расползается по конторе в виде «хабика под столом» и т.д.
              +1
              Ну например стандарт PCI DSS (который в последнее время вызывает у меня сильную мигрень) требует, чтобы все неиспользуемые на коммутаторах порты непременно были отключены. И, по-моему, там требуется проверка здоровья подключаемых к сети компьютеров (доменный ли комп, кто залогинился, какая дата у антивирусных баз, применены ли такие-то политики, стоит ли такой-то софт и т.д.), иначе не пущать практически никуда (реализуется либо отдельным VRFом для NAC, либо портовым ACL для ISE). Хотя тут не уверен, нам это в требованиях не писали, но у нас это и так развернуто.

              Защита портов коммутатора и L2 — на самом деле весьма здравая идея, о которой действительно мало кто заботится.
                +2
                Что нужно защищать больше — порт на коммутаторе или доступ к столу главбуха?
                  +4
                  А что лежит в зоне ответственности сетевого инженера?
                    +2
                    Что лучше — апельсин или велосипед?

                    А по поводу печати: работал я в одном из крупнейших банков. Нужно было впервые поставить печать на материальном пропуске. Мне объяснили, как нужно действовать. Итак: подхожу к указанному столу, бормочу «здрасьте», хватаю со стола печать банка, штампую бумажки, возвращаю печать и ухожу. Владелица печати на меня даже не посмотрела.
                    А вот человек, совершивший глупость вида «можно мне поставить печать?», потерял минут 5 на объяснениях по поводу «что это за бумаги?».
                      +3
                      Я с таким сталкивался в одной крупной фарм компании. Аналогичная история про печать. Однако, считаю это расхлябанностью, которая и ведёт к проблемам большого масштаба. В зоне своей ответственности такого не позволяю, поэтому и бешу многих :)
                        0
                        На самом деле, можно и сделать копию печати по оттиску, и подделать подпись. Экспертизу ни то, ни другое не пройдет (а печать без валидной подписи тоже не годится). Так что сомневаюсь, что само по себе воровство печати организации способно вызвать эпический факап.
                          +1
                          И на самом деле странно сравнивать важность сетевой и физической безопасностей…
                    0
                    PCI DCC совсем не страшен — я его проходил несколько раз :)
                    Есть стандартные гайды по приведению оборудования к стандартам безопасности. Но тут тоже не стоит перегибать. Проже всего настроить авторизацию по 802.1X — тогда vlan будет динамически приезжать на порт пользователя. А ежели комп гостевой, то ему отдельный изолированный vlan вообще.
                    Очень удобно.
                      0
                      У нас есть NAC и скоро будет ISE. Это круче :)
                        +1
                        Я бы не сказал что круче… Cisco в промышленных масштабах скупает компании и привлекает на себя все больше технологий, но качество их конечно оставляет желать лучшего :(
                        BYOD еще не окрепло как понятие, как уже появился Cisco ISE. Чем проще, тем мне кажется надежнее.
                          0
                          ISE вполне прост, он вешает на порт ACL. Это проще, чем менять VLANы на портах.
                            0
                            К вопросу что проще — L2 или L3.
                              0
                              Вы не участвовали во внедрении того же NAC в нашей конторе для доменных машин. Да, факт перекидывания между VLANами вызывал колоссальные проблемы. И да, эти проблемы по определению исключены в случае ISE.
                              Хотя в случае изменения VLANа сразу после поднятия физики последствия будут менее неприятными.

                              И на самом деле L3 в случае L3 коммутатора будет даже малость попроще, чем L2. И хрен с ним, что надо глубже в пакет лазить.
                                0
                                А что такого особенного в вашей конторе, что у вас проблема с 802.1X возникла?
                                  0
                                  Его никто не внедрял. Речь шла про NAC. Он не имеет отношения к 802.1Х, который, между делом, сам по себе никак не соответствует нашим требованиям.
                                    0
                                    Если вы говорили о PCI DSS, то 802.1X как раз кучу вопросов по сети закрывает. И при этом не требует вложений если сеть на cisco и стоит домен
                                      0
                                      NAC развернут не для сертификации, а потому что «так надо».
                      0
                      отключать порты на практике не очень удобно, куда проще перевести все порты в неиспользуемы VLAN и по мере подключения переводить порты в нужный.
                        0
                        На неиспользуемом VLANе неизбежно должен быть VACL вида «deny IP any any» и т.д. Да, я думал об этом — но надо еще уточнить, удовлетворятся ли этим аудиторы…
                          0
                          Просто, на транковых портах не пропускайте этот влан за пределы коммутатора.
                            0
                            Не годится — устройства за этими портами смогут общаться между собой и атаковать control plane свитча. Без VACL обойтись не удастся. Ну или извернуться средствами PVLAN.
                              0
                              Каким например образом они могут атаковать контрол плейн?
                                0
                                Ну ту же CAM таблицу к примеру (хотя это скорее data plane). А может, в железке (ASICах) отыщутся баги с обработкой определенных пакетов… Смысл рисковать?
                                  0
                                  Уровень паранойи зашкаливает, по моему.
                                    0
                                    Если требование стандарта «shutdown на все неиспользуемые порты», то альтернатива должна давать не меньшую защиту.
                      0
                      Хабик под столом — согласен. Решение, которое потом превращает задачу установки новой розетки в кабинете в эпический квест, хотя в компании работает масса специалистов строительного плана и перестроить пару перегородок на этаже можно по телефонному звонку, аналогично и с электрическими розетками. Но, если придти и сказать, что этот исторический бардак надо убрать — квест. Несмотря на то, что от владельца стола\принтера и т.д. не требуется ровно ничего.
                        0
                        Хабик под столом тоже не проблема — если свичи управляемые, то на порту, с подключенным хабом устанавливается ограничение на кол-во мак адресов на порту и правило, которое первым n мак адресам разрешает работать, а остальных просто откидывает. Естественно правила типа «Каждый компьютер должен быть подключен в свой порт коммутатора, допускается подключение ip телефона и компьютера в один порт» должен быть прописан в политике компании по безопасности. Иначе настучат по голове за самоуправство.
                      0
                      Выбить денег на ровном месте? Сложно, но необходимо!
                      Забавная агитка, а чего не написали про гарантию на железки или с контрактов маржа сликом маленькая?
                        0
                        В моём случае гарантии уже давно никакой нет. Более того юридически железа не существует, т.к. покупали его юр лица, которые ликвидированы много лет назад. По балансу оборудования не передавали.
                        0
                        Если всё работает – пора обновлять оборудование.


                        Если все работает — не трогай!
                          +2
                          Я предпочитаю и пропагандирую метод трогать самому, планово и с головой. Чтобы для пользователя всё всегда работало. Профилактика дешевле лечения.
                            +1
                            А я поддерживаю.
                            Метод «не чини то, что не сломано» всегда ведет к огромной головной боли. Например, руководствуясь этим методом, нельзя ставить патчи, если вроде как ничего не глючит…
                              0
                              А вы не пробовали просто настроить грамотный мониторинг на все случаи жизни — чтобы смс присылало если чего не так.
                              Повторяю — грамотный, который позволяет не только факапы увидеть, но и общую текущую картину. По такому мониторингу можно посмотреть загрузки аплинков, спрогнозировать когда и где трафик упрется в аплинк и надо расширятся… Так же можно мониторить нестандартные поведения трафика и реагировать на них практически сразу.
                                0
                                Причем тут мониторинг?
                                Разумеется, есть целый отдел, занятый исключительно мониторингом и способный осуществлять самую базовую диагностику (потому СМС отсутствует — будет звонок). И естественно, имеется детальная информация о сети по данным с интерфейсов, с netflow, с сенсоров и т.д. Это все само собой разумеется.
                                  +1
                                  При том, что «планово и с головой» как раз и предполагает то, что уже есть картина сети и ее можно просмотреть как в реальном времени, так и историю за некоторое время. Исходя из истории поведения на сети можно уже предполагать замены и т.п. В противном случае лучше и вправду ен трогать.
                                  Я вас уверяю, что на точке обмена трафиком MSK IX стоят далеко не самые актуальные прошивки софта. И не потому, что кому-то лень, а потому, что не всегда знаешь — что произойдет в слачае обновления. Насколько может быть факап по времени. Где взять аналогичное оборудование для тестов, если оно все в продакшене?
                                  Реальная ситуация не всегда позволяет быть с актуальным софтом и сетевым оборудованием.
                                    0
                                    Реальная ситуация не всегда позволяет быть с актуальным софтом и сетевым оборудованием.

                                    А к апгрейду стоит подходить с умом. Читать рассылки bug toolkit'а и release notes. Смотреть, какие есть опасные для данной железки с данной конфигурацией баги. Может обнаружиться баг уровня catastrophic, на который железка может напороться в любой момент.

                                    Далеко ходить не надо. У меня пограничные BGP маршрутизаторы имеют (имели до недавнего времени) аптайм года 3. И вдруг при аварии на одном из каналов я заметил, что видимость интернета у нас далеко не полная, часть префиксов, полученных через резервные каналы, не попадала в таблицу BGP и виделась лишь в received-routes из-за soft-reconfiguration (даже при радикально более коротком AS-PATH и прочими равными). Поклирил нейбора — увиделись все, проблема ушла. Я открыл ради интереса список багов и выпал в осадок от того, какие связанные с BGP баги имели место быть в той версии. Там было штуки четыре severity 1, а менее опасных куда больше.
                                      0
                                      Для багов влияющих на компанию есть отдел безопасности.
                                        0
                                        Для связанных с роутингом багов? С какой стати? Вот за багами, представляющие собой вектора целенаправленной атаки на протоколы маршрутизации они действительно должны следить.
                                          0
                                          То о чем вы говорили так же может влиять на безопасность. Смотря какая политика безопасности у компании в общем.
                                            0
                                            Скорее — смотря какие безопасники. Даже с сетевыми безопасниками уровня CCIE Sec, сетевики могут считать их некомпетентными болванами, ничего не смыслящими в роутинге.
                                              0
                                              Вы сейчас безопасников оскорбили статусом CCIE Security. Они вообще знают про безопасность, а не про сети. :)
                                              Хоть это и нелепо звучит, но это именно так.
                                                0
                                                Безопаснику теоретически положено работать с VPNами, давать рекомендации по защите сети и т.д. CCIE Sec вполне это покрывает.
                                                  0
                                                  Направление CCIE по безопасности у циски очень специфическое. Для безопасности нужно не такое сертифицирование а CISSP например
                                                    0
                                                    CCIE Sec — сертификация не менеджера, а технаря. Который будет поддерживать системы, отвечающие за секьюрность.
                                                      0
                                                      В том-то и дело, что в отделе безопасности сидят менеджеры :)
                                                        0
                                                        Видимо, мы с сильно разными безопасниками общаемся. Некоторые непосредственно администрируют файрволы, VPNы, IPSы, сканеры wi-fi и т.д.
                                                          0
                                                          Да — это инженеры сетевого отдела (какое-нибудь подразденелие FW и т.п.). Они отвечают за настройку и отладку этих устройств и протоколов. А менеджеры отдела безопасности отвечают за политики безопасности и актуальность всего этим политикам — от софта и багов на нем, до решеток на окнах.
                                                            0
                                                            Нет, это — инженеры департамента информационной безопасности, они абсолютно изолированы от сетевиков (иерархии руководства пересекаются где-то на уровне членов правления) :) Ну а физические безопасники (решетки на окнах, СКУДы и так далее) к ним вообще никаким боком.
                                                              0
                                                              У кого как. Но в любом случае должны быть те, кто руками делают, должны быть те, кто архитектуру разрабатывают и те, кто из безопасности это одобряет. Вот та безопасность обычно и смотрит за актуализацией.
                          0
                          Про резерв запчастей ничего не написано. В целом — хорошо и применимо ко всем инфраструктурным проектам.
                            +1
                            Подбираем оборудование с запасом. Здесь требуется подобрать оборудование с запасом по возможностям и портам. Желательно как можно более новое, чтобы его выпуск не прекратился через три месяца после начала проекта.

                            Зачем подбирать «как можно более новое», если стоит проблема обосновать бюджет руководству?
                            Сейчас есть большой рынок б/у сетевого оборудования. За стоимость нового dlink'a можно без проблем купить пару cisco, которые уже лет 5 не производятся.
                            Опасаетесь за качество? Купите на одну больше, протестируйте и положите в шкаф.
                              +1
                              А почему не Длинки? L2-коммутаторы у них очень приличные, стоят копейки и идут с «пожизненной» гарантией.
                                0
                                Потому что все dlink'и которые я использовал благополучно сгорали или висли по питанию.
                                Пиком моего негодования по этому поводу было выгорание схемы питания у dlink'а des-30xx (точно модель не помню), который был подключен к ИБП APC серии rt (это которые с более менее нормальной развязкой питания).

                                А по поводу копеек, я бы поспорил.
                                Вот например 48 портовый DES-3052 стоит согласно яндекс маркету от 13 т.р.
                                Б/у Сisco C2950G-48-EI стоит менее 6т.р.
                                Мой выбор однозначен.
                                  0
                                  Древние каталисты продают на вес, потому что сотки на доступе уже откровенно мало.
                                  Сколько будет стоить [стекируемый] 48-ми портовый гигабитный коммутатор от Циски? DGS-3120-48TC стоит 39 тысяч рублей.
                                    +1
                                    Гигабит на доступе идет по моему начиная с серии 2960, она пока дорогая. Точно сказать не могу — посмотрите на shop.nag.ru.

                                    И расскажите, мне правда интересно, зачем на доступе больше сотки? У меня даже на горизонте нет таких задач.
                                      +1
                                      Сотка на аксесс для пользователей — выше крыши. На аплинк — несколько агрегированных гигабитов для фиксированных свитчей либо 10G для модульных. Никто не выдает пользователям гигабиты.
                                      У нас на типичном аксессе 4510R, нередко со старенькими supV, 100mb портов в среднем по 300-350 на шасси, аплинки 2 или 4 гигабита. Ни разу нигде не было даже намека на congestion.

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

                                      Тем более что у упомянутого DGS-3120-48TC нет ни одного 10G аплинка. Это уже даже не смешно. Oversubscription будет явно выше феншуйного 1/3…
                                        0
                                        У Cisco тоже есть модели без 10G аплинков (C2960S-48TS), это ответ на них.
                                          0
                                          Да у них и 3750-е есть той же серии. Годятся разве что если основной трафик ходит внутри свитча.
                                        +1
                                        Поддерживаю всех выше высказавшихся. Просвятите — это где откровенно мало 100 мегабит на access?
                                        В голову приходит только варианты iSCSI загрузки системы у всех пользователей или Vmware thin client — он в первых версиях забивал полосу под 60 mbps хотя сейчас вроде поуменьшили аппетит.
                                          0
                                          Развёртывание и миграция операционок и софта — вещи эпизодические, но полосу нагружают очень хорошо.
                                            0
                                            Вот именно эпизодические, для которых вполне хватает оставленных на выходные включенными компьютеров.
                                              0
                                              Некоторые работают 24х7, там выходными не отделаешься :)
                                              0
                                              Для разворачивания операционок 100мб/с на порту — выше крыши.
                                            0
                                            Есть хорошая алтернатива длинку и циске для гигабитного аксеса, это Allied Telesis AT-8000gs/24 цена 30 тыщ, стекируемый. Cisco like cli.
                                        0
                                        Зачем подбирать «как можно более новое»

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

                                          1. Продавец дает гарантию на б/у циски 3 месяца. За 10% цены — на год. За 30% цены — на три года.
                                          2. То что они не производятся ничего не значит, потому как купить их проблем нет никаких. К примеру сейчас я беру линейку 2950, а через пять лет я буду покупать 2960. Никаких проблем.
                                          3. Предыдущая эксплуатация конечно может быть неблагоприятной, но опять же — купите с запасом, протестируйте под нагрузкой и положите в шкаф. Решите сразу две проблемы — и сеть обновите и резерв создатите.
                                            +1
                                            Бывает так, что сеть до тебя уже выстроена и весьма неплохо, на хорошем оборудовании, ядро дублировано на 3COM гигабитных свичах L2. (2005й год). запас по портам и пропускной способности некоторый есть. А стоимость замены оборудования — 15-20 килобаксов. В таком случае затеивать обновление — не самый лучший совет :)
                                            Так что бывают случаи, когда знать все это полезно, но делать все равно ничего не надо, кроме как иметь план.
                                              0
                                              Иметь план при аварии разом выложить все 20 штук баксов, потому что сегодняшнее используемое в продакшен оборудование уже EOS и заменить таким же или починить не представляется реальным?
                                                0
                                                На тот момент не представлялось. Через 2 года — да, компания подросла и финансово попроще стало, IT директор появился.
                                                На данный момент — не знаю, я в IT уже 4й год не работаю.
                                                  0
                                                  А зачем покупать такое-же? За несколько лет свитчи ухудшаются? Покупайте новое, в кол-ве одна штука (а лучше имейте на складе, и докупаейте на склад) и все будет ок.
                                            0
                                            С аргументами автора в целом согласен, но по поводу финансирования — весьма спорный вопрос. Как мне кажется, есть два основных момента: вы, как администратор, формируете бюджет, который должен быть утвержден, в конечном счете, руководителем компании. Если руководитель — наемный менеджер, которому поставлены конкретные PKI (повышение продаж, доля на рынке и т.д.), то он, с высокой долей вероятности, внемлет вашим аргументам о необходимости закупки нового оборудования, так как у вас есть свой PKI (доступность, мощность, непрерывность), но если руководитель = владелец, то тут отношение совсем другое (IT только деньги тратит, да пользы от них никакой, и так все работает и т.д.). К тому же имеется эффект масштаба — купить один маршрутизатор или 1000, для модернизации большой сети, уже совершенно разный ценник.
                                              +3
                                              Забавно, что статья написана для уровня SMB-админов на все руки, а в комментариях затусили прожжёные enterprise-сетевики :)
                                                0
                                                Зато сразу есть к чему стремиться :)
                                                  0
                                                  Да можно и так стремиться — по сетям как минимум CCNA сдайте и сразу будет другой взгляд на процесс. А ещё ITIL и иже с ним для понимания лучших практик, там и про изменения написано, и про обновление оборудования и про финансирование и про бог знает что написано.
                                                    0
                                                    по сетям как минимум CCNA сдайте и сразу будет другой взгляд на процесс.

                                                    Есть такое явление, которое я называю «синдром CCNA». Симптом: человек, осиливший данную сертификацию, почему-то уверен, что он хоть что-то знает про работу сетей. Я сам им в свое время переболел.

                                                    Зато сразу есть к чему стремиться
                                                    Ну например из тех контор, где надо с боем выбивать нужное железо на жалкие $20k, я бы убегал быстрее ветра… Топик в основном про них и написан.
                                                      0
                                                      Есть такое явление, которое я называю «синдром CCNA». Симптом: человек, осиливший данную сертификацию, почему-то уверен, что он хоть что-то знает про работу сетей.

                                                      Слава богу, тут таких нет=))

                                                      Ну например из тех контор, где надо с боем выбивать нужное железо на жалкие $20k, я бы убегал быстрее ветра… Топик в основном про них и написан.

                                                      Тут в соседнем топике обсуждаем какая безумная сумма $300 баксов в мире серверного оборудования :)
                                                      0
                                                      CCNA — зло! Это отвратительнейший, на мой скромный взгляд, экзамен, при подготовке к которому человеку заливают в голову совершеннейше вредные вещи, типа router-on-stick! ITIL/ITSM — полезнейшая вещь, но только 2 версии, где процесс-ориентированный подход, так как в 3-й всё черезчур отдалено от наших реалий. Для ITIL рекомендую книгу Потоцкого, после прочтения коей я стал совсем по другому смотреть на свою повседневную деятельность.
                                                        0
                                                        Зло, не зло, а какие варианты есть для освоения начал сетей? Роутер-он-стик — вполне себе реалия малых сетей. Но фильтровать конечно нужно своей головой очень многое, куча исторических артефактов там, это точно. Особенно если человек вздумает готовиться по пятилетней давности учебникам…

                                                        А ссылку на описание хотя бы книги Потоцкого можно?
                                                          0
                                                          Называется «Введение в ITSM», гуляет по интернетам в фомате .doc, есть на рутрекере, по моему. По поводу CCNA: так получилось, что я его сдавал уже после сданных ROUTE и SWITCH и я был неприятно удивлен тем, что курс охватывает только самые вершки и явно давно не пересматривался.
                                                            0
                                                            За книгу спасибо. А по поводу CCNA — так если его сдавать после CCIE, он вообще покажется детским садом. Коим он в принципе и является по задумке его разработчиков, это первый уровень, после которого вообще человеку в руки можно давать циску, чтобы он не начал ей орехи колоть :)
                                                              0
                                                              Своим ученикам я всегда говорил, что CCNA это тот уровень, на котором если тебя найдут в серверной с консольным кабелем тебя не сразу пнут оттуда под зад, а сначала спросят, что ты там делаешь. А потом пнут под зад не смотря на ответ :)
                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                  0
                                                                  Собственно я о том же. Да и для администрирования сети уровня «главный офис + пара филиалов» его вполне достаточно.
                                                            0
                                                            совершеннейше вредные вещи, типа router-on-stick!

                                                            Ну как бы создавать на маршрутизируемых интерфейсах роутеров сабинтерфейсы — совершенно нормальная практика для компаний любого масштаба. Я правильно понимаю, что претензии идут к концепции «пользователи на L2 свитче, а default GW у них указывает на подключенный транком роутер»? Дык и это используется очень часто в типовой топологии мини-бранча, где сидят 20 сотрудников с IP телефонами. Топология: пара различных каналов заходит на роутер, он по ним поднимает DMVPN к примеру до разных ЦОДов, а третьим концом смотрит на свитч уровня 2960, на котором висят юзеры и телефоны. Не вижу никаких проблем с такой реализацией (подчеркиваю — только мелкого офиса). Или прикажете ставить 3560-е в каждый миниофис и поднимать пару SVI под голос и данные? Дороговато будет, а смысла — никакого.
                                                              0
                                                              Нет, немного не так. Сабинтерфейсы были нормальной практикой до появления модуля WIC-4ESW для 17xx серии.

                                                              Для SMB-офисов я сам сторонник установки дешевых L2 коммутаторов, тут я с Вами полностью согласен, но если нужно больше 1-го Vlan, то и терминировать их надо на маршрутизаторе не через сабы, а через нормальные Vlan, что можно сделать чере HWIC-4ESW, NM-16ESW и т.д. Если трафик между этими Vlan будет больше 100 Мб/с, то уже стоит озаботиться L3 коммутатором.
                                                                0
                                                                Сабинтерфейсы были нормальной практикой до появления модуля WIC-4ESW для 17xx серии.

                                                                Нет. Функциональность (особенно QoS) несравнима, etherswith модули в этом смысле крайне убоги.
                                                                если нужно больше 1-го Vlan, то и терминировать их надо на маршрутизаторе не через сабы, а через нормальные Vlan

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

                                                                Единственное применение etherswitch — если не хочется ставить отдельную железку-свитч, тогда можно втыкать в него конечных пользователей, сейчас у них даже PoE есть. Если отдельный свитч в любом случае будет, подключать его к hwic-4esw (если хватает маршрутизируемых портов и если к модулю больше ничего не подключено, т.е. исключив архитектуру «роутер — ядро/распределение») будет несусветной глупостью.
                                                                  0
                                                                  Вот одна: сравните информативность sh int:

                                                                  Vlan225 is up, line protocol is up
                                                                  Hardware is EtherSVI, address is 0019.e771.1d78 (bia 0019.e771.1d78)
                                                                  Description: — … — Internet address is .../30
                                                                  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
                                                                  reliability 255/255, txload 1/255, rxload 4/255
                                                                  Encapsulation ARPA, loopback not set
                                                                  ARP type: ARPA, ARP Timeout 04:00:00
                                                                  Last input 00:20:00, output never, output hang never
                                                                  Last clearing of «show interface» counters never
                                                                  Input queue: 0/75/1/0 (size/max/drops/flushes); Total output drops: 0
                                                                  Queueing strategy: fifo
                                                                  Output queue: 0/40 (size/max)
                                                                  5 minute input rate 1588000 bits/sec, 206 packets/sec
                                                                  5 minute output rate 774000 bits/sec, 198 packets/sec
                                                                  231685519 packets input, 3500754793 bytes, 0 no buffer
                                                                  Received 3 broadcasts, 0 runts, 0 giants, 0 throttles
                                                                  0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
                                                                  221143132 packets output, 2834337340 bytes, 0 underruns
                                                                  0 output errors, 1 interface resets
                                                                  0 unknown protocol drops
                                                                  0 output buffer failures, 0 output buffers swapped out

                                                                  и

                                                                  GigabitEthernet0/1.225 is up, line protocol is up
                                                                  Hardware is MV96340 Ethernet, address is 0019.e869.6ff9 (bia 0019.e869.6ff9)
                                                                  Description: — … — Internet address is .../30
                                                                  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
                                                                  reliability 255/255, txload 5/255, rxload 4/255
                                                                  Encapsulation 802.1Q Virtual LAN, Vlan ID 225.
                                                                  ARP type: ARPA, ARP Timeout 04:00:00
                                                                  Last clearing of «show interface» counters never
                                                                    0
                                                                    Обычно за статистикой по скорости передачи данных принято обращаться к SNMP-мониторилкам, не? Там всё есть…

                                                                    Я правильно понимаю, что ни одного иного аргумента в пользу «и терминировать их надо на маршрутизаторе не через сабы, а через нормальные Vlan» нету? И возможность увидеть скорость передачи пакетиков с определенным тегом Вы оцениваете примерно в $400?
                                                                      0
                                                                      Вы просили назвать — я назвал, а в ответ слышу демагогию про SNMP.
                                                                        0
                                                                        Какая же это демагогия?
                                                                        Счетчики на интерфейсах совершенно неинформативны. Весь мир следит за трафиком с помощью SNMP…

                                                                        Так все-таки: на каком основании Вы категорично заявили, что «router-on-a-stick» — «совершеннейше вредная вещь»? Только на основании объема вывода «show interface», правильно?
                                                                          0
                                                                          Дмитрий, я не собираюсь Вас в чем-либо убеждать, если вы сдавали CCNP, то должны знать, что router-on-a-stick шарит пропускную способность между сабинтерфейсами и является единой точкой отказа для сети (это то, что явно упоминается в CCNP SWITCH 642-813 Quick Reference). Так же, мой опыт позволяет говорить о повышении нагрузки на CPU маршрутизатора при использовании данного решения.
                                                    0
                                                    router-on-a-stick шарит пропускную способность между сабинтерфейсами и является единой точкой отказа для сети

                                                    А один проводок, заходящий в etherswitch модуль и несущий на себе несколько VLANов, не является в точности такой же единой точкой отказа?
                                                    Если Вы используете по одному физическому проводку на каждый VLAN, то это воистину кошмарно. Даже CCNA не станет делать такую глупость.
                                                    «Шарит пропускную способность» абсолютно не является проблемой по одной простой причине: ресурсов роутера не хватит для полной загрузки даже одного имеющегося у него физического интерфейса. Так что «пропускная способность» ни разу не является аргументом. Хотя при желании никто не мешает поднять сабы не на физике, а на порт-ченнеле.
                                                    это то, что явно упоминается в CCNP SWITCH 642-813 Quick Reference

                                                    Я сдавал CCNP еще когда про SWITCH никто не слышал :) С тех пор как-то ориентируюсь не на курсы, а на SRND, config guide'ы и так далее. Там информация малость более подробная и актуальная…
                                                    Но новый трек CCNP мне абсолютно не нравится. Ну кто додумался выкинуть из него QoS к примеру? Куда делась безопасность? Раньше «CCNP» значило «универсал с углубленным знанием роутинга-свитчинга», а сейчас это вообще что-то непонятное.
                                                    Так же, мой опыт позволяет говорить о повышении нагрузки на CPU маршрутизатора при использовании данного решения.

                                                    Откуда же эта нагрузка берется? :) Вы этим вопросом вообще занимались? У меня вот в обоих сценариях нагрузка одинаковая, как оно и должно быть. Рекомендую ознакомиться с www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186a00800a70f2.shtml к примеру…
                                                      0
                                                      Простите, что вмешиваюсь, но отходя от темы, как бы вы сейчас подходили к изучению Cisco оборудования? Мне интересно из практических соображений, хочу углубиться от банальной настройки роутеров 800 серии.
                                                        0
                                                        Конечно, начинать с линеек CCNA/CCNP, попутно изучая SRND, блоги именитых сетевиков и так далее. Сертификация дает некоторую отправную точку. Хотя, как я уже написал, обновление CCNP меня разочаровало.
                                                        Хотя TSHOOT например понравился…
                                                          0
                                                          Главное забыл.
                                                          Задружиться с местными сетевиками. Изучая новые темы, задавать им вопросы (зная меру и неназойливо). Выбить себе нормального железа под лабу с целью самообразования. Ненавязчиво продемонстрировать заинтересованность в более серьезной работе.

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

                                                    Самое читаемое