Cisco Connect · Port 9 Leaf 3 * Proxy A Global Station Table содержит локальный кеш о подключенных хостах 10.1.3.35 Leaf 3 10.1.3.11 Leaf 1

Cisco Connect Москва, 2017

Цифровизация: здесь и сейчас

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

Хаванкин Максим

Системный архитектор, 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 дизайнах


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

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 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 в распределенных ЦОД

Растянутая фабрика Изолированные фабрики


MP-BGP - EVPN

Multi-Pod

…

L3 VXLAN EVPN Fabric 2 VXLAN EVPN Fabric 1

Multi-Fabric (L2 и L3 DCI)

L2/L3

DCI

В этой презентации

отличительные особенности

VXLAN EVPN фабрики будут

выделяться таким образом



MP-BGP - EVPN

Multi-Pod

…

L3

APIC кластер

Pod 1 Pod 2

ACI Fabric

Stretched Fabric

APIC Cluster



L2/L3

DCI


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


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/App DB 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

1 4

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


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

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 для отказоустойчивости)


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


Другие механизмы

выучивания адресов

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


Policy

*

EP1 e1/3

ACI Multi-Pod Solution Передача данных между POD

= VXLAN Encap/Decap


11

С этого момента для взаимодействия EP1 и EP2

коммутаторы инкапсулируют трафик от Leaf к Leaf (VTEP к

VTEP) а политика всегда имплементируется на входящем

leaf коммутаторе (и для L2 и L3 взаимодействия

независимо от типа)

EP2 EP1

*

EP1 Pod1 L4

Proxy B *

Proxy A

EP2 Pod2 L4


Policy

*

EP1 e1/3

ACI Multi-Pod Solution Передача данных между POD

= VXLAN Encap/Decap


Для растянутой

VXLAN EVPN

фабрики аналогично

единая плоскость

передачи данных

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

Процессы активны на всех узлах (не 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)


Multi pod Полная потеря связанности и утрата POD целиком

Active APIC1 (id=1)

Active APIC2 (id=2)

Active APIC3 (id=3)

Можно заменить APIC1 на Standby APIC4

APIC3 в pod2 перейдет в состояние, которое не позволит вносить изменения. (read-only access)



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


















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

Предполагается, что при разворачивании 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

фабрике

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

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


= 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


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


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

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


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,G4 10.10.10.20/32

APIC кластер

10.10.10.10/32 Null0

10.10.10.0/24 A


ACI, GOLF и LISP взаимодействие Оптимизация входящего трафика и мобильность (2)

79

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

ANP

WEB

ACI Multi-Pod Сохранение модели политик при перемещении нагрузки между Pod

Единый APIC кластер APP DB

WEB APP DB L3OUT Определяется

профиль приложения

(не зависит от POD)

1

При подключении

нагрузки происходит

рендеринг контрактов

2

ANP

WEB



WEB APP DB L3OUT

Нагрузка

перемещается между

POD вручную или

автоматически

3

ANP

WEB



WEB APP DB L3OUT

Рендеринг контракта

происходит

автоматически (см

детали на слайде по

передаче данных)

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’


Не поддерживается на

данный момент для всех

версий кластера

ASA и FTD

87

Каждый узел ASA кластера имеет уникальную пару MAC/IP

Каждый узел имеет индивидуальный конфиг в настоящее время не

поддерживается device-package для ASA (только un-managed mode)

Не поддерживается в прошивкой FTD на ASA

Валидированный дизайн отсутствует на данный момент

Pod 1 Pod 2



Multi-Pod и кластер ASA Режим ‘Single Individual’

Только кластер на

базе ASA

ACI Multisite



Варианты расширения Cisco ACI


MP-BGP - EVPN

Multi-Pod

…

L3

APIC Cluster

Pod 1 Pod 2

ACI Fabric

Stretched Fabric

APIC Cluster



L2/L3

DCI


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 в распределенных ЦОД


Использование 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 2 VXLAN 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

Cisco Connect · Port 9 Leaf 3 * Proxy A Global Station Table содержит локальный кеш о подключенных хостах 10.1.3.35 Leaf 3 10.1.3.11 Leaf 1

Documents