Комментарии 15
Навеяло.
![](https://habrastorage.org/r/w780q1/getpro/habr/comment_images/b34/804/c64/b34804c64ffe07215482106eade215ac.jpg)
(с) «Жизнь внутри пузыря» Ашманов
… будет построена невообразимо мощная и быстрая «общая шина», позволяющая легко вызывать нужные объекты из любых локаций в сети, повторно использовать код, быстро создавать новые контентные проекты и так далее. В общем, стоит разработать общую шину и будет всем Щастье с большой буквы «Щ».
![](https://habrastorage.org/getpro/habr/comment_images/b34/804/c64/b34804c64ffe07215482106eade215ac.jpg)
(с) «Жизнь внутри пузыря» Ашманов
+1
vPath в отличие от «общей шины» таки был «построен» и продуктизирован. По случайному совпадению Nexus 1000V с поддержкой vPath вышел на рынок в том же 2008 году, когда цитируемая книга была переведена на русский язык. Так что в этом году отмечаем 6-ти летие технологии с большой буквы «У» от слова Удобная.
0
Вернее не переведена, а вышла. Сорри!
![](https://habrastorage.org/r/w1560/getpro/habr/comment_images/a26/00d/e9d/a2600de9dde56ffa2c1dec14e0ee0fe6.png)
![](https://habrastorage.org/getpro/habr/comment_images/a26/00d/e9d/a2600de9dde56ffa2c1dec14e0ee0fe6.png)
0
Это вендор-специфик технологии, которые работают в экосистеме VmWare.
Из аналогов технологии хочу отметить — DSCP/TOS и MPLS.
Из аналогов технологии хочу отметить — DSCP/TOS и MPLS.
0
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 и т.д.) можно наверное пересчитать по пальцам.
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 и т.д.) можно наверное пересчитать по пальцам.
+1
И разрешите пожалуйста дополнить тему про MPLS. Возможно получится найти сервисные устройства в ЦОД с нативной поддержкой MPLS. На схеме ниже я изобразил абстрактную DPI систему с такой поддержкой. Но для остальных сервисных систем будь то виртуальные машины или физические устройства нужно будет использовать те транспортные механизмы, которые предлагает MPLS — где-то EoMPLS, где то VLAN. И тут — как на схеме ниже. Сложность при создании цепочки никуда не уходит.
![](https://habrastorage.org/r/w1560/getpro/habr/comment_images/d65/048/659/d650486591b2272870fdc18a4ee2217d.png)
![](https://habrastorage.org/getpro/habr/comment_images/d65/048/659/d650486591b2272870fdc18a4ee2217d.png)
0
В чем нарисованы картинки?
0
«Текущая версия ASAv 9.2(1) не имеет поддержки vPath. Ее реализация планируется в ближайшее время.»
1)Как же вы реализовывали данную схему, если ASAv не поддерживает данную технологию?
2)Поддерживает ли данную технологию ASA1000V?
3)Мне по прежнему не совсем понятно, в чем отличие VSG от ASA? Разве ASA не может осуществлять пакетную фильтрацию? Не дублируется ли функционал?
1)Как же вы реализовывали данную схему, если ASAv не поддерживает данную технологию?
2)Поддерживает ли данную технологию ASA1000V?
3)Мне по прежнему не совсем понятно, в чем отличие VSG от ASA? Разве ASA не может осуществлять пакетную фильтрацию? Не дублируется ли функционал?
0
1. схема в лаборатории реализована на базе ASA1000V
2. ASA1000V поддерживает vPath
3. Отличия VSG от ASA заключаются в следующем — VSG реализует контроль доступа или выполняет микросегментацию внутри VLAN/VXLAN сегмента, а ASA на его границе. VSG не имеет в чистом виде пограничных функций — затерминировать Site-to-Site VPN или Remote access VPN, сделать NAT, поговорить с вышестоящим сетевым элементом по BGP или OSPF.
![](https://habrastorage.org/r/w1560/getpro/habr/comment_images/9ff/8e1/cf6/9ff8e1cf6715982298b81e73f62b73d1.png)
Возможности пограничного МСЭ ASA
C другой стороны ASA не умеет создавать политики контроля доступа между сегментам, основываясь на атрибутах вирутальных машин, таких как имя машины, название кластера и т.д. VSG умеет это в дополнение к написанию политик с использованием традиционных сетевых атрибутов — IP-адрес, протокол, порт.
![](https://habrastorage.org/r/w1560/getpro/habr/comment_images/c69/bb6/128/c69bb6128422baecdda7a2a58f958d9a.png)
Возможности VSG по созданию политки с использованием атрибутов VM
ASA может осущствлять пакетную фильтрацию на границе сегмента. Если возникнет необходимость сделать фильтрацию средствами ASA внутри сегмента, то тогда путь один — разбиение его на более мелкие сегменты — создание дополнительных VLAN/VXLAN.
2. ASA1000V поддерживает vPath
3. Отличия VSG от ASA заключаются в следующем — VSG реализует контроль доступа или выполняет микросегментацию внутри VLAN/VXLAN сегмента, а ASA на его границе. VSG не имеет в чистом виде пограничных функций — затерминировать Site-to-Site VPN или Remote access VPN, сделать NAT, поговорить с вышестоящим сетевым элементом по BGP или OSPF.
![](https://habrastorage.org/getpro/habr/comment_images/9ff/8e1/cf6/9ff8e1cf6715982298b81e73f62b73d1.png)
Возможности пограничного МСЭ ASA
C другой стороны ASA не умеет создавать политики контроля доступа между сегментам, основываясь на атрибутах вирутальных машин, таких как имя машины, название кластера и т.д. VSG умеет это в дополнение к написанию политик с использованием традиционных сетевых атрибутов — IP-адрес, протокол, порт.
![](https://habrastorage.org/getpro/habr/comment_images/c69/bb6/128/c69bb6128422baecdda7a2a58f958d9a.png)
Возможности VSG по созданию политки с использованием атрибутов VM
ASA может осущствлять пакетную фильтрацию на границе сегмента. Если возникнет необходимость сделать фильтрацию средствами ASA внутри сегмента, то тогда путь один — разбиение его на более мелкие сегменты — создание дополнительных VLAN/VXLAN.
+1
Спасибо за ответ!
1)Ну тогда получается что мы можем использовать внутри виртуальной инфраструктуры только VSG, а для межсетевого экранирования использовать традиционный железный МЭ. Если все виртуальные машины у нас находятся в одном VLAN и доступ между виртуалками разграничивает VSG, то зачем нам виртуальная ASA? Не думаю что внутри виртуальной инфраструктуры может понадобиться VPN, NAT, BGP.
2)Cisco Nexus 1000v доступен в бесплатной версии, а есть ли подобные решения для VSG?
3)На сколько я знаю для управления Cisco ASA 1000V используется дополнительно ПО (vnmc). А какое по используется для управления VSG?
1)Ну тогда получается что мы можем использовать внутри виртуальной инфраструктуры только VSG, а для межсетевого экранирования использовать традиционный железный МЭ. Если все виртуальные машины у нас находятся в одном VLAN и доступ между виртуалками разграничивает VSG, то зачем нам виртуальная ASA? Не думаю что внутри виртуальной инфраструктуры может понадобиться VPN, NAT, BGP.
2)Cisco Nexus 1000v доступен в бесплатной версии, а есть ли подобные решения для VSG?
3)На сколько я знаю для управления Cisco ASA 1000V используется дополнительно ПО (vnmc). А какое по используется для управления VSG?
0
1. Про VSG только внутри виртуальной инфраструктуры — верно. «Железной» версии VSG не существует.
Зачем может понадобится вирутальная ASA?
Если рассматривать сценарий внедрения в Mid market/Enterprise, то железного МСЭ в ЦОД между серверами часто может и не быть (большая производительность часто стоит больших денег), а обеспечить межсетевое экранирование необходимо. Тут на сцену выходит МСЭ в виде виртуальной машины, который уступает в производительности железу, но функционально от него ничем не отличается. Виртуальной машиной можно быстро закрыть потребности в «прикрытии» какого то критичного сегмента. Таким образом часть серверов, которые размещаются в ЦОД может быть «прикрыта», а часть доступны «напрямую» без МСЭ.
Теперь сценарий SP. Провайдер создает для своих клиентов контейнеры, в которые его клиенты помещают свои вирутальные машины. Тут без вирутальной машины — никуда. Под каждого клиента железку/контекст не купишь, а полноценный сервис МСЭ нужен всем и сразу. И тут опять помогает сценарий использования МСЭ в виде виртуальной машины, опять же до тех пор пока клиенту хватает его производительности.
2. VSG является функциональностью, которая доступна в платной версии Nexus 1000V
3. Все верно. Для всех виртуализированных сервисных элементов используется PNSC (ранее известный под именем VNMC). В контуре управления PNSC сегодня находятся — Nexus1000V, VSG, CSR1000V, ASA1000V, Netscaler 1000V.
![](https://habrastorage.org/r/w1560/getpro/habr/comment_images/fb1/4ec/012/fb14ec012e7f4bd25c39c6bd67df9c55.png)
Сущности, которыми управляет PNSC
Зачем может понадобится вирутальная ASA?
Если рассматривать сценарий внедрения в Mid market/Enterprise, то железного МСЭ в ЦОД между серверами часто может и не быть (большая производительность часто стоит больших денег), а обеспечить межсетевое экранирование необходимо. Тут на сцену выходит МСЭ в виде виртуальной машины, который уступает в производительности железу, но функционально от него ничем не отличается. Виртуальной машиной можно быстро закрыть потребности в «прикрытии» какого то критичного сегмента. Таким образом часть серверов, которые размещаются в ЦОД может быть «прикрыта», а часть доступны «напрямую» без МСЭ.
Теперь сценарий SP. Провайдер создает для своих клиентов контейнеры, в которые его клиенты помещают свои вирутальные машины. Тут без вирутальной машины — никуда. Под каждого клиента железку/контекст не купишь, а полноценный сервис МСЭ нужен всем и сразу. И тут опять помогает сценарий использования МСЭ в виде виртуальной машины, опять же до тех пор пока клиенту хватает его производительности.
2. VSG является функциональностью, которая доступна в платной версии Nexus 1000V
3. Все верно. Для всех виртуализированных сервисных элементов используется PNSC (ранее известный под именем VNMC). В контуре управления PNSC сегодня находятся — Nexus1000V, VSG, CSR1000V, ASA1000V, Netscaler 1000V.
![](https://habrastorage.org/getpro/habr/comment_images/fb1/4ec/012/fb14ec012e7f4bd25c39c6bd67df9c55.png)
Сущности, которыми управляет PNSC
0
Правильно ли я понимаю, что без PNSC не возможно управлять виртуальной сетью. Если это так, то затраты на организацию защиты виртуальной инфраструктуры возрастают, в связи с необходимостью покупки PNSC. Как лицензируется PNSC? Исходя из кол-ва виртуальных устройств или так же, по процессорам?
Заранее спасибо за ответы.
Заранее спасибо за ответы.
0
Все зависит что вкладывается в понятие — «управление виртуальной сетью». Создавать VLAN, профили виртуальных и физических портов, настривать ACL и QoS на этих портах, настраивать сервисные цепочки — все можно делать при помощи CLI на коммутаторе Nexus 1000V, для этого PNSC — не требуется.
PNSC требуется для управления VSG — писать политики безопасности удобнее при помощи интерфейса PNSC.
Для ASA1000V у Вас есть два варинта — или использовать PNSC или опять же CLI. При этом лицензии на PNSC отдельно покупать не нужно если планируется управлять Nexus1000V, VSG, ASA1000V.
Если планируется управлять CSR1000V (маршрутизатор) и Netscaler 1000V (балансировщик нагрузки), то лицензии на PNSC нужны. PNSC лицензируется по числу виртуальных апплаинсов, которые находятся в его контуре управления.
PNSC требуется для управления VSG — писать политики безопасности удобнее при помощи интерфейса PNSC.
Для ASA1000V у Вас есть два варинта — или использовать PNSC или опять же CLI. При этом лицензии на PNSC отдельно покупать не нужно если планируется управлять Nexus1000V, VSG, ASA1000V.
Если планируется управлять CSR1000V (маршрутизатор) и Netscaler 1000V (балансировщик нагрузки), то лицензии на PNSC нужны. PNSC лицензируется по числу виртуальных апплаинсов, которые находятся в его контуре управления.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
vPath или как создать сервисную цепочку в среде виртуализации