Здравствуйте! Потребуется Policy Enforcer. Это оркестратор системы. Он платный. Лицензируется по количеству устройств, которые входят в Фабрику безопасносности. Цена весьма демократичная. Т.к. у Вас есть сторонние коммутаторы, то, чтобы их интегрировать, потребуется сервер политик. С коммутаторами он будет общаться по RADIUS. Коммутаторы, в этом случае используют 802.1x для блокировки зараженных хостов. Данные о том кого блокировать поступают в сервер политик от Policy Enforcer. Что касается подсчета количества устройств, то при использовании сервера политик, все коммутаторы с 802.1х будут покрываться лицензий на одно устройство (т.к. в данном случае коннектор для сервера политик является этим одним устройством). JATP не обязателен, т.к. у Вас уже есть SkyATP. Данные о заражении/подозрительных действиях будут поступать оттуда.

@@junipernetworks3993 а цена на policy enforcer ежегодная или разовая?

@@Scaran100 Разовая, т.е. вечная/постоянная лицензия

Здравствуйте! Если интересует самостоятельная подготовка, а не в авторизованных учебных центрах, то ресурсов весьма много: - наверное, первое с чего можно начать это книги издательства O'Reily. Таковых довольно много. Например, Junos Enterprise Switching, Junos Enterprise Routing 2nd Edition, Juniper SRX Series, Juniper MX Series 2nd Edition, Juniper QFX10000 Series, Juniper QFX5100 Series, MPLS in the SDN Era и т.д. - второе, это книги серий Distinguished Engineering Books и Day One Library www.juniper.net/us/en/training/jnbooks/ Day One Library можно скачивать прямо с сайта (при наличии учетной записи) - третье, это официальная документация. Есть дизайн и архитектурные гайды, руководства по настройке с описанием что и как работает www.juniper.net/documentation/ - далее, это openlearning.juniper.net/ и - www.juniper.net/us/en/training/junos-genius/

Да, для AppFW нужна лицензия. Называется Application Secure. Туда же входит и AppQoS, и Application Policy Based Routing. По нюансам работы и опциям для тюнинга Unified Policy планируется отдельное видео. Например, обращения к KZfaq или Facebook, по умолчанию, будут определяться как отдельное приложение. Про SkyATP Ок. Постараемся сделать.

@@junipernetworks3993 а Application Secure это отдельная лицензия или входит в JSE?

@@TheLisovic Здравствуйте! Она входит в JSE. Это и является единственным отличием JSB от JSE. Однако, JSB/JSE - это старая модель, которая, правда, пока еще имеет место быть. Т.е. можно заказывать и по-старому и по-новому. В актуально модели лицензирования остается только JSB, а все остальные лицензии приобретаются как бандлы (Advanced, Premium) как подписка www.juniper.net/documentation/en_US/release-independent/licensing/topics/topic-map/flex-software-subscription-model.html

Спасибо за высокую оценку!

Это зависит от того насколько строгой хотите сделать инспекцию. Т.е. получается баланс/компромис между удоством и простотой с одной стороны и безопасностью, сложностью конфигурирования и поддержки сценария где у Вас очень много зон с другой. Очевидно, что в сценарии зона-сервис Вы можете жестко задать кто с кем по каким портам с использованием каких приложений коммуницирует. При этом, включив в политике IPS с релевантными сигнатурами Вы усиливаете глубину инспеции, или антивирус/проверку объектов в песочнице там где в потоке данных могут передаваться какие объекты типа исполняемых файлов, скриптов и т.п.

"из повестовования на 33:55 непонятно чем будут обмениваться два spine S-11 и S-12 между собой?" Ответ: ========== Если это вопрос в контексте оптимизации флудинга, то для этого spine ничем специально обмениваться не должны. Каждый коммутатор Leaf выберет для себя пару Spine в качестве FR (для отказоустойчивости) и оповестит их об этом в LIE пакетах. Если вопрос в другом, поясняйте. ==========

"на 35:51 непонятно чем закончится процесс распространения маршрутной информации посредством FR, как SS-X будут получать маршруты от L-YY, они будут видны только через два FR S-11 и S-13 в в качестве next-hop? Или они должны каким-то образом узнать о связях S-12 и S-14 с L-YY и передавать их маршрутную информацию на Север, не меняя next-hop?" Ответ: ========== Обращаю внимание, что в северном направлении протокол ведет себя как Link-State, т.е. распространяет информацио о топологии и префиксах (тут, как и в OSPF/ISIS, нет такого, что каждый промежуточный узел меняет Next-Hop). Таким образом, каждый вышестоящий узел знает топологию ниже себя (как соединены маршрутизаторы) и какие префиксы на на этих маршрутизаторах существуют. По сути SS-X будут получать от каждого Leaf по две копии N-TIE (абсолютно идентичные, две - потому что у нас два FR). Усли бы не было FR, то количество копий было бы равно количеству Spine узлов. ==========

@@junipernetworks3993 Александр, прошу прощения, дал неправильный хронометраз на 30:55 есть стык между S-11 и S-12. Непонятен смысл стыка, ибо по нему никакой флудинга информации не происходит. Но если рассматривать поведение RIFT в северном напрвлении как link-state, то по логике эти спайны должны обменяться всем тем, что они получили с Leaf коммутаторов. А в обратном направлении должен возникнуть unequal-CMP и часть трафика должна разбалансится в т.ч. в стык между спайнами. Правильно? Прошу пояснить смысл создания этого стыка?

@@junipernetworks3993 Таким образом, каждый вышестоящий узел знает топологию ниже себя (как соединены маршрутизаторы) и какие префиксы на на этих маршрутизаторах существуют. =================== Все верно, но на уровне S-11 - S-14 нет связи прямой между FR и оставшиимся спайнами на этом уровне. Флуд на север происходит только от двух FR. Соответвенно они отдадут только "своё". Откуда два FR узнают, что творится на S-12 и S-14? Или поледним двум будет также дозволено пофлудить наверх "своё"? но тогда смысл в FR теряется.

Каждый Spine будет отправлять свои (которые он сгенерил) N-TIE на уровень выше (к SuperSpine / ToF на слайде в презентации) вне зависимости является он FR или нет. Пересылать же N-TIE с уровня Leaf на уровень ToF могут только Spine узлы, которые выбраны как FR.

Прежде всего спасибо за вопрос. UTM не поддерживался с первого релиза, но стал поддерживаться начиная с 18.2R1, да и функционал лицензируются. Валерий www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/nfx-series/nfx150-getting-started.pdf

@@junipernetworks3993 Извиняюсь, из этого вывода мы не видим конечно. Но вот из shell мы видим вывод top: CPU 0: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 1: 0.0% user, 0.0% nice, 0.0% system, 0.3% interrupt, 99.7% idle CPU 2: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle CPU 3: 0.3% user, 0.0% nice, 0.3% system, 0.5% interrupt, 98.9% idle CPU 4: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 533M Active, 1460M Inact, 667M Wired, 354M Buf, 13G Free 5 ядер и 16 Гбайт DDR А также qemu демон запущен с параметрами памяти 16г, и 5 ядер. root@rts-mx204> show vmhost processes | grep qemu root 4364 1 99 11:59 ? 03:06:38 /usr/bin/qemu-system-x86_64 -name vjunos -S -machine pc-i440fx-1.7,accel=kvm,usb=off -m 16384 -realtime mlock=on -smp 5,sockets=5,cores=1,threads=1 ...... Вопрос, это так идет от вендора с таким ограничениями??? или он побывал у кого-то?

Здравствуйте! Все верно, как я уже упоминал Junos работает в качестве виртуальной машины. Этой виртуальной машине выделено 5 ядер (именно поэтому и был задан вопрос "где Вы видите 4 ядра?"). Остальные 3 ядра никуда не делись и никем не украдены. Они существуют, просто зарезервированы под другие цели и виртуальной машине Junos не видны. Не могу согласиться, что это какие-то "ограничения". Сами по себе ядра и память не являются функциональными характеристиками. Важно то как производитель распорядился этими ресурсами, оптимизировал их для выполнения функций и обеспечения заданной масштабируемости (скейлинга).

Здравствуйте! Junos работает в качестве виртуальной машины на ресурсах Routing-Engine. Поэтому Вы и видите те ресурсы, которые выделены этой виртуальной машине. Однако, из каких данных результатов вывода show chassis routing-engine Вы видите, что там 4 ядра?

На смену существующим, стандартным сеткам частот в 50GHz и 100GHz channel spacing, описанным в стандарте ITU G.694, для каналов со скоростью передачи 10G/40G/100G, приходит стандарт ITU G.694.1. В стандарте G.694 каждый канал должен иметь собственную частоту. Стандарт G 694.1 описывает flexible grid pattern и предназначен, в первую очередь, увеличить эффективность использования полосы пропускания DWDM линии для каналов со скоростью передачи выше 100G. Новый стандарт использует 12,5GHz channel spacing, способ совмещать разные по скорости каналы Nx12,5GHz, например: 100G (4×12.5 GHz), 400G (12×12.5 GHz), вплоть до 1Tb. G.694.1 обратно совместим с G.694 в плане использования ROADM. Ранее оптические фильтры было сконструированы под ITU-T c-grid с определенным спейсингом. В новых системах спейсинг в фильтрах не привязан к Ghz ITU. Теперь есть возможность под определенный канал расширить спейсинг с минимальным шагом, конечно.

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

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

@@junipernetworks3993 спасибо за ответ! Однако, непонятно каким образом можно заранее узнать характеристики хроматической дисперсии на участке, где будет работать передатчик с математической компенсацией. Как происходит замер дисперсии на пролете, интерактивно или вручную с последущей закладкой данных в контроллер передатчика с небольшим гистерезисом? И почему на 10G трансиверах такой подход невозможен, просто невыгодно?

Здравствуйте! Параметры хроматической дисперсии можно рассчитать вручную. Величина на километр указывается в параметрах оптического кабеля, который используется. Максимальная величина, которую может компенсировать когерентный передатчик автоматически, указывается в характеристиках передатчика. 10G передатчик, как и когерентный, самостоятельно компенсирует дисперсию тоже, величина указывается в характеристике передатчика, но величина компенсации значительно меньше, нежели у когерентного, как правило - это 80 км. Т.о., при проектировании, для когерентного сигнала, необходимо контролировать показатель суммарной дисперсии всех оптических пролетов, не допускать превышения максимального показателя характеристики излучателя. Для 10G контролировать показания на каждом пролете.

Андрей, привет! Это оговорка, конечно же.

Вопрос немного не в той теме (все таки данное видео про маршрутизацию, а не про безопасность), но по существу вопроса: очень напряженно этим занимаемся. Например, по данным NSS Labs за 2016 и 2017 год превосходим в "отлове" атак некоторых как Вы выразились "лидеров". А вообще, все зависит от того по каким критериям оценивать кто лидер, а кто нет. Предполагаю, что Вы имеете в виду лидеров по Гартнеру. Juniper вот уже второй год подряд растет и по Гартнеру в том числе.

Juniper Networks Россия, спасибо за подробный ответ. Комментарии не по теме, потому что я знаю по маршрутизации вы самые лучшие) вы совершенно верно отметили насчет сравнение по гартнеру. Все таки хотелось бы видеть такие видео по безопасности, так как в казахстане это сейчас актуальный тренд)

На данном канале есть видео по безопасности, в частности по SDSN и по UserFW. Мы будем стараться как можно чаще выклывать что-то новенькое. Безопасность также в большом приоритете.