Максим Федотенко

gallery/1435337774_facebook
gallery/1435337799_twitter
gallery/logo

Технические требования и рекомендации по защите виртуальной инфраструктуры на базе VMware vSphere

gallery/vsphere.avatar

2013 год

Часть 1. Сетевая инфраструктура

Межсетевое взаимодействие

В рамках данной статьи мы попытаемся рассмотреть основные технические требования и рекомендации по защите виртуальной инфраструктуры, организованной на базе VMware vSphere. На момент написания статьи наиболее актуальной версией vSphere являлась версия 4.1 update 1. Все требования и рекомендации приводятся здесь с учетом того, что виртуальная инфраструктура служит для поддержания так называемого частного облака (Private Cloud) внутри одной организации.

В части 1 статьи попытаемся рассмотреть требования, которые могут предъявляться организацией к сетевой архитектуре виртуальной инфраструктуры vSphere.

Естественно, одна из основных идеологий при построении защищенной сети организации – это идеология построения подсетей, разделенных межсетевым экраном или другими средствами разграничения сетевого взаимодействия. Наиболее ярким образцом шаблонов построения такой сетевой архитектуры, на мой взгляд, является архитектура Cisco SAFE. Попытаемся в рамках данной статьи привязаться именно к ней. Cisco SAFE предлагает использовать зоны в сети организации, представленные на рисунке ниже.

gallery/vsphere.1.01.зоны сети организации

Рисунок 1. Зоны сети организации [1]

Список литературы

[1] http://www.cisco.com/assets/cdc_content_elements/images/netsol/cwc/hiLevel_view_522x312.jpg

[2] VMware vSphere 4.1 Security Hardening Guide. Пункт NAR 01

[3] VMware vSphere 4.1 Security Hardening Guide. Пункт NAR 01, NAR 02, NAR 03

[4] VMware White Paper. VMware vNetwork Distributed Switch: Migration and Configuration

[5] VMware vSphere 4.1 Security Hardening Guide. Пункт NAR 01, NAR 02, NAR 03

[6] VMware vSphere 4.1 Security Hardening Guide. VMware vSphere Hardening Guide Introduction. Recommendation Level. Стр.4-5

[7] VMware vSphere 4.0 (4.1) Security Hardening Guide. NMT 10, NMT 11

[8] VMware vSphere 4.0 (4.1) Security Hardening Guide. NCN 06

[9] VMware vSphere 4.0 (4.1) Security Hardening Guide. NCN 07, NCN 08

[10] VMware vSphere 4.0 (4.1) Security Hardening Guide. NCN 05

[11] VMware vSphere 4.0 (4.1) Security Hardening Guide. NCN 02

[12] VMware vSphere 4.0 (4.1) Security Hardening Guide. NCN 03

[13] VMware vSphere 4.0 (4.1) Security Hardening Guide. NCN 04

[14] VMware White Paper. VMware Network I/O Control: Architecture, Performance and Best Practices. Глава “NetIOC Architecture”

[15] VMware White Paper. VMware Network I/O Control: Architecture, Performance and Best Practice. Раздел “Test Scenario 3: Using Multiple vMotion Traffic Flows”

[16] Cisco Nexus 1000V High Availability and Redundancy Configuration Guide

[17] Cisco Nexus 1000V Security Configuration Guide. Chapter 15. Disabling HTTP Server.

[18] Cisco Nexus 1000V Series Switches Deployment Guide. Version 2. Chapter: Cisco Nexus 1000V Series Theory of Operation. Стр. 19-20 “System VLANs”

[19] Cisco Nexus 1000V System Management Configuration Guide. Chapter 9. Configuring Local SPAN and ERSPAN. “Configuring a Local SPAN Session”

[20] Cisco Nexus 1000V System Management Configuration Guide. Chapter 9. Configuring Local SPAN and ERSPAN. “Configuring a ERSPAN Session”

[21] Cisco Nexus 1000V Interface Configuration Guide. Chapter 4. Configuring Virtual Ethernet Interfaces. “Enabling or Disabling a vEthernet Interface”

[22] Cisco Nexus 1000V Quality of Service Configuration Guide. Chapter 2. Configuring QoS Classification.

[23] Cisco Nexus 1000V Quality of Service Configuration Guide. Chapter 6. Configuring Class Based Weighted Fair Queuing.

[24] Cisco Nexus 1000V System Management Configuration Guide. Chapter 10. Configuring SNMP. раздел “SNMPv3”

[25] Cisco Nexus 1000V System Management Configuration Guide. Chapter 10. Configuring SNMP раздел “SNMP Functional Overview”

[26] Cisco Nexus 1000V System Management Configuration Guide. Chapter 12. Configuring System Message Logging. раздел “Configuring System Message Logging for Modules”

[27] VMware vSphere 4.0 (4.1) Security Hardening Guide. Пункт HLG 01

[28] isco Nexus 1000V System Management Cofiguration Guide. Chapter 12. Configuring System Message Logging. раздел “Configuring syslog Servers”

[29] VMware Knowledge Base. Статья 1003804

[30] Статья “VMware Infrastructure 3 in a Cisco Network Environment”, стр.17

В контексте данной статьи нас интересуют два левых столбца зон, которые относятся собственно к площадке, где находятся основные вычислительные мощности организации. Если опускаться на более низкий уровень сетевых модулей, то, в одном из архитектурных вариантов сети организации, сеть можно представить набором модулей, изображенных на следующем рисунке. На рисунке отмечены также какие модули к каким зонам сети принадлежат.

gallery/vsphere.1.02.модули сети организации

Рисунок 2. Модули сети организации

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

Вот в такую сетевую инфраструктуру нам желательно вписать нашу инфраструктуру виртуализации наиболее уместным способом с точки зрения ее защиты.

Для более удобного оперирования различными сетями в виртуальной инфраструктуре давайте введем обозначения сетей виртуальной инфраструктуры:

  • Сеть vManagement. Данная сеть используется для подключения к серверу управления инфраструктурой vCenter служебных консолей каждого сервера ESX(i), управления Nexus VSM, предоставления доступа к серверам для  управления и мониторинга. Она является служебной сетью и должна принадлежать модулю Management.
  • Сеть vMotion. Данная сеть используется для обеспечения процесса миграции виртуальных машин (VMotion) между серверами ESX(i), она является служебной сетью и не относится ни к одному модулю сети.
  • Сеть vFT. Данная сеть используется для обеспечения процесса отказоустойчивости виртуальных машин из-за аппаратного сбоя (Fault Tolerance) между серверами ESX(i), она, как и сеть vMotion, является служебной сетью и не относится ни к одному модулю сети.
  • Сеть vGuest. Данная сеть используется виртуальными машинами для взаимодействия между собой и предоставления доступа к физической сети. Под сетью vGuest подразумеваются VLAN-ы, принадлежащие одному из следующих модулей сети (см. Рисунок 2):

-  Data Center
-  Extranet DMZ
-  Public Services DMZ
-  Corporate Internet Access
-  Remote Access VPN
-  Internet VPN

  • Сеть vStorage. Данная сеть используется ESX(i) для подключения к СХД  (Fiber Channel / iSCSI / NFS), она является служебной сетью. В случае с Fiber Channel не относится ни к одному модулю сети (т.к. сеть ), а в случае с iSCSI и NFS может относиться к модулю, в котором находится хранилище. Возможно и выделение для работы с хранилищами данных отдельной IP-сети, но в рамках Cisco SAFE такой модуль сети не предусмотрен и мы не будем в рамках данной статьи ее отделять.

Обобщенная функциональная схема виртуальной инфраструктуры с учетом введенных сетей приведена на следующем рисунке. При этом надо понимать, что мы полагаем, что сети vGuest, принадлежащие разным модулям сети, взаимодействуют между собой через средства межсетевого экранирования.

gallery/vsphere.1.03.функциональная схема сетевой архитектуры

Рисунок 3. Функциональная схема сетевой архитектуры виртуальной инфраструктуры

Итак, какие могут быть предъявляться требования к сетевой архитектуре виртуальной инфраструктуры.

Сеть vManagement

Сеть vManagement может быть как отдельным VLAN-ом модуля Management, так и находиться в общем адресном пространстве модуля Management. Рекомендуется, с точки зрения разделения средств управления виртуальной инфраструктуры и других систем, выделять сеть vManagement в отдельный VLAN и маршрутизацию осуществлять на межсетевом экране с использованием соответствующих правил фильтрации[2], что особенно полезно для больших организаций.

В сеть vManagement должны быть включены:

  • Интерфейсы управления ESX(i)
  • Сервер управления инфраструктурой vCenter
  • Прокси-сервер резервного копирования VMware Consolidated Backup (VCB)
  • VMware Update Manager
  • ВМ с развернутыми  в ней средствами управления  и мониторинга виртуальной инфраструктуры
  • и т.п.

Доступ администраторов к ESX(i), серверам управления и мониторинга, расположенных в сети vManagement, должен осуществляться с использованием межсетевого экранирования, т.к., по сути, это доступ между модулями сети User LAN и Management.

В организациях для управления серверами часто используются такие технологии IPMI как HP iLo или DELL DRAC. Желательно, чтобы интерфейсы ESX(i), с которыми работают данные технологии управления, также принадлежали  модулю Management, его отдельному VLAN или сети vManagement.

vMotion и vFT

Служебные сети vMotion и vFT должны быть отделены от других сетей при помощи VLAN и не должны маршрутизироваться, либо маршрутизироваться только с сетями того же назначения.

vGuest

Перейдем теперь к сетям vGuest. Очевидно, что принципы разделения сетей, присущие “физическому” миру, должны выполнять и в виртуальном. Поэтому основное требование, предъявляемое к архитектуре сетей vGuest, – это разделение сетей, принадлежащим различным модулям, по разным виртуальным сетям (VLAN).

К организации сетей vGuest с точки зрения разграничения доступа в виртуальной инфраструктуре может быть много подходов. В данной статье мы рассмотрим два. Первый – использование разного аппаратного обеспечения виртуальными машинами разных сетевых зон, второй – использование единого аппаратного обеспечения для всех виртуальных машин.

В первом варианте виртуальные машины, принадлежащие различным зонам сети (зона Data Center, зона Extranet, зона Internet Edge), располагаются на различных наборах ESX(i), не взаимодействующим между собой. При этом виртуальные машины, принадлежащие разным модулям сети в одной и той же зоне, могут обрабатываться на одних наборах ESX(i). Этот вариант отражен на Рисунок 4.

В данном варианте не предлагается располагать виртуальные машины, принадлежащие разным модулям одной зоны, на разном аппаратном обеспечении исходя из соотношения “цена-качество”, а также в следствие того, что описание требований в предлагаемом варианте получается более общим и при желании его можно легко свести к другим вариантам.

gallery/vsphere.1.04.функциональная схема сетей vguest 1

Рисунок 4. Функциональная схема сетей vGuest виртуальной инфраструктуры. Вариант 1 с разбиением зон сети по наборам ESX(i), не взаимодействующим друг с другом

Почему первый вариант имеет право на жизнь? Потому что, во-первых, разделение VLAN-ов различных сетевых зон происходит не на виртуальном уровне (виртуальных коммутаторах), а на физическом. Гипервизор ESX(i) уже не без грешков с точки зрения информационной безопасности, а что еще будет… Поэтому хотя бы некоторые фундаментальные функции разграничения доступа желательно выносить на физический уровень (аппаратные сетевые устройства). Во-вторых, обычно в организациях настройкой виртуальных коммутаторов занимаются администраторы виртуальной инфраструктуры, а не “сетевики”, т.е. не происходит разграничения полномочий “сервера – сеть”. Также работа с сетевыми настройками является не свойственной администраторам виртуальной инфраструктуры функцией, они часто “плавают” в этом функционале и могут просто случайно настроить неправильно взаимодействие между модулями сети. А в при такой архитектуре мы в большей степени застрахованы от ошибок при коммутации в виртуальной инфраструктуре.

Во втором варианте все модули сети обрабатываются на едином наборе ESX(i), все сервера которого могут взаимодействовать между собой. Такая ситуация показана на Рисунок 5.

gallery/vsphere.1.05.функциональная схема сетей vguest 2

Рисунок 5. Функциональная схема сетей vGuest виртуальной инфраструктуры. Вариант 2 с обработкой модулей сети на едином наборе ESX(i)

Такой вариант значительно экономит ресурсы, т.к. не нужно держать раздельные аппаратные платформы для разных зон сети, но, очевидно, более уязвим к атакам на виртуальную инфраструктуру. При этом возможно использовать отдельные виртуальные коммутаторы для каждой из зон сети vGuest (Data Center, Extranet, Internet Edge), а значит и отдельные сетевые адаптеры, или единый виртуальный коммутатор для всех зон vGuest. На мой взгляд, риски здесь либо во взломе гипервизора и доступа к гостевым машинам, что не зависит от использования одного коммутатора или нескольких, либо в ошибках в конфигурации сети, а для этого сеть лучше настраивать сетевым администраторам.

Как уже говорилось, в контексте данной статьи мы рассматриваем только тот случай, когда разграничение доступа между сетями vGuest происходит средствами межсетевого экранирования, расположенными вне виртуальной инфраструктуры. В этом случае виртуальные коммутаторы должны работать в режиме тегирования на уровне виртуального коммутатора (Virtual Switching Tagging, VST) и все VLAN-ы, обрабатываемые ими, в транках уходить на физические коммутаторы, маршрутизаторы или межсетевые экраны.

При этом для того, чтобы не допускать маршрутизации сетей внутри виртуальной среды, каждая виртуальная машина должна быть подключена только к одному модулю сети (в простом случае иметь только один сетевой адаптер) и, соответственно, только к одному виртуальному коммутатору. Одновременное подключение виртуальных машин к двум и более модулям сети или виртуальным коммутаторам может допускаться только в случае, когда они выполняют роль виртуальных устройств обеспечения сетевой безопасности, например МЭ или IDS.

Очевидно, что при проектировании виртуальной инфраструктуры необходимо постараться не забыть о средствах обнаружения/предотвращения вторжений (IDS/IPS), функционирующих в сети vGuest. Обнаружение вторжений стОит скорее проводить специализированными средствами физической среды, т.к. виртуальным будет необходимо достаточно много разделяемого процессорного времени, а реализация Promiscuous, SPAN или ERSPAN портов, в зависимости от используемого виртуального коммутатора, не представляется затруднительным делом. В случае же осуществления предотвращения вторжений, возможно, использование виртуальных устройств может быть и более эффективным, т.к. такие устройства обычно используются только в специализированых сегментах сети, например, в модуле Public Services DMZ.

vStorage

Сеть vStorage может представлять собой “не IP” среду, например Fiber Channel, или быть IP-средой при использовании технологий iSCSI или NFS.

При использовании IP-среды в случае, если в компании существуют специально выделенные сети (VLANы) для организации адресного пространства хранилищ данных, то VLAN сети vStorage должен принадлежать к этой сети. При этом vStorage должна быть отделена при помощи межсетевого экранирования или маршрутизации от других сетей виртуальной инфраструктуры (служебных сетей и vGuest).

Если в организации не удается разделить на серверах интерфейсы, которые обрабатывают трафик приложений, и интерфейсы, по которым происходит взаимодействия с хранилищами данных, то приходится интерфейсы хранилищ помещать в те же модули сети, что и интерфейсы приложений. Тогда логически в понимании модулей сети vStorage будет принадлежать тому же модулю сети, что и интерфейсы хранилища данных, т.е. по сути сети vGuest. Вроде бы ничего страшного, трафик все равно не будет выходить за пределы модуля сети. Однако, возможна ситуация и обычно она не редка, когда одно хранилище данных обслуживает сервера разных модулей сети, например Data Center и Extranet. Тогда такой трафик будет проходить через средства межсетевого экранирования, например, между модулями Data Center и Extranet, что может повлечь значительную нагрузку на эти средства. Вот тут и надо выбирать какую архитектуру использовать и стоит ли при этом жертвовать принципами разграничения доступа…

Виртуальные коммутаторы

На данный момент существует выбор виртуальных коммутаторов в среде виртуализации VMware vSphere. Можно использовать следующие типы коммутаторов:

VMware vSwitch (виртуальный коммутатор)
VMware Distributed vSwitch (распределенный коммутатор)
Cisco Nexus 1000V

С точки зрения удобства эксплуатации конечно же удобнее распределенные коммутаторы, как родной так и фирмы Cisco. В зависимости от желания и потребностей организация может использовать какой-то один из них или оба сразу. Cisco Nexus удобен тем, что он позволяет передать функции администрирования сетевой инфраструктуры в виртуальной среде сетевым администраторам – людям, которые и в физическом мире занимаются этим.

Для сред с высоким уровнем риска, в нашем случае это, например, зоны Internet Edge, VMware рекомендует выделять служебные сети vManagement, vMotion, vFT, vStorage на отдельные от сетей vGuest виртуальные коммутаторы[3], что выполнимо для обоих вариантов архитектур, приведенных выше. Таким образом, на ESX(i) рекомендуется использовать минимум 2 виртуальных коммутатора, а значит минимум 2 физических сетевых адаптера – для служебных сетей и для сетей гостевых виртуальных машин. Если вспомнить об отказоустойчивости, то рекомендуется также агрегировать физические сетевые интерфейсы в логические. Соответственно при этом минимум 2 физических интерфейса агрегируются в один логический, поэтому ESX(i) должен будет уже иметь минимум 4 физических адаптера – 2 для логического агрегированного интерфейса служебных сетей и 2 для логического агрегированного интерфейса сетей виртуальных машин vGuest.

Очевидно, что сети виртуальных машин vGuest должны размещаться на распределенных виртуальных коммутаторах. Служебные же сети могут располагаться на распределенных коммутаторах, отдельных от распределенных коммутаторов, обрабатывающих сети vGuest, либо на стандартных виртуальных коммутаторах vSwitch, т.к. в некоторых случаях это может быть удобнее. Примеры такого разделения приводятся самой VMware и показаны на рисунках ниже.[4]

gallery/vsphere.1.06.гибридное использование виртуальных коммутаторов – vds и vss

Рисунок 6. Гибридное использование виртуальных коммутаторов – vDS и vSS

gallery/vsphere.1.07.множественное использование vds

Рисунок 7. Множественное использование vDS

При этом необходимо осознавать, что 2 коммутатора (модуля VEM) Cisco Nexus 1000V на одном ESX(i) быть не могут, поэтому в случае использования Cisco Nexus 1000V в качестве коммутатора для служебных сетей следует использовать другие коммутаторы, как показано на рисунке ниже.

gallery/vsphere.1.08.cisco nexus 1000v и vss

Рисунок 8. Cisco Nexus 1000V и vSS

Такое решение обладает высокой степенью защиты, но реально экономически невыгодно при использовании в организации гетерогенных сетей с 10 ГБ сетевыми интерфейсами.

Для сред с невысоким (средним и низким) уровнем риска, таких как зоны Data Center и Extranet в нашем случае, VMware разрешает использовать единый виртуальный коммутатор для всех сетей виртуальной инфраструктуры[1] как показано на следующих рисунках.

gallery/vsphere.1.09.использование единого vds

Рисунок 9. Использование единого vDS

gallery/vsphere.1.10.использование cisco nexus 1000v

Рисунок 10. Использование Cisco Nexus 1000V

Вообще говоря, если сравнивать наше представление сетевой архитектуры (см. Рисунок 2) и уровни рекомендаций VMware[6], предлагаемые в VMware vSphere 4.1 Security Hardening Guide, то я бы разделил их таким образом:

  • для зоны Data Center должен использоваться уровень рекомендаций Enterprise;
  • для зоны Extranet должен использоваться уровень рекомендаций DMZ;
  • для зон Internet Edge и, если имеет место,  WAN Edge использовать уровень рекомендаций SSLF (Specialized Security Limited Functionality).

Вне зависимости от того каким образом мы разделяем сети виртуальной инфраструктуры по виртуальным коммутаторам и по физическим интерфейсам, очевидно, что значительное увеличение нагрузки в одной виртуальной сети может негативно сказаться на параметрах передачи пакетов в другой сети на том же виртуальном коммутаторе. Поэтому также как и в физической сети было бы неплохо обеспечить некоторые уровни качества обслуживания на виртуальных коммутаторах, которые на данный момент могут обеспечить распределенные виртуальные коммутаторы vNetwork Distributed Switch и Cisco Nexus 1000V.

Если суммировать все, о чем было сказано выше по поводу сетевой архитектуры инфраструктуры виртуализации, то я бы предложил бы:

  1. Виртуальные машины зон Data Center и Extranet располагать на одном наборе аппаратного обеспечения ESX(i). При этом в случае высокоскоростных гетерогенных сред использовать единый виртуальный коммутатор для служебных сетей и для сетей vGuest с объединенным логическим интерфейсом (Team), на котором внедрить уровни обслуживания трафика (QoS). Для сред с пропускной способностью 1 Гб выделить отдельный виртуальный коммутатор для сети vManagement.
  2. Виртуальные машины зоны Internet Edge размещать на отдельном от виртуальных машин других зон аппаратном обеспечении ESX(i) и выделять на них отдельные интерфейсы для создания виртуального коммутатора сети vManagement.

Также в сетевой инфраструктуре виртуальной среды не должны присутствовать виртуальные коммутаторы с наименованиями “vmsafe”, “dvfilter”и группа портов “dvfilter-appliances”, если не используются технологии VMsafe CPU/Memory/Network API для организации сетевой или антивирусной защиты в виртуальной среде. [7]

Далее мы попытаемся разобрать требования и рекомендации информационной безопасности, которые могут выставляться для виртуальных коммутаторов. Т.к. самым сложным с точки зрения обеспечения является случай объединения всех сетей виртуальной инфраструктуры на одном распределенном коммутаторе, то мы будем рассматривать именно такой случай, а также напишем отдельно требования для стандартных виртуальных коммутаторов.

Распределенные виртуальные коммутаторы VMware (Некоторые требования могут быть применены и к стандартным виртуальным коммутаторам)

Виртуальный коммутатор должен работать в режиме тегирования на уровне виртуального коммутатора (Virtual Switching Tagging, VST), т.к. мы решили, что маршрутизация и ограничение трафика между виртуальными сетями происходит на внешнем по отношению к виртуальной инфраструктуре маршрутизаторе и/или межсетевом экране. Соответственно не должен использоваться режим тегирования на уровне гостевой системы (Virtual Machine Guest Tagging, VGT), когда тэги устанавливаются самой виртуальной машиной, и режим тегирования на уровне физического коммутатора (External Switch Tagging, EST), когда трафик доходит нетегированным до порта физического коммутатора.

Каждая Port Group в настройках должна содержать значение VLAN ID. Это значение не должно быть равно 0 или 4095.

Установить соответствующее значение можно через графический интерфейс в свойствах Port Group.

Не допускается использовать в виртуальной инфраструктуре идентификаторы VLAN, используемые на физических коммутаторах в качестве идентификаторов Native VLAN для trunk-портов.[8]

Также не рекомендуется в виртуальной инфраструктуре использовать идентификаторы VLAN, зарезервированные некоторыми производителями, например для Cisco: 1001 – 1024; 3968 – 4047, 4094.[9]

Следует запретить использование режима Promiscuous Mode на портах коммутаторов. Может быть разрешено контролируемое использование данного режима на выделенных портах коммутаторов для решения задач информационной безопасности или поиска неисправностей.[10]

Устанавливается в настройке портов распределенного коммутатора, в закладе “Security” параметр “Promiscuous Mode” устанавливается в значение Reject.

На виртуальном коммутаторе должны быть отключены все неиспользуемые виртуальные сетевые порты.[11]

В разделе “Miscelaneous” свойств неиспользуемого порта установить параметр “Block this port” в значение “Override (YES)”

На портах распределенных коммутаторов должно быть запрещено использование MAC Address Change[12], т.е. MAC-адрес виртуальной машины не должен меняться, ее эффективный MAC-адрес должен соответствовать начальному (при смене MAC-адреса порт виртуальной машины на коммутаторе будет отключен, но гостевая операционная система не получит никаких уведомлений). При этом необходимо помнить, что такие технологии как кластеры Microsoft (Unicast Network Load Balance), а также vShield Apps могут при данной настройке не работать.

В разделе Policies -> Security свойств группы портов установить параметр “MAC Address Change” в значение “Reject”

На портах распределенных виртуальных коммутаторов должно быть запрещено использование Forged Transmits[13], что говорит о том, что MAC-адреса пакетов, посылаемых виртуальной машиной, должны соответствовать ее эффективному MAC-адресу.

В разделе Policies -> Security свойств группы портов установить параметр “Forget Transmits” в значение “Reject”

Должна быть настроена политика подмены (override) политики группы портов на отдельных портах. Подмена не должна быть возможна для всех параметров, кроме “Block Port”.

В разделе Advanced свойств группы портов нажать на кнопку “Edit Override Settings…”. В появившемся окне все параметры должны иметь значение “No”, кроме параметра “Block Port”, который может иметь значение “YES”.

При отсоединении виртуальной машины от порта виртуального коммутатора данный порт должен возвращаться (сбросываться, reset) в исходное состояние.

В разделе Advanced свойств группы портов включить параметр “Configure reset at disconnect”.

Как мы уже писали на виртуальных коммутаторах необходимо обеспечить соответствующие уровни качества обслуживания. Данные уровни зависят от ваших предпочтений или от политик организации в сетевой инфраструктуре. vDS предоставляет механизм “Network I/O Control” для осуществления этого.

Для каждого распределенного коммутатора vDS необходимо включить механизм управления трафиком “Network I/O Control”.

В закладке “Resource Allocation” виртуального коммутатора выбрать “Properties…” и отметить пункт “Enable I/O control on this vDS”

На vDS мы можем приоритезировать все виды трафика, используемые в виртуальной инфраструктуре, а именно: vMotion, FT logging, Management, iSCSI, NFS, Virtual machine traffic[14]. Каждый из этих трафиков можно ограничить по относительной доле в общем трафике (Share, ограничение снизу) и/или установить ограничение сверху (Limit).

Например, следующие значения получены на основании Cisco Nexus 1000V Series Switches Deployment Guide Version 2.

Таблица 1. Качественные значения пропускной способности и приоритетов для сетей виртуальной инфраструктуры

gallery/vsphere.tab.1.01

На основании Таблицы можно разделить пропускную способность физического 10Гб адаптера, например, следующим образом.

Таблица 2. Количественные значения пропускной способности для сетей виртуальной инфраструктуры

gallery/vsphere.tab.1.02

Соответственно, значения, которые вы определите, необходимо установить на определенных типах трафика на vDS.

В закладке “Resource Allocation” виртуального коммутатора выбрать строку с необходимым типом трафика, нажать правую кнопку мыши и в контекстном меню выбрать “Edit Settings…” и установить значение “Physical adapter shares”.

Верхние пределы для каждого типа трафика (Limits) устанавливать нет необходимости в случае использования Shares. Но при этом необходимо помнить, что все ограничения Network I/O Control действуют только на исходящий трафик vDS.  Таким образом, возможна такая ситуация, что входящий в vDS трафик будет превышать ограничения полосы пропускания физических адаптеров[15]. VMware рекомендует при этом использовать Traffic Shaping на виртуальных коммутаторах. Параметры Trafic Shaping могут быть установлены и на физических адаптерах (логических объединениях “NIC Teaming”), и на группах портов и на отдельных портах. Возможна установка ограничений полосы пропускания сверху как для входящего так и для исходящего трафика.

В свойствах DVUplinks, dvPortGroups или Ports установить соответствующие значения для параметров “Average Bandwidth”, “Peak Bandwidth” и “Burst Size”.

Заметим что, к сожалению, осуществлять маркировку пакетов и осуществление приоритезации трафика по его маркировке на данный момент vDS не умеет. Для осуществления этой функции может использоваться Cisco Nexus 1000V.

Cisco Nexus 1000V

Распределенный виртуальный коммутатор Cisco Nexus 1000V является наложенным на виртуальную инфраструктуру средством, поэтому имеет некоторые дополнительные архитектурные особенности. Nexus 1000V в своей работе использует дополнительные сети:

  • Сеть vNexusControl. Данная сеть используется для взаимодействия между:
  • основными (primary) и вспомогательными (secondary) модулями управления Nexus (VSM)
  • Nexus-коммутаторами (VEM) и модулем управления Nexus (VSM).
  • Сеть vNexusPacket. Данная сеть используется для взаимодействия между VEM и VSM. Передается только трафик CDP и IGMP.
  • Сеть vManagement. Та же сеть, что используется для управления виртуальной инфраструктурой. Данная сеть используется для соединения модуля управления Nexus (VSM) и vCenter, а также для осуществления доступа сетевых администраторов к VSM.

Сетям vNexusControl и vNexusPacket следует выделить отдельные VLAN, следовательно, VSM должен иметь три отдельных виртуальных сетевых интерфейса, находящихся в сетях vManagement, vNexusControl и vNexusPacket.

VSM должен быть установлен в отказоустойчивой (HA) конфигурации [16].

Как было уже сказано для родных коммутаторов, виртуальный коммутатор должен работать в режиме тегирования на уровне виртуального коммутатора (VST).

Каждый Port Profile в настройках должен содержать значение VLAN ID. Это значение не должно быть равно 0 или 4095.

n1000V(config-port-prof)# switchport access vlan <vlan-id> 

Также не стоит использовать Native VLAN-ы и зарезервированные производителями VLAN-ы.

В связи с использованием достаточно сложной структуры управления Nexus 1000V следует сразу рассмотреть некоторые требования к управлению этим коммутатором.

Управление Nexus 1000V по протоколу Telnet должно быть запрещено.

n1000V(config)# telnet server disable

Должен быть запрещен HTTP Server [17].

n1000V(config)# no feature http-server

Возможно использование списков управления доступом на уровне IP протокола (IP ACL) и/или на 2 уровне модели OSI (MAC ACL) на виртуальных коммутаторах Cisco Nexus 1000V для управления доступом непосредственно к коммутатору. Для управления доступом к траффику это не имеет смысла, т.к. отслеживать такие ACL становится очень сложно. Для ограничения трафика между сетями vGuest должны использоваться специальные средства межсетевого экранирования.

Заметим, что MAC ACL не влияют на IP-трафик, а ограничивают только трафик, несущий на 3 уровне модели OSI не-IP трафик.

VLAN-ы служебных сетей (в том числе сетей vNexusControl и vNexusPacket) должны быть определены в профилях как виртуальных так и физических портов в качестве системных VLAN-ов (system VLANs).[18]

Настройка системного VLAN для профиля виртуального порта:

n1000V(config)# port-profile type vethernet <profile-name>

n1000V(config-port-prof)# switchport mode access

n1000V(config-port-prof)# switchport access vlan <vlan-number>

n1000V(config-port-prof)# system vlan <vlan-number>

Введите текст

Настройка системного VLAN для профиля физического порта:

n1000V(config)# port-profile type ethernet <profile-name>

n1000V(config-port-prof)# switchport mode trunk

n1000V(config-port-prof)# switchport trunk allowed vlan <vlan-number1>-<vlan-numberN>

n1000V(config-port-prof)# system vlan <vlan-numberK>

где:

vlan-numberK in [vlan-number1;vlan-numberN]

В рамках данной статьи не рассматривается использование такого функционала Cisco Nexus 1000V как виртуальные служебные домены (Virtual Service Domain, VSD) и защиты их при помощи служебной виртуальной машины (Service Virtual Machine, SVM).

Должно быть запрещено использование режимов SPAN и ERSPAN на портах коммутаторов. Возможно контролируемое использование режимов SPAN или RSPAN на выделенных портах коммутаторов для решения задач информационной безопасности и поиска неисправностей [10].

Осуществить проверку этих настроек можно следующим образом:

n1000V(config-monitor)# show monitor

n1000V(config-erspan-src)# show monitor session <session-number>

Заметим, что перед настройкой новой SPAN- или ERSPAN-сессии рекомендуется вначале удалить предыдущую сессию [19, 20].

n1000V(config)# no monitor session <session-number>

Далее перечислим требования по защите.

На виртуальном коммутаторе Cisco Nexus 1000V должны быть отключены все неиспользуемые виртуальные порты доступа (vEth) [11].

Необходимо блокировать неиспользуемые порты доступа vEth [21]:

n1000V(config)# interface vethernet <interface-number>

n1000V(config-if)# shutdown

На портах доступа (vEth) следует использовать политику защиты портов (port security) [12, 13].

n1000V(config-if)# switchport port-security

На портах доступа (vEth), следует использовать статически сконфигурированные MAC-адреса или способ конфигурирования Sticky[12, 13], что является мерой защиты от подмены MAC-адресов.

Для статических MAC-адресов:

n1000V(config-if)# switchport port-security mac-address 0019.D2D0.00AE

Для способы конфигурирования Sticky:

n1000V(config-if)# switchport port-security mac-address sticky

Для портов, подключенных к виртуальным машинам (vEth), необходимо установить максимально возможное количество MAC-адресов на порту в значение 1 [12, 13].

n1000V(config-if)# switchport port-security maximum 1

Способ реакции на нарушение политики защиты портов (port security) должен быть установлен в значения protect или shutdown.

n1000V(config-if)# switchport port-security violation protect

           или

n1000V(config-if)# switchport port-security violation shutdown

На виртуальном коммутаторе Cisco Nexus 1000V должен быть включен механизм DHCP Snooping для защиты от подмены DHCP-сервера. Также база привязок DHCP snooping (DHCP snooping binding database) используется другими средствами защиты (Dynamic ARP Spoofing, IP Source Guard).

n1000V(config)# ip dhcp snooping

В механизме DHCP Snooping должна быть включена проверка MAC-адресов на недоверенных (untrusted) интерфейсах.

n1000V(config)# ip dhcp snooping verify mac-address

В механизме DHCP Snooping все порты коммутатора должны быть определены как недоверенные (untrusted), за исключением портов, соответствующих физическим подключениям (по-умолчанию и неизменяемо), портов виртуальных машин, которые реализуют службу DHCP или имеют статические адреса.

Для интерфейса:

     n1000V(config)# interface vethernet <interface-number>

     n1000V(config-if)# no ip dhcp snooping trust

Для профиля портов:

     n1000V(config)# port-profile <profilename>

     n1000V(config-port-prof)# no ip dhcp snooping trust

На виртуальном коммутаторе Cisco Nexus 1000V должен быть включен механизм ARP Inspection на всех VLAN виртуального коммутатора для защиты от атак ARP Spoofing.

n1000V(config)# ip arp inspection vlan <list>

В механизме ARP Inspection все порты коммутатора должны быть определены как недоверенные (untrusted), за исключением портов, соответствующих физическим подключениям (по-умолчанию и неизменяемо).

Для интерфейса:

     n1000V(config)# interface vethernet <interface-number>

     n1000V(config-if)# no ip arp inspection trust

Для профиля портов:

     n1000V(config)# port-profile <profilename>

     n1000V(config-port-prof)# no ip arp inspection trust

Желательно включить блокировку интерфейса по ошибке ARP Inspection.

n1000V(config)# errdisable detect cause arp-inspection

При этом стоит увеличить глобальный параметр автоматического восстановления работоспособного состояния порта после его блокировки. По-умолчанию значение составляет 5 минут, предлагается увеличить его до 10 – 30 минут.

Необходимо разрешить проверку ARP-пакетов по:

  • MAC-адресу назначения (destination)
  • IP-адресу
  • MAC-адресу источника (source)

n1000V(config)# ip arp inspection validate src-mac dst-mac ip

На виртуальном коммутаторе Cisco Nexus 1000V должен быть включен механизм IP Source Guard на всех портах виртуального коммутатора для защиты от атак IP Spoofing.

Для интерфейса:

     n1000V(config)# interface vethernet <number>

     n1000V(config-if)# ip verify source dhcp-snooping-vlan

Для профиля портов:

     n1000V(config)# port-profile <profilename>

     n1000V(config-port-prof)# ip verify source dhcp-snooping-vlan

На виртуальных коммутаторах Cisco Nexus 1000V также как и на vDS необходимо обеспечить соответствующие уровни качества обслуживания. Cisco Nexus 1000V предоставляет в этом отношении больше функциональности.

Cisco Nexus 1000V в отличие от vDS может осуществлять классификацию и маркировку пакетов в зависимости от класса трафика в значения DSCP и CoS. Но это будет актуально для организации, у которой в сети внедрена поддержка QoS.

Итак, далее приведем требования, распространяющиеся на виртуальные интерфейсы vEth Cisco Nexus 1000V.

На портах виртуального коммутатора Cisco Nexus 1000V (vEth), к которым подключены служебные сети (сеть vMotion, сеть FT, сеть vStorage, сеть vManagement, сеть vNexusControl, сеть vNexusPacket), необходимо осуществлять классификацию и маркировку пакетов в зависимости от класса трафика в значения DSCP и/или CoS.

При этом значения DSCP и/или CoS, естественно должны быть привязаны к значениям, используемым для сети организации в целом. Ниже, для примера, приведена таблица возможных значений DSCP и CoS.

gallery/vsphere.tab.1.03

Таблица 3. Значения маркировки для сетей виртуальной инфраструктуры

Для выполнения требования на виртуальном коммутаторе Cisco Nexus 1000V следует сделать следующее.

Необходимо настроить класс для трафика сети при помощи команд на vEth: [22]

     n1000V(config)# ip access-list <acl-name>

     n1000V(config-acl)# permit ip any any

     n1000V(config)# class-map <class-name>

     n1000V(config-cmap-qos)# match access-group name <acl-name>

Далее определить политику маркировки:

n1000V(config)# policy-map <policy-name>

n1000V(config-pmap-qos)# class <class-name>

n1000V(config-pmap-c-qos)# set dscp <value>

n1000V(config-pmap-c-qos)# set cos <value>

Далее необходимо политику закрепить за соответствующим интерфейсом vEth или профилем порта.

Для виртуального интерфейса:

     n1000V(config)# interface veth <number>

     n1000V(config-if)# service-policy input <policy-name>

Для профиля порта:

     n1000V(config)# port-profile <access-profile-name>

     n1000V(config-port-prof)# service-policy input <policy-name>

Далее приведен набор команд для проведения классификации и маркировки в соответствии с  перечисленными в таблице значениями на служебных интерфейсах vEth.

     n1000V(config)# ip access-list ALL-ACL

     n1000V(config-acl)# permit ip any any

     n1000V(config)# class-map MARK-CLASS

     n1000V(config-cmap-qos)# match access-group name ALL-ACL

Для vEth сети vMotion:

     n1000V(config)# policy-map VMOTION-POLICY

     n1000V(config-pmap-qos)# class MARK-CLASS

     n1000V(config-pmap-c-qos)# set dscp 18

     n1000V(config-pmap-c-qos)# set cos 2

Для vEth сети vFT:

     n1000V(config)# policy-map VFT-POLICY

     n1000V(config-pmap-qos)# class MARK-CLASS

     n1000V(config-pmap-c-qos)# set dscp 18

     n1000V(config-pmap-c-qos)# set cos 2

Для vEth сети vStorage:

     n1000V(config)# policy-map VSTORAGE-POLICY

     n1000V(config-pmap-qos)# class MARK-CLASS

     n1000V(config-pmap-c-qos)# set dscp 24

     n1000V(config-pmap-c-qos)# set cos 4

Для vEth сети vManagement:

     n1000V(config)# policy-map VMANAGEMENT-POLICY

     n1000V(config-pmap-qos)# class MARK-CLASS

     n1000V(config-pmap-c-qos)# set dscp 48

     n1000V(config-pmap-c-qos)# set cos 6

Для vEth сети vNexusControl:

     n1000V(config)# policy-map VNEXUSCONTROL-POLICY

     n1000V(config-pmap-qos)# class MARK-CLASS

     n1000V(config-pmap-c-qos)# set dscp418

     n1000V(config-pmap-c-qos)# set cos 6

Для vEth сети vNexusPacket:

     n1000V(config)# policy-map VNEXUSPACKET-POLICY

     n1000V(config-pmap-qos)# class MARK-CLASS

     n1000V(config-pmap-c-qos)# set dscp 48

     n1000V(config-pmap-c-qos)# set cos 6

На портах виртуального коммутатора Cisco Nexus 1000V (vEth), подключенных к виртуальным машинам, необходимо осуществлять классификацию и маркировку пакетов в зависимости от класса трафика в соответствующие значения DSCP и CoS для физической инфраструктуры.

Необходимо настроить класс соответствующего трафика:[22]

     n1000V(config)# class-map <class-name>

     Настроить class-map в зависимости от критериев качества обслуживания различных приложений виртуальных машин.

Далее определить политику маркировки:

     n1000V(config)# policy-map <policy-name>

     n1000V(config-pmap-qos)# class <class-name>

     n1000V(config-pmap-c-qos)# set dscp <value>

     n1000V(config-pmap-c-qos)# set cos <value>

Далее необходимо политику закрепить за соответсвующим интерфесом или профилем порта.

     Для виртуального интерфейса:

          n1000V(config)# interface veth <number>

          n1000V(config-if)# service-policy input <policy-name>

     Для профиля порта:

          n1000V(config)# port-profile <access-profile-name>

          n1000V(config-port-prof)# service-policy input <policy-name>

Рассмотрим требования, распространяющиеся на физические интерфейсы Ethernet Cisco Nexus 1000V.

Немного модернизируем Таблица 2 , приводящуюся в разделе, посвящённому vDS, в которой приведены значения пропускной способности для 10Гб адаптера, т.к. с введением Cisco Nexus 1000V у нас появились еще сети vNexusControl и vNexusPacket.

Таблица 4. Количественные значения пропускной способности для сетей виртуальной инфраструктуры с учетом установки распределенного виртуального коммутатора Cisco Nexus 1000V

gallery/vsphere.tab.1.04

Мы не станем выделять отдельно в целях QoS сети vManagement, vNexusControl и vNexusPacket, а выделим им общую полосу пропускания шириной в 100 Мбит/с.

На физических портах Cisco Nexus может устанавливать минимальные пропускные способности для соответствующих классов трафика на основе CoS, но на данный момент не может использовать DSCP. Также как и в случае vDS Cisco Nexus 1000V ограничивает только исходящий с физических портов трафик.

На физических портах виртуального коммутатора Cisco Nexus 1000V (Ethernet) необходимо установить гарантированные пропускные способности для трафика служебных сетей (сеть vMotion, сеть vFT, сеть vManagement, сеть vNexusControl, сеть vNexusPacket).[23]

Необходимо настроить класс соответствующего трафика:

     n1000V(config)# class-map type queuing match-any <class-name>

     n1000V(config-cmap-que)# match protocol <protocol-name>

Далее определить политику ограничения:

     n1000V(config)# policy-map type queuing <policy-name>

     n1000V(config-pmap-que)# class type queuing <class-name>

     n1000V(config-pmap-c-que)# bandwidth percent <%>

Далее необходимо политику закрепить за соответствующим физическим интерфейсом:

     n1000V(config)# interface ethernet <number/number>

     n1000V(config-if)# service-policy type queuing output <policy-name>

Далее приведен набор команд для установки гарантированных пропускных способностей для трафика служебных сетей в соответствии с  таблицей на физических интерфейсах Ethernet.

Определение классов[23]:

     Для сети vMotion:

          n1000V(config)# class-map type queuing VMOTION-CLASS

         n1000V(config-cmap-que)# match protocol vmw_vmotion

     Для сети vFT:

          n1000V(config)# class-map type queuing VFT-CLASS

          n1000V(config-cmap-que)# match protocol vmw_ft

     Для сетей vManagement, vNexusControl и vNexusPacket:

         n1000V(config)# class-map type queuing match-any VMANAGEMENT_vNEXUS-CLASS

         n1000V(config-cmap-que)# match protocol vmw_mgmt

         n1000V(config-cmap-que)# match protocol n1k_mgmt

         n1000V(config-cmap-que)# match protocol n1k_control

         n1000V(config-cmap-que)# match protocol n1k_packet

     Определение политик для физического интерфейса[23]:

          n1000V(config)# policy-map type queuing BANDWIDTH-POLICY

          n1000V(config-pmap-que)# class type queuing VMOTION-CLASS

          n1000V(config-pmap-c-que)# bandwidth percent 10

          n1000V(config-pmap-que)# class type queuing VFT-CLASS

          n1000V(config-pmap-c-que)# bandwidth percent 10

          n1000V(config-pmap-que)# class type queuing VMANAGEMENT_VNEXUS-CLASS

          n1000V(config-pmap-c-que)# bandwidth percent 1

    Закрепление политики за интерфейсом:

         n1000V(config)# interface ethernet <number/number>

         n1000V(config-if)# service-policy type queuing output BANDWIDTH-POLICY

На физических портах виртуального коммутатора Cisco Nexus 1000V (Ethernet) необходимо установить гарантированные пропускные способности для трафика сетей хранения данных (сеть vStorage), приведенные в таблице.[23]

Необходимо настроить класс соответствующего трафика[23]:

     n1000V(config)# class-map type queuing match-any <class-name>

     n1000V(config-cmap-que)# match protocol vmw_iscsi

     n1000V(config-cmap-que)# match protocol vmw_nfs

Далее определить политику ограничения:

     n1000V(config)# policy-map type queuing <policy-name> (если политика на интерфейсе уже определена, то название должно соответствовать названию уже определенной политики)

    n1000V(config-pmap-que)# class type queuing <class-name>

    n1000V(config-pmap-c-que)# bandwidth percent 50

Далее необходимо политику закрепить за соответсвующим физическим интерфесом:

     n1000V(config)# interface ethernet <number/number>

     n1000V(config-if)# service-policy type queuing output <policy-name>

На физических портах виртуального коммутатора Cisco Nexus 1000V (Ethernet) необходимо установить гарантированные пропускные способности для трафика сети vGuest в соответствии со значениями CoS, определенными для физической среды. Суммарно значения пропускной способности всех типов трафика не должны превышать значения, определённого в таблице для трафика сети vGuest.[23]

Необходимо настроить класс соответствующего трафика:

     n1000V(config)# class-map type queuing match-any <class-name>

     n1000V(config-cmap-que)# match protocol <cos>

Далее определить политику ограничения:

     n1000V(config)# policy-map type queuing <policy-name> (если политика на интерфейсе уже определена, то название должно соответствовать названию уже определенной политики)

    n1000V(config-pmap-que)# class type queuing <class-name>

    n1000V(config-pmap-c-que)# bandwidth percent <%>

Далее необходимо политику закрепить за соответсвующим физическим интерфесом:

    n1000V(config)# interface ethernet <number/number>

    n1000V(config-if)# service-policy type queuing output <policy-name>

Также как и в случае vDS рекомендуется не ограничивать какие-либо виды трафика по пропускной способности сверху.

Проверка:

    n1000V# show policy-map interface brief

    n1000V(config)# show policy-map <policy-name>

     В политике, установленном на внешних физических интерфейсах не должны встречаться параметры “cir” и “pir”, установленные в абсолютные значения.

Далее коснемся требований по осуществлению мониторинга Cisco Nexus 1000V.

Опрос состояния существующими средствами сетевого управления по протоколу SNMP должно производиться только с использованием версии 3 протокола.[24]

SNMP должен использоваться только для получения информации от виртуального коммутатора (Notifications: traps или informs).[25] В текущей версии программного обеспечения виртуального коммутатора Cisco Nexus 1000V возможность записи (snmp sets) не предусмотрена.

Для защиты протокола SNMP версии 3 могут применяться следующие уровни защиты:

gallery/vsphere.tab.1.05

Для защиты SNMP не должен использоваться уровень защиты noAuthNoPriv.

Проверка:

     n1000V(config)# show snmp

    n1000V(config)# show snmp user <user-name>

Для защиты SNMP рекомендуется использовать уровень защиты authPriv.

n1000V(config)# snmp-server user <user-name> auth <md5 или sha> <passphrase> priv <aes-128> <passphrase>

Необходимо настроить SNMP на проверку аутентификации для входящих запросов.

n1000V(config)# snmp-server globalEnforcePriv

Доступ к виртуальному коммутатору или с виртуального коммутатора по протоколу SNMP должен быть организован только на интерфейсе, подключенном к сети управления (vManagement).

Использование SNMP должно быть ограничено списком IP-адресов устройств, для которых такой доступ необходим, при помощи списков контроля доступа (ACL).

Приведем некоторые требования по журналированию в cisco Nexus 1000V.

Должно быть настроено журналирование событий от модулей с уровнем критичности 6 (informational) и выше.[26]

n1000V(config)# logging module 6

Должно быть настроено журналирование событий на внешний сервер сбора событий (syslog-сервер).[27, 28]

n1000V(config)# logging server <host>

Проверка:

     n1000V(config)# show logging server

На внешний сервер должны журналироваться события с уровнем критичности 6 (informational) и выше.[28]

n1000V(config)# logging server <host> 6

Сетевое физическое окружение

В этой части приведем некоторые требования и рекомендации, касающиеся сетевого взаимодействия виртуальной инфраструктуры и аппаратных устройств сетевого уровня.

В целях обеспечения отказоустойчивости виртуальной инфраструктуры все физические сетевые подключения ESX(i) должны резервироваться с использованием резервных путей подключения или объединением нескольких физических интерфейсов.

Допускается использование объединений физических интерфейсов в один логический интерфейс (Team). При этом разделение трафика подсистем осуществляется назначением каждой подсистеме отдельного VLAN.

Служебные сети виртуальной инфраструктуры в физическом окружении должны быть изолированы друг от друга и от других видов трафика физически или на 2 уровне модели OSI (при помощи VLAN).

Cети vGuest в физическом окружении должны быть изолированы друг от друга и от других видов трафика физически или на 2 уровне модели OSI (при помощи VLAN).

При этом также как и в виртуальной инфраструктуре желательно использовать методы QoS для приоритезации и квотирования трафика.

Каждому транковому порту физического коммутатора должен быть присвоен уникальный Native VLAN, неиспользуемый ни для каких других целей, отличный от VLAN 1.

Транковые порты физических коммутаторов, обеспечивающие подключение ESX(i), должны передавать на ESX(i) только тэгированый трафик для определенного перечня VLAN ID, используемых в виртуальной инфраструктуре.

Должна быть включена функция portfast настройки STP для портов физического коммутатора, обеспечивающих подключение ESX(i).[29]

Switch(config-if)# spanning-tree portfast trunk

Для защиты от петель при ошибках конфигурирования на портах физических коммутаторов, к которым подключены ESX(i), стоит включить функцию защиты BPDU Guard настроек STP и, возможно, BPDU Filter.

Switch(config-if)# spanning-tree bpduguard enable

Switch(config-if)# spanning-tree  bpdufilter enable

Для транковых портов физического коммутатора, обеспечивающих подключение ESX(i), должен быть настроен статический 802.1q транк.[30]

Switch(config-if)# switchport mode trunk

Switch(config-if)# switchport trunk encapsulation dot1q

Switch(config-if)# switchport nonegotiate