Как я и написал в самом начале, у нас нет задачи рекламировать конкретный продукт. В первую очередь мы ищем заинтересованных сетевых инженеров, которые в своей работе применяют новые подходы\технологии, готовые делиться информацией и пробовать новое. Свой подход мы постарались изложить в статье. Если вы хотите узнать про наш продукт (системные требования, функционал и тд), прошу написать на указанную почту или посмотрите на доменное имя.
По поводу банальных слов, извините, вынужден с вами не согласиться. На практике мало кто использует потоковую телеметрию для сбора данных с сетевого оборудования.
Если вы действительно применяете все заявленные технологии, прошу ответить на некоторые вопросы, думаю это было бы полезно и интересно всем читателям:
Какими технологиями вы пользуетесь для мониторинга вашей сети? (SNMP, Syslog, etc)
Используете вы скрипты (python, tcl) для получения дополнительной информации с оборудования? Какой?
Есть ли необходимость получать более детальную информацию о состоянии протоколов маршрутизации с вашей сети? (OSPF SPF run, LSA counters, BGP routes (accepted, filtered, rejected)
Используете ли вы Overlay технологии (VXLAN, MPLS). Если да, то есть ли мониторинг специфичной для данных технологий информации. (Routes per VRF, MAC per VNI)?
Важно ли вам иметь историю по изменениям основных таблиц форвардинга на сети (MAC, Adjacency, Routes)?
Какими технологиями вы пользуетесь для мониторинга вашей сети? (SNMP, Syslog, etc)
Спасибо за интересную статью. Подскажите пожалуйста насколько это возможно, как вы производите мониторинг сетевой инфраструктуры? Собираете телеметрию с помощью snmp или уже streaming telemetry? Продукт самописный или купленный\опенсорс?
Спасибо за комментарий!
NETCONF — это уже следующий уровень зрелости, как нам видится. Если ansible — это первый этап, если так можно выразиться (пусть меня поправят) — template-based automation, то netconf — это уже более программистский подход, model-driven. Здесь YANG, XML, модели данных. Сама идея структурированного, программисткого подхода к сети требует серьезной команды, но к этому все должно прийти в итоге. Идея единообразного api на базе netconf/yang — это громко, амбициозно и заслуживает отдельной беседы
Спасибо за комментарий!
Тут в первую очередь вопрос подхода, как мы и писали в статье. Каждый сам решает, как ему сделать. Мы верим, что в светлом будущем рутинные\стандартные задачи будут делаться автоматически «по кнопке», не тратя ресурсы.
Касательно вашего комментария
«Думаю, на два-три порядка больше, чем время сэкономленное при выкатке конфига» — это бесспорно. Времени было затрачено сильно много. Но тут классический момент — на этом примере было изучено много подводных камней, которых никак и нигде не узнаешь. Какие модули для какого оборудования лучше использовать, какие параметры модулей, и как лучше вообще не делать. Конкретный пример не про экономию — можно было написать блокнотик с командами и положить его себе под кровать, это проще, и тоже сработает. Это скорее про возможности, подход и средства. Преимущества данного конкретного примера — сеть перестраивается полностью по кнопке и правильно, и про это можно не думать.
«написанием инструкции для человека» — вот здесь главный момент и от чего мы хотим уйти. Не должно быть никаких инструкций для человека — это вообще не человеческое) инструкции они для машин. Если есть подробная и понятная инструкция — доверим это машине.
Спасибо за комментарий! Мы их очень ценим)
«такие резервы должны работать всегда» — согласен, но полностью держать работающий резерв в онлайне — это значит для каждого из сегментов держать дополнительное OSPF соседство. Это довольно затратно для RP CORE коммутатора да и в целом не нужно. Часть emergency маршрутизатора всегда в онлайне и служит для резервного доступа в сеть.
«Зачем ложить интерфейсы?» — как правило сами железки не падают. Ну или крайне редко. Падает логика внутри самих устройств. Что-то дропается непонятно почему, сессии зависают, голос булькает и т.д., при этом OSPF/BGP работают и в плане сети все хорошо. Интерфейсы кладутся жестко — мы точно уверены, что нет никаких возможностей для трафика пойти через FW.
«зачем менять Косты других маршрутов?» — потому что можем) ну и для перестраховки и красоты. Они и правда пропадают, и в целом мера излишняя, но мы любим такие.
«Не хватает VRRP для автоматического переезда шлюзов обслуживаемых сетей на резервные роутеры» — Это так же в тему падения железок, но не логики. да и никак нам не поднять VRRP кластер между кластером межсетевых экранов и emergency маршрутизатором. К тому же нам нужно сохранить NAT адрес для исходящего трафика. И поправить еще несколько вещей в конфиге — стандартными средствами не обойтись.
В целом задача была сделать Cold резерв в варианте «Разбейте в случае необходимости». Чтобы не было лишнего присутствия в сети и лишней нагрузки и логики. Это делается для того, чтобы никогда не пригодилось.
В статье говорится «What Hold Security found is not related to the breach in the U.S., which Equifax disclosed last week.» То есть это не совсем одно и то же, но Ваш пример тоже показательный:) все это потому что не выстроены процессы, недостаточно что-то купить, этим надо еще уметь пользоваться.
Не очень понял, как этот тезис помогает подтвердить то, что написано выше.
Во-первых, статус СТР-К сейчас под большим вопросом, его сейчас мало кто применяет, в основном 17 и 21 приказ ФСТЭК.
Во-вторых, выходит за пределы КЗ и что? Когда писался СТР-К нового РД на МЭ еще не было. Защищенный канал до ЦОД, там стоит МЭ, на котором ACL для всех объектов. А до ЦОД — криптография, эти площадки ходят в интернет через ЦОД, если ходят вообще.
магпро — он создает большие задержки в канале, что в данном случае было непозволительно
криптопро — задержек особо не создавал, но плохо масштабируемый продукт и производитель больше не развивает решение (к сожалению)
1) Есть выход сети за пределы контролируемой зоны, значит будьте любезны МЭ, если у вас сеть то железный МЭ, если единичный АРМ или сервер можно софтовым обойтись (привет ФСТЭК)
это оценочное суждение, если Вы сможете привести конкретные цитаты из нормативки, я готов с Вами согласиться=)
спасибо за Ваш комментарий. Не совсем так, в самих радиологических кабинетах нет выхода в интернет (то есть не обязательно, чтоб там был МЭ класса 4А, может быть и 4Б или 4В, то есть софт), поэтому наша задача состоит в организации защищенных каналов связи до ЦОД, МЭ 4А может в ЦОДе стоять. А уже из ЦОД может быть выход в интернет, например. Программные СКЗИ действительно рассматривались, но они не показали себя с лучшей стороны в данной конкретной задаче.
Локально ничего не хранится, там тонкий клиент стоит, поэтому большое внимание уделяется задержкам в канале, все сразу в ЦОД передается, но компьютеры в радиологическом кабинете оборудованы средствами защиты информации (СЗИ от НСД, Антивирус и тд)
Этот факт очень даже способствует защите персональных данных. Если Вы сталкивались с медицинскими организациями, то наверно знаете, что у них нет в штате выделенного специалиста по информационной безопасности, там в основном ИТ-специалисты широкого профиля. То есть обеспечить высокий уровень безопасности проблематично (патчменеджмент, антивирусная защита, учет железа и софта хотя бы). Когда же все централизовано, это повышает требования по ИБ, но гораздо проще найти нескольких сотрудников в центр и обеспечить нужный уровень, чем искать для каждой ЛПУ.
согласен с Вами, что в первую очередь данное оборудование используется для выполнения требований законодательства. Данной статьей я как раз хотел донести информацию, что не нужно после него ставить дополнительное шифрование и ждать что ViPNet помрет:) графики я как раз привел, чтоб была возможность убедиться, что это оборудование работает. Если у Вас есть какие-то вопросы по работе оборудования, то я готов на них ответить.
Спасибо, за Ваш комментарий. Вы думаете, я эти графики сам рисовал? :) это скриншоты из системы мониторинга. В общем, уверяю Вас, оборудование работает и трафик ходит через него. Если у вас будет возможность столкнуться с ЛПУ в Москве еще раз, можете убедиться в том, что оборудование стоит и работает.
Спасибо за комментарии, в целом со всем согласен кроме четвертого. Но тут скорее уже дело вкуса и предпочитаемого способа восприятия информации (например, кто-то лучше воспринимает информацию визуально, кто-то лучше на слух). Видимо, у Вас бэкграунд разработчика, у меня больше аналитическо-математический, мне не обязательно программировать, чтобы понять логику работы.
Спасибо за комментарий. Будем расширять и дополнять информацию, раз есть интерес.
спасибо, что зашли на наш сайт
спасибо за идеи для новых статей, расскажем про потоковую телеметрию более подробно
Спасибо за ваш комментарий!
Как я и написал в самом начале, у нас нет задачи рекламировать конкретный продукт. В первую очередь мы ищем заинтересованных сетевых инженеров, которые в своей работе применяют новые подходы\технологии, готовые делиться информацией и пробовать новое. Свой подход мы постарались изложить в статье. Если вы хотите узнать про наш продукт (системные требования, функционал и тд), прошу написать на указанную почту или посмотрите на доменное имя.
По поводу банальных слов, извините, вынужден с вами не согласиться. На практике мало кто использует потоковую телеметрию для сбора данных с сетевого оборудования.
Если вы действительно применяете все заявленные технологии, прошу ответить на некоторые вопросы, думаю это было бы полезно и интересно всем читателям:
Какими технологиями вы пользуетесь для мониторинга вашей сети? (SNMP, Syslog, etc)
Используете вы скрипты (python, tcl) для получения дополнительной информации с оборудования? Какой?
Есть ли необходимость получать более детальную информацию о состоянии протоколов маршрутизации с вашей сети? (OSPF SPF run, LSA counters, BGP routes (accepted, filtered, rejected)
Используете ли вы Overlay технологии (VXLAN, MPLS). Если да, то есть ли мониторинг специфичной для данных технологий информации. (Routes per VRF, MAC per VNI)?
Важно ли вам иметь историю по изменениям основных таблиц форвардинга на сети (MAC, Adjacency, Routes)?
Какими технологиями вы пользуетесь для мониторинга вашей сети? (SNMP, Syslog, etc)
NETCONF — это уже следующий уровень зрелости, как нам видится. Если ansible — это первый этап, если так можно выразиться (пусть меня поправят) — template-based automation, то netconf — это уже более программистский подход, model-driven. Здесь YANG, XML, модели данных. Сама идея структурированного, программисткого подхода к сети требует серьезной команды, но к этому все должно прийти в итоге. Идея единообразного api на базе netconf/yang — это громко, амбициозно и заслуживает отдельной беседы
Тут в первую очередь вопрос подхода, как мы и писали в статье. Каждый сам решает, как ему сделать. Мы верим, что в светлом будущем рутинные\стандартные задачи будут делаться автоматически «по кнопке», не тратя ресурсы.
Касательно вашего комментария
«Думаю, на два-три порядка больше, чем время сэкономленное при выкатке конфига» — это бесспорно. Времени было затрачено сильно много. Но тут классический момент — на этом примере было изучено много подводных камней, которых никак и нигде не узнаешь. Какие модули для какого оборудования лучше использовать, какие параметры модулей, и как лучше вообще не делать. Конкретный пример не про экономию — можно было написать блокнотик с командами и положить его себе под кровать, это проще, и тоже сработает. Это скорее про возможности, подход и средства. Преимущества данного конкретного примера — сеть перестраивается полностью по кнопке и правильно, и про это можно не думать.
«написанием инструкции для человека» — вот здесь главный момент и от чего мы хотим уйти. Не должно быть никаких инструкций для человека — это вообще не человеческое) инструкции они для машин. Если есть подробная и понятная инструкция — доверим это машине.
«такие резервы должны работать всегда» — согласен, но полностью держать работающий резерв в онлайне — это значит для каждого из сегментов держать дополнительное OSPF соседство. Это довольно затратно для RP CORE коммутатора да и в целом не нужно. Часть emergency маршрутизатора всегда в онлайне и служит для резервного доступа в сеть.
«Зачем ложить интерфейсы?» — как правило сами железки не падают. Ну или крайне редко. Падает логика внутри самих устройств. Что-то дропается непонятно почему, сессии зависают, голос булькает и т.д., при этом OSPF/BGP работают и в плане сети все хорошо. Интерфейсы кладутся жестко — мы точно уверены, что нет никаких возможностей для трафика пойти через FW.
«зачем менять Косты других маршрутов?» — потому что можем) ну и для перестраховки и красоты. Они и правда пропадают, и в целом мера излишняя, но мы любим такие.
«Не хватает VRRP для автоматического переезда шлюзов обслуживаемых сетей на резервные роутеры» — Это так же в тему падения железок, но не логики. да и никак нам не поднять VRRP кластер между кластером межсетевых экранов и emergency маршрутизатором. К тому же нам нужно сохранить NAT адрес для исходящего трафика. И поправить еще несколько вещей в конфиге — стандартными средствами не обойтись.
В целом задача была сделать Cold резерв в варианте «Разбейте в случае необходимости». Чтобы не было лишнего присутствия в сети и лишней нагрузки и логики. Это делается для того, чтобы никогда не пригодилось.
Во-первых, статус СТР-К сейчас под большим вопросом, его сейчас мало кто применяет, в основном 17 и 21 приказ ФСТЭК.
Во-вторых, выходит за пределы КЗ и что? Когда писался СТР-К нового РД на МЭ еще не было. Защищенный канал до ЦОД, там стоит МЭ, на котором ACL для всех объектов. А до ЦОД — криптография, эти площадки ходят в интернет через ЦОД, если ходят вообще.
криптопро — задержек особо не создавал, но плохо масштабируемый продукт и производитель больше не развивает решение (к сожалению)
это оценочное суждение, если Вы сможете привести конкретные цитаты из нормативки, я готов с Вами согласиться=)