Реальный случай использования IP SLA Tracking для влияния на маршрутизацию?

[vv0bbLeS]

Всем привет! Конечно, мы можем использовать IP SLA и объекты Track для отслеживания доступности следующего прыжка (например, ISP), а затем удалить маршрут, чтобы повлиять на нашу маршрутизацию, но я пытаюсь придумать реальный случай, когда я бы действительно это сделал, а не просто позволил бы моему протоколу маршрутизации (например, BGP, EIGRP, OSPF) обрабатывал отработку отказа за меня (просто присвоив худшую метрику моему альтернативному маршруту)? 0xD2A6762E

[Joseph W. Doherty]

«Классический» случай использования — отслеживание со статической маршрутизацией. Как вы заметили, при использовании динамической маршрутизации отслеживание не так полезно, за исключением OER/PfR. В последнем случае эта технология может опционально использовать IP SLA для определения оптимального пути. Личный пример из реальной жизни: у одного из наших провайдеров MPLS есть узел, который стал «черной дырой», но маршрутизация продолжала считать его хорошим путем. IP SLA OER/PfR обнаружила проблему и динамически внесла обновления в маршрутизацию, чтобы не использовать «действительный» путь, по которому нельзя было добраться до пункта назначения.

[paul driver]

Здравствуйте, различные варианты использования, которые могут быть:
*статическая/динамическая реклама маршрута на основе определенного условия или булевых операций AND/OR:
наличие/отсутствие маршрута, статус ссылки, доступность пути *маршрутизация на
основе политики < двойной маршрут и вы хотите маршрутизировать определенные маршруты по обоим из них и при этом сохранить отказоустойчивость *переключение при сбое — FHRP (hsrp -glbp-vrrp)
*скрипты EEM, относящиеся к определенному действию, которое должно быть выполнено на rtr — отключение/включение канала — очистка таблицы NAT — добавление маршрута — включение функции и т. д. Пожалуйста, оцените и отметьте как принятое решение, если вы нашли какую-либо из предоставленной информации полезной.
Это поможет другим участникам форума найти ценный ответ и расширит глобальную сеть сообщества.

[julian.bendix]

Однажды у нас был клиент с множеством очень маленьких филиалов, каждый из которых имел один стационарный телефон и резервный LTE. У клиента были старые и небольшие маршрутизаторы Cisco, которые не планировалось заменять или обновлять, а резервная связь LTE работала по тарифному плану с ограниченным трафиком. Лучшее решение, которое я смог придумать, заключалось в отслеживании доступности по стационарному телефону с помощью IP SLA... с использованием маршрута по умолчанию с трекером через указанный стационарный телефон.
Другой маршрут по умолчанию через резервную связь LTE с AD 200, который активируется только в случае сбоя IP SLA через стационарный телефон. Моим предпочтительным решением здесь было бы Meraki или что-то в этом роде, но я должен был работать с тем, что уже было.
Надеюсь, это поможет. BR Jules

[Giuseppe Larosa]

Привет,
@vv0bbLeS
, >> а не просто позволить моему протоколу маршрутизации (например, BGP, EIGRP, OSPF) обрабатывать отработку отказа за меня (просто присвоив худшую метрику моему альтернативному маршруту)? Есть случаи, когда вы соединяете две разные компании, которые не хотят делиться динамическим протоколом маршрутизации по политическим причинам. В таких случаях использование статических маршрутов + IP SLA + отслеживание предпочтительнее простой статической маршрутизации. Особенно если есть LAN-коммутатор или любой другой способ, который может создать интерфейс, даже если удаленное устройство не работает. Надеюсь, это поможет Джузеппе

[vv0bbLeS]

Отлично, спасибо всем! 0xD2A6762E