Обзор технологии
После того как мы с Вами познакомились с vPC, переходим к следующей теме – FabricPath.
Как Вы все знаете, для избавления от петель на 2ом уровне работает протокол STP, который имеет определенные недостатки:
- Нет поддержки multipath. STP создает loop-free топологии путем блокирования избыточных линков, используя широко известный алгоритм (выбор root bridge, затем выбор root ports и т.д.)
- Очень часто пакеты путешествуют по неоптимальному пути. Связано это с тем, что построение дерева начинает от корневого свитча и пакеты бегают именно через него.
- Нет L2-TTL. Эта «проблема» напрямую с STP не связана, но … при поломке STP Ваша сеть моментально получает broadcast-шторм.
- Масштабируемость MAC-адресов. Каждый коммутатор в сети владее информацией о всех МАС-адресах устройств, подключенных в сеть в рамках L2-домена.
Конечно, все эти недостатки можно устранить путем перехода на L3 с каким-либо IGP протоколом. Но это далеко не всегда возможно – часто требуется обеспечить L2 связность между хостами (например, если Вы используете VMware VMotion). Тут то на помощь и приходит технология FabricPath. Первоначально она появилась на Nexus7000, а затем мигрировала и на 6000/5000. Основным достоинством технологии является поддержка L2 Equal Cost Multipathing. Достигнуто это путем применения нового Control Plane протокола – ISIS.
Архитектура FabricPath
В FP различают два вида коммутаторов: корневые (Core) и пограничные (Edge). Edge устройства имеют порты, которые относятся как к FP-облаку, так и к классическому Ethernet. Именно эти устройства держат на себе таблицу МАС-адресов конечных хостов.
Core устройства соединяют Edge между собой. Коммутация трафика данными свитчами осуществляется на основе Switch-ID (рассмотрим далее что это такое и зачем нужно).
Switch-ID каждому коммутатору назначается либо вручную либо автоматически, используя протокол Dynamic Resource Allocation Protocol (DRAP). Switch-ID должен быть уникальным в пределах сети, т.к. целиком и полностью характеризует конкретный коммутатор.
Заголовок FP не предусматривает переноса номера VLAN, поэтому из классического Ethernet фрейм должен прийти уже тегированным с 802.1Q чтобы на удаленной площадки пакет попал туда, куда необходимо.
FP инкапсуляция
Основные поля нового кадра:
- Switch-ID. Нужен для идентификации коммутатора в FP.
- SubSwitch-ID. Используется при интеграции vPC и FP (рассмотрим позже).
- Port-ID. Благодаря этому полю коммутация трафика по пути FP->Ethernet может осуществляться без просмотра MAC таблицы. По сути идентифицирует порт, с которого пришел фрейм (или порт, на который этот фрейм должен быть скоммутирован удаленной железкой).
- Ethertype ставится в значение 0х8903
- FTAG (Forwarding TAG). Это 10-битный идентификатор, который отвечает за то, по какому пути будет коммутироваться фрейм внутри FP (эдакая mpls label).
- TTL выполняет такую же функцию, как и поле TTL внутри IP заголовка.
Control Plane механизм
В качестве CP для FP был выбран ISIS. В основном это из-за того, что он работает непосредственно на link-layer и поэтому не требует наличия IP для своей работы (как OSPF). Ну и плюс – ISIS обладает механизмами построения loop-free топологии, которые нужно адаптировать для L2 (сделано это было путем создания новых TLV).
Прим. Здесь я не буду рассматривать работу ISIS. Кому интересно, тот без труда найдет соответствующую литературу (в треке Service Provider).
У администратора есть возможно гибко манипулировать ISIS деревьями, группируя их на основе VLAN’ов (напр. Для VLAN 1 у нас используется один путь, для VLAN 2 другой и т.д. – очень похоже на ручной traffic engineering в STP).
Также ISIS создает 2 дополнительных дерева для Multicast и Broadcast трафика. Первое из них (всегда использует FTAG=1) предназначено для переноса unknown unicast, multicast и broadcast. Второе используется только для балансировки multicast’а. Корнем первого дерева становится коммутатором с наивысшим приоритетом. Корень второго дерева назначается только что выбранным рутом.
Прим. Рекомендуется оба рута выбрать статически с помощью команды root—priority.
Механизм изучения МАС-адресов в FP
В среде FP изучение сетевых адресов делится на 2 стадии: Control Plane и Data Plane.
Control Plane Learning
За изучение, распространение Switch-ID отвечает протокол ISIS.
Data Plane Learning
Здесь все гораздо интереснее. Ибо процесс изучения МАС адресов мало того, что проходит только на Edge свитчах, так он еще и зависит от того, какой это свитч (относительно движения фрейма): Egress или Ingress (о как!).
FabricPath использует так называемое изучение МАС по требованию (Conversational MAC learning). Понимать это надо следующим образом: для пакетов, которые принимаются через core порт, необходимо делать связку SMAC с удаленным Switch-ID только в том случае, если DMAC уже известен. Это позволяет изучать МАС адреса только для тех хостов, которые активно вовлечены в двухсторонний обмен данными. Для Ingress устройства порядок изучения адресов не меняется по сравнению с классическим Ethernet.
Взаимодействие FabricPath и STP
Как же обстоит дело с предотвращением петель, когда лбами сталкиваются две независимые технологии, которые работают сами по себе? По сути, с точки зрения STP, FP есть один коммутатор (т.е. Edge коммутаторы высылают BPDU через свои FP-порты в сторону классического Ethernet). Однако, есть особенность: BPDU не пересылаются через FP-core порты. Т.е. при наличии нескольких сайтов у Вас образуется несколько STP-доменов.
Прим. Edge коммутатор должен быть STP корнем (в случае 2ух коммутаторов это будет vPC-свитч) для того, чтобы избежать блокировки линков на нем.
Давайте теперь рассмотрим порядок отработки DP+CP на примере взаимодействия двух хостов.
Работа DataPlane
Представим, что Хост А хочет переслать данные на Хост Б.
- Первым делом Хост А высылает ARP запрос чтобы определить МАС адрес удаленной рабочей станции.
- Фрейм достигает граничного коммутатора SW1 через порт E1/1, который относится к vlan10 (эта vlan имеет специальный тип – fabricpath vlan). Далее производится L2 lookup. Коммутатор заносит изученный МАС (А) в таблицу МАС адресов согласно классическому правилу изучения. И поскольку DMAC=FF, то фрейм распространяется через все порты в vlan10.
SW1# show mac address-table dynamic
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O -Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link
VLAN MAC Address Type age Secure NTFY Ports/SWID.SSID.LID
-------------+--------------------+----------+-------+------+----+------------------
* 10 0000.0000.000a dynamic 30 F F Eth1/1
- Чтобы передать фрейм дальше SW1 выбирает первое дерево (Tree1), которое предназначено для broadcast пакетов.
- После выбора дерева производится multilookup, результатом которого служит выбор выходного интерфейса. Какой это будет интерфейс зависит от положения корневого коммутатора в сети. В нашей сети это SW5, значит SW1 выбирает интерфейс Po2. Далее фрейм инкапсулируется внутрь FP и отправляется в сторону SW5. FTAG нового кадра выставляется равным единице. Также важно отметить то, что ODA=FFFF.FFFF.FFFF
- Фрейм достигает коммутатора SW5, который анализирует ODA и принимает решение о передаче фрейма через Po5 и Po8.
- SW2 и SW3 принимают FP фрейм. Если на коммутаторе есть vlan10 (как в случае с SW3), то происходит деинкапсуляция и отправка его в классический Ethernet. Также коммутатор принимает решение о том, что MAC A не стоит добавлять в таблицу сетевых адресов, согласно правилу Conversational MAC Learning.
- Хост Б получает ARP Request и отвечает на него сообщением ARP Reply, которое является unicast.
- Фрейм от Хоста Б достигает SW3 через порт E1/1 в vlan10. Происходит изучение МАС-адреса.
- На SW3 происходит lookup, МАС адрес Хоста А не находится. Соответственно фрейм пересылается внутрь FP как unknown unicast. При этом ODA=010F.FFC1.01C0, FTAG=1.
10.В конце концов фрейм достигает SW1 по FP, на котором производится изучение МАС адреса Хоста Б (т.к. DMAC=A коммутатору уже известен).
11.Фрейм деинкапсулируется и отправляется в сторону Хоста А.
12.Хост А заносит запись о Хосте Б в свою ARP таблицу и в этот момент он готов начать unicast-сессию, отправляет фрейм с SMAC=A, DMAC=B.
13.SW1 получает фрейм, делает L2 lookup и делает вывод, что фрейм необходимо отправить в FP в сторону Switch-ID=3 (SW3).
14.SW1 делает lookup для определения выходного интерфейса в сторону SW3.
SW1# show fabricpath route topology 0 switchid 3
FabricPath Unicast Route Table
'a/b/c' denotes ftag/Switch-ID/subSwitch-ID
'[x/y]' denotes [admin distance/metric]
ftag 0 is local ftag
subSwitch-ID 0 is default subSwitch-ID
FabricPath Unicast Route Table for Topology-Default
1/3/0, number of next-hops: 3
via Po1, [115/40], 0 day/s 10:12:15, isis_fabricpath-default
via Po2, [115/40], 0 day/s 10:12:15, isis_fabricpath-default
via Po3, [115/40], 0 day/s 10:12:15, isis_fabricpath-default
Выбирается один из трех доступных ECMP путей. Предположим, что был выбран интерфейс Po2 (в сторону SW5).
15.SW5 после получений фрейма также делает route lookup, основываясь на полученном ODA.
SW5# show fabricpath route topology 0 switchid 3
FabricPath Unicast Route Table
'a/b/c' denotes ftag/Switch-ID/subSwitch-ID
'[x/y]' denotes [admin distance/metric]
ftag 0 is local ftag
subSwitch-ID 0 is default subSwitch-ID
FabricPath Unicast Route Table for Topology-Default
1/3/0, number of next-hops: 1
via Po8, [115/40], 0 day/s 10:12:10, isis_fabricpath-default
Думаю, что на этом у Вас должна была появиться ясность того, как работает Data Plane.
Настройка технологии
Прим. Для работы FP необходима Enhanced Layer2 лицензия
Базовая настройка проста и состоит буквально из пары шагов.
Сначала инсталлируем и включаем нужную фичу командами install feature—set fabricpath и feature—set fabricpath.
Затем необходимо указать VLAN’ы, которые мы хотим распространить между сайтами. Делается это командой mode fabripath в режиме настройки VLAN.
Завершающим шагом является перевод нужных физических интерфейсов в FP режим командой switchport mode fabripath.
Метки: fabricpath, nexus
Опубликовано: Data Center , Unified Fabric
» Оставить комментарий
Вы должны войти чтобы прокомментировать.