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

Хаванкин Максим cистемный архитектор [email protected]

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

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

Long Distance

DC 1 DC 2

CO

RE

AG

GR

AC

CES

S

Server Cluster

CO

RE

AG

GR

AC

CESS

Server Cluster

vPC domain 10 vPC domain 20


Использование vPC для связи между ЦОД

Rootguard

B

F

N

E

BPDUguard BPDUfilter

Network port Edge or portfast port type

- Normal port type

R

802.1AE (Optional)

E E

- -

- -

- -

E

E

E

E

F

F

F

F -

-

- -

-

- -

B

N N

N

N N

N

R R

-

R R R R

R R

N N

B

Long Distance

DC 1 DC 2

CO

RE

AG

GR

AC

CES

S

Server Cluster

CO

RE

AG

GR

AC

CESS

Server Cluster

Лучшие практики: §  vPC Domain id должны быть разными §  Настроить BPDU Filter для изоляции 2-х STP доменов §  Настроить STP Edge Mode быстрой сходимости §  За пределами vPC домена петель быть не должно §  Динамическую маршрутизацию использовать нельзя:

•  статическая маршрутизация •  выделенные каналы для L3 связности



Использование vPC для связи между ЦОД

E E

- -

- -

- -

E

E

E

E

F

F

F

F -

-

- -

-

- -

B

N N

N

N N

N

R R

-

R R R R

R R

N N

B

DC 1 N7k

Po10

Po1

http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_1/nx-os/security/configuration/guide/sec_storm.html

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 ! interface port-channel1 switchport switchport mode trunk vpc peer-link switchport trunk allowed vlan 1,100-210 spanning-tree port type network

interface port-channel10 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

Настройка DCI порта

5

Пример настройки vPC на Nexus




Применение FabricPath в сценариях объединения ЦОД

Зависимость от 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 локализация §  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

О чем нужно помнить приступая к внедрению FP на DCI?

Root MDT1 S1

R2

10 20 40 40

5

40 40

Site C

Site B

R1

Site A

7

Multidestination трафик (одна топология) Пример № 1 – multicast трафик передается через MDT дерево

Vlan 100 Vlan 100

Vlan 100

Root MDT1 S1

R2

20 20 40 40

Site C

Site B

R1

•  Нельзя управлять распространением Multicast/ARP трафика между S1 и R2 находясь в ЦОД A.

•  Неоптимальная передача связана с природой FabricPath MDT

•  Природа FabricPath -  Несоответствие с принципами DCI (автономность, зашита от эффекта домино, …) -  Требуется серьезное планирование возможностей MDT дерева, особенно в случае multicast

Site A

Multidestination трафик (одна топология) Пример № 2 – влияние сбоев

Vlan 100

Vlan 100

S1

R2

Root MDT1

Vlan 100

•  После сбоя в ЦОД А Multicast/ARP трафик между S1 и R2 больше не локализуется в ЦОД A.

•  Неоптимальная передача связана с природой FabricPath MDT

•  Природа FabricPath -  Несоответствие с принципами DCI (автономность, зашита от эффекта домино, …) -  Требуется серьезное планирование возможностей MDT дерева, особенно в случае multicast

Site C

Site B Site A

IP маршрутизация поверх FabricPath Зависимость OSPF adjacency от FabricPath топологии

Локальный Vlan 1000



Vlan 100

Vlan 300 Vlan 200 Vlan 400

Vlan 500 Vlan 600

Vlan 700

A

B

C

D

E F

Site A Site B

•  Один транзитный OSPF Vlan на каждое соседское взаимоотношение FabricPath L2 ISIS

•  Природа FabricPath

-  Даже с “OSPF network point-to-point” на SVI, OSPF hello-пакеты являются multicast-пакетами

-  OSPF Hello-пакеты всегда используют MDT (см. пред. слайды)

-  Выход из строя DCI канала не приводит к разрыву соседских отношений в OSPF

-  Потеря MDT1 root влияет на все соседские отношения в OSPF

Site C


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











Site A Site B

A C

Шаг 1 : IP маршрутизация Следующих узел - C Шаг 2 : FabricPath Используется канал AВD

чтобы достичь SVI 100 на C

B D

E F Site C




vlan-ы 100, 200, 300, 400, 500, 600, 700 должны быть настроены на всех FP узлах

Root MDT1







Особенности использования 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 сетей

Возможности технологии

Ref: RFC 3985 Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture

Emulated Layer-2 Service

Pseudowire (PW)

PE

PE

CE

CE

CE

CE PW2

PW1

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

Возможности технологии

MPLS

CE-B1 CE-B3

CE-A1 CE-A3

CE-B2

CE-A2

Поддержка в аппаратуре

§  L2VPN функциональность поддерживается сегодня на картах M-серии §  F1 и F2e* модули поддерживают MPLS Layer 3 VPN в режиме proxy-mode §  F2 модули не поддерживают MPLS §  Планируется, что F3 модули будут поддерживать MPLS, в том числе L2VPN в релизе NX-OS 7.2

* -требуется NX-OS 6.2(2)

N7K-M108X2-12L

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 или туннель

Принципы работы протокола

Server 1 MAC 1

Server 2 MAC 2

OTV OTV MAC IF

MAC1 Eth1

MAC2 IP B

MAC3 IP B

IP A IP B

Encap Decap MAC1 à MAC2 IP A à IP B MAC1 à MAC2 MAC1 à MAC2

Взаимодействие между 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

OTV Internal Interface

OTV Join Interface

Aggregation Device

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

OTV Internal Interface

OTV Join Interface

Aggregation Device

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

IP A IP B

IP C

East

South

Распространение информации о MAC адресах

OTV

OTV


§ Перед тем как информация о MAC адресах начнет распространяться между площадками устройства OTV Edge должны:

‒  обнаружить друг друга ‒  построить друг с другом соседские отношения

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

25

Обнаружение соседей и формирование соседских отношений

Конечный результат •  Соседские отношения поддерживаются посредством «вещания в» и «слушания» multicast-группы

•  Один пакет “OTV-update” реплицируется multicast сетью на всех соседей

Механизм •  Edge Devices (ED) присоединяются к

multicast группе, как хосты (включать PIM на ED не нужно)

•  Пакеты “OTV-hello” и “OTV-update” используют multicast транспорт

West

OTV OTV Control Plane

IP A East


IP B

Транспортная сеть с поддержкой Multicast


26

Обнаружение соседей (опора на транспортную сеть с поддержкой multicast)

West

OTV

South

East

OTV

OTV

OTV Control Plane

OTV Control Plane OTV Control Plane

IP A IP B

IP C

Encap Decap

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

IP A è G OTV Hello

IP A è G OTV Hello IP A è G OTV Hello

OTV Hello IP A è G OTV Hello

OTV Hello IP A è G OTV Hello

Neighbor IP Addr West IP A


Neighbor IP Addr Транспортная сеть

с поддержкой Multicast


27

Шаг1: обнаружение соседей с опорой на сеть muticast


28

Шаг2: обнаружение соседей с опорой на сеть muticast

South

East West

OTV

OTV

OTV

OTV Control Plane

OTV Control Plane OTV Control Plane

IP A IP B

IP C

Decap Decap

Encap

OTV Hello

IP C è G OTV Hello

IP C è G OTV Hello IP C è G OTV Hello

OTV Hello OTV Hello

OTV Hello IP C è G OTV Hello OTV Hello IP C è G OTV Hello


Neighbor IP Addr West IP A South IP C

Neighbor IP Addr South IP C

1

2

3

4 4

5 5

Двух-сторонние соседские отношения сформированы

Сайт South создает свой «OTV-hello» пакет помещая в TLV-поле пакета

адрес сайта West


South

East 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

VLAN MAC IF 100 MAC A e1/1 100 MAC B e1/1 100 MAC C e1/1

VLAN MAC IF 100 MAC A e1/1 101 MAC B e1/1 102 MAC C e1/1

Update A

VLAN MAC IF 100 MAC A IP A 101 MAC B IP A 102 MAC C IP A


Новый MAC адрес был выучен в VLAN, который при помощи OTV «растягивается» между ЦОД

Формируется пакет «OTV-update» с новым MAC адресом

IP A è G Update A

Update A

Update A

IP A è G Update A IP A è G Update A

Update A IP A è G Update A

Update A IP A è G Update A

Encap Decap

Decap 1

2

3

4

5

5

6

6


7

7

Добавление MAC адреса выученного при помощи OTV

Добавление MAC адреса выученного при помощи OTV

MAC Table

MAC Table

MAC Table



29

Проактивное выучивание MAC адресов (с опорой на multicast)

Настройка

30

Опора на multicast транспорт

otv

otv

otv

otv

Core

West East

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

interface port-channel 100 mtu 9216 ip address 172.16.1.34/30 ip igmp version 3

Настройка

31

Опора на multicast транспорт - картина целиком

otv

otv

otv

otv

Core

West East

WEST_OTVA feature otv otv site-vlan 210 otv site-identifier 0001.0001.0001 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 no shutdown interface port-channel100 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 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 no shutdown interface port-channel100 mtu 9216 ip address 172.16.1.26/30 ip igmp version 3


§  Идеально для объединения небольшого количества ЦОД §  С увеличением числа ЦОД рекомендуется опираться на multicast в транспортной сети

32

Обнаружение соседей (транспорт с поддержкой unicast)

West


IP A East


IP B

Транспортная сеть с поддержкой unicast

Конечный результат • Поиск соседей автоматизируется при помощи “Adjacency Server”

• Все пакеты управления реплицируются в сторону каждого соседа

• Трафик данных так же реплицируется на устройстве источнике таких данных( head-end replication)

Механизм • Edge Devices (ED) регистрируется на

“Adjacency Server” ED • ED полный список соседей (oNL) от AS • Пакеты «OTV-hello» и «OTV-update» инкапсулируются в IP и в unicast режиме передаются каждому соседу

Настройка

33

Транспорт с поддержкой unicast: Primary Adjacency Server Overlay

otv

otv

otv

otv

Core

West East

interface Overlay1 otv join-interface port-channel100 otv extend-vlan 200-209 otv adjacency-server unicast-only

Настройка

34

Транспорт с поддержкой unicast: Secondary Adjacency Server Overlay

otv

otv

otv

otv

Core

West East

interface Overlay1 otv join-interface port-channel100 otv extend-vlan 200-209 otv use-adjacency-server 172.16.1.34 unicast-only otv adjacency-server unicast-only

Primary Server

Конфигурация

35

Транспорт с поддержкой unicast: клиентские Overlay интерфейсы

otv

otv

otv

otv

Core

West East

interface Overlay1 otv join-interface port-channel100 otv extend-vlan 200-209 otv use-adjacency-server 172.16.1.34 172.16.1.26 unicast-only

Primary Server Secondary Server

§  Проверка установления соседских отношений OTV Edge устройствами (multicast или unicast транспорт):

§  Проверка достижимости для MAC адресов:

Remote Site MAC

Local 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

Транспортная инфраструктура

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

37

Передача пакетов между ЦОД

Передача данных в OTV

• 42 Байта накладных расходов для каждого пакета (IPv4 пакет) •  IP Заголовок + OTV Shim – Исходный L2 заголовок (без .1Q компоненты заголовка)

• 802.1Q заголовок удаляется информация из поля VLAN копируется в OTV заголовок (shim header) • OTV заголовок (shim header) содержит VLAN, overlay number, и т.д. • Требуется поддержка Jumbo MTU

38

Инкапсуляция

20B + 8B + 14B* = 42 Байт общие накладные расходы

6B 6B 2B 20B 8B

DMAC SMAC Ether Type IP Header

Payload 4B

CRC OTV Shim

802.1Q DMAC SMAC Ether

Type

802.1Q

14B*

Original L2 Frame

L2 Header

802.1Q заголовок удалается

* 4 байта .1Q заголовка уже удалены

Новые функции в OTV

39

OTV 2.5 инкапсуляция

•  Используется VXLAN инкапсуляция •  Исходный IETF драфт для OTV (expired) •  Только на картах F3 •  Деполяризация

Release 7.2

Original L2 FrameVXLAN Header



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


Spanning-Tree и OTV

§  Прозрачно для ЦОД: никаких изменения в топологии STP §  Полная изоляция STP доменов §  Поведение по умолчанию: настройка не требуется

§  BPDU сообщения посылаются и получаются ТОЛЬКО на внутренних интерфейсах (Internal Interfaces)

41

Независимость ЦОД

L2 L3

OTV OTV

BPDU фильтруются

здесь

BPDU фильтруются

здесь

L2 L3

OTV OTV

Передача Unknown Unicast и OTV

§  Unknown unicast фреймы не передаются

§  Предположение: конечные хосты не молчат и не допускают однонаправленную передачу данных

§  Поведение по умолчанию: настройка не требуется

42

Останавливаем Unknown Unicast шторма между ЦОД

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

L2 L3

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 трафиком

§  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.

Release 6.1





Резервированное подключение OTV

§  Дополнительные протоколы (например BGP) не требуется §  Для обнаружения соседа в том же ЦОД используется OTV site-vlan §  Выборы устройства с ролью Authoritative Edge Device (AED) §  Растягиваемые VLAN распределяются между AED

§  Четные VLAN/Нечетные VLAN §  AED отвечает за:

§  Проактивное распространение информации о MAC адресах, обнаруженных в VLAN-е

§  Передачу данных VLAN-ов внутри ЦОД и между ЦОД

46

Полная автоматизация

L2 L3

OTV OTV AED AED

Site Adjacency используются для выбора AED

Site Adjacency


§  Устройства, расположенные в одном ЦОД должны использовать общий site-identifier

§  Информация о site-id включается в служебные пакеты OTV §  Надежное и предсказуемое резервирование OTV

§  При выборе AED используются Site Adjacency и Overlay Adjacency

§  AED «видят» друг-друга через site-vlan и через внешнее IP-подключение

§  Overlay интерфейс не поднимется, пока не будет настроен site-id

47

Использование параметра OTV site-identifier

L2 L3

OTV OTV

feature otv otv site-identifier 0x1 otv site-vlan 99

AED AED

Site Adjacency

Overlay Adjacency


§  Автоматизация и предсказуемость §  В случае 2-х AED на ЦОД:

§  Меньшее значение IS-IS System-ID (Ordinal 0) = Четные VLAN §  Большее значение IS-IS System-ID (Ordinal 1) = Нечетные VLAN

48

Распределение VLAN между AED

OTV OTV IP B IP A

Site Adjacency

Overlay 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.  Нагрузка перемещается между ЦОД

51

Перемещение MAC и пакеты «OTV-update» (1)

Core

OTV OTV

OTV

AED AED

OTV ESX ESX

VM перемещается

MAC X

MAC X

MAC X

MAC X

MAC X

MAC X


1.  Нагрузка перемещается между ЦОД 2.  Нагрузка детектируется в ЦОД East и плоскость управления OTV обрабатывает это событие

52


Core

OTV OTV

OTV

AED AED

OTV ESX ESX

MAC X

MAC X

MAC X

MAC X

MAC X

MAC X

2.1) Сервер генерирует пакет

Gratuitous ARP (GARP) 2.2) AED

обнаруживает, что 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 адресов.


1.  Нагрузка перемещается между ЦОД 2.  Нагрузка детектируется в ЦОД East и плоскость управления OTV обрабатывает это событие

3.  Трафик данных между ЦОД обновляет состояние CAM-таблиц на L2 устройствах ЦОД West

53


Core

OTV OTV

OTV

AED AED

OTV ESX ESX

MAC X

MAC X

MAC X

MAC X

MAC X

MAC X

MAC X

3.1) AED ЦОД East передает GARP broadcast

пакет через overlay

MAC X

3.2) AED в ЦОД West пересылает GARP дальше всем L2 коммутаторам, которые обновляют CAM таблицы

Замечание: GARP используется как пример, такой же алгоритм при получении любого L2 broadcast пакета





QoS и OTV

• Инкапсуляция §  Биты CoS (802.1p) копируются в OTV заголовок (shim header) §  В случае IP трафика: исходное (внутреннее) значение DSCP так же копируется

во “внешний” DSCP

55

Маркировка и инкапсуляция

OTV OTV

IP A IP B West East

802.1Q 1

Encap 2

DMAC SMAC 802.1Q ETHERTYPE IP (опция) внутр. DSCP CoS

802.1p

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 West East

802.1Q 2

DMAC SMAC 802.1Q ETHERTYPE IP (опция) Внутрн. DSCP CoS

802.1p

IP (опция) OTV Исходный пакет Внешн. DSCP OTV

shim

Decap 1

Release 5.2

OTV масштабируемость

57

Текущие поддерживаемые значения

NX-OS 5.2

NX-OS 6.2

16k

MAC адреса во всех

растягиваемых VLAN

32k

2000

Multicast группы

4000

6*

Количество ЦОД

8*

256

Растягиваемые OTV VLAN-ы

1500

* Два ED на ЦОД

Release 6.2





Оптимизация трафика

§  Растянутый VLAN обычно ассоциирован с HSRP группой

§  По умолчанию, только один HSRP маршрутизатор активен и все сервера используют его HSRP VIP как адрес шлюза по умолчанию

§  Результат: неоптимальная маршрутизация

59

Маршрутизация трафика в растянутых VLAN

HSRP Active

HSRP Standby

HSRP Listen

HSRP Listen

HSRP Hellos

VLAN 20

VLAN 10

ARP for HSRP VIP

ARP reply

Пакет из Vlan 10 в Vlan 20

DMAC = Host Vlan 20

Пакет из Vlan 10 в Vlan 20

DMAC = DGW

Routing

Локализация исходящего трафика

§  Фильтрация FHRP с комбинацией VACL и MAC фильтров §  Результат: используется одна HSRP группа и один VIP, но теперь шлюз по умолчанию активен на каждой площадке

60

Применение фильтров для FHRP

HSRP Active

HSRP Standby

HSRP Listen

HSRP Listen

HSRP Hellos

VLAN 20

VLAN 10

HSRP Hellos ✗ ✗ ✗ ✗ HSRP Filter

HSRP Active

HSRP 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


Оптимизация передачи трафика

§  Логический или физический ЦОД? §  Высокая доступность или защита от сбоев?

65

Какой способ выбрать?

WAN

East-West / Server-Server





Это ОДИН логический ЦОД ? (Высокая доступность - High Availability)

Или ДВА физически и логически …

… разделенных ЦОД?

Оптимизация пути входящего трафика

66

Возможные решения

Проблема •  Подсети растянуты между ЦОД •  Суммарной информации о доступных подсетях в таблицах маршрутизации недостаточно

•  Процесс маршрутизации не знает ничего о перемещении северов между ЦОД

•  Трафик может приходить в ЦОД, где приложение не доступно

Решение •  На основе DNS •  Route Injection •  LISP – Locator/ID Separation Protocol

Рекомендуем посетить сессию: Построение катастрофоустойчивых и распределённых ЦОД (часть 3)





Новые функции

§  VLAN трансляция дает возможность при помощи OTV отобразить локальный VLAN в новый удаленный VLAN.

68

OTV VLAN трансляция

otv

otv

otv

otv

Core

West East

interface Overlay0 otv extend-vlan 202-203 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 303 Vlan 303 Vlan 203


Весь инкапсулированный трафик между AED имеет одни и те же IP адреса отправителя и получателя, ограничивая возможности по балансировке, которые предлагают технологии Etherchannel и ECMP

69

Деполяризация туннелей при помощи Secondary IP (до 4-х адресов)

otv

otv

West otv

otv

East

A1->B1 A1->B1 A1->B1 A1->B1


§  Настройка Secondary IP дает возможность предотвратить поляризацию при передаче инкапсулированного в OTV трафика

70

Деполяризация туннелей при помощи Secondary IP (до 4-х адресов)

otv

otv

West otv

otv

East

A4->B4 A2->B2 A3->B3 A1->B1

interface port-channel11 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

Interface port-channel12 ip address 1.1.1.7/32 ip address 1.1.1.17/32 secondary

Новые возможности OTV в NX-OS 6.2

Карты F1 и F2e могут выполнять роль internal Interface в OTV

§  Без F3 в том же VDC 71

Поддержка новых карт Nexus 7000

Aggregation VDC (M-only, M1-F1 or F2/F2e) L2

L3

OTV VDC

Маршрутизируемые линки в ядро

В сторону уровня доступа (Классический Ethernet или FabricPath)

OTV Internal Interface (CE)

OTV Join Interface

M-Series interface

F/M-Series interface

M1, F1, F2e

§  Поддержка OTV на карте F3 в 6.2(6) –  Доступность OTV на Nexus 7700 –  Деполяризация в 6.2(8) –  VLAN трансляция на F3 не поддерживается

M1 M2 F3 M1 P P M2 P P P F1 P P

F2e P P F3 P P

Inte

rnal

Inte

rface

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

дизайне

Подключение к межсетевому экрану

§  МСЭ в L2 режиме, OTV растягивает Inside и Outside VLAN-ы §  OTV поддерживает ситуацию, когда один и тот же MAC адрес находится в разных VLAN

74

МСЭ в прозрачно режиме, растягиваются Inside и Outside VLAN-ы

DC West DC

East

OTV

OTV OTV

OTV

VLAN Outside

FW

VLAN Inside

FW

VLAN Outside

FW

VLAN Inside

FW

Подключение к межсетевому экрану

§  OTV шлет пакеты PIM-hello с адресом источника 0.0.0.0 и адресом назначения 224.0.0.13 §  Hello-сообщения от MAC-адреса OTV Edge Device (VDC) §  МСЭ постоянно регистрирует событие «mac-move», что может вызвать переполнение лога

§  фильтрация PIM-hello на входе в МСЭ §  очистка log МСЭ

75

МСЭ в прозрачно режиме, растягиваются Inside и Outside VLAN-ы

DC West

VLAN 100 Inside Firewall

VLAN 150 Outside Firewall

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

PIM Hellos sourced

from 0.0.0.0 (ED MAC

Address) on VLAN 150

Объединение сетевых фабрик Объединение фабрики ACI с существующими фабриками на базе Nexus

APIC WAN

OTV

DCNM

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

Ethernet трафиком

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

Простота развертывания и настройки

It Just Works Все компоненты и аспекты под

контролем

CiscoRu Cisco CiscoRussia

Ждем ваших сообщений с хештегом #CiscoConnectRu

Пожалуйста, заполните анкеты. Ваше мнение очень важно для нас.

Спасибо Contacts: Name Хаванкин Максим Phone +74999295710 E-mail [email protected]

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 в транспортной сети


§  Адреса multicast групп внутри VLAN отображаются на SSM группы в транспортной сети §  Каждый (S1,Gs1) отображается случайным образом на SSM группу из диапазона адресов,

выделенного владельцем транспортной сети

81

Шаг 1 – отображение адресного пространства multicast групп

S1

OTV OTV

IP A IP B West East

Mcast Stream 1

S1 è Gs1

IP C South

OTV

Передача отображения другим ED 3

Отображение на Delivery Group

2

Транспортная сеть с поддержкой multicast

Отображение номеров групп Mcast

Site Group Core Group Gs1 Gd1

S2

S2 è Gs2

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

East


82

Шаг 2 – начальное программирование устройств, передающих multicast

S1

OTV OTV

IP A IP B West

S1 è Gs1

IP C South

OTV


IGMP join Gs1

1 Client IGMP snoop

2

GM-Update 3.1

IGMPv3 join (IP A, Gd1) в SSM

группу

3.2

Пакет GM-Update обновляет OIF-List

4

SSM дерево для Gd1

Устройства OTV присоединяются к вещанию multicast групп как конечные хосты, а не как маршрутизаторы!

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 (for Gs1) South

East


83

Шаг 3 – передача multicast пакетов

OTV OTV

IP A IP B West

IP C


OTV

Receiver (for Gs1)

OIF-List

Group IF

Gs1 è Gd1 Overlay Lookup

1

S1

S1 è Gs1

IP Aè Gd1 S1 è Gs1

Encap 2

Репликация в транспортной

сети 3

IP A è Gd1 S1 è Gs1

IP A è Gd1 S1 è Gs1

4

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 otv control-group 239.1.1.1 otv data-group 232.192.1.0/24 otv extend-vlan 100-150


§  Выделенная группа для передачи Broadcast трафика §  Возможно разделить по разным группам служебный трафик (control traffic) и

broadcast трафик

85

Возможности по передаче broadcast трафика

interface Overlay1 otv join-interface port-channel100 otv broadcast-group 239.1.1.5 otv control-group 239.1.1.1 otv data-group 232.1.1.0/24 otv extend-vlan 200-209

Release 6.2(2)

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


Быстрая сходимость в 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-Update

AED-Server assigns: West-A (AED)

West-B (Backup-AED)

AED-Server assigns EAST-A (AED)

EAST-B (Backup-AED)

East-A

East-B

AED-Update AED-Update AED-Update AED-Update 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 (Overlay1 0000.0000.0001 ffff.ffff.ffff vlan:100) 6c9c.ed4e.c144 Yes Yes No /Yes -1/-1/29 No No (Overlay1 0000.0000.0002 ffff.ffff.ffff vlan:100) *6c9c.ed4e.4b44 Yes Yes Yes/No 0 /-1/4 No No (Overlay1 0000.0000.0002 ffff.ffff.ffff vlan:100) 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


91

otv

otv

otv

otv

Core West-A

West-B

East-A

East-B

Immediately update forwarding tables to start sending frames to West-B without waiting for West-B to re-advertise the MAC’s

AED-Update AED-Update

Convergence is NOT dependent on the size of the MAC table

Date post:	19-Jul-2015
Category:	Technology
Upload:	cisco-russia
View:	282 times
Download:	15 times

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

Technology