Привет, Хабр! Меня зовут Сергей Балдаков — я техлид группы поддержки сетей передачи данных в компании К2Тех.

В своей практике я часто сталкиваюсь с кейсами, когда в GUI все выглядит красиво:  графики строятся, трафик ходит, коммутаторы жужжат  и греют воздух дата-центра. А вот конкретные сетевые взаимодействия, для которых «вот только вчера сделали контрактик», почему-то не работают. Классическая ситуация — рисовали на бумаге, но забыли про овраги.

Чтобы сетевой инженер не свалился в такой «овраг» и не переломал себе ноги, хочу поделиться нашими наработками по tshoot относительно работы контрактов внутри фабрики. По сути, это вольное изложение нашей внутренней документации, которую мы  используем для работы по кейсам. Данная статья не претендует на откровения, всю информацию можно найти в официальных документах вендора. Скорее это некая хрестоматия, где я собрал все средства,  доступные инженеру, для проверки работы правил ограничения трафика на фабрике.

Надеюсь, этот материал поможет инженерам, работающим с фабриками ACI, разобраться, что же конкретно работает не так в их среде и как настроить работу контрактов правильно.

Способ первый: самый простой — проверка через GUI

Первое, что можно сделать  — это проверить прохождение трафика через инструмент Visibility & Troubleshooting

Он доступен из меню Operations -> Visibility & Troubleshooting и позволяет, не выполняя дополнительных телодвижений, крупными мазками показать ,  пройдет трафик между определенными Endpoint или нет.

Собственно, принцип работы крайне прост: мы придумываем имя сессии — они сохраняются. В случае, если какой-то тест нужно будет повторить, к нему можно вернуться по имени.

Определяем вид трафика, который нас интересует:

Endpoint - Endpoint —  тот случай, когда оба хоста зарегистрированы на ACI и изучены в COOP. Можно указывать, как IP (если мы знаем как L3 EP), так и mac адрес. В этом случае GUI автоматически предложит изученную машину для выбора, по ней нужно только кликнуть.

Endpoint - External IP (or vice versa) — когда мы проверяем взаимодействие хоста внутри ACI с внешним миром (например, через L3 Out). Для параметра External IP доступно только указание IP адреса, подсказок со стороны GUI не будет, так как ACI не знает про данный EP.

External IP - External IP — ситуация, когда мы проверяем прохождение транзитного трафика. Мне в реальной жизни с подобным  кейсом работать не приходилось, но, тем не менее, такая возможность есть.

Окно Time Window — можно отобразить информацию за последний период 5-240 минут, либо использовать фиксированный отрезок времени, отметив чекбокс Fixed Time.

Мы рассмотрим на наиболее  репрезентативном примере н проверку связности между двумя EP, находящимися на самой фабрике. 

После нажатия кнопки Submit ACI выводит схему, по которой проходит трафик между двумя EP внутри фабрики, а также подсвечивает ошибки на Leaf/Spine коммутаторах, если таковые имеются в данном взаимодействии.

На ошибки можно кликнуть и развернуть их для получения более подробной информации.

Также в данном окне можно проверить наличие  ошибок,  связанных с дропами трафика, и контрактов, примененных между EP.

Данный инструмент хорош для того, чтобы проверить, есть ли принципиальная связность между EP на фабрике, и дать информацию для дальнейшего траблшутинга, включая локацию EP на конкретных Leaf и интерфейсах.

Однако этот  инструмент не даст ответа на вопрос, если связность между EP есть, но, например,  соединение по 22 порту не устанавливается.

Для более детальной диагностики используем следующий инструмент.

Способ второй: fTriage

fTriage использует в своей работе данные ELAM с коммутаторов, из которых состоит фабрика.

Для работы ему необходимо задать несколько параметров, в зависимости от типа трафика, который мы проверяем. После получения данных параметров fTriage инициирует создание ELAM триггера на Leaf коммутаторах, которые мы указали как стартовую точку для поиска трафика. После чего считывает информацию из ELAM, передает её в Human readeble формате в вывод на APIC. Инициирует ELAM триггер на следующем коммутаторе, который он определяет по выводу предыдущего ELAM. И по такой цепочке до того момента, пока пакет не достигнет своей конечной точки на фабрике — порта в сторону EP или порта в сторону L3Out.

Исходя из вышесказанного следует, что для работы ELAM триггеров данному инструменту требуется присутствие «живого» трафика  как вариант постоянных ICMP запросов. Например, так:

Однако поскольку  пример рассматривает проблемы на 22 порту, то нам понадобится простой скрипт на python, который мы запустим на машине-инициаторе трафика. Если по какой-то причине такой скрипт запустить невозможно, то потребуется вручную отправить несколько запросов на 22 порт хоста назначения.

Пример скрипта

import socket

import time

def check_port(ip, port, timeout=5):

    while True:

        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

        sock.settimeout(timeout)

        try:

            sock.connect((ip, port))

            print(f"Соединение с {ip}:{port} успешно установлено.")       

            sock.close()

            time.sleep(5)

        except socket.timeout:

            print(f"Ошибка тайм-аута при соединении с {ip}:{port}. Повторная попытка через 5 секунд.")

            time.sleep(5)

        except socket.error as e:

            print(f"Не удалось соединиться с {ip}:{port}. Ошибка: {e}")

            time.sleep(5)

        finally:

            sock.close()

ip_address = "X.X.10.179"  

port = 22

check_port(ip_address, port)

fTriage вызывается из CLI интерфейса APIC сервера

По данному инструменту можно посмотреть встроенную справку на APIC:

ftriage example - примеры использования команды;

ftriage -h - вывод общего help;

ftriage <команда> -h вывод help по конкретной команде (например ftriage route -h).

В примере, который мы рассматриваем в этой  статье, нам нужен тип трафика route, так как данный пакет маршрутизируется внутри фабрики, а не коммуницирует в рамках одного bridge domain

Запустим на тестовой машине наш скрипт, чтобы сгенерировать поток трафика:

На APIC сервере запускаем ftriage со следующими параметрами, чтобы проследить за тем, что происходит с пакетом:

ftriage -user username route (так как трафик L3) -ii VPC:VPC_TEST-SEGMENT (интерфейс на котором ожидаем входящий трафик) -sip X.X.16.5 (source ip в заголовке) -dip X.X.10.179 (destination ip в заголовке)

После выполнения команды получаем следующий вывод:

_{TEST-APIC-01# ftriage -user admin route -ii VPC:VPC_TEST-SEGMENT -sip X.X.16.5 -dip X.X.10.179}

_{Starting ftriage}

_{Log file name for the current run is: ftlog_2025-08-04-14-01-25-455.txt}

_{2025-08-04 14:01:25,460 INFO     /controller/bin/ftriage -user admin route -ii VPC:VPC_TEST-SEGMENT -sip X.X.16.5 -dip X.X.10.179}

_{Request password info for username: admin}

_Password:

_{2025-08-04 14:01:46,724 INFO     ftriage:      pif:103  VPC VPC_TEST-SEGMENT maps to N9K-TEST-Leaf-16:Po2,N9K-TEST-Leaf-15:Po1}

_{2025-08-04 14:02:34,662 INFO     ftriage:     main:2064 Invoking ftriage with username: admin}

_{2025-08-04 14:02:54,403 INFO     ftriage:     main:1491 Enable Async parellel ELAM with 2 nodes}

_{2025-08-04 14:03:03,248 INFO     ftriage:     fcls:2371 N9K-TEST-Leaf-16: Valid ELAM for asic:0 slice:0 srcid:84 pktid:1080}

_{2025-08-04 14:03:03,941 INFO     ftriage:     fcls:2658 N9K-TEST-Leaf-16: Signal ELAM found for Async lookup}

_{2025-08-04 14:03:03,944 ERROR    ftriage:  unicast:238  N9K-TEST-Leaf-16: L3 packet getting fwd dropped, checking drop reason}

_{2025-08-04 14:03:03,944 ERROR    ftriage:  unicast:238  N9K-TEST-Leaf-16: L3 packet getting fwd dropped, checking drop reason}

_{0x00000000000400000              condition setcast:240  N9K-TEST-Leaf-16: Drop reason - SECURITY_GROUP_DENY              condition set}

_{2025-08-04 14:03:13,031 INFO     ftriage:  unicast:265  N9K-TEST-Leaf-16: policy drop flow sclass:32874 dclass:16410 sg_label:4 proto:6}

_{2025-08-04 14:03:13,031 INFO     ftriage:  unicast:287  N9K-TEST-Leaf-16: nxos matching rule id:5950}

_{2025-08-04 14:03:13,032 INFO     ftriage:     main:1523 : Ftriage Completed with hunch: Packet drop}

В нем видно, что наш трафик попадает в явное запрещающее правило:

_{2025-08-04 14:03:03,944 ERROR    ftriage:  unicast:238  N9K-TEST-Leaf-16: L3 packet getting fwd dropped, checking drop reason}

_{0x00000000000400000              condition setcast:240  N9K-TEST-Leaf-16: Drop reason - SECURITY_GROUP_DENY              condition set}

_{2025-08-04 14:03:13,031 INFO     ftriage:  unicast:265  N9K-TEST-Leaf-16: policy drop flow sclass:32874 dclass:16410 sg_label:4 proto:6}

_{2025-08-04 14:03:13,031 INFO     ftriage:  unicast:287  N9K-TEST-Leaf-16: nxos matching rule id:5950}

_{2025-08-04 14:03:13,032 INFO     ftriage:     main:1523 : Ftriage Completed with hunch: Packet drop}

sclass 32874 это pcTag source EPG, dclass 16410 это pcTag destination EPG, nxos matching rule 5950 — это ID правила, в которое попадает наш трафик.

Проверить, что же это за правила такие, можно с помощью следующих команд на Leaf коммутаторе.

Сначала проверяем, какие контракты в целом регулируют доступы между нашими EPG. В этом примере их всего два, и здесь наглядно видно, что один из них — явно запрещающий

_{N9K-TEST-Leaf-16# show zoning-rule src-epg 32874 dst-epg 16410}

_{+---------+--------+--------+----------+--------+---------+---------+-------------------------}

_{| Rule ID | SrcEPG | DstEPG | FilterID |  Dir   |  operSt |  Scope  |            Name           | Action |    Priority   |}

_{+---------+--------+--------+----------+--------+---------+---------+-------------------------}

_{|   5950  | 32874  | 16410  |    1     | bi-dir | enabled | 2326528 |     TEST_Tenant:VLAN616    |  deny  | fully_qual(7) |}

_{|   5149  | 32874  | 16410  |    9     | bi-dir | enabled | 2326528 | TEST_Tenant:Default_Permit | permit | fully_qual(7) |}

_{+---------+--------+--------+----------+--------+---------+---------+-------------------------}

В случае, когда контрактов много, можно посмотреть сразу по rule-id:

_{N9K-TEST-Leaf-16# show zoning-rule rule-id 5950}

_{Config State}

_============

_{+---------+--------+--------+----------+--------+---------+---------+--------------------+---}

_{| Rule ID | SrcEPG | DstEPG | FilterID |  Dir   |  operSt |  Scope  |        Name        | Action |    Priority   |  Intent |}

_{+---------+--------+--------+----------+--------+---------+---------+--------------------+---}

_{|   5950  | 32874  | 16410  |    1     | bi-dir | enabled | 2326528 | TEST_Tenant:VLAN616 |  deny  | fully_qual(7) | install |}

_{+---------+--------+--------+----------+--------+---------+---------+--------------------+---}

_{Install State}

_{=============}

_{+---------+--------+--------+----------+--------+---------+--------------------+--------+----}

_{| Rule ID | SrcEPG | DstEPG | FilterID |  Dir   |  Scope  |        Name        | Action |    Priority   |}

_{+---------+--------+--------+----------+--------+---------+--------------------+--------+----}

_{|   5950  | 32874  | 16410  |    1     | bi-dir | 2326528 | TEST_Tenant:VLAN616 |  deny  | fully_qual(7) |}

_{+---------+--------+--------+----------+--------+---------+--------------------+--------+----}

В этих выводах мы видим, что какой-то нехороший человек намеренно запретил из нашей EPG подключения на 22 порт EPG серверного сегмента.

Осталось только зайти в GUI APIC и удалить ненужный контракт.

Этот способ работает достаточно хорошо в большинстве случаев. Однако есть и более сложные кейсы, когда может потребоваться детальный разбор.

3. ELAM — Ereport

В этом разделе мы рассмотрим детальный разбор захвата пакета через ELAM и его расшифровку через Ereport.

ELAM расшифровывается как Embedded Logic Analyzer Module. Он предназначен для захвата пакетов на уровне ASIC и позволяет подробно изучить как их заголовки, так и то, как он будет обработан логикой самого коммутатора.

Этот инструмент в ACI унаследован из классической NXOS.

Суть практически аналогична работе ftriage, за тем исключением, что мы подробно разбираем пакет, который активировал триггер ELAM на нашем порту. Ftriage же вынимает из ELAM только самую базовую информацию.

Если трафик проходит без ограничений, ftriage не указывает правило, куда он попадает, если он легитимен с точки зрения ACI. Ereport же выведет полную информацию и о поступившем пакете, и том, как он будет обработан. 

Как пример: заказчик утверждает, что в его окружении коммуникация внутри vrf ограничена из-за отсутствия явного разрешающего контракта. Такого контракта между EP нет, но трафик все равно проходит.

Сервер X.X.10.179 доступен по 22 порту с машины X.X.16.5, хотя правила, разрешающего такое взаимодействие, нет.

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

Коммутатор мы выбираем тот, к которому подключена машина – инициатор трафика. В большинстве случае на ACI политики применяются на Ingress интерфейсах.

Переходим в shell линейной карты:

_{vsh_lc}

Включаем дебаг для ASIC:

_{debug platform internal roc elam asic 0}

Тип ASIC зависит от модели коммутатора. Общая логика такая:

_{N9K-C*-EX- Leaf - ASIC tah} 

_{N9K-C*FX/FXP/FX2 -Leaf - ASIC roc} 

_{N9K-C*-GX – Leaf - ASIC app}

Сбрасываем триггер

_{trigger reset} 

Выбираем параметры для необходимого нам трафика. В нашем случае, если мы ожидаем non-VXLAN кадр (так как, по сути, дела мы инициируем триггер на порту в сторону EP), нужно выбрать in-select 6:

_{trigger init in-select 6 out-select 1}

Задаем параметры пакета, который мы ожидаем увидеть:

_{set outer ipv4 src_ip X.X.16.5 dst_ip X.X.10.179}

Стартуем наш ELAM:

_start

Запускаем скрипт на тестовой машине и проверяем статус нашего триггера.

_status

Если триггер успешно отработал, вбиваем команду: 

_ereport

И получаем полный отчет о том, что за пакет к нам пришел, как он будет обработан и куда отправлен (если будет):

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

Первое — это то, что пакет собственно тот, который нас интересует. То есть источник X.X.16.5, назначение X.X.10.179, и порт назначения - 22:

-------------------------------------------------------------------------------------------------

^{Outer L3 Header}

-------------------------------------------------------------------------------------------------

_{L3 Type                       : IPv4}

_{IP Version                    : 4}

_{DSCP                          : 0}

_{IP Packet Length              : 52 ( = IP header(28 bytes) + IP payload )}

_{Don't Fragment Bit            : set}

_{TTL                           : 128}

_{IP Protocol Number            : TCP}

_{IP CheckSum                   : 50511( 0xC54F )}

_{Destination IP                : X.X.10.179}

_{Source IP                     : X.X.16.5}

-------------------------------------------------------------------------------------------------

_{Outer L4 Header}

-------------------------------------------------------------------------------------------------

_{L4 Type                       : TCP}

_{Source Port                   : 20643( 0x50A3 )}

_{Destination Port              : 22( 0x16 )}

_{TCP/UDP CheckSum              : 0x91F0( 0x91F0 )}

Далее мы листаем вывод до секции Contract lookup:

===============================================================================

                                                              Contract Lookup ( FPC )

===============================================================================

-------------------------------------------------------------------------------------------------

_{Contract Lookup Key}

-------------------------------------------------------------------------------------------------

_{IP Protocol                             : TCP( 0x6 )}

_{L4 Src Port                             : 20643( 0x50A3 )}

_{L4 Dst Port                             : 22( 0x16 )}

_{sclass (src pcTag)                      : 32874( 0x806A )}

_{dclass (dst pcTag)                      : 16410( 0x401A )}

_{src pcTag is from local table           : yes}

_{derived from a local table on this node by the lookup of src IP or MAC}

_{Unknown Unicast / Flood Packet          : no}

_{If yes, Contract is not applied here because it is flooded}

-------------------------------------------------------------------------------------------------

_{Contract Result}

-------------------------------------------------------------------------------------------------

_{Contract Drop                           : no}

_{Contract Logging                        : no}

_{Contract Applied                        : yes}

_{Contract Hit                            : yes}

_{Contract Aclqos Stats Index             : 80827}

_{( show sys int aclqos zoning-rules | grep -B 9 "Idx: 80827" )}

В выводе мы обращаем информацию на то, что контракт был все же применен при этом взаимодействии:

_{Contract Applied                        : yes}

_{Contract Hit                            : yes}

Далее прямо в elam, из приглашения module-1(DBG-elam-insel6)#, вводим команду из короткой подсказки в ereport:

_{show sys int aclqos zoning-rules | grep -B 9 "Idx: 80827"}

Этой командой мы смотрим, какую запись в TCAM использовал пакет для обработки:

_{module-1(DBG-elam-insel6)# show sys int aclqos zoning-rules | grep -B 9 "Idx: 80827"}

_{===========================================}

_{Rule ID: 5950 Scope 4 Src EPG: 32874 Dst EPG: 16410 Filter 9}

    _{unit_id: 0}

    _{=== Region priority: 1950 (rule prio: 7 entry: 158)===}

        _{sw_index = 1105 | hw_index = 1093 | stats_idx = 80827}

  _{Curr TCAM resource:}

  _{=============================}

    _{=== SDK Info ===}

        _{Result/Stats Idx: 80827}

Тут нас интересует параметр Rule ID, который мы можем проверить уже из обычного shell нашего коммутатора.

_{N9K-TEST-Leaf-16# show zoning-rule rule-id 5950}

_{Config State}

_============

_{+---------+--------+--------+----------+----------------+---------+---------+--------------------+--------+-------------}

_{| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       |  operSt |  Scope  |        Name        | Action |    Priority   |  Intent |}

_{+---------+--------+--------+----------+----------------+---------+---------+--------------------+--------+-------------}

_{|   5950  | 32874  | 16410  |    6     | uni-dir-ignore | enabled | 2326528 | TEST_Tenant:VLAN616 | permit | fully_qual(7) | install |}

_{+---------+--------+--------+----------+----------------+---------+---------+--------------------+--------+-------------}

_{Install State}

_{=============}

_{+---------+--------+--------+----------+----------------+---------+--------------------+--------+---------------+}

_{| Rule ID | SrcEPG | DstEPG | FilterID |      Dir       |  Scope  |        Name        | Action |    Priority   |}

_{+---------+--------+--------+----------+----------------+---------+--------------------+--------+---------------+}

_{|   5950  | 32874  | 16410  |    6     | uni-dir-ignore | 2326528 | TEST_Tenant:VLAN616 | permit | fully_qual(7) |}

_{+---------+--------+--------+----------+----------------+---------+--------------------+--------+---------------+}

Здесь мы видим, что трафик попадает в правило c направлением uni-dir-ignore. Это говорит нам о том, что трафик попадает в правило для обратного трафика.

Возникает ситуация, когда в контракте создается фильтр с параметрами Apply Both Directions и чекбоксом Reverse filter ports. Поскольку ACI полагается на hardware в виде коммутаторов Nexus, здесь не применимы stateful правила, к которым уже многих приучили фаерволы. А используется решение, когда для обратного трафика программируются отдельные записи в TCAM коммутаторов.

Далее мы ищем в GUI APIC контракт, в который попадает данный трафик, и смотрим его настройки. В частности, настройки фильтров. И где он применен.

Смотрим, что же в этих фильтрах:

Видим, что трафик разрешен с диапазона портов куда угодно.

Теперь проверяем, как же применен контракт.

Видим, что изначальный план был в том, чтобы разрешить коммуникацию с любого порта EPG-Vlan505 до группы портов в EPG Vlan616. Но не было предусмотрено, что обратный трафик так же пойдет по контракту с опциями Apply both Directions и Reverse Filter ports.

Отчасти именно поэтому вендор не рекомендует использовать контракты на ACI с группами портов, так как это может приводить к подобным ситуациям и истощать TCAM коммутаторов из-за особенностей программирования диапазонов портов в нем. 

Заключение

Вот такими инструментами пользуемся мы в нашей рутине в К2Тех. Будет интересно послушать мнение коллег в комментариях. Возможно, есть какие-то способы, которые мы ещё не применяем в своей практике. Конечно, функционал описанных мной инструментов выходит далеко за рамки проверки контрактов на фабрике. Я их рассмотрел, ограничив наш кейс контрактами для простоты восприятия. Поэтому я с удовольствием отвечу на вопросы,  возникшие в результате прочтения.