Сегодня я хотел бы поделиться своим опытом настройки связности 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:

SW1(config)# interface ethernet1/46
SW1(config-if)# shutdown
SW1(config-if)# no switchport
SW1(config-if)# ip add 192.168.0.1/24
SW1(config-if)# mac-address 0000.0000.0001

SW2(config)# interface ethernet1/46
SW2(config-if)# shutdown
SW2(config-if)# no switchport
SW2(config-if)# ip add 192.168.0.2/24
SW2(config-if)# mac-address 0000.0000.0002

Такие значения MAC-адресов выбраны не случайно: они позволяют легче различать записи в таблице подключенных к фабрике устройств. Напомню, что IP-адреса в этом случае не сработают, поскольку маршрутизация в рамках BD отключена и происходит коммутация пакетов.

Впрочем, всех этих настроек пока недостаточно, чтобы между SW1 и SW2 появилась связность, поскольку ACI требует явного разрешения трафика между хостами в виде контрактов. Создадим такой объект, разрешающий ICMP-пакеты в обе стороны:

Обратите внимание на область действия контракта: он описывает связность в рамках AP вместо VRF. Хотя в случае только двух хостов это и не имеет большого смысла, ограничение области действия контракта в общем случае позволяет избежать интересных спецэффектов в форме неочевидной связности между EPG в рамках одного и того же VRF. Остаётся только назначить контракт соответствующим EPG:

Время проверить связность между SW1 и SW2:

SW1# ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2): 56 data bytes
36 bytes from 192.168.0.1: Destination Host Unreachable
Request 0 timed out
36 bytes from 192.168.0.1: Destination Host Unreachable
Request 1 timed out
64 bytes from 192.168.0.2: icmp_seq=2 ttl=254 time=2.259 ms
64 bytes from 192.168.0.2: icmp_seq=3 ttl=254 time=2.061 ms
64 bytes from 192.168.0.2: icmp_seq=4 ttl=254 time=2.138 ms

Довольно простой процесс, не правда ли? Создание L2Out вместо EPG SW2 должно занять несколько меньше времени, поскольку большая часть настроек остаётся неизменной. Вначале нужно удалить статическую привязку физического порта к EPG, а затем можно использовать освободившийся порт в L2Out:

Мне не удалось убедить L2Out принимать кадры в VLAN 1: ACI отказывался распознавать подключённый хост независимо от того, приходил ли трафик с меткой или без неё. Ошибок в соответствующем разделе тоже не было, поэтому я не уверен, есть ли ограничение на использование VLAN 1 в L2Out. Как бы то ни было, я переделал настройки SW2 на использование SVI и подключение к ACI с помощью trunk: 

SW2(config)# interface ethernet1/46
SW2(config-if)# switchport
SW2(config-if)# switchport mode trunk
SW2(config-vlan)# interface vlan 150
SW2(config-if)# mac-address 0000.0000.0002
SW2(config-if)# ip address 192.168.0.2/24
SW2(config-if)# no shutdown

Наконец, EPG должна быть связана с внешним L2-доменом (L2 External Domain), в противном случае политики не будут реализованы в фабрике.

Поскольку допустимая связность в ACI описана в виде контрактов, все внешние L2-сущности должны быть классифицированы как внешняя EPG.

Настройки EPG SW1 остались прежними, поэтому достаточно назначить контракт EPG SW2, чтобы разрешить связность между ними:

Проверим связность между SW1 и SW2 ещё раз:

SW1# ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2): 56 data bytes
Request 0 timed out
Request 1 timed out
Request 2 timed out
Request 3 timed out
Request 4 timed out

Что-то явно пошло не так. Проверить, что проблема кроется в контракте, можно, отключив применение политик на уровне VRF (policy enforcement). Если контракт действительно ограничивает связность, ICMP пакеты должны успешно пройти, поскольку реализация контрактов отключена. Если связность не появилась, значит, ошибка закралась в настройки L2Out.

SW1# ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2): 56 data bytes
64 bytes from 192.168.0.2: icmp_seq=0 ttl=254 time=1.713 ms
64 bytes from 192.168.0.2: icmp_seq=1 ttl=254 time=1.457 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=254 time=1.397 ms
64 bytes from 192.168.0.2: icmp_seq=3 ttl=254 time=1.415 ms
64 bytes from 192.168.0.2: icmp_seq=4 ttl=254 time=1.548 ms

Теперь становится очевидно, что проблема в контракте. Однако в первом случае (EPG вместо L2Out) всё работало корректно, значит, фильтрация настроена правильно. В чём же подвох? Как обычно, дьявол кроется в деталях. Безусловно, фильтры контракта в полном порядке, как и применение его в EPG. Сейчас мне кажется, что в такой конструкции остаётся лишь одно место, где можно допустить ошибку; однако на тот момент у меня ушло несколько часов на её поиск, после чего я стал перебирать все возможные настройки в рамках tenant, пытаясь выяснить, что именно блокирует ICMP между SW1 и SW2. Забавно и то, что количество зарегистрированных ошибок было равно нулю, т.е. противоречий в объектной модели не было.

Помните область действия контракта? Мы установили её как “Application Profile”, но к какому AP можно отнести L2Out? К сожалению, у меня нет ответа на этой вопрос; впрочем, возникает ощущение, что для L2Out такая область действия контакта неестественна, поэтому изменим её на более широкую, например, на “VRF”, и проверим связность:

SW1# ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2): 56 data bytes
64 bytes from 192.168.0.2: icmp_seq=0 ttl=254 time=1.807 ms
64 bytes from 192.168.0.2: icmp_seq=1 ttl=254 time=1.528 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=254 time=1.412 ms
64 bytes from 192.168.0.2: icmp_seq=3 ttl=254 time=1.446 ms
64 bytes from 192.168.0.2: icmp_seq=4 ttl=254 time=1.391 ms

Итак, мы добились связности через L2Out. Проще ли это, чем настроить EPG? Скорее нет, чем да: потребовались дополнительные действия (дополнительный домен, ассоциация EPG с доменом), которые привели к менее гибкой конструкции (только один VLAN в рамках одного L2Out). Поиск документации по L2Out также оказался непростым квестом, информацию пришлось собирать по разным блогам и форумам. Впрочем, есть и положительный результат: я наткнулся на любопытную книгу, которая может пригодиться при отладке ACI.

А что насчёт L3Out, спросите вы? Как нетрудно догадаться, для него характерно то же поведение, что и для L2Out: ограничение области действия контакта до ”Application profile” проявляется в отсутствии связности внешних хостов с теми, что подключены непосредственно  к ACI. 

Спасибо за рецензию: Анастасии Куралёвой.