Если вы хоть раз настраивали MPLS L3VPN, то у вас не возникнет сомнения в том, что весь подход вертится вокруг BGP. Будучи протоколом маршрутизации с развитым чувством собственного достоинства (в конце концов, он является основой для интернета), BGP использует внушительный список атрибутов префикса, который лежит в основе алгоритма выбора лучшего маршрута. Несмотря на неприличную длину этого списка, большинство параметров предназначены для обеспечения детерминированности результата алгоритма, а не для управления трафиком руками инженера. Впрочем, иногда даже самые популярные параметры не подходят для решения определённой задачи. Если вы видите EIGRP в связке с L3VPN, возможно, это наш сегодняшний пациент. Сестра, топологию: R1-R3 – это PE-маршрутизаторы, которые используют в ядре OSPF наряду с LDP. Они также обеспечивают связность между площадками с использованием разных IGP:  R1↔R4 ≡ OSPF, R2↔R5 ≡ EIGRP, R3↔R6 ≡ eBGP. Клиентские устройства CE, R4-R6, находятся в одном и том же VRF. R4 и R5 предоставляют R6 доступ к некоему сервису, который расположен по адресу 8.8.8.8/32. Настройка R1 в качестве образца: На CE-маршрутизаторах всё ещё аскетичнее: Интерфейсы loopback эмулируют доступность некого сервиса: Посмотрим, есть ли в принципе связность между R6 и 8.8.8.8: Основная цель такой схемы – обеспечить отказоустойчивый доступ R6 к 8.8.8.8/32 через R4 и R5, именно поэтому BGP-сессии построены между PE-маршрутизаторами напрямую. R1 и R2 должны считать префиксы от IGP лучшими с точки зрения BGP RIB (это локальные маршруты); как следствие, R3 должен получить оба маршрута, по одному от каждого из соседей. По странному стечению обстоятельств R3 получил только один префикс вместо двух. Вполне вероятно, что R1 вовсе не слал ничего о 8.8.8.8/32: R1 считает 8.8.8.8/32, полученный от R2, лучшим маршрутом (символ ‘>’). Поскольку этот префикс получен по iBGP, он не попадает в обновления, предназначенные обычным iBGP-соседям. Почему же выбор R1 именно такой? Согласно алгоритму выбора лучшего маршрута, только weight и local preference имеют больший приоритет, чем локальность префикса. Более того, по умолчанию локальные маршруты получают атрибут weight со значением 32768. По всем правилам получается так, что 8.8.8.8/32 от OSPF должен с большим отрывом победить маршрут от R2. Что же не так? Зубрить сухие цифры – крайне неблагодарное занятие, поэтому весьма неплохо иметь под рукой шпаргалку с номерами и содержанием community для OSPF и EIGRP. Впрочем, виновник торжества сам по себе имеет довольно выразительное название – Cost:pre-bestpath:128:103040. Роль cost community в топологиях L3VPN с EIGRP вполне прозаична. Представим две площадки, A и B, которые соединены между собой посредством быстрого L3VPN как основного пути и через выделенную линию в качестве запасного маршрута. В произвольный момент времени в недрах Площадки-А возникает Префикс-А, обновление о котором распространяется по обоим маршрутам. В такой ситуации возникает race condition: Обновление о Префиксе-А достигает Площадки-В вначале через MPLS backbone. PE устанавливает новый префикс в BGP RIB, передает его в EIGRP (попутно восстанавливая метрику из 	community) и анонсирует новый маршрут на Площадке-В. Выделенная линия имеет худшую метрику, поэтому основной путь до Префикса-А лежит через ядро MPLS, что и требовалось реализовать. Обновление о Префиксе-А достигает Площадки-В вначале через выделенную линию. При таком раскладе Префикс-А попадает в BGP RIB через EIGRP локально, поэтому когда соответствующее обновление приходит со стороны MPLS, оно не может стать лучшим с точки зрения BGP. Как следствие, Площадка-В начинает использовать выделенную линию в качестве основного пути, что не соответствует требуемому поведению. Cost community является одним из решений описанной проблемы. Этот инструмент позволяет BGP рассматривать специальную метрику в определённом месте алгоритма выбора лучшего пути (в нашем случае – в самом начале). Значение метрики EIGRP становится значением cost community, что позволяет однозначно выбирать кратчайший маршрут. Несмотря на то, что описанный подход неплохо работает с EIGRP в рамках L3VPN, у него есть очевидный побочный эффект – он изменяет стандартный и всем привычный алгоритм выбора лучшего пути. Как вы уже догадались, OSPF совершенно не в курсе  про cost community, поэтому для его префиксов cуществует значение по умолчанию, 0x7FFFFFFF (214748347), которое значительно больше типовой метрики EIGRP. На первый взгляд, можно было бы попробовать изменить метрику EIGRP таким образом, чтобы она была больше 0x7FFFFFFF. Однако это привело бы лишь к изменению «направления» проблемы, так как в этом случае уже R2 сравнивал бы значение по умолчанию для префиксов OSPF с огромной метрикой маршрутов EIGRP.   Самым простым решением, безусловно, было бы отключить добавление cost community в принципе, но увы, такой команды пока не существует. То, что доступно простым смертным – это игнорировать cost community в процессе выбора лучшего маршрута: Хоть нам и удалось отвлечь R1 от cost community, R3 страдает тем же самым недугом: методично выбирает лучший маршрут от EIGRP, несмотря на все остальные атрибуты. Наконец, выбор лучшего маршрута соответствует привычным всем правилам: меньший MED решает исход гонки. В качестве альтернативы можно было бы вручную удалить противный cost community из исходящих обновлений: Цели этой статьи – обсудить cost community и немного попрактиковаться в отладке. Не забывайте: в технике и технологии нет другого волшебства, кроме значений по умолчанию. Большая печенька за рецензию: Анастасии Куралёвой.  Системный инженер