1. Связь распределённых
ЦОД с использованием
OTV и LISP
Скороходов Александр
Системный инженер – консультант
askorokh@cisco.com
+7(495)789-8615

2. «Растягивание» LAN:
внутри и между ЦОД
Data Data
Center Center
A B
§ Ряд приложений требуют
смежности на 2 уровне § Миграция серверов
§ Кластеры (Veritas, MSFT) § Высокая доступность
§ vMotion § Распределенные служебные и
§ «Доморощенные» приложения прикладные сервисы

3. Связь ЦОД
Требования к расширению подсетей
Необходимо
q Защита от «петель»
WAN q Изоляция STP
Intra-DC Domain
q Отказоустойчивость.
Intra-DC Domain
with STP Isolation with STP Isolation q Балансировка нагрузки
на WAN
WAN No Inter-DC Loop WAN q Прозрачность для
ядра
Core Core
q Прозрачность для
L3
Aggr/ L3
Aggr/
сетей ЦОД
L2 Distr
Same Extended VLAN
L2 Distr q Оптимизация трафика
Access Access q Масштабирование
q Связь многих ЦОД
Data-center Data-center
SAN SAN
§ Изоляция STP: предотвращение распространения проблем
§ Предотвращение «зацикливания» между ЦОДами
§ Отказоустойчивость и масштабирование производительности
§ Поддержка многих сайтов

4. Overlay Transport
Virtualization (OTV)

5. Распределенные ЦОД
Проблемы существующих решений
• Сложно строить и эксплуатировать
• Зависимость от транпорта (MPLS, Dark fiber, etc.).
• Неэффективное использование полосы
• Сбои могут распространяться между ЦОД

6. Информация об адресах: flooding
§ Традиционные технологии выучивают MAC адреса с помощью
flooding
§ Опора на flooding – потенциал для распространения сбоев
x2
Site A Site C
MAC 1
MAC 1 propagation
Site B

7. Кабели или Pseudo-Wires
§ Опора на full-mesh сеть кабелей, лямбд, или “pseudo-wire”
сервисов
§ Для N объектов - N*(N-1)/2 соединений
§ Для multicast и broadcast трафика – репликация на источнике

8. Резервирование подключения сайта
§ Необходимы дополнительные протоколы для выбора активного
устроства/подключения
§ Опора на STP для управления альтернативными путями –
опасно и ненадёжно!
Active Active
L2 Site L2 VPN L2 Site

9. Overlay Transport Virtualization (OTV)
Простое и надежное решение для связи ЦОД
• Расширение L2 доменов по
произвольной IP сети
– Тёмная оптика, MPLS, IP VPN...
– Поддержка нескольких ЦОД
• Упрощение построения и
эксплуатации
– Простота интеграции в
существующие сети
– Настройка за несколько команд
• Высокая надёжность
– Изоляция доменов сбоев OTV
– Резервирование подключения
сайтов без дополнительных
усилий
Any Workload, Anytime, Anywhere

10. Overlay Transport Virtualization
Принципы работы протокола
• Ethernet трафик инкапсулируется в IP: “MAC in IP”
• Динамическая инкапсуляция с использованием таблицы
маршрутизации MAC
• Не строится Pseudo-Wire или туннель
MAC1 à MAC2 IP A à IP B MAC1 à MAC2 MAC1 à MAC2
Encap Decap
MAC IF
OTV OTV
MAC1 Eth1
MAC2 IP B IP A IP B
MAC3 IP B
Communication between
MAC1 (site 1) and MAC2 (site 2)
Server 1 Server 2
MAC 1 MAC 2

11. Элементы решения OTV
• Пограничное устройство (Edge Device)
– Реализует OTV, подключает сайт к траспортной сети
– На сайте может быть несколько OTV Edge Devices
• Внутренние интерфейсы
– Интерфейсы Edge Devices внутрь ЦОД
– Ведут себя как обычные интерфейсы L2
– Spanning tree BPDU обрабатываются как на обычных портах коммутатора
• Внешние интерфейсы
– Маршрутизируемые интерфейсы Edge Device в ядро.
– Используются для ргестрации в multicast группы OTV.
– IP адреса используются для инкапсуляции Overlay
OTV Interface
• Интерфейс Overlay
– Виртуальный интерфейс для
– связи сайтов
– Не участвует в STP
L2 L3
Core
Join
Internal Interface
Interfaces

12. OTV Data Plane: коммутация между ЦОД
1. Поиск MAC адресата в таблице 4. Пограничное устройство на втором
коммутации 2 уровня. MAC 3 достижим сайте принимает и декапсулирует
через IP B. пакет
2. Пограничное устройство инкапсулирует 5. Коммутация фрейма на 2 уровне. MAC
фрейм в IP пакет 3 – локальный адрес
3. Транпорт доставляет пакет на второй сайт 6. Фрейм доставляется адресату
3
MAC TABLE Транспортная MAC TABLE
VLAN MAC IF сеть VLAN MAC IF
Decap
IP A
100 MAC 1 Eth 2 2 4 IP B 100 MAC 1 IP A
1 100 OTV MAC 2 Eth 1 OTV
Encap OTV
100 OTV
MAC 2 IP A 5
Layer 2 100 MAC 3 IP B MAC 1 è MAC 3 IP A è IP B
MAC 1 è MAC 3 IP A è IP B
100 MAC 3 Eth 3
Layer 2
Lookup Lookup
100 MAC 4 IP B 100 MAC 4 Eth 4
MAC 1 è MAC 3 6
MAC 1 è MAC 3 MAC 1 West East
MAC 3
Site Site

13. Пополнение MAC таблиц
OTV Control Plane
• OTV проактивно анонсирует достижимость MAC (control-plane learning)
• MAC адреса автоматически анонсируются в процессе рабты
коммутатора, как только настроен OTV
• Не требуется отдельная настройка
MAC Addresses
Reachability
Core
IP A IP B
West East
IP C
South

14. OTV Control Plane
Поиск других устройств и взаимодействие с ними
• Взаимодействие c другими устройствами через multicast
(предпочтительно) или unicast
OTV OTV
OTV OTV Control Plane
Control Plane
East
West
OTV
OTV
Control
Plane
South

15. Транспорт не поддерживает multicast?
В OTV есть решение: режим Adjacency Server
• Использование multicast в ядре обеспечивает множество
преимуществ:
– Сокращает число hello и update пакетов, которые должен
формировать OTV
– Упрощает обнаружение партнеров, доваление и удаление
сайтов
– Оптимизирует обработку broadcast и multicast трафика
• Тем не менее, он доступен не всегда
• Adjacency Server Mode обеспечивает поддержку для
траспортных сетей, поддерживающих только unicast

16. Spanning Tree и OTV
Независимость сайтов
• OTV не влияет на STP топологию сайта
• У кажого сайта – свой домен STP, полностью независимый от
других
• Встроенная функциональность – настройка не требуется
• Edge Device посылает/принимает STP BPDUs только на
внутренних интерфейсах
OTV OTV
The BPDUs The BPDUs
stop here
L3 stop here
L2

17. Unknown Unicast и OTV
Предотвращение flooding между ЦОД
• OTV не опирается на flooding для того, чтобы узнавать MAC
адесах на других сайтах
• Любые unknown unicasts попадающие на OTV edge device не
передаются в ядро. Это не требует дополнительной настройки.
• Мы исходим из того, что оконечные устройства не являются
«молчаливыми»
MAC TABLE
VLAN MAC IF
OTV OTV
100 MAC 1 Eth1
100 MAC 2 IP B
L3 No MAC 3 in the
- - -
L2 MAC Table
MAC 1 è MAC 3

18. Контроль ARP трафика
ARP Neighbor-Discovery (ND) кеш
• Каждое OTV edge device поддерживает ARP кеш, заполняемый
в результате прослушивания ARP ответов
• Первоначальные ARP запросы распространяются между
сайтами, для последующих ответ формируется OTV Edge
Device локально
• Существенное сокращение ARP широковещания на магистрали
2
ARP
5 ARP reply on reply
4
Subsequent behalf of
ARP requests remote server
(IP A) (IP A) OTV
Transport
OTV
Infrastructure
1 3
First
ARP Snoop &
request cache
ARP Cache
(IP A) ARP
MAC 1 IP A reply
MAC 2 IP B

19. Резервирование подключения
Authoritative Edge Device
• OTV обеспечивает резервирование без «петель» за счёт выбора
активного Edge устройства в каждой VLAN: Authoritative Edge
Device (AED).
• Edge устройства на сайте взаимодействуют по “site-vlan”, чтобы
выбрать AED
OTV
Internal peering for
AED election
OTV
AED

20. Настройка OTV
Транспорт с поддержкой multicast
Интерфейс для подключения к транспортной
сети. Его IP адрес используется как адрес
источника при инкапсуляции OTV
ASM/Bidir группа для управляющего
feature otv трафика OTV
interface Overlay0 SSM диапазон адресов для передачи
multicast-трафика сайтов
otv join-interface Ethernet1/1
otv control-group 239.1.1.1
otv data-group 232.192.1.0/24
otv extend-vlan 100-150
otv site-vlan 99 VLAN, растягиваемые с помощью OTV
otv site-identifier 10
VLAN используемые внтури сайта для связи
Идентификатор сайта между пограничными устройствами

21. Настройка OTV
Unicast транспорт
Интерфейс для подключения к транспортной сети. Его IP
адрес используется как адрес источника при
инкапсуляции OTV
Конфигурирует устройство как Adjacency
feature otv Server
interface Overlay0 Удалённые устройства, работающие как
Adjacency Server (настройка, взаимно
otv join-interface Ethernet1/1 исключающаая с предыдущей)
otv adjacency-server
или otv use-adjacency-server 10.10.10.10 10.10.11.11
otv extend-vlan 100-150
otv site-vlan 99 VLAN, растягиваемые с помощью OTV
otv site-identifier 10
VLAN используемые внтури сайта для связи
Идентификатор сайта между пограничными устройствами

22. Проблемы «растягивания» LAN
Решаемые OTV
North
Data
• Работа поверх любого транспорта (IP, Fault Center Fault
Domain Domain
MPLS)
• Изоляция доменов сбоев
• Независимость сайтов
• Оптимальное использование полосы
• Встроенная отказоустойчивость
• Встроенная защита от «петель»
• Связь многих сайтов LAN Extension
• Масштабируемость
§ VLANs, сайты, MACs
§ ARP, broadcasts/floods
• Простота настройки
Only 6 CLI
• Легкость добавления сайтов commands
Fault Fault
Domain Domain
South
Data
Center

23. Оптимизация потоков
трафика

24. Проблема оптимальной доставки
• Расширение на 2 уровне – проблема для оптимальной
маршрутизации
• Проблема выбора расположения шлюза по умолчанию и
анонсирования подсети в магистраль
Ingress Routing Localization:
Clients-Server
WAN
Egress Routing Localization:
Server-Client Egress Routing Localization:
Server-Client
Pod A Server-Server Pod N

25. Оптимальный путь
В чём именно проблема?
10.1.1.0/25 & 10.1.1.128/25 advertised into L3 10.1.1.0/24 advertised into L3
DC A is the primary entry point Backup should main site go down
Layer 3 Core
Agg
Agg
Access
Access
Node A
Virtual Machine Virtual Machine
ESX
ESX
Data Center 1 VMware Data Center 2
vCenter

26. Оптимальный путь
Хотелось бы так...
Agg
Agg
Access
Access
Node A
Virtual Machine
ESX
ESX
Data Center 1 VMware Data Center 2
vCenter

27. Оптимизация пути «на выход»
Локализация FHRP с помощью OTV
• Одна и та же HSRP группа на всех сайтах с теме виртуальным MAC
адресом
• Каждый сайт обеспечивает исходящую маршрутизацию
• OTV локализует исходящий трафик за счёт фильтрации HSRP hello
сообщений между сайтами
• ARP запросы перехватываются на OTV edge устройстве чтобть
обеспечить ответы именно от локального шлюза
Active Active
GWY Site 1 GWY Site 2
L3
L2
FHRP FHRP
ARP traffic is Hellos Hellos ARP traffic is
kept local kept local
West East

28. Оптимизация пути «на вход»
Locator-ID Separation Protocol (LISP)
• Отделяет идентификатор сервиса (IP адрес) от его
местоположения
• Маршрутизация исходя из местоположения, а не адреса хоста
• Соотношение адреса и его местоположение хранятся в
директории
• Поиск метоположения IP адреса по информации из директории
• Инкапсуляция трафика (IP in IP) и передача по месту
нахождения хоста
• Директория – распределенная база данных
ALT directory
§ Информация о хостах не
хранится в таблице
маршрутизации
§ “Summarizable host routing”
Resolution & Registration
Data Path

29. Location Identity Separation Protocol
Что подразумевается под “Location” и “Identity”?
Стандартное поведение
Loc/ID “совмещены”
Internet
x.y.z.1 При перемещении, устройство
получает новый адрес
IPv4 или IPv6 адрес
служит и для
идентификации, и поиска w.z.y.9
месоположения
Логика LISP
Loc/ID “отделены”
Internet
x.y.z.1 При перемещении,
устройство сохраняет адрес
IPv4 или IPv6 адрес a.b.c.1
служит только для e.f.g.7
идентификации x.y.z.1
Местоположение
здесь! Меняется только
местоположение

30. LISP: инкапсуляция
IPv4 RLOC используя IPv4 EID или IPv6 EID
IPv4 Outer Header:
Router supplies
RLOCs
UDP
LISP
header
IPv4 Inner
Header: IPv6 Inner
Host supplies Header:
EIDs Host supplies
EIDs
• Внешний заголовок тоже может быть IPv6
• Инкапсуляция в UDP чтобы повысить эффективность балансировки
нагрузки на магистральных линках (ECMP/Port Channel)

31. LISP: составные части решения
Два пространства имен – EID и RLOC
• LISP – Элементы решения
§ EID
(Endpoint
IdenBfier)
EID
RLOC
IP
адрес
хоста
–
«имя
человека»
MS/
a.a.a.0/24
b.b.b.0/24
c.c.c.0/24
w.x.y.1
x.y.w.2
z.q.r.5
MR
EID
Space
d.d.0.0/16 z.q.r.5
EID
RLOC
§ RLOC
(RouBng
Locator)
a.a.a.0/24
b.b.b.0/24
w.x.y.1
x.y.w.2
IP
адрес
LISP
роутера
–
«адрес
человека»
c.c.c.0/24 z.q.r.5
d.d.0.0/16 z.q.r.5
EID
RLOC
§ Mapping
Database
System
a.a.a.0/24 w.x.y.1
связывает
EID
и
RLOC
–
«адресная
книга»
b.b.b.0/24 x.y.w.2
c.c.c.0/24 z.q.r.5
xTR
d.d.0.0/16 z.q.r.5
§ MS
-­‐
Map
Server
Non-­‐LISP
§ MR
-­‐
Map
Resolver
Mapping
§ ALT
–
Alternate
Topology
Prefix
Next-­‐hop
System
w.x.y.1 e.f.g.h
x.y.w.2 e.f.g.h
z.q.r.5 e.f.g.h
§ xTR
–
Ingress
/
Egress
Tunnel
Router
z.q.r.5 e.f.g.h
§ PxTR
–
Proxy
Ingress
/
Egress
Tunnel
Router
PxTR
RLOC
Space
• LISP – уровень коммутации
§ Запрос по требованию, кеширование ответа xTR
xTR
§ Динамическая инкасуляция
§ Оверлей над транспортной сетью (только на
пограничных роутерах) EID
Space
• LISP – уровень управления
§ Распределённая адресная база
§ Map-Servers и Map-Resolvers
§ LISP+ALT

32. Prefix Route
Locator-ID Separation Protocol (LISP) Locator
(RLOC)
Принцип работы 10.10.10.1 A, B
Host IP = End-point ID 10.10.10.2 A, B
… …
Router IP = Route Locator
10.10.10.5 X, Y
1. ITR консультируется с Dest = 10.10.10.1 10.10.10.6 X, Y
директорией, чтобы получить …… …
Route Locator (RLOC) для данного 1
End-point ID (EID) Encap Ingress Tunnel Router (ITR)
2
2. ITR инкапуслирует трафик IPinIP
и отправляет по адресу RLOC
RLOC
Dest = 10.10.10.1 Dest = A
3. ETR принимает и декапсулирует Core routes
only
трафик
§ Детальная информация о
достижимости хостов 3
Decap
§ При миграции хоста Egress TR (ETR)
RLOCs: A B X Y
информация отражается в
директории Pod N
Dest = 10.10.10.1 Pod A
…
§ Информация об оконечных Access
устройствах не хранится в
таблицам маршрутизации
EIDs: 10.10.10.1 .2 .3 .4 .5 .6 .7 .8
Extended Subnet (10.10.10.0 /24)

33. LISP: путь пакета
3
EID-­‐prefix:
10.1.0.0/24
Mapping Locator-­‐set:
Entry
172.16.1.1,
pNon-­‐LISP
s,
weight:
50
(D1)
riority:
1 ite
Определяется
1
Non-­‐LISP
site
priority:
1,
weight:
50
(D2)
172.16.2.1,
сайтом-получателем
DNS
Entry:
D.abc.com
A
10.1.0.1
10.3.0.0/24
LISP
Site
S
ITR
PiTR
2 172.16.10.1
4.4.4.4
10.3.0.1
-­‐>
10.1.0.1
IP
Network
3.3.3.3
EID-­‐to-­‐RLOC
4 mapping
1.1.1.1
2.2.2.2
172.16.10.1
-­‐>
172.16.1.1
10.3.0.1
-­‐>
10.1.0.1
172.16.1.1
172.16.2.1
172.16.3.1
172.16.4.1
ETR
5
West-­‐DC
East-­‐DC
10.3.0.1
-­‐>
10.1.0.1
D
10.1.0.0/24
10.2.0.0/24

34. LISP: база отображения адресов
Регистрация и поиск
LISP
Site
Mapping Cache Entry (ITR):
10.1.0.0/16-> (A, B)
iTR
Map Server /
Resolver: 1.1.1.1
Map-Reply
10.1.0.0/16 -> (A, B)
A B C D
Database Mapping Entry (ETR): eTR
eTR
eTR
eTR
Database Mapping Entry (ETR):
10.1.0.0/16 -> (A, B) 10.2.0.0/16 -> (C, D)
West-­‐DC
East-­‐DC
10.1.0.0 /16 10.2.0.0/16
Y
X Y Z
10.1.0.2

35. LISP: поддержка мобильности VM
Обнаружение перемещения
• Новый xTR обнаруживает новый источник трафика
• Настройка динамических EID определяет, для каких
адресов разрешёно роуминг
• Регистрация в базе LISP
lisp dynamic-eid roamer
database-mapping 10.1.0.0/24 <RLOC-C> …
database-mapping 10.1.0.0/24 <RLOC-D> Получен пакет...
map-server 1.1.1.1 key abcd
interface vlan 100 … от «нового» хоста
lisp mobility roamer … входит в разрешённый
Mapping DB диапазон динамических EID...
1.1.1.1 2.2.2.2
…это «переезд»!
A B C D
Регистрация /32 в LISP
LISP-­‐VM
(xTR)
West-­‐DC
East-­‐DC
10.1.0.0 /16 10.2.0.0/16
Y
X Y Z
10.1.0.2

36. LISP: поддержка мобильности VM
Перенаправление трафика
• При обнаружении переезда, происходит обновление:
– Обновляется соотношение в базе соотношений EID->RLOC
– iTR уведомляются о необходимости обновить кеш
• Удалённые LISP роутеры (iTRs или PiTRs) теперь отправляют
трафик на другой сайт
• «Прозрачность» для хостов и транспортной сети
10.1.0.0/16 – RLOC A, B
LISP
Site
xTR
Mapping DB
10.1.0.2/32 – RLOC C, D
A B C D
LISP-­‐VM
(xTR)
West-­‐DC
East-­‐DC
10.1.0.0 /16 10.2.0.0 /16
Y
X Y Z
10.1.0.2

37. Где внедрять LISP and OTV
Роли и положение в сети
xTR: роутеры филиалов на LISP
LISP
Site
сайтах Mapping Servers/
• Customer-managed/owned resolvers:распределены
xTR
• Customer-
• SP-Managed CE service Non-­‐LISP
Sites
managed/owned
PxTR: Пограничые роутеры в • SP provided service
Internet
/
WAN
транзитных точках Backbone
• Customer backbone routers
PxTR
• Customer router @ co-
location Mapping DB
• SP provided router/service Data
Center
IP
Backbone
LISP-­‐VM
(xTR)
OTV
LISP-VM xTR: коммутаторы
DC-Aggregation
агрегирования в ЦОД
• Customer-managed/owned
DC-Access
West-­‐DC
East-­‐DC
OTV: Коммутаторы
агрегирования в ЦОД RLOC
EID
LISP
Encap/Decap
• Customer-managed/owned

38. Оптимальный транспорт с помощью LISP и OTV
Client in LISP Site Client in non-LISP Site
C1 C2
D E
Layer3 Core
MR PxTR
MS
A A’
B B’
OTV Server-to-Server L2 traffic
VLAN A – 10.1.1.0
VLAN A – 10.1.1.0
FHRP: 10.1.1.1 ESX Server B
ESX Server A FHRP: 10.1.1.1
- Virtual-Machine-A - Virtual-Machine-A
- IP Address = 10.1.1.100 - IP Address = 10.1.1.100
- Mask: 255.255.255.0 - Mask: 255.255.255.0
- Default GW = 10.1.1.1 - Default GW = 10.1.1.1
LISP: L3 Client-to-Server OTV: L2 Server-to-Server
• Оптимизация маршрутизации с детальной информацией • Оптимизация расширения LAN
о местоположении • Распределение прикладных систем
• Оптимицация мобильности внутри или между подсетями • Надежная связь на втором уровне для мобильности
• Масштабирование прикладных сервисов виртуальных сервисов и кластерных систем

39. LISP: Аппаратные требования к Nexus 7000
Interfaces N7K-M132XP-12 Другие карты Карты F1
Encap/Decap N7K-M132XP-12L M-серии (Proxy Mode)
N7K-M132XP-12
N7K-M132XP-12L
P O P
• Только N7K-M132XP-12 или N7K-M132XP-12L
способны выполнять LISP-инкапсуляцию
• F1 карты могут использовать карты N7K-
M132XP в прокси-режиме
• Другие карты M-серии не поддерживают LISP
и не должны присутствовать в том же VDC

40. Nexus 7000: сосуществование OTV и LISP
Aggregation VDC OTV VDC
IP Services, SVIs, LISP OTV Services
• OTV должен работать в отдельном VDC, чтобы
поддерживать растягивание маршрутизируемых VLAN
• LISP работает в VDC агрегирования, также как и любой
другой IP сервис

41. Дополнительная информация
• http://www.cisco.com/go/dci
• http://www.lisp4.net
• http://lisp.cisco.com

42. Вопросы и Ответы

43. Спасибо!
Просим Вас заполнить анкеты.
Ваше мнение очень важно для нас!