close

Вход

Забыли?

вход по аккаунту

- Cisco Connect

код для вставкиСкачать
Архитектура и принципы
функционирования
сетевой фабрики Cisco ACI
Скороходов Александр
Системный инженер-консультант
[email protected]
25.11.2014
© 2014 Cisco and/or its affiliates. All rights reserved.
Развитие подходов к построению сети ЦОД
Традиционная
модель сети
Альтернативная
SDN модель
Новая
модель сети
Сумма
устройств
Программная
виртуализация сети
Application Centric
Infrastructure
Проверенное решение
Существующая модель
эксплуатации сети и
приложений
Остаётся сложность
Устраняет сложность
Отдельные оверлей и
транспортная сеть
Управление по политикам
Широкое
распространение
Зависимость от
гипервизора
Много точек управления
Несколько точек
управления
Негибкость
Аппаратные оверлеи
Автоматизация
Программируемая
инфраструктура
Защита инвестиций
Cisco ACI
новое поколение инфраструктуры ЦОД
App
Web
Внешняя сеть
передачи
данных
DB
QoS
QoS
QoS
МСЭ, LB
LB
ACL
APIC
ACI фабрика
Программируемость, масштабируемость, открытость
Application Policy
Infrastructure
Controller
Сетевой профиль приложения
Application Network Profile (ANP)
Сетевой профиль приложения
=
Входящие/
Исходящие политики
Входящие/
Исходящие политики
Сетевой профиль - логическое объединение групп EPG и
политик, определяющих правила взаимодействия между EPG
Модель политик ACI
концепция End-Point Group (EPG)
EPG - Web
HTTPS Service
HTTPS Service
HTTPS Service
HTTPS Service
HTTP Service
HTTP Service
HTTP Service
HTTP Service
EPG – логическая группа конечных хостов
представляющих приложение целиком или компоненты
приложения, которая (в общем случае) не зависит от
сетевых атрибутов
Сетевой профиль приложения ACI
Профиль приложения и его применение к сети
Клиент приложения
Профиль приложения: определяет
сетевые требования приложения
(сетевой профиль приложения)
Storage
Storage
App Tier
Web Tier
DB Tier
Применение профиля: каждое сетевое
устройство динамически производит
изменения настройки, требуемые
профилем
APIC
VM
VM
10.2.4.7
VM
VM
VM
VM
10.9.3.37
VM
10.32.3.7
Вся передача данных в фабрике управляется при помощи профилей приложений
• IP адреса полностью переносимы и могут использоваться где угодно внутри фабрики
• Безопасность и передача данных не зависят от физических и логических сетевых атрибутов
• Коммутаторы автономно обновляют свои настройки на основе правил, определенных профилем приложения, в
случае миграции приложения или его компонент
Application Policy Infrastructure Controller
Централизованная автоматизация и управление фабрикой
• Единая точка управления политиками в
сети ЦОД:
Сервисы 4..7
Управление
системами
Управление
СХД
Оркестрация
• Профили приложений
• Интеграция с сервисами L4-L7
• Открытая модель данных для управления при
помощи внешних средств оркестрации
• Мониторинг приложений, поиск и устранение
неисправностей фабрики
Открытый
RESTful API
• Управление образами (Spine / Leaf)
• Кластер APIC может поддержать более
миллиона конечных хостов, 200,000+
портов, 64,000+ логических организаций
(tenant)
• Не принимает непосредственное участие в
передаче данных
• Не занимается детальной настройкой
APIC
Управление при помощи
политик
Storage SME
Server SME
Network SME
Security SME
App. SME
OS SME
Архитектура сетевой фабрики Cisco ACI
Обзор ACI фабрики
• Наиболее эффективная фабрика в индустрии:
‒ 1/10 Gb на границе сети, высокая плотность 40GE на Spine
и возможность перехода на 100GE
‒ 1 миллион+ IPv4 и IPv6 хостов
‒ 64,000+ логических организаций (tenants)
‒ 220K+ 1/10 Gb хостов на одном уровне с переподпиской
3:1 на уровне фабрики
Spine
Аппаратная база отображения адресов
До 576 x 40 Gb портов на устройство
Высокая плотность за умеренную стоимость
• Маршрутизируемая фабрика – оптимальная
передача IP трафика
APIC
‒ Масштабируемая распределённая коммутация (L2) и
маршрутизация (L3) для VXLAN, NVGRE, VLAN
‒ Не требуются программные шлюзы – физические или
виртуальные
‒ Быстрота развертывания приложения – нет ограничений
при выборе точки размещения в фабрике
• Полная прозрачность – физическая или
виртуальная нагрузка
• Передача метаданных вместе с трафиком
‒ Детальное управление без необходимости
программировать потоки
Оптимизация фабрики
Использование IEEE 1588 для измерения
задержки
Оптимальная балансировка ECMP
Масштабирование
Интеллектуальное кеширование
Поддержка терминации оверлеев
Улучшенная аналитика
ACI фабрика
Интегрированные оверлеи
APIC
VTEP
VXLAN
IP
VTEP
Payload
VTEP
VTEP
VTEP
VTEP
VTEP
• ACI фабрика базируется на IP сети, обеспечивающей маршрутизацию между элементами
фабрики и интегрированных оверлеях для маршрутизации/коммутации между хостами
фабрики
‒ весь трафик между конечными хостами внутри фабрики передается при помощи оверлеев
• Почему интегрированные оверлеи?
‒ Мобильность, масштабируемость, поддержка multi-tenancy и интеграция с гипервизорами
‒ Вместе с трафиком данных можно передавать мета-данные для реализации распределенных политик
Таблица отображения фабрики
Inline Hardware Mapping DB - 1,000,000+ хостов
Proxy
Global Station Table –
локальный кэш записей для
подключенных к фабрике
хостов
10.1.3.35
Proxy
Proxy
Proxy
10.1.3.35
10.1.3.11
fe80::8e5e
fe80::5b1a
Leaf 3
Leaf 1
Leaf 4
Leaf 6
Leaf 3
*
Proxy
10.1.3.11
Port 9
Local Station Table – адреса
“всех” конечных хостов,
которые подключены
напрямую к Leaf коммутатору
Proxy Station Table –адреса «всех» хостов,
подключенных к фабрике
10.1.3.11
10.1.3.35
fe80::462a:60ff:fef7:8e5e
fe80::62c5:47ff:fe0a:5b1a
• Таблица отображения на коммутаторе Leaf делится между локальными и глобальными
записями
• Глобальная таблица на коммутаторе Leaf кеширует часть полной глобальной таблицы,
которая содержится на каждом коммутаторе Spine
• Если адрес конечного хоста не найден в локальном кэше, то (по умолчанию) пакет
передается на коммутатор Spine (до 1,000,000+ записей в таблице отображения
коммутатора Spine)
Режимы передачи пакетов в фабрике
Если прокси не знает адрес, то
пакет отбрасывается
APIC
Передача на VTEP адрес
Anycast Layer 2 MAC Proxy
Передача на VTEP адрес
Anycast IPv4 Proxy
Неизвестный Layer
2 Unicast адрес
Неизвестный Layer 3
Unicast адрес
Неизвестный Layer 3 Unicast адрес
Неизвестный Layer 2 Unicast адрес
•
Если адрес назначения не известен, то он
пересылается на коммутатор уровня Spine
proxy. Если Spine не знает адрес, то пакет
отбрасывается (Режим по умолчанию)
•
Опциональный режим - Flood Mode: если
MAC адрес назначения не известен, то он
пересылается всем хостам Bridge Domain-а
•
Если адрес не известен, то пакет
пересылается коммутатору Spine proxy. Если
Spine не знает адрес, то пакет отбрасывается
ACI фабрика
Нормализация инкапсуляции
IP фабрика
использует
eVXLAN тег
APIC
Нормализация
инкапсуляции
Any to Any
VTEP
Локализация
инкапсуляции
VXLAN
VNID = 5789
802.1Q
VLAN 50
VXLAN
VNID = 11348
eVXLAN
NVGRE
VSID = 7456
• Весь трафик инкапсулируется при помощи заголовка extended VXLAN (eVXLAN)
• Внешний тег VLAN, VXLAN, NVGRE на входящем порту отображается во
внутренний eVXLAN тег
• Внешние идентификаторы локальны на уровне Leaf устройства или Leaf порта
• Возможность переиспользования, если требуется
IP
Данные
Eth
MAC
Данные
Eth
IP
Данные
802.1Q
IP
Данные
Outer
IP
NVGRE
IP
Данные
Outer
IP
VXLAN
Eth
IP
Данные
Нормализация входящей инкапсуляции
Передача пакетов в ACI фабрике
4b
4a
Если входящий Leaf коммутатор не имеет записи в кеше о соответствии IP назначения адресу
VTEP, то пакет пересылается на spine-коммутатор на адрес anycast VTEP, где на уровне ASIC
происходит HW lookup и переписывается адрес VTEP назначения. Дополнительной задержки или
снижения производительности при этом не происходит.
Если входящий Leaf коммутатор уже выучил
соответствие IP адреса хоста назначения и адреса
VTEP, то в качестве адреса назначения для eVXLAN
туннеля выбирается известный VTEP адрес и
пакет передается напрямую на исходящий Leaf
коммутатор
VTEP
3
VXLAN
IP
IP
Payload
APIC
VTEP
Payload
eVXLAN
IP
Payload
5
Исходящий Leaf коммутатор производит
замену eVXLAN заголовка на требуемую
инкапсуляцию и применяет политику
VTEP
IP
VTEP
GRE IP
Payload
vSwitch инкапсулирует пакет и
передает его в сторону Leaf VTEP
IP
1
eVXLAN
VTEP
Коммутатор Leaf заменяет
заголовок VXLAN на eVXLAN и
применяет политику
VTEP
2
eVXLAN
VTEP
vSwitch (VMWare)
Payload
VM, подключенная к Ingress Port Group
или физический сервер формируют
пакет
IP
Payload
Коммутатор Leaf передает пакет
vSwitch-у или физическому серверу
vSwitch (MSFT)
IP
NVGRE
Payload
Пакет передается на порт vSwitch
7
6
Реализация политик в ACI фабрике
4
Если коммутатору Leaf известен
исходящий EPG который
ассоциирован с узлом назначения, то
он реализует политику устанавливая в
соответствующее значение бит в
заголовке eVXLAN, показывающий, что
входящая политика была применена к
пакету
VTEP
3
2
Flags
SRC
Group
VNID
5
Если политика приложения требует передачу пакета через сервисное устройство
или цепочку таких устройств, то фабрика в качестве VTEP узла назначения
указывает адрес коммутатора, в которому подключено сервисное устройство
6
Payload
VTEP
На основе классификации
коммутатор Leaf формирует
значение поля Source Group в
eVXLAN заголовке
Пакет идентифицируется как принадлежащий
определенной end point group (EPG) на
основе входящей классификации (port group,
физический порт, IP адрес, VLAN)
1
Исходящий Leaf коммутатор
проверяет был ли установлен policy
флаг в заголовке eVXLAN и если
требуется применяет политику
Flags
GRE IP
vSwitch (VMWare)
vSwitch инкапсулирует пакеты,
ассоциированные с EPG при
помощи назначенного
VLAN/VXLAN/NVGRE
идентификатора
vSwitch (MSFT)
SRC
Group
NVGRE
VNID
IP
Payload
Payload
Коммутатор Leaf пересылает
пакет vSwitch-у или
подключенному напрямую
физическому серверу.
7
ACI фабрика:
управление трафиком
• ACI фабрика отслеживает перегрузки на всем пути
передачи входящим и исходящим leaf (измерения в
реальном времени)
‒ Перегрузка на внешних портах коммутаторов
(external wires)
‒ Перегрузка на соединениях ASIC-to-ASIC (internal
wires)
• Фабрика балансирует потоки трафика по принципу
‘flowlet switching’
‒ Динамическое перенаправление активных
потоков с загруженного пути на менее
загруженный путь передачи трафика
• Фабрика приоритезирует небольшие потоки
‒ Обеспечение поведения как DC-TCP без
модификации на конечном хосте
‒ Увеличение скорости передачи больших TCP
потоков
APIC
Фокус на времени отклика приложения
Балансировка внутри ACI фабрики
Flowlet Switching
•
•
d1
H1
TCP
поток
d2
H2
*Flowlet Switching (Kandula et al ’04)
Flowlet switching* обеспечивает
независимую передачу “порций”
пакетов принадлежащих одному
потоку по разным аплинкам
Без изменения порядка
передаваемых пакетов
Gap ≥ |d1 – d2|
Балансировка внутри ACI фабрики
Dynamic Flow Prioritization
Реальный трафик представляет собой
микс больших (elephant) и
малых (mice) потоков.
F1
F2
Standard
Priority
F3
Ключевая идея:
Фабрика обнаруживает первые
несколько “порций” (flowlets)
каждого потока данных и
помещает их в приоритетную
очередь
Стандартный режим
(один приоритет):
Потоки больших размеров
влияют на
производительность
небольших потоков
(задержка и потери).
High
Priority
Dynamic Flow Prioritization:
фабрика автоматически
приоритезирует потоки
малого размера
ACI фабрика:
возможности по телеметрии
Необходимость мониторинга
SLA в разделяемых
ландшафтах
Фабрика больших размеров
усложняет корреляцию собираемых
статистических данных со
специфическим приложением/tenantом
Увеличение
распределенной
нагрузки
VM
APIC
VM
VM
VM
VM
VM
• Изменения в топологии и схеме распределения трафика заставляют пересмотреть
традиционные подходы к поиску и устранения неисправностей, а так же планирования емкостей
в ЦОД
• Высокая степень разделяемости инфраструктуры объединенная с распределенной сущность
приложений требуют сбора статистки в контексте приложения
• Возможности ACI фабрики
• Atomic Counters – точный учёт переданных и потерянных пакетов по каждому пути
• Измерение задержки– контроль матрицы задержек между всеми узлами
Интеграция сервисов и гипервизоров
Фабрика с поддержкой нескольких гипервизоров
Интеграция с
виртуальным миром
Сетевой
администратор
APIC
APIC
ACI фабрика
• Интегрированный шлюз для
VLAN, VxLAN, NVGRE сетей
• Заказчик не ограничен в выборе
гипервизора
• Фабрика готова к поддержке
нескольких гипервизоров «из
коробки»
• Возможность использования
нескольких VMM в одной группе
EPG
VLAN
VXLAN
Администратор
приложения
ESX
VLAN
NVGRE
Hyper-V
VLAN
VXLAN
VLAN
KVM
ФИЗИЧЕСКИЙ
СЕРВЕР
Управление
гипервизором
Координация политик с администраторами гипервизоров
Интеграция с
виртуальным миром
Управление
гипервизорами
APIC
APIC
• Координация сетевых политик с
администраторами систем
виртуализации
• Автоматическое детектирование
виртуальных машин и
применение политик
• Политики применяют к
физическим и
виртуализированным ресурсам
• Политика следует за VM
Web
App
DB
Профиль приложения
Нотификация о
добавлении/
удалении VM
PortGroup
Координация
сетевых
политик
PortGroups
Web
нотификация о
перемещении
VM
VM Networks
App
DB
Интеграция Cisco ACI и VMWare vSphere
Instantiate
VMs
vCenter
We
b
We
b
App
HYPERVISOR
DB
HYPERVISOR
We
b
We
b
DB
HYPERVISOR
APP PORT
GROUP
WEB PORT
GROUP
VI/Server Admin
App
DB PORT GROUP
VIRTUAL DISTRIBUTED SWITCH
Cisco APIC and
VMWare vCenter
Handshake
Application Network Profile
Firewal
Apply Policy
APIC
ACI
Fabric
WEB
ADC
APP
DB
Интеграция Cisco ACI и Microsoft Hyper-V
We
b
System Center
Virtual Machine
Manager
Instantiate
VMs
App
App
HYPERVISOR
We
b
DB
HYPERVISOR
VM NETWORK
APP
VM NETWORK
WEB
VI/Server Admin
DB
HYPERVISOR
VM NETWORK
DB
LOGICAL SWITCH
Cisco APIC and
Microsoft SCVMM
Handshake
Application Network Profile
Firewal
Apply Policy
APIC
ACI
Fabric
WEB
ADC
APP
DB
Интеграция Cisco ACI и OpenStack
Фаза 1
3
APIC
Create Application Policy
APIC Admin
(Performs Steps 3)
5
ACI
Fabric
Push Policy
2
Automatically Push
Network Profiles to
APIC
Create Network, Subnet,
Security Groups, Policy
1
NEUTRON
OpenStack Tenant
(Performs Steps 1,4)
NOVA
4
OPEN VIRTUAL SWITCH
Web
Instantiate VMs
ROUTING
NETWORK
SECURITY
OPEN VIRTUAL SWITCH
App
Web
HYPERVISOR
App
HYPERVISOR
37
OPEN VIRTUAL SWITCH
DB
Web
Web
HYPERVISOR
DB
Интеграция Cisco ACI и OpenStack
Фаза 2
Create Application Network
Profile
Application Network Profile
NEUTRON
NOVA
4
OpenStack Tenant
(Performs step 1,4)
Web
Instantiate VMs
2
EPG
WEB
F/W
L/B
1
App
Web
HYPERVISOR
EPG
APP
L/B
DB
App
Web
HYPERVISOR
EPG
DB
Web
DB
HYPERVISOR
Automatically Push
Network Profiles to
APIC
Application Network Profile
3
APIC
ACI Admin
(manages physical
network, monitors tenant
state)
F/W
L/B
Create Application Policy
5
Push Policy
ACI
Fabric
EPG
WEB
L/B
EPG
APP
EPG
DB
ACI: интеграция с сервисами 4 - 7 уровня
Централизация, автоматизация и поддержка существующей модели
• Эластичность вставки сервиса
физического или виртуального
Web
Web
Server
Web
App
Server
сервер
begin
Stage 1
…..
inst
inst
……..
…
…
Администрато
р сервиса
Stage N
inst
inst
МСЭ
Балансировка
end
Серв.
граф
Определение “Security 5”
• Поддержка текущей операционной модели
эксплуатации
• Описание сервиса в виде device package –
может быть создан сторонним
разработчиком
сервер
Сервисная
цепочка
“Security 5”
• Автоматизация процесса
развертывания/свертывания сервиса
посредством программируемого
интерфейса
• Применение сервиса вне зависимости от
места нахождения приложения
App Tier
B
Сервисный
профиль
• APIC – центральная точка контроля сети и
согласовании политик
Администратор
приложения
Политика
перенаправления
Providers
• Помощь в административном разделении
между уровнями приложения и сервиса
App Tier
A
ACI: автоматизации вставки сервиса
Device Package
• Для автоматизации управления
сервисов требуется device package. Это
zip файл:
• Спецификация устройства (XML файл)
Device Specification
<dev type= “f5”>
<service type= “slb”>
<param name= “vip”>
<dev ident=“210.1.1.1”
<validator=“ip”
<hidden=“no”>
<locked=“yes”>
APIC – Policy Element
Модель устройства
APIC
• Скрипт устройства (Python)
Скриптовый интерфейс APIC
• APIC взаимодействует с устройством при
помощи Python скрипта
• APIC использует модель устройства,
описанную в XML файле для настройки
устройства при помощи скрипта
• Для коммуникации с устройством скрипт
использует REST или CLI
Специфичный для устройства Python скрипт
Интерфейс устройства: REST/CLI
Script Engine
Узел APIC
Устройство
предоставляющее сервис
(FW, SLB)
Cервисная архитектура
Определение сервисного графа
• Сервисный граф настраивается в
APIC
• Определяет модель
взаимодействия между EPG
• В сервисной цепочке доступны
следующие операции - split, join,
tap и т.д.*
• Типичные сервисы:
- Firewall
- IPS
- TAP/Packet mirror
EPG App
- ADC/SLB
*Не всё доступно первоначально
EPG App
TAP
EPG DB
EPG
Outside
IPS
EPG Web
EPG
Desktop
EPG Web
ADC
EPG
Mobile
EPG
Web1
ADC
EPG
Web2
FW
ADC
EPG
AppA
EPG DB
Автоматизация сервисных цепочек
Роли и обязанности
Администратор приложения
Объекты управления:
• Сервисный граф
• Создание сервисного графа
APIC
• Применение сервисного графа
• Конфигурация устройства и сервиса
Device Package A
Device Package B
Device Package
C
Сетевой администратор
• Загружает device package
• Подключает оборудование
• Регистрирует сервисные
устройства и назначает их
группам пользователей (tenants)
• Публикует сервисный граф
Device A
Tenant X
Device A
Device A
Device C
Device C
Device B
L4-L7 устройство может говорить на языке ACI!
OpFlex: открытый декларативный протокол
• Файл с integration package больше не нужен
• OpFlex разрабатывается как открытый стандарт, который
может быть реализован любым инфраструктурным
элементом (коммутатор, L4-L7 устройство, маршрутизатор)
• OpFlex IETF: http://tools.ietf.org/html/draft-smith-opflex-00
• OpFlex так же интегрируется в OpenDaylight:
https://wiki.opendaylight.org/view/OpFlex:Main
• OpFlex агент с открытым исходным кодом разрабатывается
• Вендоры поддержавшие
OpFlex: (список расширяется)
Открытость архитектуры ACI
Открытая экосистема ACI
Все возможности доступны благодаря открытому API и модели данных
Northbound API
• Быстрая интеграция с
существующими средствами
управления
• Поддержка приложений и орг.
cтруктуры (tenant)
• Поддержка OpenStack
Объектно-ориентированная
Автоматизация
RESTful XML / JSON
Southbound API
• Опубликованная модель
данных
• Протокол OpFlex для
открытой интеграции
элементов в ACI
• Open source реализация DME
• Встраивание L4-L7 сервисов
Системное
управление
Управление
гипервизорами
Открытая
экосистема
Средства
автоматизации
Средства
оркестрации
Программируемость
Полный доступ к системе
посредством API
*На момент FCS есть ограничения, обращайтесь за уточнениями
Представляем Opflex – открытое управление
элементами фабрики ACI
ПРОТОКОЛ OPFLEX + ЭКОСИСТЕМА
OPEN SOURCE
APIC
OPFLEX
L4-7 DEVICE
КОММУТАТОР
ГИПЕРВИЗОРА
Открытый код, доступный всем
СТАНДАРТ
Стандартизация Opflex в IETF
ЭКОСИСТЕМА
Широкая и постоянно расширяющаяся
поддержка производителей включая
гипервизоры, сетевые устройства L4-7
ЗАЩИТА ИНВЕСТИЦИИ ЗА СЧЕТ ВОЗМОЖНОСТИ СТОРОННЕМУ УСТРОЙСТВУ
ИНТЕГРИРОВАТЬСЯ В ФАБРИКУ CISCO ACI
Opflex: открытый расширяемый протокол для
описания политик
OPFLEX СОЗДАН,
Policies:
• Who can talk to
whom
ЧТОБЫ ОБЕСПЕЧИТЬ:
1.
Абстрактное описание политик а не
настройки конкретного устройства
2.
Гибкое, расширяемое описание с
использованием XML / JSON
3.
4.
Поддержка любых устройств, включая
виртуальные коммутаторы, физические
коммутаторыи и сетевые сервисы с
обеспечением интероперабельности
между вендорами
Открытый, стандартизованный API с
эталонной open source реализацией
• What about
APIC
• Ops requirements
OPFLEX
PROXY
OPFLEX
AGENT
OPFLEX
AGENT
OPFLEX
AGENT
FIREWALL
HYPERVISOR
SWITCH
ADC
49
Миграция на ACI традиционных ЦОД
Сценарий 1:
Подключение нового ACI Pod
BGP
OSPF
VLAN
VxLAN
Существующая
инфраструктура
Новый POD
Сценарий 2:
Расширение уровня доступа
Layer 2
соединения
Существующая
инфраструктура
VLAN 10
VLAN 20
Банд ACI начального
уровня, подключенный к
коммутаторам агрегации
New Server Group
Сценарий 3
ACI как «сервисное устройство»
L3 OSPF
BGP
МСЭ 1
L2 VLAN
802.1Q
ADC
L2
L3
40G ACI
Сценарий 4
Интеграция средствами виртуальных коммутаторов
Поддерживает произвольную сеть
L2 (Nexus 7k/6k/5k/3k/2k/FI) между
Nexus 9k и AVS: защита инвестиций

На данный момент для «запуска»
OpFlex необходима L2 сеть

VMware DVS поддерживает только
один L2 коммутатор между N9k и
DVS

Интеграция с помощью LLDP а не
OpFlex
OpFlex

OpFlex
AVS поддерживает OpFlex для
взаимодействия с APIC
OpFlex

AVS
AVS
AVS
Phase 1: Layer 2 Existing
Network/Local Switching
Внедрение ACI в существующих ЦОД
Вынесенные по IP leaf устройства: 9300 & AVS (1HCY15)
Backbone
Directory/Proxy
Service Nodes
Border
Leaves
Nexus 9300:
вынесенный leaf
реализующий
политики ACI
vSwitch
APIC Policy
Controller
AVS
Hyper-V
AVS
OVS
ACI Policy based
forwarding, automation,
service insertion and
counters extended to the
edge of existing networks
Ждем ваших сообщений с хештегом
#CiscoConnectRu
Спасибо
Пожалуйста, используйте код для
оценки доклада:
2532
Скороходов Александр
Phone: +7(495)789-8615
E-mail: [email protected]
CiscoRu
25.11.2014
Cisco
© 2014 Cisco and/or its affiliates. All rights reserved.
CiscoRussia
1/--страниц
Пожаловаться на содержимое документа