Сегодня я хотел бы поделиться своим опытом настройки связности Cisco ACI с внешним L2-сегментом. Как известно, есть два подхода к решению этой задачи: классифицировать внешний сегмент в отдельную EPG или же использовать объект External Bridged Network, также известный как L2Out. Стенд выглядит следующим образом: SW1 и SW2 – это коммутаторы Nexus 3000, выполняющие роль хостов, подключенных к фабрике, поэтому от них требуются только L3-интерфейсы для проверки связности. APIC использует прошивку версии 4.2(7l); конкретные модели коммутаторов фабрики большого значения для повестки не имеют. Политики доступа (access policies) так же находятся за рамками этой статьи, поэтому их настройку можно опустить. Создадим объекты, необходимые для обеспечения связности EPG: VRF и bridge domain (BD). Поскольку L3-связность в данном случае не требуется, можно отключить маршрутизацию и uRPF в рамках BD, оставив остальные параметры без изменений: Теперь мы можем создать application profile (AP) и заняться настройкой L2-связности с помощью первого подхода: назначить определённые порты EPG SW1 и SW2, а затем создать необходимый контракт между ними. Важно настроить связь между EPG и физическим доменом (physical domain); в противном случае политика не будет реализована в фабрике. Назначим физические порты коммутаторов соответствующим EPG: Закончив (почти) настройки на стороне ACI, переключим внимание на N3k: Такие значения MAC-адресов выбраны не случайно: они позволяют легче различать записи в таблице подключенных к фабрике устройств. Напомню, что IP-адреса в этом случае не сработают, поскольку маршрутизация в рамках BD отключена и происходит коммутация пакетов. Впрочем, всех этих настроек пока недостаточно, чтобы между SW1 и SW2 появилась связность, поскольку ACI требует явного разрешения трафика между хостами в виде контрактов. Создадим такой объект, разрешающий ICMP-пакеты в обе стороны: Обратите внимание на область действия контракта: он описывает связность в рамках AP вместо VRF. Хотя в случае только двух хостов это и не имеет большого смысла, ограничение области действия контракта в общем случае позволяет избежать интересных спецэффектов в форме неочевидной связности между EPG в рамках одного и того же VRF. Остаётся только назначить контракт соответствующим EPG: Время проверить связность между SW1 и SW2: Довольно простой процесс, не правда ли? Создание L2Out вместо EPG SW2 должно занять несколько меньше времени, поскольку большая часть настроек остаётся неизменной. Вначале нужно удалить статическую привязку физического порта к EPG, а затем можно использовать освободившийся порт в L2Out: Мне не удалось убедить L2Out принимать кадры в VLAN 1: ACI отказывался распознавать подключённый хост независимо от того, приходил ли трафик с меткой или без неё. Ошибок в соответствующем разделе тоже не было, поэтому я не уверен, есть ли ограничение на использование VLAN 1 в L2Out. Как бы то ни было, я переделал настройки SW2 на использование SVI и подключение к ACI с помощью trunk:  Наконец, EPG должна быть связана с внешним L2-доменом (L2 External Domain), в противном случае политики не будут реализованы в фабрике. Поскольку допустимая связность в ACI описана в виде контрактов, все внешние L2-сущности должны быть классифицированы как внешняя EPG. Настройки EPG SW1 остались прежними, поэтому достаточно назначить контракт EPG SW2, чтобы разрешить связность между ними: Проверим связность между SW1 и SW2 ещё раз: Что-то явно пошло не так. Проверить, что проблема кроется в контракте, можно, отключив применение политик на уровне VRF (policy enforcement). Если контракт действительно ограничивает связность, ICMP пакеты должны успешно пройти, поскольку реализация контрактов отключена. Если связность не появилась, значит, ошибка закралась в настройки L2Out. Теперь становится очевидно, что проблема в контракте. Однако в первом случае (EPG вместо L2Out) всё работало корректно, значит, фильтрация настроена правильно. В чём же подвох? Как обычно, дьявол кроется в деталях. Безусловно, фильтры контракта в полном порядке, как и применение его в EPG. Сейчас мне кажется, что в такой конструкции остаётся лишь одно место, где можно допустить ошибку; однако на тот момент у меня ушло несколько часов на её поиск, после чего я стал перебирать все возможные настройки в рамках tenant, пытаясь выяснить, что именно блокирует ICMP между SW1 и SW2. Забавно и то, что количество зарегистрированных ошибок было равно нулю, т.е. противоречий в объектной модели не было.  Помните область действия контракта? Мы установили её как “Application Profile”, но к какому AP можно отнести L2Out? К сожалению, у меня нет ответа на этой вопрос; впрочем, возникает ощущение, что для L2Out такая область действия контакта неестественна, поэтому изменим её на более широкую, например, на “VRF”, и проверим связность: Итак, мы добились связности через L2Out. Проще ли это, чем настроить EPG? Скорее нет, чем да: потребовались дополнительные действия (дополнительный домен, ассоциация EPG с доменом), которые привели к менее гибкой конструкции (только один VLAN в рамках одного L2Out). Поиск документации по L2Out также оказался непростым квестом, информацию пришлось собирать по разным блогам и форумам. Впрочем, есть и положительный результат: я наткнулся на любопытную книгу, которая может пригодиться при отладке ACI. А что насчёт L3Out, спросите вы? Как нетрудно догадаться, для него характерно то же поведение, что и для L2Out: ограничение области действия контакта до ”Application profile” проявляется в отсутствии связности внешних хостов с теми, что подключены непосредственно  к ACI.  Спасибо за рецензию: Анастасии Куралёвой.  Системный инженер