Построение катастрофоустойчивых и распределённых ЦОД (часть 2). Объединение сетей ЦОД на 2 уровне

Построение катастрофоустойчивых и
распределённых ЦОД (часть 2).
Объединение сетей ЦОД на 2 уровне
Хаванкин Максим
cистемный архитектор
mkhavank@cisco.com
11/19/14 © 2014 Cisco and/or its affiliates. All rights reserved.

Содержание
§ Использование vPC для объединения ЦОД
§ Особенности применения FabricPath в сценариях объединения ЦОД
§ Технологии EoMPLS и VPLS для связи между ЦОД
§ Применение OTV для объединения ЦОД
11/19/14 © 2014 Cisco and/or its affiliates. All rights reserved. 2

Использование vPC для связи между ЦОД
DC 1 DC 2
vPC domain 11 vPC domain 21
Long Distance
AGGR CORE
R R
- -
N N
- -
ACCESS
E
E
E
-
N
- E
F
F
F
F
-
-
N N
E E
Server Cluster
CORE AGGR
ACCESS
Server Cluster
Network port
Edge or portfast port type
- Normal port type
Rootguard
N
E
B
F
BPDUguard
BPDUfilter
R
802.1AE (Optional)
- -
- -
-
B
N
N N
R
R
-
R R R R
B

Использование vPC для связи между ЦОД
DC 1 DC 2
Long Distance
AGGR CORE
R R
- -
N N
- -
ACCESS
E
E
E
-
N
- E
F
F
F
F
-
-
N N
E E
Server Cluster
CORE AGGR
ACCESS
Server Cluster
Лучшие практики:
§ vPC Domain id должны быть разными
§ Настроить BPDU Filter для изоляции 2-х STP доменов
§ Настроить STP Edge Mode быстрой сходимости
§ За пределами vPC домена петель быть не должно
§ Динамическую маршрутизацию использовать нельзя:
• статическая маршрутизация
• выделенные каналы для L3 связности
- -
- -
-
B
N
N N
R
R
-
R R R R
B

desc DCI point to point connection
switchport
switchport mode trunk
vpc 10
switchport trunk allowed vlan 100-200
spanning-tree port type edge trunk
spanning-tree bpdufilter enable
storm-control broadcast level 1
storm-control multicast level 1
DC
1
N7k
interface port-channel10
Po1
Po10
Настройка DCI порта
feature lacp
feature vpc
!
vrf context vpc-keepalive
vpc domain 5
role priority 4000
peer-keepalive destination 192.168.10.2
source 192.168.10.1 vrf vpc-keepalive
delay restore 40
!
switchport
switchport mode trunk
vpc peer-link
switchport trunk allowed vlan 1,100-210
spanning-tree port type network
http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_1/nx-os/security/configuration/guide/sec_storm.html
5
Пример настройки vPC на Nexus

Применение FabricPath в сценариях объединения ЦОД
О чем нужно помнить приступая к внедрению FP на DCI?
Зависимость от L1 WAN каналов
§ Требуются каналы точка-точка высокого качества
§ Remote Port Shutdown и micro flapping protection
Организация передачи multidestination трафика
§ Требуется тюнинг для локализации трафика, m-cast всегда через корень дерева
IP маршрутизация поверх FabricPath
§ hello-пакеты OSPF (multicast) всегда через корень MDT дерева
FabricPath DCI и взаимодействие с STP
§ Фабрика всегда является STP root для всех своих VLAN,
блокировка параллельного vPC
FabricPath и HSRP локализация
40
40
40 40
Site B
§ HSRP Control-plane может быть изолирован при помощи неправильных authentication key
§ HSRP data-plane не может быть изолирован когда все VLAN настроены в режиме FP, что приводит к
flapping-у vMAC
Высокая доступность
§ Необходима тонкая настройка L2 ISIS: allocate-delay timer, transition-delay, linkup-delay, spf-interval, lsp-gen-
interval
S1 Root MDT1
R2
10 20
5
Site C
R1
Site A
7

Multidestination трафик (одна топология)
Пример № 1 – multicast трафик передается через MDT дерево
Site B
Site A
S1 Root MDT1
Vlan 100 Vlan 100
Vlan 100
R2
20 40 20
40
Site C
R1
• Нельзя управлять распространением Multicast/ARP трафика между S1 и R2 находясь в ЦОД A.
• Неоптимальная передача связана с природой FabricPath MDT
• Природа FabricPath
- Несоответствие с принципами DCI (автономность, зашита от эффекта домино, …)
- Требуется серьезное планирование возможностей MDT дерева, особенно в случае multicast

Multidestination трафик (одна топология)
Пример № 2 – влияние сбоев
Vlan 100
Site A Site B
Vlan 100
S1
R2
Root MDT1
Vlan 100
Site C
• После сбоя в ЦОД А Multicast/ARP трафик между S1 и R2 больше не локализуется в ЦОД A.
• Неоптимальная передача связана с природой FabricPath MDT
- Несоответствие с принципами DCI (автономность, зашита от эффекта домино, …)
- Требуется серьезное планирование возможностей MDT дерева, особенно в случае multicast

Зависимость OSPF adjacency от FabricPath топологии
Локальный
Vlan 1000
Локальный
Vlan 2000
Локальный
Vlan 3000
Site A Site B
Vlan 100
Vlan 200 Vlan 400
Vlan 300
Vlan 500 Vlan 600
Vlan 700
A
B
C
D
E F
Site C
• Один транзитный OSPF Vlan на каждое соседское взаимоотношение FabricPath L2 ISIS
- Даже с “OSPF network point-to-point” на SVI, OSPF hello-пакеты являются multicast-пакетами
- OSPF Hello-пакеты всегда используют MDT (см. пред. слайды)
- Выход из строя DCI канала не приводит к разрыву соседских отношений в OSPF
- Потеря MDT1 root влияет на все соседские отношения в OSPF

Site A
Site C
Site B
Vlan 100 A C
OSPF HELLOS
Шаг 1 : IP маршрутизация
Следующих узел - C
Шаг 2 : FabricPath
Используется канал AC
чтобы достичь SVI 100 на C
vlan-ы 100, 200, 300, 400, 500, 600, 700
должны быть настроены на всех FP узлах
B D
E F Root MDT1
Локальный
Vlan 1000
Локальный
Vlan 2000
Локальный
Vlan 3000

Site A Site B
A C
Шаг 1 : IP маршрутизация
Следующих узел - C
Шаг 2 : FabricPath
Используется канал AВD
чтобы достичь SVI 100 на C
B D
E F
Site C
Локальный
Vlan 1000
Локальный
Vlan 2000
vlan-ы 100, 200, 300, 400, 500, 600, 700
должны быть настроены на всех FP узлах
Root MDT1
Локальный
Vlan 3000

Особенности использования FabricPath
Технология FabricPath при связи ЦОД друг с другом не поддерживает режим
Plug and Play
§ Специализированный набор функций отсутствует
§ Существуют подводные камни (L1 физические каналы между ЦОД, настройка маршрутизации )
§ Планирование возможностей/мощности Multidestination Tree – ключевая проблема
FabricPath допустимо использовать когда:
§ Небольшие расстояния между ЦОД
§ Multicast широко не используется
§ Вы понимаете подводные камни и допускаете распределение трафика с опорой на
Multidestination Tree
OTV - более предпочтительный вариант
13

Virtual Private Wire Service (EoMPLS)
Возможности технологии
§ Прозрачный сервис растягивания ЛВС при помощи соединений точка-точка
§ Инкапсуляция Ethernet фреймов в MPLS пакеты
§ RFC 4448 определяет методы инкапсуляции для передачи Ethernet поверх MPLS
сетей
Emulated Layer-2 Service
Pseudowire (PW)
CE
Ref: RFC 3985 Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture
P
E
P
E
CE
CE
CE
PW1
PW2
Native
Service
Native
Service
AC
AC
AC
AC

Virtual Private LAN Service (VPLS)
Возможности технологии
§ Архитектура которая реализует
многоточечную связанность Ethernet
устройств так, как если бы они были
подключены к одному ЛВС сегменту
§ VPLS эмулирует IEEE Ethernet
коммутатор поверх MPLS облака
§ Основан на создании связей точка-тока
по топологии «full mesh»
§ Передача данных на основе MAC
адреса назначения
§ Flooding - Broadcast, Multicast, Unknown
Unicast
CE-A1 CE-A3
MPLS
CE-B1 CE-B3
CE-B2
CE-A2

Поддержка в аппаратуре
§ L2VPN функциональность поддерживается сегодня на картах M-серии
§ F1 и F2e* модули поддерживают MPLS Layer 3 VPN в режиме proxy-mode
§ F2 модули не поддерживают MPLS
§ Планируется, что F3 модули будут поддерживать MPLS, в том числе L2VPN в
релизе NX-OS 7.2
N7K-M108X2-12L
* -требуется NX-OS 6.2(2)
N7K-M148GS-11
N7K-M148GS-11L
N7K-M148GT-11
N7K-M148GT-11L
N7K-M132XP-12
N7K-M132XP-12L
N7K-M224XP-23L
N7K-M202CF-22L
N7K-M206FQ-23L

Применение L2 VPN для объединения ЦОД
VPLS / EoMPLS рекомендуется в следующих случаях:
§ Существующая сеть уже поддерживает MPLS/L2VPN
сервис
§ Персонал имеет опыт в разворачивании и поддержке
MPLS L2VPN сервисов
§ Требуется организация DCI на базе стандартных
технологий, например для совместимости с другими
производителями
Во всех остальных случаях рекомендуется OTV:
§ Простота обслуживания
§ Возможность задействовать персонал,
обслуживающий сеть ЦОД
§ Технология, не зависящая от методов
транспортировки информации между ЦОД

§ Плоскости управления и передачи данных
§ Изоляция доменов сбоя
§ Резервированное подключение
§ Мобильность
§ QoS и масшатбируемость
§ Оптимизация исходящего трафика
§ Новые функции в OTV
§ Проектирование сетей с применением OTV

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

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

Терминология
Edge Device
§ Реализует OTV функции
§ Уровень агрегации или ядра
§ Несколько OTV Edge Device на один ЦОД
(multi-homing)
Internal Interface
§ Интерфейс на Edge Device, который
«смотрит вниз» внутрь сети ЦОД
§ Принимает VLAN-ы, которые будут
распространяться OTV
§ Обычный интерфейс 2-го уровня
§ Специальная настройка «для OTV» не требуется
§ Поддерживается IPv4 и IPv6
22
OTV устройства и интерфейсы
Core Device
OTV Edge
Device
Aggregation Device
OTV Internal Interface
OTV Join Interface
OTV Overlay Interface
OTV Edge
Device
OTV Internal
Interfaces

Терминология
Join Interface
§ Интерфейс, которым Edge Device
подключается «наверх»
§ Маршрутизируемый интерфейс point-to-point
(поддерживаются - physical, sub-interface
или port-channel)
§ Используется для физического «присоединения»
к оверлейной сети
§ Специальная настройка «для OTV» не требуется
§ Только IPv4
Overlay Interface
§ Виртуальный интерфейс с основной OTV конфигурацией
§ Логический интерфейс типа multi-access с поддержкой multicast
§ Инкапсулирует L2 фреймы в IP unicast или multicast
23
OTV устройства и интерфейсы
Core Device
OTV Edge
Device
Aggregation Device
OTV Internal Interface
OTV Join Interface
OTV Overlay Interface
OTV Join
Interface
Overlay Interface

Плоскость управления OTV
§ Проактивное выучивание MAC-адресов
§ Unknown unicast flooding не используется по умолчанию (функция
selective unicast flooding в релизе 6.2)
§ Фоновый процесс не требующий специальной настройки
§ Между различными OTV Edge Device используется протокол IS-IS
24
Создание MAC таблиц доступных устройств
West
OTV
Распространение
информации
о MAC адресах
IP A IP B
IP C
East
South
OTV
OTV

Обнаружение соседей и формирование соседских отношений
§ Перед тем как информация о MAC адресах начнет распространяться
между площадками устройства OTV Edge должны:
‒ обнаружить друг друга
‒ построить друг с другом соседские отношения
§ Соседские отношения формируются поверх транспортной инфраструктуры
‒ с опорой на Multicast (функция доступна во всех версиях ПО)
‒ с опорой только на Unicast ( начиная с версии ПО NX-OS 5.2 & IOS-XE 3.9)
25

Обнаружение соседей (опора на транспортную сеть с поддержкой multicast)
Конечный результат
• Соседские отношения поддерживаются
посредством «вещания в» и «слушания»
multicast-группы
• Один пакет “OTV-update” реплицируется
multicast сетью на всех соседей
OTV Control Plane
West
OTV
IP A
Механизм
• Edge Devices (ED) присоединяются к
multicast группе, как хосты (включать
PIM на ED не нужно)
• Пакеты “OTV-hello” и “OTV-update”
используют multicast транспорт
East
OTV
OTV Control Plane
IP B
Транспортная сеть
с поддержкой Multicast
26

Шаг1: обнаружение соседей с опорой на сеть muticast
OTV Control Plane OTV Control Plane
West
OTV
IP A IP B
Encap Decap
South
East
OTV
OTV
OTV Control Plane
IP C
Decap
OTV Hello
OTV Hello
OTV Hello
IGMP Join G
IGMP Join G
IGMP Join G
Multicast state for group G
established throughout transport
Сеть реплицирует multicast
пакет и доставляет всем
участникам OTV домена
Все устройства
присоединяются к OTV
control-group G
1
2
3
4
5
6
6
7
7
OTV Hello IP A è G
OOTTVV H Heelllolo IP A è G
OOTTVV H Heelllolo IP A è G
Neighbor IP Addr
West IP A
Neighbor IP Addr
West IP A
Neighbor IP Addr
27

Шаг2: обнаружение соседей с опорой на сеть muticast
OTV Hello OTV Hello
5 5
OTV Control Plane OTV Control Plane
OOTTVV HHeelllloo IP C è G OOTTVV HHeelllloo IP C è G
IP A IP B
4 4
Decap Decap
OTV Hello IP C è G
28
South
East
West
OTV
OTV
OTV
OTV Control Plane
IP C
Encap
OTV Hello
Neighbor IP Addr
West IP A
Neighbor IP Addr
West IP A
South IP C
Neighbor IP Addr
South IP C
1
2
3
Двух-сторонние
соседские отношения
сформированы
Сайт South создает свой «OTV-hello»
пакет помещая в TLV-поле пакета
адрес сайта West

Проактивное выучивание MAC адресов (с опорой на multicast)
Encap Decap
South
East
Формируется пакет «OTV-update
» с новым MAC
Update A IP A è G
West
OTV
OTV
OTV
VLAN MAC IF
100 MAC A
100 MAC B
100 MAC C
VLAN MAC IF
100 MAC A
100 MAC B
100 MAC C
адресом
Update A
VLAN MAC IF
100 MAC A e1/1
101 100 MAC B e1/1
102 100 MAC C e1/1
VLAN MAC IF
100 MAC A IP A
101 MAC B IP A
102 MAC C IP A
VLAN MAC IF
100 MAC A IP A
100 MAC B IP A
100 MAC C IP A
Новый MAC адрес был
выучен в VLAN, который при
помощи OTV «растягивается»
между ЦОД
Decap
Update A
Update A
UUppddaatete A A IP A è G
UUppddaatete A A IP A è G
1
2
3
4
5
5
6
6
101 102 Добавление MAC
адреса выученного
при помощи OTV
7
7
Добавление MAC
адреса выученного
при помощи OTV
MAC Table
MAC Table
MAC Table
29

Настройка
interface Overlay1
otv join-interface port-channel100
otv control-group 239.1.1.1
otv data-group 232.1.1.0/24
otv extend-vlan 200-209
West East
30
Опора на multicast транспорт
otv
otv
otv
otv Core
interface port-channel 100
mtu 9216
ip address 172.16.1.34/30
ip igmp version 3

Настройка
Опора на multicast транспорт - картина целиком
West East
31
otv
otv
otv
otv Core
WEST_OTVA
feature otv
otv site-vlan 210
otv site-identifier 0001.0001.0001
interface Overlay1
no shutdown
mtu 9216
ip address 172.16.1.34/30
ip igmp version 3
EAST_OTVA
feature otv
otv site-vlan 210
otv site-identifier 0002.0002.0002
interface Overlay1
no shutdown
mtu 9216
ip address 172.16.1.26/30
ip igmp version 3

Обнаружение соседей (транспорт с поддержкой unicast)
§ Идеально для объединения небольшого количества ЦОД
§ С увеличением числа ЦОД рекомендуется опираться на multicast в
транспортной сети
32
West
OTV
OTV Control Plane
IP A
East
OTV
OTV Control Plane
IP B
Транспортная сеть с
поддержкой unicast
Конечный результат
• Поиск соседей автоматизируется при
помощи “Adjacency Server”
• Все пакеты управления реплицируются в
сторону каждого соседа
• Трафик данных так же реплицируется на
устройстве источнике таких данных( head-end
replication)
Механизм
• Edge Devices (ED) регистрируется на
“Adjacency Server” ED
• ED полный список соседей (oNL) от AS
• Пакеты «OTV-hello» и «OTV-update»
инкапсулируются в IP и в unicast режиме
передаются каждому соседу

Настройка
Транспорт с поддержкой unicast: Primary Adjacency Server Overlay
interface Overlay1
otv adjacency-server unicast-only
West East
33
otv
otv
otv
otv Core

Настройка
Транспорт с поддержкой unicast: Secondary Adjacency Server Overlay
interface Overlay1
otv use-adjacency-server 172.16.1.34 unicast-only
otv adjacency-server unicast-only
Primary Server
West East
34
otv
otv
otv
otv Core

Конфигурация
Транспорт с поддержкой unicast: клиентские Overlay интерфейсы
Primary Server Secondary Server
interface Overlay1
otv use-adjacency-server 172.16.1.34 172.16.1.26 unicast-only
West East
35
otv
otv
otv
otv Core

§ Проверка установления соседских отношений OTV Edge
устройствами (multicast или unicast транспорт):
§ Проверка достижимости для MAC адресов:
Local Site
MAC
Remote Site
MAC
dc1-agg-7k1# show otv adjacency
Overlay Adjacency database
Overlay-Interface Overlay100 :
Hostname System-ID Dest Addr Up Time Adj-State
dc2-agg-7k1 001b.54c2.efc2 20.11.23.2 15:08:53 UP
dc1-agg-7k2 001b.54c2.e1c3 20.12.23.2 15:43:27 UP
dc2-agg-7k2 001b.54c2.e142 20.22.23.2 14:49:11 UP
dc1-agg-7k1# show otv route
OTV Unicast MAC Routing Table For Overlay100
VLAN MAC-Address Metric Uptime Owner Next-hop(s)
---- -------------- ------ -------- --------- -----------
2001 0000.0c07.ac01 1 3d15h site Ethernet1/1
2001 0000.1641.d70e 1 3d15h site Ethernet1/2
2001 0000.49f3.88ff 42 2d22h overlay dc2-agg-7k1
2001 0000.49f3.8900 42 2d22h overlay dc2-agg-7k2
36
Проверка при помощи CLI

4
Передача данных в 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
3
2 Encap
Decap
5
OTV OTV OTV OTV
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
6
Layer 2
Lookup
MAC 1 è MAC IP A è IP B
Layer 2 MAC 1 è3 MAC 3
Lookup
MAC 1 è MAC 3
West
East
Site
Server 1 Site Server 3
7
IP A IP B
1
MAC 1 è MAC 3 IP A èIP B
37
Передача пакетов между ЦОД

Передача данных в OTV
• 42 Байта накладных расходов для каждого пакета (IPv4 пакет)
• IP Заголовок + OTV Shim – Исходный L2 заголовок (без .1Q компоненты заголовка)
• 802.1Q заголовок удаляется информация из поля VLAN копируется в OTV
заголовок (shim header)
• OTV заголовок (shim header) содержит VLAN, overlay number, и т.д.
• Требуется поддержка Jumbo MTU
802.1Q заголовок удалается
802.1Q DMAC SMAC Ether
Type
L2
Header
OTV Shim CRC
6B 6B 2B 20B 8B
38
Инкапсуляция
20B + 8B + 14B* = 42 Байт
общие накладные расходы
DMAC SMAC
Ether
Type IP Header
Payload 4B
802.1Q
14B*
Original L2 Frame
* 4 байта .1Q заголовка уже
удалены

Новые функции в OTV
39
OTV 2.5 инкапсуляция
• Используется VXLAN инкапсуляция
• Исходный IETF драфт для OTV (expired)
• Только на картах F3
• Деполяризация
Release 7.2
VXLAN
Header Original
L2
Frame

§ QoS и масшатируемость

Spanning-Tree и OTV
§ Прозрачно для ЦОД: никаких изменения в топологии STP
§ Полная изоляция STP доменов
§ Поведение по умолчанию: настройка
не требуется
§ BPDU сообщения посылаются и получаются
ТОЛЬКО на внутренних интерфейсах
(Internal Interfaces)
41
Независимость ЦОД
L3
L2
OTV OTV
BPDU
фильтруются
здесь
BPDU
фильтруются
здесь

Передача Unknown Unicast и OTV
Останавливаем Unknown Unicast шторма между ЦОД
L3
L2
OTV OTV
§ Unknown unicast фреймы не
передаются
§ Предположение: конечные
хосты не молчат и не
допускают однонаправленную
передачу данных
§ Поведение по умолчанию:
настройка не требуется
42
MAC TABLE
VLAN MAC IF
100 MAC 1 Eth1
100 MAC 2 IP B
- - -
MAC 1 è MAC 3
MAC 3
отсутствет в
MAC таблице

Unknown Unicast и OTV
§ Некоторые приложения требуют передачи unknown unicast фреймов
§ Функция Selective Unicast Flooding
может быть включена для определенного
MAC адреса
§ Поведение по умолчанию:
unknown unicast не передаются
43
Выборочный Unicast Flooding
Release 6.2
L3
L2
OTV OTV
MAC 1 è MAC 3
VLAN 100
MAC 6 è MAC 7
VLAN 102
Enable Flooding
for MAC .0101
Unknown Unicast
MAC State IF
.0000 Blk Overlay1
.0101 Blk Overlay1
.1111 Fwd Overlay1
OTV-a # conf
Enter configuration commands, one per line. End with
CNTL/Z
OTV-a(config)# otv flood mac 0000.2102.1111 vlan 172

Контроль за ARP трафиком
Release 6.1
§ ARP кэш поддерживается на Edge Device, который отвечает на ARP запросы
§ Первый ARP запрос передается на все сайты. На последующие ARP запросы
отвечает локальный Edge Device
§ Настраиваемый timeout (NX-OS 6.1(1))
§ Существенное уменьшение ARP трафика на DCI
§ ARP spoofing можно отключить
§ Только для IPv4 трафика
§ Поведение по умолчанию: настройка не требуется
44
ARP Neighbor-Discovery (ND) кэш
OTV-a(config)# interface overlay 1
OTV-a(config-if-overlay)# no otv surpress-arp-nd
# Allows ARP requests over an overlay network and
disables ARP caching on edge devices. This command
does not support IPv6.
OTV-a(config)# interface overlay 1
OTV-a(config-if-overlay)# otv arp-nd timeout 70
# Configures the time, in seconds, that an entry
remains in the ARP-ND cache.
The time is in seconds varying from 60 to 86400. The
default timeout value is 480 seconds.

Резервированное подключение OTV
§ Дополнительные протоколы (например BGP) не требуется
§ Для обнаружения соседа в том же ЦОД используется OTV site-vlan
§ Выборы устройства с ролью Authoritative Edge Device (AED)
§ Растягиваемые VLAN распределяются между AED
§ Четные VLAN/Нечетные VLAN
§ AED отвечает за:
§ Проактивное распространение информации о MAC
адресах, обнаруженных в VLAN-е
§ Передачу данных VLAN-ов внутри ЦОД и между ЦОД
46
Полная автоматизация
AED OTV OTV AED
L3
L2
Site Adjacency
Site Adjacency используются
для выбора AED

§ Устройства, расположенные в одном ЦОД должны использовать общий
site-identifier
§ Информация о site-id включается в служебные пакеты OTV
§ Надежное и предсказуемое резервирование OTV
§ При выборе AED используются Site Adjacency и
Overlay Adjacency
§ AED «видят» друг-друга через site-vlan и через
внешнее IP-подключение
§ Overlay интерфейс не поднимется, пока не будет
настроен site-id
47
Использование параметра OTV site-identifier
Overlay Adjacency
AED AED
L3
L2
OTV OTV
Site Adjacency
feature otv
otv site-identifier 0x1
otv site-vlan 99

§ Автоматизация и предсказуемость
§ В случае 2-х AED на ЦОД:
§ Меньшее значение IS-IS System-ID (Ordinal 0) = Четные VLAN
§ Большее значение IS-IS System-ID (Ordinal 1) = Нечетные VLAN
48
Распределение VLAN между AED
IP A IP B
Overlay Adjacency
OTV OTV
Site Adjacency
OTV-a OTV-b
OTV-a# show otv vlan
OTV Extended VLANs and Edge Device State Information (* - AED)
VLAN Auth. Edge Device Vlan State Overlay
---- ------------------ ---------- -------
100 East-b inactive(Non AED) Overlay100
101* East-a active Overlay100
102 East-b inactive(Non AED) Overlay100
OTV-b# show otv vlan
OTV Extended VLANs and Edge Device State Information (* - AED)
VLAN Auth. Edge Device Vlan State Overlay
---- ------------------ ---------- -------
100* East-b active Overlay100
101 East-a inactive(Non AED) Overlay100
102* East-b active Overlay100
AED
Нечетные
VLAN
AED
Четные
VLAN
Таблица MAC адресов на
удаленном OTV устройстве
VLAN MAC IF
100 MAC 1 IP A
101 MAC 2 IP B

1. Broadcast-пакеты достигают Edge Device внутри ЦОД
2. Только устройство AED передает пакет Overlay-интерфейсу
3. Все устройства Edge Devices удаленного ЦОД получают broadcast-пакет
4. В удаленном ЦОД только AED пересылает broadcast-пакет дальше
49
AED и распространение broadcast пакетов
Core
OTV
OTV
OTV
AED
AED
Bcast
пакет
broadcast-пакета
останавливается
здесь
broadcast-пакета
останавливается
здесь
OTV

OTV и мобильность MAC адресов
1. Нагрузка перемещается между ЦОД
ESX OTV ESX
51
Перемещение MAC и пакеты «OTV-update» (1)
Core
OTV
OTV
OTV
AED
AED
VM перемещается
MAC X
MAC X
MAC X
MAC X
MAC X
MAC X

2. Нагрузка детектируется в ЦОД East и плоскость управления OTV
обрабатывает это событие
ESX OTV ESX
52
Core
OTV
OTV
OTV
AED
AED
MAC X
MAC X
MAC X
MAC X
MAC X
MAC X
2.1) Сервер
генерирует пакет
Gratuitous ARP
2.2) AED (GARP)
обнаруживает,
что MAC X стал
локальным
MAC X
MAC X
MAC X
2.3) AED пересылает
сообщение о MAC X
нулевой метрикой
MAC X
MAC X
2.4) ED в ЦОД West получает информацию о MAC
X с более лучшей метрикой из ЦОД East вносит
изменения в свою таблицу MAC адресов.

2. Нагрузка детектируется в ЦОД East и плоскость управления OTV
обрабатывает это событие
3. Трафик данных между ЦОД обновляет состояние CAM-таблиц на L2
устройствах ЦОД West
3.2) AED в ЦОД West пересылает
GARP дальше всем L2 коммутаторам,
которые обновляют CAM таблицы
ESX OTV ESX
53
Core
OTV
OTV
OTV
AED
AED
MAC X
MAC X
MAC X
MAC X
MAC X
MAC X
MAC X
3.1) AED ЦОД East
передает GARP broadcast
пакет через overlay
MAC X
Замечание: GARP используется как пример, такой же алгоритм при получении любого L2 broadcast пакета

QoS и OTV
• Инкапсуляция
§ Биты CoS (802.1p) копируются в OTV заголовок (shim header)
§ В случае IP трафика: исходное (внутреннее) значение DSCP так же копируется
во “внешний” DSCP
55
Маркировка и инкапсуляция
DMAC SMAC 802.1Q ETHERTYPE IP (опция)
CoS внутр. DSCP
802.1p
OTV OTV
IP A IP B
802.1Q
West East
1
Encap
2
IP (опция) OTV Исходный пакет
Внешн.DSCP OTV
shim
Release 5.2

QoS и OTV
• При деинкапсуляции
§ Значение CoS восстанавливается из OTV заголовка добавляется к 802.1Q заголовку
• Исходные значения CoS и DSCP сохраняются
• Служебный трафик OTV статично маркиркуется CoS = 6/DSCP = 48
56
Маркировка и деинкапсуляция
OTV OTV
IP A IP B
802.1Q
2
West East
DMAC SMAC 802.1Q ETHERTYPE IP (опция)
CoS Внутрн. DSCP
802.1p
IP (опция) OTV Исходный пакет
Внешн. DSCP OTV
shim
Decap 1
Release 5.2

OTV масштабируемость
57
Текущие поддерживаемые значения
NX-OS 6.2
NX-OS 5.2
32k
16k
MAC адреса
во всех
растягиваемых VLAN
4000
2000
Multicast
группы
8*
6*
Количество
ЦОД
1500
256
Растягиваемые
OTV VLAN-ы
* Два ED на ЦОД
Release 6.2

Оптимизация трафика
§ Растянутый VLAN обычно ассоциирован с HSRP группой
§ По умолчанию, только один HSRP маршрутизатор активен и все сервера
используют его HSRP VIP как адрес шлюза по умолчанию
§ Результат: неоптимальная
маршрутизация
59
Маршрутизация трафика в растянутых VLAN
HSRP
Active
HSRP
Standby
Пакет из
Vlan 10 в Vlan 20
DMAC = DGW
HSRP
Listen
HSRP
Listen
HSRP Hellos
VLAN
20
VLAN
10
ARP for
HSRP VIP
ARP reply
Пакет из Vlan 10 в
Vlan 20
DMAC = Host Vlan 20
Routing

Локализация исходящего трафика
§ Фильтрация FHRP с комбинацией VACL и MAC фильтров
§ Результат: используется одна HSRP группа и один VIP, но теперь
шлюз по умолчанию активен на каждой площадке
60
Применение фильтров для FHRP
HSRP
Active
HSRP
Standby
Listen
HSRP
Listen
HSRP Hellos
VLAN
20
VLAN
10
✗✗ HSRP Hellos ✗ ✗
HSRP Filter
HSRP
Active
Standby
ARP for
HSRP VIP
ARP reply

Настройка изоляции FHRP
1. VLAN Access List (VACL) для фильтрации hello-пакетов HSRP
61
Шаг 1: создание и применение VACL
! IP ACL для фильтрации HSRP hello-пакетов,
! весь остальной трафик передается
ip access-list HSRP_IP
10 permit udp any 224.0.0.2/32 eq 1985
20 permit udp any 224.0.0.102/32 eq 1985
ipv6 access-list HSRP_IPv6
10 permit udp any ff02::66/128 eq 2029
ip access-list ALL_IPs
10 permit ip any any
ipv6 access-list ALL_IPv6
10 permit ipv6 any any
! MAC ACL для фильтрации не-IP HSRP трафика,
! весь остальной трафик передается
mac access-list HSRP_VMAC
10 permit 0000.0c07.ac00 0000.0000.00ff any
20 permit 0000.0c9f.f000 0000.0000.0fff any
mac access-list ALL_MACs
10 permit any any
! Создание VACL
vlan access-map HSRP_Localization 10
match mac address HSRP_VMAC
match ip address HSRP_IP
match ipv6 address HSRP_IPv6
action drop
vlan access-map HSRP_Localization 20
match mac address ALL_MACs
match ip address ALL_Ips
match ipv6 address ALL_IPv6
action forward
! Применение VACL к растянутым vlan
vlan filter HSRP_Localization vlan-list
<OTV_Extended_VLANs>

2. Настройка ARP Inspection для фильтрации ARP пакетов от Virtual MAC
(решение проблемы с duplicate IP между Active Edge Device в каждом
ЦОД)
62
Шаг 2: фильтрация ARP от vMAC
! Feature dhcp необходимо включить для активации ARP inspection
feature dhcp
! Создаем ARP access-list для фильтрации ARP-трафика от Virtual MAC
arp access-list HSRP_VMAC_ARP
10 deny ip any mac 0000.0c07.ac00 ffff.ffff.ff00
20 deny ip any mac 0000.0c9f.f000 ffff.ffff.f000
30 deny ip any mac 0005.73a0.0000 ffff.ffff.f000
40 permit ip any mac any
! Применяем ARP ACL к каждому растянутому VLAN
ip arp inspection filter HSRP_VMAC_ARP vlan <OTV_Extended_VLANs>

3. При помощи Route-Map для каждого Overlay-интерфейса фильтруем
Virtual MAC (предотвращаем попеременное выучивание в OTV virtual
MAC то на одной площадке, то на другой - flapping between sites)
63
Шаг 3: фильтрация vMAC в OTV
! mac-list для фильтрации сообщений OTV-update, содержащих virtual MAC
mac-list OTV_HSRP_VMAC_deny seq 10 deny 0000.0c07.ac00 ffff.ffff.ff00
mac-list OTV_HSRP_VMAC_deny seq 11 deny 0000.0c9f.f000 ffff.ffff.f000
mac-list OTV_HSRP_VMAC_deny seq 12 deny 0005.73a0.0000 ffff.ffff.f000
mac-list OTV_HSRP_VMAC_deny seq 20 permit 0000.0000.0000 0000.0000.0000
! создаем route-map
route-map OTV_HSRP_filter permit 10
match mac-list OTV_HSRP_VMAC_deny
! применяем route-map к каждому overlay интерфейсу
otv-isis default
vpn Overlay1
redistribute filter route-map OTV_HSRP_filter

Оптимизация передачи трафика
§ Растягивание L2 создает проблемы с оптимальной маршрутизацией
§ Проблема размещения шлюза по умолчанию и анонсирования маршрутов в
растянутый VLAN
64
Проблема оптимальной маршрутизации
WAN
HSRP
Active
HSRP
Standby
HSRP Filter
HSRP
Active
HSRP
Standby
East-West /
Server-Server
Egress:
South-North /
Server-Client
Ingress:
North-South /
Client-Server
Egress:
South-North /
Server-Client
Ingress:
North-South /
Client-Server

Оптимизация передачи трафика
§ Логический или физический ЦОД?
§ Высокая доступность или защита от сбоев?
… разделенных
65
Какой способ выбрать?
WAN
East-West /
Server-Server
Egress:
South-North /
Server-Client
Ingress:
North-South /
Client-Server
Egress:
South-North /
Server-Client
Ingress:
North-South /
Client-Server
Это ОДИН логический ЦОД ?
Или ДВА
физически и
логически …
(Высокая доступность - High Availability)
ЦОД?

Оптимизация пути входящего трафика
66
Возможные решения
Проблема
• Подсети растянуты между ЦОД
• Суммарной информации о
доступных подсетях в таблицах
маршрутизации недостаточно
• Процесс маршрутизации не знает
ничего о перемещении северов
между ЦОД
• Трафик может приходить в ЦОД, где
приложение не доступно
Решение
• На основе DNS
• Route Injection
• LISP – Locator/ID Separation Protocol
Рекомендуем посетить сессию: Построение катастрофоустойчивых
и распределённых ЦОД (часть 3)

Новые функции
§ VLAN трансляция дает возможность при помощи OTV отобразить
локальный VLAN в новый удаленный VLAN.
West East
68
OTV VLAN трансляция
otv
otv
otv
otv Core
interface Overlay0
otv vlan mapping 203 to 303
WEST_OTVA# show otv vlan-mapping
Original VLAN -> Translated VLAN
--------------------------------
203 -> 303
interface Overlay0
otv extend-vlan 202, 303
Vlan 203 Vlan 203V lan 303 Vlan 303

Деполяризация туннелей при помощи Secondary IP (до 4-х адресов)
Весь инкапсулированный трафик между AED имеет одни и те же IP адреса
отправителя и получателя, ограничивая возможности по балансировке,
которые предлагают технологии Etherchannel и ECMP
69
otv
otv
West
otv
otv
East
A1->B1

Деполяризация туннелей при помощи Secondary IP (до 4-х адресов)
§ Настройка Secondary IP дает возможность предотвратить поляризацию
при передаче инкапсулированного в OTV трафика
Interface port-channel12
ip address 1.1.1.7/32
ip address 1.1.1.17/32 secondary
70
otv
otv
West
otv
otv
East
AAA1234--->>>BBB1234
ip address 2.100.11.100/24
ip address 2.100.11.1/24 secondary
WEST_OTVA# show otv
(output omitted)
Join interface(s) : Po11 (2.100.11.100)
Secondary IP Addresses: : 2.100.11.1

Новые возможности OTV в NX-OS 6.2
§ Поддержка OTV на карте F3 в 6.2(6)
– Доступность OTV на Nexus 7700
– Деполяризация в 6.2(8)
– VLAN трансляция на F3 не поддерживается
Карты F1 и F2e могут выполнять роль
internal Interface в OTV
§ Без F3 в том же VDC
71
Поддержка новых карт Nexus 7000
Aggregation VDC
L3
(M-only, M1-F1 or F2/F2e) L2
OTV VDC
Маршрутизируемые
линки
в ядро
В сторону уровня доступа
(Классический Ethernet или FabricPath)
OTV
Join
Interface
OTV
Internal
Interface (CE)
M-Series interface
F/M-Series interface
M1, F1, F2e
M1 M2 F3
M1 P P
M2 P P P
F1 P P
F2e P P
F3 P P
Internal Interface
Join-Interface
Release 6.2

Рекомендуемый дизайн
OTV OTV
• SVI на уровне агрегации
• Дизайн OTV On-a-Stick
• OTV в отдельном VDC
• vPC подключение OTV VDC
• Один overlay интерфейс для
лучшей сходимости
• Один internal интерфейс
• Резервированное подключение
OTV лучшие
практики
• SVI в OTV VDC (not supported)
• Несколько Internal интерфейсов
• FEX в OTV VDC (not supported)
• Статический маршрут для join-interface
Недопустимо
в OTV
дизайне

Подключение к межсетевому экрану
МСЭ в прозрачно режиме, растягиваются Inside и Outside VLAN-ы
§ МСЭ в L2 режиме, OTV растягивает Inside и Outside VLAN-ы
§ OTV поддерживает ситуацию, когда один и тот же MAC адрес находится в
разных VLAN
OTV
DC
West DC
74
East
OTV
OTV OTV
VLAN
Outside
FW
VLAN
Inside
FW
VLAN
Outside
FW
VLAN
Inside
FW

Подключение к межсетевому экрану
МСЭ в прозрачно режиме, растягиваются Inside и Outside VLAN-ы
§ OTV шлет пакеты PIM-hello с адресом источника 0.0.0.0 и адресом назначения 224.0.0.13
§ Hello-сообщения от MAC-адреса OTV Edge Device (VDC)
§ МСЭ постоянно регистрирует событие «mac-move», что может вызвать переполнение лога
§ фильтрация PIM-hello на входе в МСЭ
§ очистка log МСЭ
75
VLAN 150
Outside Firewall
DC
West
VLAN 100 Inside
Firewall
PIM Hellos
sourced
from 0.0.0.0
(ED MAC
Address) on
VLAN 150
OTV
Firewall MAC Table
MAC VLAN Zone
OTV ED 100 Inside
OTV ED 150 Outside
PIM Hellos
sourced
from 0.0.0.0
(ED MAC
Address) on
VLAN 100

Объединение сетевых фабрик
Объединение фабрики ACI с существующими фабриками на базе Nexus
APIC WAN
OTV
DCNM
§ Nexus 7K в каждом ЦОД выполняет роль «border leaf»
§ Между ЦОД запускается OTV
§ Исходящий из ЦОД трафик должен быть классическим
Ethernet трафиком

Заключение
Почему Заказчики чаще всего используют OTV для связи между ЦОД?
Простота
развертывания
и настройки
Все компоненты It Just Works
и аспекты под
контролем

Ждем ваших сообщений с хештегом
#CiscoConnectRu
Спасибо
Пожалуйста, заполните анкеты.
Ваше мнение очень важно для нас.
Contacts:
Name Хаванкин Максим
Phone +74999295710
E-mail mkhavank@cisco.com
CiscoRu Cisco CiscoRussia
11/19/14 © 2014 Cisco and/or its affiliates. All rights reserved.

Передача multicast трафика в OTV

Передача multicast трафика между ЦОД
§ OTV может использовать поддержку multicast внутри транспортной сети
для оптимизации доставки multicast трафика внутри растянутых между
ЦОД VLAN-ах
§ Три шага:
1. Автоматизированное отображение адресного пространства multicast групп,
которое используется внутри растягиваемых VLAN на адресное пространство
multicast групп, которое доступно в транспортной сети
2. Программирование OTV Edge Device устройств при начале передачи multicast
трафика
3. Трафик Multicast между ЦОД передается через Overlay
80
Опора на multicast в транспортной сети

Шаг 1 – отображение адресного пространства multicast групп
§ Адреса multicast групп внутри VLAN отображаются на SSM группы в транспортной сети
§ Каждый (S1,Gs1) отображается случайным образом на SSM группу из диапазона адресов,
выделенного владельцем транспортной сети
81
S1
OTV OTV
IP A IP B
Mcast Stream
West East
1
S1 è Gs1
IP C
South
OTV
Передача
отображения
3 другим ED
Отображение на
Delivery Group
2
с поддержкой multicast
Отображение номеров
групп Mcast
Site Group Core Group
Gs1 Gd1
S2 è Gs2
S2
4
Отображение номеров
групп Mcast
Site Group Core Group
Gs1 Gd1
Gs2 Gd2
1) Mcast источник
начинает вещать в
группу Gs1
2) West Ed в ЦОД West
отображает пару
(S1,Gs1) на multisat
группу из транспортной
сети (delivery group
Gd1)
3) West ED передает таблицу отображения
(включая номер VLAN) другим ED в
удаленных ЦОД
4) Процесс повторяется когда
источник S2 начинает вещать
в группу Gs2

Шаг 2 – начальное программирование устройств, передающих multicast
Устройства OTV присоединяются к вещанию multicast групп как конечные хосты, а не как маршрутизаторы!
East
82
S1
4
OTV OTV
IP A IP B
West
S1 è Gs1
IP C
South
OTV
IGMP join
Gs1
Client IGMP 1
snoop
2
3.1 GM-Update
IGMPv3 join (IP
A, Gd1) в SSM
группу
3.2
Пакет GM-Update
обновляет OIF-List
SSM
дерево
для Gd1
OIF-List
Group IF
Gs1 è Gd1 Overlay
1) Получатель в ЦОД
East пересылает
сообщение IGMP join
для подключения к
вещанию в Gs1
2) OTV ED
перехватывает пакет
IGMP join (дальше не
передает)
3.1) ED сообщает всем
остальным ED о том,
что в группе появился
получатель (GM-Update)
3.2) ED передает пакет
IGMPv3 (IP A, Gd1) для
присоединения к вещанию
в SSM группу
4) ED источника добавляет
Overlay интерфейс в
таблицу Outbound Interfaces
(OIF)
5) Создается SSM дерево
для группы Gd1
Receiver
(for Gs1)

Receiver
4
South (for Gs1)
East
83
Шаг 3 – передача multicast пакетов
OTV OTV
IP A IP B
West
IP C
OTV
Receiver
(for Gs1)
OIF-List
Group IF
1
Lookup Gs1 è Gd1 Overlay
S1 è Gs1
S1
S1 è Gs1 IP Aè Gd1
Encap
2
Репликация
в транспортной
3 сети
S1 è Gs1 IP A è Gd1
S1 è Gs1 IP A è Gd1
4
Decap 5
Decap 5
S1 è Gs1
S1 è Gs1

OTV может использовать преимущества транспортной сети для передачи
служебных пакетов, а так же пакетов данных:
§ Control group – одна PIM-SM или PIM-Bidir группа, которая используется
для формирования соседских отношений и передачи информации о MAC
адресах
§ Data group – набор SSM групп, которые используются для передачи
multicast трафика, который генерируется внутри ЦОД на удаленные
площадки
Число SSM групп, которое необходимо выделить зависит от возможностей транспортной сети по
оптимизации доставки multicast трафика и от потребностей в multicast в растягиваемых VLAN
84
Multicast группы в транспортной сети
interface Overlay100
otv join-interface e1/1

§ Выделенная группа для передачи Broadcast трафика
§ Возможно разделить по разным группам служебный трафик (control traffic) и
broadcast трафик
85
Возможности по передаче broadcast трафика
interface Overlay1
otv broadcast-group 239.1.1.5
Release
6.2(2)

Быстрая сходимость в OTV

§ Previously, AED election ran independently on each edge device which
required a short black-holing timer to prevent multiple active AEDs for a VLAN
§ AED Server: centralized model where a single edge device runs the AED
election for each VLAN and assigns VLANs to edge devices.
§ Per-VLAN AED and Backup AED assigned and advertised to all sites
§ Fast Remote Convergence: on remote AED failure, OTV routes are updated
to new AED immediately
§ Fast Failure Detection: Detect site VLAN failures faster with BFD and core
failures with route tracking
87

88
feature bfd
feature interface-vlan
otv site-vlan 210
otv isis bfd
Interface Vlan210
no shutdown
no ip redirects
ip address 10.210.0.1/30
otv-isis default
track-adjacency-nexthop
WEST_OTVA# show otv isis track-adjacency-nexthop
OTV-IS-IS process: default
OTV-ISIS adjs for nexthop: 172.16.1.38, VRF: default
Hostname: WEST_OTVB, Overlay: Overlay1
Configure OTV-ISIS BFD
Configure Route Tracking

AED Server
89
otv
otv
otv
otv Core
West-A
West-B
AED-Server assigns:
West-A (AED)
West-B (Backup-AED)
AED-Update
AED-Server assigns
EAST-A (AED)
EAST-B (Backup-AED)
East-A
East-B
AED-Update
AED Server

EAST_OTVA# show otv internal shared-database vlan-device
Device-ID AED-Capable AED/Backup Ord/Ver Flags
----------- ------------------------
Device Vlan Mark-Del Del-Pending
(some output omitted)
(Overlay1 0000.0000.0001 ffff.ffff.ffff vlan:100)
6c9c.ed4e.4b41 Yes Yes Yes/No -1/-1/29 No No
6c9c.ed4e.c144 Yes Yes No /Yes -1/-1/29 No No
*6c9c.ed4e.4b44 Yes Yes Yes/No 0 /-1/4 No No
6c9c.ed4e.c141 Yes Yes No /Yes 1 /0 /4 No No
In this example, EAST_OTVA at site
0000.0000.0002 can see both AED
and backup-AED for local site and
remote site 0000.0000.0001

Immediately update forwarding tables to start
sending frames to West-B without waiting for
West-B to re-advertise the MAC’s
91
Convergence is NOT dependent on the
size of the MAC table
otv
otv
otv
otv Core
West-A
West-B
East-A
East-B
AED-Update

Построение катастрофоустойчивых и распределённых ЦОД (часть 2). Объединение сетей ЦОД на 2 уровне

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (18)

Ähnlich wie Построение катастрофоустойчивых и распределённых ЦОД (часть 2). Объединение сетей ЦОД на 2 уровне

Ähnlich wie Построение катастрофоустойчивых и распределённых ЦОД (часть 2). Объединение сетей ЦОД на 2 уровне (20)

Mehr von Cisco Russia

Mehr von Cisco Russia (20)

Построение катастрофоустойчивых и распределённых ЦОД (часть 2). Объединение сетей ЦОД на 2 уровне