Pull to refresh

Comments 33

Шпионажа со стороны «товарищей» не опасаетесь совсем?
Стана происхождения думаю не будет важна. Основная часть оборудования за рубежом делается у всяких «товарищей». Гарантии все равно не будет на 100%.
Оборудование, работающее полностью автономно, без связки с вендором (через патчи, обновления, лицензии, или просто напрямую), в XXI веке или не производится, или неконкурентоспособно. При формировании политик ИБ компании это обстоятельство надо учитывать.
со стороны американцев не опасаются
а какого шпионажа вы ожидаете? у одного из ведущих интеграторов по ИБ? А также по искоренению непониманию в данной сфере — специально создан такой глобальный институт, как Huawei Cyber Security Transparency Centre.
www.huawei.com/en/press-events/news/2019/3/huawei-cyber-security-transparency-centre-brussels
Его задача, как раз и убирать такой Black PR, который все ещё PR )
UFO just landed and posted this here
Наоборот. Есть рекомендация в госконторах не использовать в новых проектах CISCO, ZTE, из-за риска санкций. Проекты выполняются на оборудовании Huawei. Возможно еще что-то.
не буду делать рекламу, но помимо Huawei — на наш рынок пришло еще много китайских производителей, к которым нет такой глобальной «аллергии». Живут и продают вполне неплохо
ZTE тоно такая-же китайская компания, как и Huawei.
Не совсем китайская: 51,8 % акций принадлежит КНР.
И новость годовой давности:
В настоящее время ZTE планирует разместить $400 млн на депозитном счете в подконтрольном США банке, чтобы выполнить последнее условия для снятия американских санкций. Ранее ZTE согласилась выплатить $1 млрд штрафа, сменить руководителей и выполнить некоторые другие условия американского регулятора. Согласно существующим соглашениям, правительство США получит доступ к $400 млн, если ZTE не сменит весь руководящий состав компании.
Проект был инициирован около года назад, завершен в феврале. Тогда «последние события» даже на горизонте не просматривались. Подобные риски есть всегда, здесь мы «в одной лодке» с нашими заказчиками.
UFO just landed and posted this here
так с серверами — это все-таки кросс-лицензированный x86, с которым пресловутый Entity List — позволяет поддерживать текущие контракты и обязательства. С точки зрения сетевых продуктов — влияние минимальное
У хуавей с поставками серверов/СХД/VDI традиционно трудности — не раз на эти грабли наступал с разными заказчиками. Трудности вплоть до невозможности цену посчитать.
Почему IS-IS? Это довольно экзотический протокол для использовании в андерлее L3 фабрик, т.к. далеко не все ведоры его умеют в дата-центр коммуторах, ospf тут был бы всё же универсальнее. А вообще, имхо, bgp больше подходит в качестве протокола маршрутизации в L3 фабрике, т.к. куда лучше масштабируется, но в сети семью парами лифов, на масштабируемость конечно пофиг.
Вы имеете в виду, организовать маршрутизацию по BGP не только на overlay, но и на underlay? Мы посчитали, что для сети из 7 пар лифов (на самом деле 8, т. к. присутствует ещё одна пара border leaves) это некоторый overkill.
Что до OSPF vs IS-IS — для сети такого размера это действительно значения не имеет, но у нас был не самый положительный опыт с OSPF в предыдущей нашей сети, и мы хотели попробовать что-то новое.
Так Huawei пришел из Телеком со стандартным де-факто IS-IS, его реализация в Underlay вполне обоснована, в тч из-за нативного dual-stack механизма.
Внезапно, проприетарная L3 фабрика у juniper (virtual chassis fabric) — основана на IS-IS. А тут в целом что-то похожее…
VCF — это L2 фабрика, а не L3 так-то. Благо для L3 фабрик сейчас ничего проприентарного не нужно, кроме разве что mlag у части вендор-лиз, джун благо умеет нативный EVPN multihoming
Не увидел, как вы роутите vrf'ы, используете EVPN Type5 маршруты? Или тяние каждый влан vxlan'ом кудато на отдельную коробку, где уже роутите между собой?
Мы используем оба варианта — для приложений/пользователей, которым достаточно обычной L3-связности, используем первый вариант, а если нужно организовать «растянутый» broadcast domain — то второй вариант. В следующей части статьи попробуем разрисовать подробнее.
UFO just landed and posted this here
До модернизации у нас так и было — ничего никуда не инкапсулировалось. Но в какой-то момент мы обнаружили, что между некоторыми кроссовыми и серверными есть кабели подразделения А, и кабели подразделения Б, и ещё кабели подразделения В, и хорошо бы ещё кабель протянуть, на 16 волокон, или даже на 32. Сетью с L2/L3 VPN рулить всё же проще, по крайней мере типовые задачи лучше поддаются автоматизации.
UFO just landed and posted this here
UFO just landed and posted this here
текст самобытный и аутентичный, может в копирайтеры для диктаторов? Успех гарантирован!
UFO just landed and posted this here
Хорошая статья, но обратил внимание на одну деталь:
Организациям разного профиля — банкам,… — под их задачи и стандарты нужны определённые типы сетей, специфика которых понятна и стандартизирована. Однако с нами такое не прокатит.
Не уверен, что мы говорим об одном и том же, но как работник банка хочу заметить, что проектирование сетей в банке может строиться по такому принципу: «Так, тут у нас будет техподдержка, тут — девочки с приемной сидеть, здесь — конференц-зал для стейкхолдеров, а сюда мы воткнем наш главный монолит! Никого не забыли? Тфу, да нет конечно же!».

После чего спустя какое-то время всем отделам разработки и QA приходится решать такие инересные задачи: «Как расширять внутреннюю инфраструктуру, когда некуда», «Как ввести новую методологию 'УЖЕ СЕЙЧАС ПРЯМО СРОЧНО', когда сервер под это дело получить можно будет в лучшем случае через пол года, если вообще дойдет очередь», или «Как провести нагрузочное тестирование сервиса и не уронить внутреннюю сеть».

Возможно, конечно, ошибаюсь и в России стандарты другие, чем «на западе».
Да, вы правы. Если в банке заводится собственная разработка/QA (а сейчас такие — все, или скоро будут), его ИТ-службам приходится решать проблемы, очень похожие на наши.
Улыбнуло «Порядок работы над сложной автоматизированной системой пока лучше всего описан в ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания», поэтому мы работали по нему. И уже на стадиях формирования требований и разработки концепции мы столкнулись с первыми трудностями. » — что ж там в 34-м такого нашли? Или замполит эту фразу дописал? Джету — привет!
Все 34-е госты изучать и использовать не обязательно, там много воды и мусора. Но упомянутый небольшой документ считаю одним из самых важных. Фактически, в нём описан правильный порядок работы над сложной системой, и не пропущена ни одна важная стадия (за исключением корректировки рабочей документации после опытнй эксплуатции).
Так почему же именно Хуавей? Чем не подошли другие вендоры?
Мне как новичок в сетей, такие статьи очень интересны, несмотря на то что не все понимаю. Спасибо.
Sign up to leave a comment.