В одной из прошлых статей я описал способ реализации L3VPN поверх DMVPN, который позволяет организовать связность spoke-маршрутизаторов между собой напрямую, без необходимости отправлять трафик через hub. Одним из ключевых элементов этого способа было использование internal BGP labeled unicast (iBGP LU) для распределения транспортных меток. Поначалу я считал, что модифицировать схему с использованием eBGP не составит большого труда; однако, как показала практика, всё оказалось не так просто.

Сегодня я хотел бы поделиться своим опытом настройки связности Cisco ACI с внешним L2-сегментом. Как известно, есть два подхода к решению этой задачи: классифицировать внешний сегмент в отдельную EPG или же использовать объект External Bridged Network, также известный как L2Out.

Сегодня мы займёмся некой функцией, которая включена по умолчанию на большинстве платформ Cisco IOS. Преследуемых целей две: встать на грабли, а потом выяснить их модель (производитель уже известен).

Disclaimer: только для гиков; устаревшая технология; статья в режиме “just for fun”.

Иногда можно наткнуться на такое поведение по умолчанию, обнаружение и понимание которого требует определённой медитации. Для меня одной из таких особенностей была команда “bgp redistribute-internal”. Первоначально назначение этой функции не вызывало у меня каких-либо вопросов, как и то, что её использование может привести к петлям маршрутизации; раз знающие люди написали, что может, значит, так оно и есть. Однако спустя неопределённое время в голове начало скрестись желание получить наглядный пример такой петли. Беглый поиск, впрочем, не дал ничего конкретного.

DMVPN является известным решением для построения топологий hub&spoke. В ряде случаев может понадобиться поддержка изолированной передачи трафика различных клиентов. Конечно, можно построить DMVPN туннель в каждом VRF; однако в реальной жизни такой подход не является достаточно масштабируемым. В такой ситуации на ум приходит MPLS, который зарекомендовал себя в корпоративных и провайдерских сетях.

GRE поддерживает инкапсуляцию различных PDU, в том числе и MPLS, поэтому, на первый взгляд, не должно возникнуть проблем на уровне передачи трафика. С управляющими протоколами, однако, ситуация обстоит несколько сложнее. LDP и RSVP должны установить соседство перед тем, как обменяться какими-либо данными. Масштабируемость этих протоколов обусловлена использованием мультикаста для обнаружения соседей и обмена с ними необходимыми параметрами протокола. Ручная настройка LDP/RSVP соседства в DMVPN сведёт на нет масштабируемость, поэтому такой сценарий статья не рассматривает. Использование же мультикаста ограничивает функциональность решения, поскольку spoke могут обмениваться такими сообщениями только с hub, что исключает наличие spoke-to-spoke связности с использованием MPLS.

Про настройку и диагностику технологии DMVPN в интернете написано немало статей. Однако про использование мультикаста поверх DMVPN лучшее, что мне удалось найти – это маленькая заметка в Configuration Guide.

“In DMVPN, it is recommended to configure a Rendezvous Point (RP) at or behind the hub. If there is an IP multicast source behind a spoke, the ip pim spt-threshold infinity command must be configured on spokes to avoid multicast traffic going through spoke-to-spoke tunnels.”

Давайте выясним, в чем на самом деле заключается необходимость этой команды.

OSFP, будучи link-state протоколом, исключает петли в топологии за счёт построения дерева кратчайшего пути. Впрочем, тёмный гений изобрёл инструмент разрушения стройной идеи OSPF – речь пойдёт о функции OSPF Virtual Link.

EIGRP – это дистанционно-векторный протокол маршрутизации, изначально разработанный Cisco. Найти корректное определение одного из основных параметров DUAL, feasible distance (FD), оказывается подчас непростой задачей.