Кто-нибудь успешно использует политики AAR (маршрутизация с учетом приложений)?

[pietro manicioto]

Я открыл заявку TAC в Cisco, но они зашли в тупик, что заставило меня задуматься и усомниться в жизни. Я дошел до того, что сомневаюсь, действительно ли Cisco полностью протестировала этот инструмент и/или действительно ли клиенты его используют? Поэтому я внедрил политики AAR в мою накладку с некоторыми конкретными приложениями, чтобы отдавать предпочтение определенным цветам TLOC и переходить на лучшее доступное соединение на основе определенных мной метрик SLA. Я обнаружил, что мои спицы следуют политике, как и положено, и обрабатывают данные через лучший TLOC до HUB, а затем hub отправляет их в пункт назначения, используя тот же цвет TLOC. Однако на обратном маршруте концентратор использует таблицу маршрутизации для определения маршрута обратно к спице, а не предпочитает исходный входной TLOC. Это проблема, потому что маршруты являются ECMP по всем доступным TLOC, в которых концентраторы иногда возвращают трафик обратно по проблемному каналу, что приводит к тому, что AAR становится в основном бессмысленным и игнорируется. Cisco предложило добавить мои хабы в политику AAR, но моя логика заключается в том, что у моих хабов практически никогда не будет проблем с TLOC в моем ЦОД, поэтому они по-прежнему будут использовать ECMP, что снова поставит меня в ту же ситуацию или вообще не перенаправит трафик.

[Kanan Huseynli]

Здравствуйте, Я понимаю вашу озабоченность. Именно так и работает AAR. AAR является однонаправленным, т. е. если спица отправляет данные через TLOC1, это не означает, что обратный трафик будет проходить через TLOC1. Это полностью зависит от решения удаленного узла (в вашем случае — концентратора). Вам необходимо реализовать AAR и на концентраторе, чтобы он не выбирал проблемный туннель. На самом деле AAR не проверяет TLOC, а проверяет трафик TLOC-TLOC, то есть ipsec-туннели между маршрутизаторами. И, конечно, для работы AAR вам понадобится ECMP (таблица маршрутизации) (AAR учитывает только лучшие пути). AAR работает на основе лучших маршрутов (удаленных TLOC) и рассчитывает параметры приложения (потери, джиттер, задержка) для каждого туннеля (от локального к удаленному TLOC). HTH,
пожалуйста, оцените и отметьте как принятое решение, если вы нашли какую-либо из предоставленной информации полезной.

[MHM Cisco World]

Спицы отправляют трафик в концентратор, а концентратор перенаправляет его на другие спицы, т. е. между спицами нет связи? MHM

[pietro manicioto]

У меня топология «звезда», а не «сеть». Между узлами нет связи.

[pietro manicioto]

Спасибо. Мне кажется, что этого не хватало в документации AAR от Cisco, и часто трафик обратного маршрута остается без внимания. Вчера я встретился с архитектором по продажам и подтвердил то же самое. Я думал, что правила учитывают метрики подслоя по сравнению с метриками надслоя/туннеля, и это сбило меня с толку. Сейчас я рассматриваю возможность добавления концентраторов к существующим политикам.