Коммутаторы : Коммутаторы Cisco Nexus серии 7000

Проверка пересылки по обратному пути FabricPath для VPC + эмулированный ID коммутатора

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв

Введение

Этот документ описывает, как определить, какой интерфейс использовать для Пересылки по обратному пути (RPF) сверяются с Эмулированным ID коммутатора (ESID).

Внесенный Аль Брайантом, специалистом службы технической поддержки Cisco.

Prerequsities

Требования

Cisco рекомендует ознакомиться с основной терминологией FabricPath и понятиями. В частности пользователи должны быть знакомы с Передачей Меток (FTAGs) и как они используются. Для получения дополнительной информации о FTAGs посмотрите Планирование Дерева Для нескольких адресатов для FTAG.

Примечание: Термины FTAG, Деревья и Деревья FTAG использованы взаимозаменяемо в этом документе. В то время, когда этот документ был записан, только FTAG1 и FTAG2 были внедрены. В будущем мог бы быть дополнительный FTAGs.

Используемые компоненты

Сведения в этом документе основываются на Nexus 7000. Некоторые команды могли бы варьироваться на других платформах Nexus, но понятия останутся тем же.

Топология

Примечание: Это - только частичная топология. Существует другой Spine1, связанный с Spine2 и и Leaf1 и Leaf2, но это исключено из этого документа для простоты. Spine1 является root для FTAG1, и Spine2 является root для FTAG2.

Общие сведения

В домене FabricPath каждый коммутатор определен ID коммутатора (SID). В случае Канала Виртуального порта + (vPC +) настройка, каждый удаленный коммутатор имеет два SID. Один для физического коммутатора и один для логического ключа, который сформирован vPC +. Логический SID разделен на обоих узлах и известен как ESID.

Когда пакет для нескольких адресатов получен на vPC + интерфейс и передан в домен FabricPath, пакет инкапсулируется с заголовком FabricPath, и исходный SID установлен в ESID. Как только этот пакет получен на порту ядра FabricPath, Проверка переадресации по обратному пути выполнена, чтобы гарантировать, что пакет был получен на корректном интерфейсе. Короче говоря, перекрестные ссылки Проверки переадресации по обратному пути исходный SID и FTAG пакета к интерфейсу это было получено на. Если это не было получено на интерфейсе RPF, пакет отказывает Проверку переадресации по обратному пути и отброшен.

Проверки переадресации по обратному пути только играют роль для пакетов для нескольких адресатов, которые включают одноадресного одноадресного, передают в многоадресном режиме, и транслируемые пакеты. Проверки переадресации по обратному пути не выполнены на одноадресных пакетах, потому что они могут прибыть в несколько интерфейсов с Равноценным Мультисоединением каналом. Пакеты для нескольких адресатов должны только прибыть в один интерфейс на исходный SID на основе дерева FTAG.

В этом документе исследована Проверка переадресации по обратному пути для ESID. ESID представляет vPC + домен. Это означает, что это - один логический ключ, который состоит из двух физических коммутаторов. Если вы рассмотрите схему топологии, то вы будете видеть, что существует два физических соединения к одному ESID, который, как правило, имеет место. Помните, Проверка переадресации по обратному пути только позволяет пакетам для нескольких адресатов быть принятыми в одном интерфейсе на основе дерева FTAG.

Процедура

Шаг 1. Проверьте Состояние RPF

В данном примере Spine2 является root для FTAG2. Во-первых, проверьте Spine2 для текущего интерфейса RPF для ESID 34 и FTAG2. Существуют два, размещает для проверки статуса RPF, которые находятся в программном обеспечении и в аппаратных средствах. Оба выходных данных показывают, что это Eth4/41 является интерфейсом RPF для FTAG2, ESID 34.

Проверка программного обеспечения

Spine2# show l2 multicast trees

<snip>

ftag/2, topo/0, Switch-id 34), uptime: 04:55:59, isis
Outgoing interface list: (count: 1, '*' is the preferred interface)
* Interface Ethernet4/41, [RPF] [admin distance/115] uptime: 02:09:32, isis

Аппаратная проверка

Во-первых, определите количество VDC и модуль пакетные входы.

Spine2# show vdc

Switchwide mode is m1 f1 m1xl f2 m2xl

vdc_id vdc_name state mac type lc

------ -------- ----- ---------- --------- ---
6 Spine2 active 84:78:ac:0b:60:46 Ethernet f2

Затем присоединение к модулю получения взаимодействуют для проверки состояния аппаратного обеспечения.

Spine2# attach module 4

module-4# show fabricpath unicast routes vdc 6 ftag 2 switchid 34
Route in VDC 6
---------------
--------------------------------------------------------------------------------
FTAG | SwitchID | SubSwitchID | Loc/Rem | RPF | RPF Intf | Num Paths | Merge V
--------------------------------------------------------------------------------
0002 | 0034 | 0000 | Remote | Yes | Eth4/41 | 0 | 1
--------------------------------------------------------------------------------
PD Information for Prefix:

FE num | ADDR TYPE | HTBL ADDR | TCAM ADDR | SWSI
----------------------------------------------------------
10 | HASH TABLE | 00001440 | 000000ff | 0000124c
11 | HASH TABLE | 00001440 | 000000ff | 0000124c
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------

Шаг 2 ---- -------------------------------- --------- . Проверьте vPC + Близость

Для понимания, почему Spine2 выбрал Eth4/41 to Leaf1 instead of Eth4/45 to Leaf2, когда оба - часть ESID, необходимо сначала понять понятие близости.

В не-vpc + настройка, пакеты для нескольких адресатов прежде всего переданы на первом дереве в топологии, которая является Tree1. В vPC + среда, каждое дерево (FTAG1 или FTAG2) обнаруживает сходство для одного или другого удаленного коммутатора. В этой ситуации широковещание, одноадресный одноадресный и многоадресные кадры не-IP пересекают дерево, для которого коммутатор конкретного однорангового узла обнаруживает сходство.

Необходимо проверить, какой узел имеет близость к FTAG2. Чтобы сделать это, войдите к одному из коммутаторов листа в vPC + домен. Проверка может быть сделана от любого удаленного коммутатора, потому что оба должны знать близость их узла, а также их собственное.

Leaf1# show fabricpath isis database detail | i Affinity|Hostname|Nickname

<snip>

Hostname : Leaf2 Length : 5
Affinity :
Nickname: 34 Numgraphs: 1 Graph-id: 1 Nickname :
Priority: 0 Nickname: 4 BcastPriority: 64
Priority: 0 Nickname: 34 BcastPriority: 0
Nickname Migration :

Hostname : Leaf1 Length : 5
Affinity :
Nickname: 34 Numgraphs: 1 Graph-id: 2
Nickname Migration :
Nickname :
Priority: 0 Nickname: 3 BcastPriority: 64
Priority: 0 Nickname: 34 BcastPriority: 0

С этой информацией вы видите это, если кадр для нескольких адресатов принят на Leaf1, коммутатор вперед она вдоль дерева FTAG2. Если кадр принят на Leaf2, он передан вдоль дерева FTAG1.

Для получения дополнительной информации о деревьях FTAG посмотрите Планирование Дерева Для нескольких адресатов для FTAG.

Эта информация используется на Spine2 для построения состояния RPF для ESID 34. Это - Eth4/41, используется в качестве интерфейса RPF для FTAG2 ESID 34. 

Выбор близости

Близость FTAG выбрана этим методом:

  • Существует занимающая место система, основанная прочь SID. SID получен из пула MAC-адресов, выделенных рассматриваемому шасси.

  • Самый низкий идентификатор системы имеет самый высокий разряд.

  • VPC + узел с самым низким идентификатором системы, и поэтому самым высоким разрядом, имеет близость к FTAG1.

  • Второй самый низкий идентификатор системы, и поэтому второй по высоте разряд, имеют близость к FTAG2.

Заключение

Состояние RPF создано в соответствии с vPC + состояние близости на каждом узле. Интерфейс RPF к ESID для данного FTAG является интерфейсом, который соединяется с удаленным коммутатором с близостью.


Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Document ID: 117297