Связь территориально- распределенных ЦОД

Cisco
Connect
Москва, 2017
Цифровизация:
здесь и сейчас

Связь
территориально-
распределенных
ЦОД
Хаванкин Максим
Системный архитектор, CCIE
mkhavank@cisco.com
© 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 дизайнах

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 BMAC 1  MAC 3MAC 1  MAC 3Layer 2
Lookup
2
Encap
3
Decap
5
MAC 1  MAC 3
West
SiteServer 1 Server 3
East
Site
4
7
IP A IP B
1
IP A IP BMAC 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

ACI Multipod

Единый 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 2ACI Fabric 1
Multi-Fabric (with L2 and L3 DCI)
L2/L3
DCI
L3Site ‘A’ Site ‘n’
MP-BGP - EVPN
Multi-Site (Q3CY17)
Multi-Site
Controller
Использование Cisco ACI в распределенных ЦОД

Использование VXLAN EVPN в распределенных ЦОД
Растянутая фабрика Изолированные фабрики
MP-BGP - EVPN
Multi-Pod
…
L3 VXLAN EVPN Fabric 2VXLAN EVPN Fabric 1
Multi-Fabric (L2 и L3 DCI)
L2/L3
DCI
В этой презентации
отличительные особенности
VXLAN EVPN фабрики будут
выделяться таким образом

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/AppDB Web/App
APIC кластер
…
Внутри ЦОД Прямое соединение
двух ЦОД
Pod 1 Pod 2
Web/AppDB 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

ACI Multipod: требования к IPN

 Не управляется при помощи 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/AppDB Web/App
MP-BGP - EVPN
APIC Cluster
* Broadcast, Unknown unicast, Multicast
ACI Multi-Pod
Требования к Inter-Pod Network (IPN)
16

ACI Multipod: плоскости управления и
передачи данных

ACI Multi-Pod
Автоматическое обнаружение Pod
Обнаруживание и
настройка всех
устройств в корневом
Pod
2
Настройка интерфейсов на узлах
spine смотрящих в IPN, а так же
запуск EVPN
3
Узел Spine 1 в Pod 2
подключается к IPN и
отправляет DHCP request
14
DHCP request передается
IPN устройством на APIC
в Pod 1
5
DHCP response возвращается
на Spine 1 после чего
выполняется его полная
автоматическая настройка
6
‘Корневой’
Pod 1
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/AppDB 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
Leaf Node Underlay VRF
IP Prefix Next-Hop
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
PayloadIPVXLANVTEP
APIC
VTEP VTEP VTEP VTEP VTEP VTEP

Организация распределенной базы о конечных хостах
Inline Hardware Mapping DB - 1,000,000+ хостов
10.1.3.11 fe80::462a:60ff:fef7:8e5e10.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 для
отказоустойчивости)
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 фабрике
отсутствует

EP2EP1
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
11
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
Другие механизмы
выучивания адресов
EP (MP-BGP или
через L2/L3 cтык)

EP2EP1
*
EP1 Pod1 L4
Proxy B*
Leaf имплементирует
политику на входе и, если
политика разрешает
передачу, инкапсулирует
трафик в сторону
Leaf node L4
8
Leaf изучает местоположение
EP2 (имплементировать
политику уже не требуется)
Proxy A
9
EP2 Pod2 L4
7
EP2 посылает
обратный пакет VM1
EP1 получает пакет
10
Group
Policy
*
EP1 e1/3
ACI Multi-Pod Solution

11
С этого момента для взаимодействия EP1 и EP2
коммутаторы инкапсулируют трафик от Leaf к Leaf (VTEP к
VTEP) а политика всегда имплементируется на входящем
leaf коммутаторе (и для L2 и L3 взаимодействия
независимо от типа)
EP2EP1
*
EP1 Pod1 L4
Proxy B*
Proxy A
EP2 Pod2 L4
Group
Policy
*
EP1 e1/3
ACI Multi-Pod Solution
Для растянутой
VXLAN EVPN
фабрики аналогично
единая плоскость
передачи данных

ACI Multipod: отказоустойчивость
кластера и APIC Standby

 Процессы активны на всех узлах (не active/standby)
 Данные распределяются как активные + 2 резервные копии (shards) для каждого
атрибута/объекта/политики
База Данных
реплицируется между
APIC контроллерами
APIC APIC APIC
Shard 2
Shard 1
Shard 3
Shard 1Shard 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
APICAPICAPIC
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
APICAPICAPIC APIC APIC
X
X X
XX
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)

ACI Multipod: масштабируемое
подключение ко внешним сетям

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

Централизованная и распределенная модели
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 Multipod: пути входящего трафика
без оптимизации

 Предполагается, что при разворачивании ACI Multi-Pod совместно с
GOLF все узлы spine имеют соседские отношения с одним и тем же
набором устройств GOLF (и с локальными и с расположенными на
соседней площадке GOLF устройствами)
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
Исходящие потоки трафика
Неоптимальный путь
передачи
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
Входящие потоки трафика
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
фабрике

ACI Multipod: оптимизация входящего и
исходящего трафика на примере LISP

WAN/Campus
 Сравнимая с DNS проблема по
масштабированию
• Протокол на основе запросов
 Каталог хостов
• Location != Routing
 Исключение хостовых маршрутов
из таблицы маршрутизации
• Состояние хостов перемещается в
LISP directory
 Минимизация ресурсов на
коммутаторах и маршрутизаторах
Branch/Clo
set
LISP XTR
DC 1 DC 2
LISP Host
directory
Отслеживание состояния конечного хоста при помощи
LISP
66BRKACI-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/2410.2.0.0/24
West-DC
PITR
5.4.4.4
10.1.0.0/24
Сайт без LISP
ITRS
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
69BRKACI-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
Передача исходящего трафика
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,G410.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
= 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
путь для
входящего
трафика
путь для
входящего
трафика
Оптимизация входящего трафика
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
10.10.10.10/32 G1,G2
G3,G410.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
10.10.10.10/32 Null0
10.10.10.0/24 A
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
Оптимизация входящего трафика и мобильность (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
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
10.10.10.10/32 G3,G4
G3,G410.10.10.20/32
APIC кластер
10.10.10.10/32 Null0
10.10.10.0/24 A
Оптимизация входящего трафика и мобильность (2)
79

ACI Multipod: модель политик и
микросегментация

ANP
WEB
ACI Multi-Pod
Сохранение модели политик при перемещении нагрузки между Pod
Единый APIC кластерAPP DB
WEB APP DBL3OUTОпределяется
профиль приложения
(не зависит от POD)
1
При подключении
нагрузки происходит
рендеринг контрактов
2

ANP
WEB
ACI Multi-Pod
WEB APP DBL3OUT
Нагрузка
перемещается между
POD вручную или
автоматически
3

ANP
WEB
ACI Multi-Pod
WEB APP DBL3OUT
Рендеринг контракта
происходит
автоматически (см
детали на слайде по
передаче данных)
4
В VXLAN EVPN
фабрике отсутствует
модель политик

ACI Multipod: интеграция с сервисным
устройствами

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

ACI Multisite

Единый APIC кластер/домен Много APIC кластеров/доменов
Варианты расширения Cisco ACI
MP-BGP - EVPN
Multi-Pod
…
L3
APIC Cluster
Pod 1 Pod 2
ACI Fabric
Stretched Fabric
APIC Cluster
ACI Fabric 2ACI Fabric 1
Multi-Fabric (with L2 and L3 DCI)
L2/L3
DCI
L3Site ‘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
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 в распределенных ЦОД

Использование 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 устройства
MP-BGP - EVPN
Multi-Pod
…
L3 VXLAN EVPN Fabric 2VXLAN EVPN Fabric 1
Multi-Fabric (L2 и L3 DCI)
L2/L3
DCI

Сравнение ACI и VXLAN EVPN
Краткое и неполное
Функция ACI VXLAN
Автоматическая конфигурация
фабрики/Pod
Полная Частичная PoAP
COOP, 1M+ хостов Да Нет
Контроллер Да Нет
GOLF (автоматизация L3) Да Нет
Требуется управление
входящим/исходящим трафиков
(для определенных сценариев)
Да Да
Модель политик Да Нет

Заключение

Заключение
• OTV
• Надежная и проверенная технология
• ACI MultiPod
• Баланс между изоляцией доменов сбоя и централизацией управления
• APIC Standby – выживаемость кластера без потери управления
• Автоматизация подключения ко внешним сетям при помощи Golf
• Простое управление входящими и исходящими потоками при помощи LISP
• VXLAN EVPN
• Еще один вариант организации взаимодействия между ЦОД на базе Nexus 9000
• ACI MultiSite
• То ли еще будет 

#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

Связь территориально- распределенных ЦОД

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Связь территориально- распределенных ЦОД

Similar to Связь территориально- распределенных ЦОД (20)

More from Cisco Russia

More from Cisco Russia (20)

Связь территориально- распределенных ЦОД