Все зависит что вкладывается в понятие — «управление виртуальной сетью». Создавать VLAN, профили виртуальных и физических портов, настривать ACL и QoS на этих портах, настраивать сервисные цепочки — все можно делать при помощи CLI на коммутаторе Nexus 1000V, для этого PNSC — не требуется.
PNSC требуется для управления VSG — писать политики безопасности удобнее при помощи интерфейса PNSC.
Для ASA1000V у Вас есть два варинта — или использовать PNSC или опять же CLI. При этом лицензии на PNSC отдельно покупать не нужно если планируется управлять Nexus1000V, VSG, ASA1000V.
Если планируется управлять CSR1000V (маршрутизатор) и Netscaler 1000V (балансировщик нагрузки), то лицензии на PNSC нужны. PNSC лицензируется по числу виртуальных апплаинсов, которые находятся в его контуре управления.
1. Про VSG только внутри виртуальной инфраструктуры — верно. «Железной» версии VSG не существует.
Зачем может понадобится вирутальная ASA?
Если рассматривать сценарий внедрения в Mid market/Enterprise, то железного МСЭ в ЦОД между серверами часто может и не быть (большая производительность часто стоит больших денег), а обеспечить межсетевое экранирование необходимо. Тут на сцену выходит МСЭ в виде виртуальной машины, который уступает в производительности железу, но функционально от него ничем не отличается. Виртуальной машиной можно быстро закрыть потребности в «прикрытии» какого то критичного сегмента. Таким образом часть серверов, которые размещаются в ЦОД может быть «прикрыта», а часть доступны «напрямую» без МСЭ.
Теперь сценарий SP. Провайдер создает для своих клиентов контейнеры, в которые его клиенты помещают свои вирутальные машины. Тут без вирутальной машины — никуда. Под каждого клиента железку/контекст не купишь, а полноценный сервис МСЭ нужен всем и сразу. И тут опять помогает сценарий использования МСЭ в виде виртуальной машины, опять же до тех пор пока клиенту хватает его производительности.
2. VSG является функциональностью, которая доступна в платной версии Nexus 1000V
3. Все верно. Для всех виртуализированных сервисных элементов используется PNSC (ранее известный под именем VNMC). В контуре управления PNSC сегодня находятся — Nexus1000V, VSG, CSR1000V, ASA1000V, Netscaler 1000V.
1. схема в лаборатории реализована на базе ASA1000V
2. ASA1000V поддерживает vPath
3. Отличия VSG от ASA заключаются в следующем — VSG реализует контроль доступа или выполняет микросегментацию внутри VLAN/VXLAN сегмента, а ASA на его границе. VSG не имеет в чистом виде пограничных функций — затерминировать Site-to-Site VPN или Remote access VPN, сделать NAT, поговорить с вышестоящим сетевым элементом по BGP или OSPF.
Возможности пограничного МСЭ ASA
C другой стороны ASA не умеет создавать политики контроля доступа между сегментам, основываясь на атрибутах вирутальных машин, таких как имя машины, название кластера и т.д. VSG умеет это в дополнение к написанию политик с использованием традиционных сетевых атрибутов — IP-адрес, протокол, порт.
Возможности VSG по созданию политки с использованием атрибутов VM
ASA может осущствлять пакетную фильтрацию на границе сегмента. Если возникнет необходимость сделать фильтрацию средствами ASA внутри сегмента, то тогда путь один — разбиение его на более мелкие сегменты — создание дополнительных VLAN/VXLAN.
И разрешите пожалуйста дополнить тему про MPLS. Возможно получится найти сервисные устройства в ЦОД с нативной поддержкой MPLS. На схеме ниже я изобразил абстрактную DPI систему с такой поддержкой. Но для остальных сервисных систем будь то виртуальные машины или физические устройства нужно будет использовать те транспортные механизмы, которые предлагает MPLS — где-то EoMPLS, где то VLAN. И тут — как на схеме ниже. Сложность при создании цепочки никуда не уходит.
1. vPath несмотря на то что начинается на букву v был разработан Cisco
2. Как я писал в статье — vPath технология, которую Вы можете использовать абстрагируясь от производителя гипервизора. Cisco поддерживает vPath в версиях Nexus 1000V для vSphere (VMware), Hyper-V (Microsoft). Поддержка vPath в версии N1K для KVM планируется. Таким образом не только экосистема VMware поддерживается на данный момент.
3. Технология vPath исходно действительно разрабатывалась Сisco, но постенно из «вендор-специфик» превращается в открытую. Тут аргументов несколько. Во первых — экосистема, а во вторых — стандартизация. Говоря про экосистему — в статье я приводил пример Citrix который поддерживает vPath в виртуализированной версии Netscaler. Говоря про стандартизацию — процес начался и про текущий статус стандартизации и архитектуру NSH планируем опубликовать еще одну статью.
4. По аналогам тоже есть пара мыслей:
DCSP/TOS — считать аналогом vPath нельзя. Это не оверлей, а всего лишь часть заголовка IP-пакета, которая в теории может использоваться для создания сервисной цепочки (практические реализации мне не неизвестны), но, как правило, используется для других целей (QoS).
MPLS — тут согласен, это оверлей и его, опять же в теории, можно было использовать для создания сервисных цепочек в ЦОД. Но мне пока не встречалась продуктизация этой идеи. А поддержку MPLS в сервисных устройствах для ЦОД (МСЭ, IPS и т.д.) можно наверное пересчитать по пальцам.
vPath в отличие от «общей шины» таки был «построен» и продуктизирован. По случайному совпадению Nexus 1000V с поддержкой vPath вышел на рынок в том же 2008 году, когда цитируемая книга была переведена на русский язык. Так что в этом году отмечаем 6-ти летие технологии с большой буквы «У» от слова Удобная.
PNSC требуется для управления VSG — писать политики безопасности удобнее при помощи интерфейса PNSC.
Для ASA1000V у Вас есть два варинта — или использовать PNSC или опять же CLI. При этом лицензии на PNSC отдельно покупать не нужно если планируется управлять Nexus1000V, VSG, ASA1000V.
Если планируется управлять CSR1000V (маршрутизатор) и Netscaler 1000V (балансировщик нагрузки), то лицензии на PNSC нужны. PNSC лицензируется по числу виртуальных апплаинсов, которые находятся в его контуре управления.
Зачем может понадобится вирутальная ASA?
Если рассматривать сценарий внедрения в Mid market/Enterprise, то железного МСЭ в ЦОД между серверами часто может и не быть (большая производительность часто стоит больших денег), а обеспечить межсетевое экранирование необходимо. Тут на сцену выходит МСЭ в виде виртуальной машины, который уступает в производительности железу, но функционально от него ничем не отличается. Виртуальной машиной можно быстро закрыть потребности в «прикрытии» какого то критичного сегмента. Таким образом часть серверов, которые размещаются в ЦОД может быть «прикрыта», а часть доступны «напрямую» без МСЭ.
Теперь сценарий SP. Провайдер создает для своих клиентов контейнеры, в которые его клиенты помещают свои вирутальные машины. Тут без вирутальной машины — никуда. Под каждого клиента железку/контекст не купишь, а полноценный сервис МСЭ нужен всем и сразу. И тут опять помогает сценарий использования МСЭ в виде виртуальной машины, опять же до тех пор пока клиенту хватает его производительности.
2. VSG является функциональностью, которая доступна в платной версии Nexus 1000V
3. Все верно. Для всех виртуализированных сервисных элементов используется PNSC (ранее известный под именем VNMC). В контуре управления PNSC сегодня находятся — Nexus1000V, VSG, CSR1000V, ASA1000V, Netscaler 1000V.
Сущности, которыми управляет PNSC
2. ASA1000V поддерживает vPath
3. Отличия VSG от ASA заключаются в следующем — VSG реализует контроль доступа или выполняет микросегментацию внутри VLAN/VXLAN сегмента, а ASA на его границе. VSG не имеет в чистом виде пограничных функций — затерминировать Site-to-Site VPN или Remote access VPN, сделать NAT, поговорить с вышестоящим сетевым элементом по BGP или OSPF.
Возможности пограничного МСЭ ASA
C другой стороны ASA не умеет создавать политики контроля доступа между сегментам, основываясь на атрибутах вирутальных машин, таких как имя машины, название кластера и т.д. VSG умеет это в дополнение к написанию политик с использованием традиционных сетевых атрибутов — IP-адрес, протокол, порт.
Возможности VSG по созданию политки с использованием атрибутов VM
ASA может осущствлять пакетную фильтрацию на границе сегмента. Если возникнет необходимость сделать фильтрацию средствами ASA внутри сегмента, то тогда путь один — разбиение его на более мелкие сегменты — создание дополнительных VLAN/VXLAN.
2. Как я писал в статье — vPath технология, которую Вы можете использовать абстрагируясь от производителя гипервизора. Cisco поддерживает vPath в версиях Nexus 1000V для vSphere (VMware), Hyper-V (Microsoft). Поддержка vPath в версии N1K для KVM планируется. Таким образом не только экосистема VMware поддерживается на данный момент.
3. Технология vPath исходно действительно разрабатывалась Сisco, но постенно из «вендор-специфик» превращается в открытую. Тут аргументов несколько. Во первых — экосистема, а во вторых — стандартизация. Говоря про экосистему — в статье я приводил пример Citrix который поддерживает vPath в виртуализированной версии Netscaler. Говоря про стандартизацию — процес начался и про текущий статус стандартизации и архитектуру NSH планируем опубликовать еще одну статью.
4. По аналогам тоже есть пара мыслей:
DCSP/TOS — считать аналогом vPath нельзя. Это не оверлей, а всего лишь часть заголовка IP-пакета, которая в теории может использоваться для создания сервисной цепочки (практические реализации мне не неизвестны), но, как правило, используется для других целей (QoS).
MPLS — тут согласен, это оверлей и его, опять же в теории, можно было использовать для создания сервисных цепочек в ЦОД. Но мне пока не встречалась продуктизация этой идеи. А поддержку MPLS в сервисных устройствах для ЦОД (МСЭ, IPS и т.д.) можно наверное пересчитать по пальцам.