Поиск и устранение сетевых неполадок на Cisco UCS Fabric Interconnect (Часть 1)

[Anton Pogrebnyak]

При анализе подключения Cisco UCS к сети важно понимать, каким образом пакеты передаются непосредственно между элементами UCS. По причине специфического поведения Cisco UCS Fabric Interconnect по сравнению с обычными коммутаторами и с Cisco Nexus поиск возможных ошибок конфигурации и сетевых неполадок будет несколько отличаться от стандартного набора процедур на классическом оборудовании уровня доступа.

Ключевые термины в рамках данной статьи

1. Fabric Interconnect (FI) - коммутаторы, используемые одновременно как сетевые устройства при передаче LAN и SAN трафика, так и как средство управления сетевыми и серверными настройками Cisco UCS с помощью Cisco UCS Manager. Коммутаторы FI не обмениваются трафиком серверов напрямую - соединения между FI необходимы для синхронизации параметров Active и Subordinate процессов UCS Manager.
2. I/O Module (IOM/FEX) - модули расширения, устанавливаемые в UCS 5108 chassis для обеспечения связности между сетевыми адаптерами серверов и FI. Два модуля IOM подключаются без пересечения к двум FI для создания двух независимых путей для прохождения трафика от сетевых адаптеров.
3. vNIC - виртуальные сетевые адаптеры, презентуемые операционной системе, установленной на сервере. Количество данных адаптеров будет определяться типом физического сетевого адаптера в сервере и количеством физических соединений между модулями IOM и коммутаторами FI.
4. vEth - виртуальный Ethernet интерфейс на FI, который создается для каждого vNIC  (на одном из двух FI, A или B, если не была выбрана опция Fabric Failover, и на обоих, если опция применена). Физические интерфейсы FI, обращенные в сторону модулей IOM выступают в качестве высокоскоростных каналов приема трафика множества карт vNIC. FI "передает" трафик на соответствующий vEth после прочтения метки VNTag, которая устанавливается во фреймы при передаче между IOM и FI.

Cisco UCS Fabric Interconnect являются связующим звеном между серверами и остальным сетевым оборудованием центра обработки данных, а также систем хранения данных в некоторых вариантах подключения. Однако, имея внешнее сходство с коммутаторами Cisco Nexus, FI по умолчанию передает данные между своими интерфейсами не как традиционный коммутатор. Такой режим работы получил название End-host mode (EHM), и его рекомендуется использовать в большинстве вариантов подключения Cisco UCS. В режиме EHM передача фреймов от сетевых адаптеров серверов через FI на исходящие интерфейсы идет путем процедуры, называемой пиннинг (Pinning). Каждому виртуальному сетевому адаптеру при создании назначается путь через один из двух FI (Fabric A или Fabric B). Трафик данного vNIC направляется на соответствующий выбранному пути модуль IOM, от которого по одному из физических каналов поток достигает FI.

Для пересылки фрейма на соответствующий Uplink интерфейс коммутатор FI обращается к политике пиннинга для карты vNIC, от которой данный трафик поступил. В правиле пиннинга либо задан конкретный интерфейс коммутатора FI (Static pinning), либо правило определено как динамическое. В последнем случае FI выбирает один из доступных Uplink интерфейсов, на котором разрешен к передаче соответствующий VLAN (Dynamic pinning). При осуществлении пересылки никаких изменений, за исключением изъятия VNTag, с фреймом не производится.

Вышестоящее оборудование, например, коммутатор, работающий в классическом режиме, воспринимает фреймы как поступающие непосредственно от сетевых адаптеров серверов и записывает их MAC-адреса в таблицу коммутации.

Ответный трафик в сторону конкретного vNIC должен вернуться на тот же интерфейс FI, через который политика пиннинга отправила оригинальные фреймы. Нарушившие это правило фреймы дропаются.

Преимущество подобного принципа пересылки фреймов состоит в том, что EHM исключает необходимость использования STP на участке от FI до вышестоящих коммутаторов, при этом такие механизмы, как Port-Channel, по-прежнему можно использовать. Так как FI всегда направляют трафик в строго определенные Uplink интерфейсы, а также благодаря реализованному на коммутаторах FI механизму устранения повторов и зацикливаний фреймов (Deja Vu check), появление петель коммутации исключается.

При необходимости FI может быть переведен в режим классической коммутации (Switching mode), но в таком случае становится обязательным использование STP для устранения возможных петель коммутации и правила пиннинга более не применяются.

Поиск пути прохождения трафика по MAC-адресу

В случае возникновения проблем с производительностью UCS или при поиске неполадок на уровне сети одной из частых задач на стадии сбора предварительной информации становится поиск пути, по которому трафик от конкретного MAC-адреса (vNIC) идет через модули IOM и коммутаторы FI на вышестоящее оборудование.
 

Предположим ситуацию, в которой необходимо установить местоположение (шасси и слот с сервером) MAC-адреса 00:11:22:33:44:55, а также путь, по которому трафик от данного MAC-адреса поступает на вышестоящее оборудование. Процедура разбивается на несколько этапов, последовательность которых может варьироваться.

Необходимо определить:

1. FI, обслуживающий данный MAC-адрес (vNIC).

   Cluster# connect nxos a
   Cluster-A(nxos)# show mac-address address 0011.2233.4455
   VLAN          MAC Address                Type             Age         Port
   -------------+--------------------------+--------------+-------------+----------
   100           0011.2233.4455             dynamic        10            veth901

   Cluster# connect nxos b
   Cluster-B(nxos)# show mac-address address 0011.2233.4455
   Total MAC Addresses: 0

2. Местонахождение сервера с данной картой vNIC (номер шасси и слот с сервером)

   Cluster-A(nxos)# show interface veth901
   vethernet901 is up
       Bound Interface is Ethernet1/1/1

   В данном выводе присутствует запись о неком интерфейсе Ehternet1/1/1, номер которого на самом деле указывает позицию сервера (первая цифра – номер шасси, третья – номер слота с нужным сервером).

3. Uplink на FI, через который трафик этого vNIC покидает UCS.

   Cluster-A(nxos)# show pinning interface veth901

   SIF Interface        Sticky       Pinned Border interface
   --------------------+------------+--------------------------------
   veth901              No           Eth1/5

4. Интерфейс FI, на который этот трафик поступает от модуля IOM.
   Cluster-A(nxos)# show fex <chassis#> detail
   ……..
   Fex Port                    State             Fabric Port
   Eth1/1/1                    Up                 Eth1/11
   ………
5. Uplink интерфейс IOM-а.
   Cluster-A(nxos)# show interface fex-fabric
              Fabric          Fabric             Fex
   Fex        Port            Port State         Uplink
   1          Eth1/11         Active             1
6. Интерфейс модуля IOM в сторону карты vNIC. Опционально можно также вывести диаграмму подключения в GUI и CLI UCS Manager.

   Cluster# connect iom <chassis#>
   fex-1# show platform software woodside sts (для FI 62xx и IOM 220x)

   Вывод данной команды отобразит в CLI диаграмму портов IOM в зависимости от его модели с расположением серверов согласно их слотам в шасси и соответствующие им внутренние интерфейсы модуля IOM.

Отобразим на рисунке найденные интерфейсы

В следующей статье по UCS будут рассмотрены полезные команды для поиска неполадок на пути прохождения трафика и рекомендации по избеганию распространенных проблем.

---

Антон Погребняк
инструктор-консультант учебного центра Fast Lane в России