cisco connect · port 9 leaf 3 * proxy a global station table содержит локальный...
TRANSCRIPT
Связь территориально-распределенных ЦОД
Хаванкин Максим
Системный архитектор, CCIE [email protected]
© 2017 Cisco and/or its affiliates. All rights reserved.
Содержание
• Применение OTV в DCI дизайнах
• ACI Multipod
• Общая архитектура
• Требования к IPN
• Плоскости управления и передачи данных
• Отказоустойчивость кластера и APIC Standby
• Масштабируемое подключение ко внешним сетям
• Оптимизация входящего и исходящего трафика при помощи LISP
• Модель политик и микросегментация
• Интеграция с сервисными устройствами
• ACI Multi-Site
• VXLAN EVPN в распределенных ЦОД
Cisco Connect 2017 © 2017 Cisco and/or its affiliates. All rights reserved. 3
Применение OTV в DCI дизайнах
Cisco Connect 2017 © 2017 Cisco and/or its affiliates. All rights reserved. 4
Overlay Transport Virtualization (OTV)
Расширение L2 доменов по произвольной IP сети
Тёмная оптика, MPLS, IP VPN...
Поддержка нескольких ЦОД
Упрощение построения и эксплуатации Простота интеграции в существующие сети
Настройка за несколько команд
Высокая надёжность Изоляция доменов сбоев
Резервирование подключения сайтов без дополнительных усилий
Простое и надежное решение для связи ЦОД
Транспортная инфраструктура
OTV OTV OTV OTV
MAC TABLE
VLAN MAC IF
100 MAC 1 Eth 2
100 MAC 2 Eth 1
100 MAC 3 IP B
100 MAC 4 IP B
MAC 1 MAC 3
MAC TABLE
VLAN MAC IF
100 MAC 1 IP A
100 MAC 2 IP A
100 MAC 3 Eth 3
100 MAC 4 Eth 4
Layer 2 Lookup
6
IP A IP B MAC 1 MAC 3 MAC 1 MAC 3 Layer 2 Lookup
2 Encap
3 Decap
5
MAC 1 MAC 3 West Site Server 1 Server 3
East Site
4
7
IP A IP B
1
IP A IP B MAC 1 MAC 3
Передача данных в OTV
6
Передача пакетов между ЦОД
OTV – что нового Выбор вариантов инкапсуляции
Инкапсуляция по умолчанию для OTV - “IP GRE” (OTV 1.0)
Новая OTV инкапсуляция - “UDP VXLAN” RFC 7348 (OTV 2.5)
Формат OTV настраивается на VDC / Site
UDP инкапсуляция требует новых линейных карт (F3, M3)
Тип инкапсуляции должен быть одинаковым на всех связываемых при помощи OTV объектах
OTV-a(config)# otv encapsulation-format ip {gre | udp} # или IP GRE или IP UDP
BRKDCT-3000 7
Единый APIC кластер/домен Много APIC кластеров/доменов
Pod ‘A’ Pod ‘n’
MP-BGP - EVPN
Multi-Pod
…
L3
APIC кластер
Pod 1 Pod 2
ACI Fabric
Stretched Fabric
APIC Cluster
ACI Fabric 2 ACI Fabric 1
Multi-Fabric (with L2 and L3 DCI)
L2/L3
DCI
L3 Site ‘A’ Site ‘n’
MP-BGP - EVPN
Multi-Site (Q3CY17)
Multi-Site
Controller
Использование Cisco ACI в распределенных ЦОД
Использование VXLAN EVPN в распределенных ЦОД
Растянутая фабрика Изолированные фабрики
Pod ‘A’ Pod ‘n’
MP-BGP - EVPN
Multi-Pod
…
L3 VXLAN EVPN Fabric 2 VXLAN EVPN Fabric 1
Multi-Fabric (L2 и L3 DCI)
L2/L3
DCI
В этой презентации
отличительные особенности
VXLAN EVPN фабрики будут
выделяться таким образом
Единый APIC кластер/домен Много APIC кластеров/доменов
Pod ‘A’ Pod ‘n’
MP-BGP - EVPN
Multi-Pod
…
L3
APIC кластер
Pod 1 Pod 2
ACI Fabric
Stretched Fabric
APIC Cluster
ACI Fabric 2 ACI Fabric 1
Multi-Fabric (with L2 and L3 DCI)
L2/L3
DCI
L3 Site ‘A’ Site ‘n’
MP-BGP - EVPN
Multi-Site (Q3CY17)
Multi-Site
Controller
Использование Cisco ACI в распределенных ЦОД
Pod ‘A’
MP-BGP - EVPN
Единый APIC кластер
Несколько модулей (ACI Pod) связанных IP
сетью (Inter-Pod network), каждый состоит из
набора leaf и spine
Управлением единым кластером APIC
Единый домен управления и политик
Изоляция доменов отказов протоколов
control plane (IS-IS, COOP)
Инкапсуляция VXLAN между модулями
Сквозное применение политик
Pod ‘n’
Inter-Pod Network
…
IS-IS, COOP, MP-BGP IS-IS, COOP, MP-BGP
ACI Multi-Pod Обзор
ACI Multi-Pod Поддерживаемые топологии
Pod 1 Pod n
Web/App DB Web/App APIC кластер
…
Внутри ЦОД Прямое соединение двух ЦОД
Pod 1 Pod 2
Web/App DB Web/App APIC кластер
Dark fiber/DWDM (up to 10 msec RTT)
Много ЦОД через транспортную сеть Pod 1 Pod 2
Pod 3
3 ЦОД
Dark fiber/DWDM (up to 10 msec RTT)
L3
10G*/40G/100G
10G*/40G/100G
10G/40G/100G 10G*/40G/100G 10G*/40G/100G
10G*/40G/100G 10G*/40G/100G
10G*/40G/100G
10G/40G/100G
10G*/40G/100G
10G*/40G/100G
10G*/40G/100G
10G*/40G/100G
* 10G только с QSA адаптерами на Spine коммутаторах -EX
Не управляется при помощи APIC, требуется отдельная настройка (day-0)
Топология IPN произвольная, все spine узлы к IPN подключать не обязательно
Основные требования:
Multicast BiDir PIM для передачи L2 BUM* трафика
OSPF для установления соседских отношений между spine и IPN для обеспечения связанности между VTEP
Поддержка Jumbo MTU (9150B) для обработки VXLAN инкапсулированного трафика
DHCP-Relay
Pod ‘A’ Pod ‘B’
Web/App DB Web/App
MP-BGP - EVPN
APIC Cluster
* Broadcast, Unknown unicast, Multicast
ACI Multi-Pod Требования к Inter-Pod Network (IPN)
16
ACI Multi-Pod Автоматическое обнаружение Pod
Обнаруживание и
настройка всех
устройств в корневом
Pod
2
Настройка интерфейсов на узлах
spine смотрящих в IPN, а так же
запуск EVPN
3
Узел Spine 1 в Pod 2
подключается к IPN и
отправляет DHCP request
1 4
DHCP request передается
IPN устройством на APIC
в Pod 1
5
DHCP response возвращается
на Spine 1 после чего
выполняется его полная
автоматическая настройка
6
‘Корневой’
Pod 1
Единый APIC кластер
APIC узел 2
присоединяется к
кластеру
9
Обнаруживание и
настройка всех
устройств в локальном
Pod
7
APIC узел 2
подключается к узлу
Leaf в Pod 2
8 1
APIC узел 1 подключается
к узлу Leaf в ‘корневом’
Pod 1
Pod 2
1
Обнаружение остальных Pod по этому же алгоритму 10
Автоматическая
конфигурация всех
POD в VXLAN EVPN
недоступна,
частичная при
помощи PoAP
ACI Multi-Pod Плоскость управления IPN
Два разных пула IP адресов для интерфейсов VTEP назначаемых при помощи APIC каждому Pod
Суммарные маршруты для этих пулов объявляются в сторону IPN при помощи OSPF
Узлы Spine редистрибутят суммарные машруты для других Pod в локальные процессы IS-IS
Требуется для того чтобы локальные VTEP могли взаимодействовать с удаленными VTEP
Web/App DB Web/App APIC кластер
OSPF OSPF
10.1.0.0/16 10.2.0.0/16
IPN Global VRF
IP Prefix Next-Hop
10.1.0.0/16 Pod1-S1, Pod1-S2, Pod1-S3, Pod1-S4
10.2.0.0/16 Pod2-S1, Pod2-S2, Pod2-S3, Pod2-S4
Leaf Node Underlay VRF
IP Prefix Next-Hop
10.2.0.0/16 Pod1-S1, Pod1-S2, Pod1-S3, Pod1-S4
IS-IS в OSPF
взаимная
редистрибуция
ACI фабрика обеспечивает независимость адресов конечных узлов (end-point), или их
идентификаторов (identifier), от местоположения конечного узла которое определяется при
помощи VTEP адреса или “locator”-адреса
Передача данных внутри фабрики осуществляется между VTEP-ами (ACI VXLAN tunnel
endpoints) с использованием расширенного VXLAN заголовка, известного как ACI VXLAN
policy header
Отображение внутренних MAC и IP адресов на местоположение обеспечивается при
помощи адресов VTEP с опорой на распределенную базу данных COOP
ACI фабрик – интегрированный оверлей Decoupled Identity, Location & Policy
Payload IP VXLAN VTEP
APIC
VTEP VTEP VTEP VTEP VTEP VTEP
Организация распределенной базы о конечных хостах Inline Hardware Mapping DB - 1,000,000+ хостов
10.1.3.11 fe80::462a:60ff:fef7:8e5e 10.1.3.35 fe80::62c5:47ff:fe0a:5b1a
Forwarding Table на Leaf коммутаторе разделяется на две части между локальными
(directly attached) и глобальными записями
Таблица с глобальными записями на Leaf коммутаторе кеширует часть полной
глобальной таблицы которая хранится на Proxy-устройствах
Если адрес хоста не найден в локальном кеше, то пакет по умолчанию отправляется
на spine коммутатор, который должен иметь информацию обо всех хостах (до
1,000,000+ записей)
Local Station Table
содержит адреса
‘всех’ хостов,
которые напрямую
подключены к Leaf
10.1.3.11
10.1.3.35
Port 9
Leaf 3
Proxy A *
Global Station Table
содержит локальный
кеш о подключенных
хостах
10.1.3.35 Leaf 3
10.1.3.11 Leaf 1 Leaf 4
Leaf 6
fe80::8e5e
fe80::5b1a
Proxy Station Table содержит
адреса ‘всех’ хостов,
подключенных к фабрике
Proxy Proxy Proxy Proxy
ACI Multi-Pod Плоскость управления MP-BGP EVPN
MP-BGP EVPN используется для синхронизации информации о конечных хостах и (Endpoint - EP) и группах Multicast (для каждого BD регистрируется своя группа)
Все записи с удаленных Pod ассоциируются с адресом Proxy VTEP который должен маршрутизироваться глобально (не является частью Pod TEP Pool)
Один и тот же BGP AS во всех Pod
iBGP EVPN сессии между узлами spine в разных Pod
Full mesh MP-iBGP EVPN связанность между локальными и удаленными узлами spine (по умолчанию)
Опционально возможно настроить RR (рекомендация – один RR на каждый Pod для отказоустойчивости)
Единый APIC кластер
MP-BGP - EVPN
EP1
EP1 Leaf 1
Proxy A Proxy B
EP1 Proxy A
EP2 EP3
EP2 Leaf 3
Proxy B
Proxy B
EP3
EP4
EP4
EP2 Proxy A
Leaf 4
Leaf 6
EP3
EP4
COOP
Одна BGP ASN
Аналог протокола
COOP и
возможность
поддержки 1М+
хостов в VXLAN
EVPN фабрике
отсутствует
EP2 EP1
Proxy A Proxy B
Spine инкапсулирует
трафик в сторону
Proxy B Spine VTEP
3
EP1 Leaf 4
EP2 Proxy B
4
Spine инкапсулирует
трафик в сторону leaf
EP2 Leaf 4
EP1 Proxy A
6
Если политика
позволяет, EP2 получает
пакет
EP1 посылает трафик
удаленному узлу EP2
1 1
VTEP IP VNID Tenant Packet Group
Policy
Информация о
политике переносится
между Pod
5
EP1 Pod1 L4
Proxy B *
Leaf выучивает адрес
удаленного EP1 и
имплементирует политику
EP2 e1/1
Местоположение EP2
неизвестно, трафик
инкапсулируется в сторону
local Proxy A Spine VTEP
(добавляется информация
S_Class)
Proxy A *
2
EP1 e1/3
ACI Multi-Pod Передача данных между POD
= VXLAN Encap/Decap
Единый APIC кластер
Другие механизмы
выучивания адресов
EP (MP-BGP или
через L2/L3 cтык)
EP2 EP1
*
EP1 Pod1 L4
Proxy B *
Leaf имплементирует
политику на входе и, если
политика разрешает
передачу, инкапсулирует
трафик в сторону
Leaf node L4
8 Leaf изучает местоположение
EP2 (имплементировать
политику уже не требуется)
Proxy A
9
EP2 Pod2 L4
7
EP2 посылает
обратный пакет VM1
EP1 получает пакет
10
VTEP IP VNID Tenant Packet Group
Policy
*
EP1 e1/3
ACI Multi-Pod Solution Передача данных между POD
= VXLAN Encap/Decap
Единый APIC кластер
11
С этого момента для взаимодействия EP1 и EP2
коммутаторы инкапсулируют трафик от Leaf к Leaf (VTEP к
VTEP) а политика всегда имплементируется на входящем
leaf коммутаторе (и для L2 и L3 взаимодействия
независимо от типа)
EP2 EP1
*
EP1 Pod1 L4
Proxy B *
Proxy A
EP2 Pod2 L4
VTEP IP VNID Tenant Packet Group
Policy
*
EP1 e1/3
ACI Multi-Pod Solution Передача данных между POD
= VXLAN Encap/Decap
Единый APIC кластер
Для растянутой
VXLAN EVPN
фабрики аналогично
единая плоскость
передачи данных
Процессы активны на всех узлах (не active/standby)
Данные распределяются как активные + 2 резервные копии (shards) для каждого
атрибута/объекта/политики
База Данных
реплицируется между
APIC контроллерами
APIC APIC APIC
Shard 2
Shard 1
Shard 3
Shard 1 Shard 1
Shard 2 Shard 2 Shard 3 Shard 3
Одна копия находится в
‘активном’ состоянии для
части БД
30
APIC – распределенная Multi-Active база данных
Контроллер на
основе полити для
VXLAN EVPN
фабрики не
доступен
APIC отключает доступ на запись к Базе
Данных, когда только один узел кластер
остается активным (standard DB quorum)
Аппаратная ошибка на двух узлах
приводит к тому что все шарды (shards)
переключаются в режим ‘read-only’ (по
мере восстановления узлов кластер
переключается в исходный режим)
Дополнительные узлы APIC кластера
увеличивают масштабируемость, но не
добавляют отказоустойчивости
Аппаратная ошибка на двух серверах приводит к
неконсистентному поведению для некоторых
шард (некоторые окажутся в режиме ‘read-only’
некоторые в режиме ‘read-write’)
APIC APIC APIC X X Шарды в
режиме
‘read-only’
APIC APIC APIC
Шарды в режиме
‘read-only’
APIC APIC X X
Шарды в режиме
‘read-write’
APIC – соображения по развертыванию кластера Сценарий с одним POD
31
Pod 1 Pod 2
Up to 10 msec
APIC APIC APIC X X
X
X Сценарий изоляции Pod: изменения
возможны на узлах в Pod1, но не в Pod2.
Кластер восстанавливается после того как
Pod-ы восстановят связанность
Полный выход из строя одного из Pod: при
полном выходе из строя одного из Pod
рекомендуется активировать Standby узел
чтобы вернуть возможность вносить
изменения в конфигурацию
APIC
Cценарий изоляции Pod: такое же поведение как и
в случае с кластером на 3 ноды (некоторые шарды
могут перейти в режим ”read-only”)
Полный выход из строя одного из Pod: полный
выход из строя Pod1 может привести к потере
информации
Возможно восстановление состояния при наличии
снепшота конфигурации (‘ID Recovery’ procedure –
требуется вовлечение BU и TAC)
Pod 1 Pod 2
Up to 10 msec
APIC APIC APIC APIC APIC
X
X X X
X
APIC – соображения по развертыванию кластера Multi-Pod – сценарий с 2-мя POD
32
• Упрощает замену вышедших из строя APIC контроллеров
• Standby APIC используется для замены любого активного узла в кластере
• Не принимает участия в конфигурации или управлении фабрикой до момента активации
• Никакие данные на него не реплицируются, даже admin credentials (Rescue-user логин работает)
• Минимальный рекомендуемый размер кластера - 3
• Поддерживается в Multi POD.
Функция Standby APIC
Multi pod Один контроллер вышел из строя в Pod2
Active APIC1 (id=1)
Active APIC2 (id=2)
Active APIC3 (id=3)
Можно заменить APIC3 на Standby APIC5
Standby APIC5 (id=5)
Standby APIC4 (id=4)
Multi pod Полная потеря связанности и утрата POD целиком
Active APIC1 (id=1)
Active APIC2 (id=2)
Active APIC3 (id=3)
Можно заменить APIC1 на Standby APIC4
APIC3 в pod2 перейдет в состояние, которое не позволит вносить изменения. (read-only access)
Standby APIC5 (id=5)
Standby APIC4 (id=4)
WAN
Client
PE
PE
PE
PE
Подключение WAN Edge устройств к Border Leaf узлам
Определение логической конструкции L3Out
VRF-lite для организации подключений различных контекстов маршрутизации
Для каждого tenant определяется один (или больше) L3Out с набором из Logical Nodes, Logical Interfaces, peering protocol
L3Out
Border Leafs
Организация L3 подключений фабрики ACI ‘Традиционный’ L3Out на пограничных узлах
42
43
Организация L3 подключений фабрики ACI ‘GOLF’ Design (начиная с релиза ACI 2.0)
Web/App
DCI OTV/VPLS
WAN
Client
PE
PE
PE
PE
Прямое/непрямое
подключение узла
spine к PE
GOLF (WAN Edge)
Routers
Прямое или непрямое подключение к WAN Edge маршрутизаторам
Лучшая масштабируемость, одна сессия протокола для всех VRF
Нет ограничений, которые накладывает аппаратная платформа border leaf (число префиксов)
VXLAN handoff на базе MP-BGP EVPN
Упрощенная настройка L3Out
= VXLAN Encap/Decap Автоматизированное
подключение ко
внешним сетям не
доступно в VXLAN
EVPN фабрике
WAN
Масштабируемое подключение Multi-Pod к WAN Поддерживаемые платформы
IP Network
WAN Edge Router
Nexus 7000/7700: F3 карта с релиза 7.3(1)D1(1). M3 планируется (Q3CY17)
ASR 9000: IOS-XR 6.1.2 для платформ с
RSP2*, RSP440 и RSP880 супервизорами
ASR 1000: все платформы (включая CSR1Kv).
SW release 16.4.1 без OpFlex
SW release 16.5.1 OpFlex
Whitepaper:
http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-736899.html
MP-BGP
EVPN
*Поддержка OpFlex будет добавлена в версии 6.2.1 (Q1CY17)
44
Масштабируемое подключение Multi-Pod к WAN Централизованная и распределенная модели
MP-BGP
EVPN
WAN
Централизованная модель WAN Edge
Применяется когда Pod-ы представляют собой комнаты/залы в одном физическом ЦОД
MP-BGP EVPN peering между узлом spine в каждом Pod и общими WAN Edge устройствами
WAN Edge
Routers
IPN
WAN
Распределенная модель WAN Edge
Pod-ы представляют собой различные ЦОД
Full mesh EVPN подключения между узлами spine внутри Pod и WAN Edge устройствами в каждом ЦОД
IPN IPN
WAN Edge
Routers WAN Edge
Routers
MP-BGP
EVPN
Предполагается, что при разворачивании ACI Multi-Pod совместно с GOLF все узлы spine имеют соседские отношения с одним и тем же набором устройств GOLF (и с локальными и с расположенными на соседней площадке GOLF устройствами)
Масштабируемое подключение Multi-Pod к WAN Full Mesh Peering между Spines и GOLF устройствами
IPN
WAN
APIC кластер
= MP-BGP EVPN Peering 49
IPN
WAN
10.10.10.10 20.20.20.10
Proxy A Proxy B
G1 G2 G3 G4
20.20.20.10
10.10.10.20
= VXLAN Encap/Decap
Оптимальный путь передачи
Update
APIC кластер
ACI Leaf Routing Table
20.20.20.0/24 G1,G2
G3,G4
Full Mesh Peering между Spines и GOLF устройствами Исходящие потоки трафика
Неоптимальный путь передачи
50
IPN
WAN
10.10.10.10
Proxy A Proxy B
Remote Router Table
10.10.10.0/24 G1,G2
G3,G4
G1 G2 G3 G4
20.20.20.10 10.10.10.10
10.10.10.20
= VXLAN Encap/Decap
Full Mesh Peering между Spines и GOLF устройствами Входящие потоки трафика
APIC кластер
Оптимальный путь передачи
G1,G2 Routing Table
10.10.10.0/24 A,B
G1,G2 Routing Table
10.10.10.0/24 A,B
Неоптимальный путь передачи
Update
Оптимизация путей
входящего и
исходящего трафика
так же требуется и в
VXLAN EVPN
фабрике
WAN/Campus
Сравнимая с DNS проблема по масштабированию
• Протокол на основе запросов
Каталог хостов
• Location != Routing
Исключение хостовых маршрутов из таблицы маршрутизации
• Состояние хостов перемещается в LISP directory
Минимизация ресурсов на коммутаторах и маршрутизаторах
Branch/Closet
LISP XTR
DC 1 DC 2
LISP Host directory
Отслеживание состояния конечного хоста при помощи LISP
66 BRKACI-2220
IP core
IPv4 или IPv6 адрес устройства
or IPv6 определяет и его
идентификатор (identity) и
местоположение (location)
Традиционная IP сеть
10.1.0.1 Когда устройство перемещается,
оно получает новый IPv4 или IPv6
адрес, который определяет и его
идентификатор (identity) и
местоположение (location)
20.2.0.9
IPv4 или IPv6
адреса устройств
определяют только
их идентификацию.
Когда устройство
перемещается, его IPv4 или
IPv6 адрес, определяющий
его идентификатор не
изменяется.
Сеть с поддержкой LISP Loc/ID “Разделение”
IP core
1.1.1.1
2.2.2.2
Только местоположение
изменяется при переезде
10.1.0.1
10.1.0.1
Это его местоположение
Location Identity Separation Protocol Что понимается под “Location” и “Identity”
Сайт без LISP
East-DC
LISP сайт
IP сеть
ETR
EID-to-RLOC mapping
5.1.1.1
5.3.3.3
1.1.1.1
5.2.2.2
10.3.0.0/24 10.2.0.0/24
West-DC
PITR
5.4.4.4
10.1.0.0/24
Сайт без LISP
ITR S
D
DNS Entry: D.abc.com A 10.2.0.1
1
10.1.0.1 -> 10.2.0.1
2
EID-prefix: 10.2.0.0/24
Locator-set:
2.1.1.1, priority: 1, weight: 50 (D1)
2.1.2.1, priority: 1, weight: 50 (D2)
Mapping
Entry
3 Эта политика контролируется владельцем ЦОД, который устанавливает веса
10.1.0.1 -> 10.2.0.1
1.1.1.1 -> 2.1.1.1
4
10.1.0.1 -> 10.2.0.1
5
2.1.1.1 2.1.2.1 3.1.1.1 3.1.2.1
Передача пакетов в LISP Как работает LISP?
WAN/Campus
• Фабрика может быть основана на любой технологии:
• ACI, EVPN
• LISP маршрутизаторы получают от фабрики /32 маршруты и регистрируют их в базе данных LISP
LISP Host Directory Services для любой фабрики Branch/Clo
set
LISP XTR
DC 1 DC 2
Local host routes
Local host routes
69 BRKACI-2220
Решение на базе
LISP совместимо с
VXLAN EVPN
фабрикой
IPN
IP WAN
Proxy A Proxy B
G1 G2 G3 G4
= VXLAN Encap/Decap
Site Gateway (SG): LISP encap/decap
LISP signaling
= LISP Encap/Decap
Fabric based Mobility: Move Detection
Local Routing Fix-up
COOP Registration
Fabric based Mobility: Move Detection
Local Routing Fix-up
COOP Registration
Site Gateway (SG): LISP encap/decap
LISP signaling
APIC кластер
ACI, GOLF и LISP взаимодействие Функциональные компоненты
70
IPN
IP WAN
10.10.10.10
Proxy A Proxy B
G1 G2 G3 G4
20.20.20.10
10.10.10.20
LISP Map-System
IP Prefix RLOC
= LISP Encap/Decap = VXLAN Encap/Decap = EVPN Update = LISP Map-Register
APIC кластер
… …
20.20.20.0/24 Branch1
Branch1
TOR Routing Table
… …
0.0.0.0/24 G3,G4
TOR Routing Table
… …
0.0.0.0/24 G1,G2
Передача исходящего трафика на LISP устройства Вариант 1 – шлюз по умолчанию (Control Plane)
G1-G4 анонсируют
шлюз по умолчанию в
фабрику
Филиальные
маршрутизаторы
регистрируют свои
префиксы в LISP
71
1
2
IPN
IP WAN
10.10.10.10
Proxy A Proxy B
G1 G2 G3 G4
20.20.20.10
10.10.10.20
LISP Map-System
IP Prefix RLOC
= LISP Encap/Decap = VXLAN Encap/Decap = BGP Message = LISP Map-Register
APIC кластер
… …
20.20.20.0/24 Branch1
Branch1
G1-G4 анонсируют
удаленные
префиксы в фабрику
TOR Routing Table
… …
20.20.20.0/24 G3,G4
TOR Routing Table
… …
20.20.20.0/24 G1,G2
Филиальные
маршрутизаторы
регистрируют свои
префиксы в LISP
Экспорт LISP префиксов
& редистрибуция в BGP ipv4 route-export site-registrations
redistribute lisp
Передача исходящего трафика на LISP устройства Вариант 2 – анонсирование специфических маршрутов (Control Plane)
72
1
2
3
IPN
IP WAN
10.10.10.10
Proxy A Proxy B
G1 G2 G3 G4
20.20.20.10
10.10.10.20
LISP Map-System
DC-WAN Router LISP Cache
20.20.20.0 /24 Branch1
IP Prefix RLOC
= LISP Encap/Decap = VXLAN Encap/Decap = EVPN Update = LISP Map-Request/Reply
APIC кластер
… …
20.20.20.0/24 Branch1
Branch1
TOR Routing Table
… …
0.0.0.0/24 G3,G4
TOR Routing Table
… …
0.0.0.0/24 G1,G2
ACI, GOLF и LISP взаимодействие Передача исходящего трафика
75
Настройка APIC
Настройка анонсов для хостов на уровне VRF
Применяется для всех public subnets, которые анонсируются через L3Out
Настройка N7K GOLF
Type-2 апдейты, которые шлются в сторону GOLF устройства содержать идентификатора L2VNI в поле Ethernet Tag ID (такие же апдейты пересылаются между spine-узлами Pod)
VTEP-ы ожидают что Ethernet Tag ID будет установлен в значение zero, поэтому N7K GOLF по умолчанию будет игнорировать Type-2 апдейты
Дополнительная команда была добавлена в N7K:
Эта настройка не требуется на ASR9K или ASR1K
router bgp 3 router-id 111.111.111.111 address-family l2vpn evpn allow-vni-in-ethertag
ACI release 2.1(1h) Оптимизация входящего трафика
Настройка анонсирования /32 маршрутов
76
IPN
IP WAN
10.10.10.10
Proxy A Proxy B
G1 G2 G3 G4
20.20.20.10
10.10.10.20
LISP Map-System
Remote Router LISP Cache
10.10.10.10/32 G1,G2
G3,G4 10.10.10.20/32
IP Prefix RLOC
= LISP Encap/Decap
G3, G4 Routing Table
10.10.10.20/32 B
10.10.10.0/24 B
10.10.10.10/32 A
10.10.10.0/24 A
G1, G2 Routing Table
= VXLAN Encap/Decap = EVPN Update = LISP Map-Register
APIC кластер
10.10.10.10/32 G1,G2
10.10.10.20/32 G3,G4
10.10.10.0/24 G1,G2,G3,G4
Оптимальный
путь для
входящего
трафика
Оптимальный
путь для
входящего
трафика
ACI, GOLF и LISP взаимодействие Оптимизация входящего трафика
77
IPN
IPWAN
Proxy A Proxy B
G1 G2 G3 G4
20.20.20.10
10.10.10.20
= VXLAN Encap/Decap
LISP Map-System
IP Prefix RLOC
Remote Router LISP Cache
10.10.10.10/32 G1,G2
G3,G4 10.10.10.20/32
APIC кластер
10.10.10.10
10.10.10.10/32 B
10.10.10.20/32 B
10.10.10.0/24 B
G3, G4 Routing Table
10.10.10.10/32 Null0
10.10.10.0/24 A
G1, G2 Routing Table
10.10.10.10/32 G1,G2
10.10.10.20/32 G3,G4
10.10.10.0/24 G1,G2,G3,G4
10.10.10.10/32 G3,G4
ACI, GOLF и LISP взаимодействие Оптимизация входящего трафика и мобильность (1)
78
IPN
IPWAN
10.10.10.10
Proxy A Proxy B
G1 G2 G3 G4
20.20.20.10
10.10.10.20
= VXLAN Encap/Decap
10.10.10.10/32 B
10.10.10.20/32 B
10.10.10.0/24 B
G3, G4 Routing Table
LISP Map-System
IP Prefix RLOC
10.10.10.10 G3,G4
10.10.10.20 G3,G4
10.10.10.0/24 G1,G2,G3,G4
Remote Router LISP Cache
10.10.10.10/32 G3,G4
G3,G4 10.10.10.20/32
APIC кластер
10.10.10.10/32 Null0
10.10.10.0/24 A
G1, G2 Routing Table
ACI, GOLF и LISP взаимодействие Оптимизация входящего трафика и мобильность (2)
79
ANP
WEB
ACI Multi-Pod Сохранение модели политик при перемещении нагрузки между Pod
Единый APIC кластер APP DB
WEB APP DB L3OUT Определяется
профиль приложения
(не зависит от POD)
1
При подключении
нагрузки происходит
рендеринг контрактов
2
ANP
WEB
ACI Multi-Pod Сохранение модели политик при перемещении нагрузки между Pod
Единый APIC кластер APP DB
WEB APP DB L3OUT
Нагрузка
перемещается между
POD вручную или
автоматически
3
ANP
WEB
ACI Multi-Pod Сохранение модели политик при перемещении нагрузки между Pod
Единый APIC кластер APP DB
WEB APP DB L3OUT
Рендеринг контракта
происходит
автоматически (см
детали на слайде по
передаче данных)
4
В VXLAN EVPN
фабрике отсутствует
модель политик
ACI Multi-Pod Интеграция сервисными устройствами
Устройства в режиме Active и Standby в разных Pod
Создается точка в сети которая «притягивает» трафик через IPN сеть (hair-pinning across the IPN) Active Standby
Active/Standby Active/Standby
Независимые пары Active/Standby разворачиваются в каждом Pod
Рекомендуется только сценария использования МСЭ на периметре сети, предполагая что мероприятия по организации симметричных потоков проведены
Cluster
Кластер МСЭ между Pod
Для режима ‘Split Spanned EtherChannel’ не поддерживается (единственный режим доступный в кластере на основе FTD)
Поддерживается только в режиме ‘Single Individual’ (кластер на основе ASA)
Есть возможность организовать подключение
в режиме Spanned Etherchannel –
фильтрация cluster-mac на уровне IPN
Pod 1 Pod 2
86
Все узлы кластера ASA используют один и тот же MAC и IP адреса (назначен узлу
с ролью – «cluster Master»)
В случае Multi-POD приводит к проблеме одновременного детектирования EP в
обоих POD в настоящий момент НЕ ПОДДЕРЖИВАЕТСЯ
Замечание: так же самая проблема, если ASA подключается к разным узлам leaf в
одном и том же POD
MAC1 (or MAC1/IP1) COOP Update
Multi-Pod и кластер ASA Режим ‘Split Spanned EtherChannel’
MAC1 (or MAC1/IP1) COOP Update
Не поддерживается на
данный момент для всех
версий кластера
ASA и FTD
87
Каждый узел ASA кластера имеет уникальную пару MAC/IP
Каждый узел имеет индивидуальный конфиг в настоящее время не
поддерживается device-package для ASA (только un-managed mode)
Не поддерживается в прошивкой FTD на ASA
Валидированный дизайн отсутствует на данный момент
Pod 1 Pod 2
MAC1 (or MAC1/IP1) COOP Update
MAC2 (or MAC2/IP2) COOP Update
Multi-Pod и кластер ASA Режим ‘Single Individual’
Только кластер на
базе ASA
Единый APIC кластер/домен Много APIC кластеров/доменов
Варианты расширения Cisco ACI
Pod ‘A’ Pod ‘n’
MP-BGP - EVPN
Multi-Pod
…
L3
APIC Cluster
Pod 1 Pod 2
ACI Fabric
Stretched Fabric
APIC Cluster
ACI Fabric 2 ACI Fabric 1
Multi-Fabric (with L2 and L3 DCI)
L2/L3
DCI
L3 Site ‘A’ Site ‘n’
MP-BGP - EVPN
Multi-Site (Q3CY17)
Multi-Site
Controller
90
Отдельные ACI фабрики с независимыми
кластерами APIC
Каждая фабрика рассматривается как отдельный
«регион» и «зона доступности»
Ограничение зоны вносимых изменений
Использование для сценариев DR и Active/Active
Нет ограничений по расстоянию
Multi-Site контроллер настраивает
сквозные конфигурации в нескольких
кластерах APIC
MP-BGP EVPN с VXLAN инкапсуляцией
между сайтами
Сквозное применение политик
ACI Multi-Site Обзор решения
Site 1
MP-BGP - EVPN
Site 2
…
L3 Регион ‘A’ Регион ‘B’
Multi-Site
Controller
Web
GUI
Rest
API
Планируется:
Q3CY17
90
9
1
ACI Multi-Site Основные сценарии
Планируется:
Q3CY17
Layer 3 между сайтами
L3 Site 1
2 Мобильность IP для Disaster Recovery
• Одна и та же IP подсеть на нескольких сайтах
• Мобильность IP (‘холодная’ миграция) между сайтами
• Нет Layer 2 фладинга между сайтами
Site 2
L3 Site 1 Site 2
1
• L2 (BD) не растянут между сайтами
• Связь только на L3 (внутри ли между VRF)
• Каждый сайт можеть быть ACI Multi-Pod фабрикой*
*Позднее
L3 Site 1 Site 2
3 Высокомасштабируемые ЦОД Active/Active
• Связь нескольких фабрик, чтобы создать «большую» фабрику
• L2 домены (BD) растянуты между сайтами
• Поддержка ‘живой’ миграции VM
• Layer 2 фладинг между сайтами
VXLAN EVPN в распределенных ЦОД
Cisco Connect 2017 © 2017 Cisco and/or its affiliates. All rights reserved. 92
Использование VXLAN EVPN в распределенных ЦОД
Растянутая фабрика Изолированные фабрики
• Два изолированных MP-BGP EVPN домена
• Связанность через L3 IPN
• Единая плоскость передачи данных – VTEP из POD1
напрямую взаимодействует c VTEP из POD2
• Для распространения BUM трафика используется
multicast или Ingress-репликация
• Точка контроля/фильтрации для BUM трафика между
POD отсутствует
• Две независимые MP-BGP EVPN фабрики
• L2-связанность через традиционный VLAN и далее OTV
• L3-связанность через традиционный VRF Lite, MPLS VPN
• Единая плоскость передачи данных между VTEP
отсутствует – передача всегда через border leaf
• Для распространения BUM трафика между POD
применяется OTV
• Есть точка контроля/фильтрации для BUM-трафика в
виде OTV устройства
Pod ‘A’ Pod ‘n’
MP-BGP - EVPN
Multi-Pod
…
L3 VXLAN EVPN Fabric 2 VXLAN EVPN Fabric 1
Multi-Fabric (L2 и L3 DCI)
L2/L3
DCI
Сравнение ACI и VXLAN EVPN Краткое и неполное
Cisco Connect 2017 © 2017 Cisco and/or its affiliates. All rights reserved. 94
Функция ACI VXLAN
Автоматическая конфигурация фабрики/Pod
Полная Частичная PoAP
COOP, 1M+ хостов Да Нет
Контроллер Да Нет
GOLF (автоматизация L3) Да Нет
Требуется управление входящим/исходящим трафиков (для определенных сценариев)
Да Да
Модель политик Да Нет
Заключение
• OTV
• Надежная и проверенная технология
• ACI MultiPod
• Баланс между изоляцией доменов сбоя и централизацией управления
• APIC Standby – выживаемость кластера без потери управления
• Автоматизация подключения ко внешним сетям при помощи Golf
• Простое управление входящими и исходящими потоками при помощи LISP
• VXLAN EVPN
• Еще один вариант организации взаимодействия между ЦОД на базе Nexus 9000
• ACI MultiSite
• То ли еще будет
Cisco Connect 2017 © 2017 Cisco and/or its affiliates. All rights reserved. 102
#CiscoConnectRu
Спасибо за внимание! Оцените данную сессию в мобильном приложении конференции
© 2017 Cisco and/or its affiliates. All rights reserved.
Контакты:
Тел.: +7 495 9611410 www.cisco.com
www.facebook.com/CiscoRu
www.vk.com/cisco
www.instagram.com/ciscoru
www.youtube.com/user/CiscoRussiaMedia