Желающий Опубликовано 15 мая, 2019 · Жалоба Приветствую, уважаемые, IOSXR подкидывает вопросы по мере эксплуатации.... В IOS помнится, были route-map, которые создавались, а затем применялись на нужном интерфейсе и все...трафик маршрутизировался по ним...Как это организовать в IOSXR? Вместо route-map тут route-policy, примерно такая конструкция получилась: route-policy test if source in prefix-set then set next-hop x.x.x.x else set next-hop y.y.y.y endif end-policy Не могу сообразить как ее применить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
drovorub Опубликовано 15 мая, 2019 · Жалоба В XR PBR делается при помощи ACL Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Atlant Опубликовано 15 мая, 2019 · Жалоба В XR это называется ABF:https://community.cisco.com/t5/service-providers-documents/asr9000-xr-abf-acl-based-forwarding/ta-p/3153403https://blog.it-playground.eu/acl-based-forwarding-abf-on-ios-xr/ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Желающий Опубликовано 15 мая, 2019 · Жалоба 1 час назад, Atlant сказал: В XR это называется ABF:https://community.cisco.com/t5/service-providers-documents/asr9000-xr-abf-acl-based-forwarding/ta-p/3153403https://blog.it-playground.eu/acl-based-forwarding-abf-on-ios-xr/ спасибо! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Желающий Опубликовано 21 мая, 2019 · Жалоба В 15.05.2019 в 09:20, Atlant сказал: В XR это называется ABF:https://community.cisco.com/t5/service-providers-documents/asr9000-xr-abf-acl-based-forwarding/ta-p/3153403https://blog.it-playground.eu/acl-based-forwarding-abf-on-ios-xr/ Хм, какая то странная ситуация... может кто сталкивался... вот ACL: ipv4 access-list next_hop 10 permit ipv4 host x.x.144.3 any default nexthop1 ipv4 y.y.y.y 20 permit ipv4 any any Так применяется на интерфейсе (как в инструкциях): interface TenGigE0/0/1/2 mtu 1550 ipv4 address q.q.q.q 255.255.255.252 ipv4 access-group next_hop ingress Кроме этого прописан статикой маршрут по умолчанию 0.0.0.0\0 на шлюз, отличный от y.y.y.y (в этом и суть, что мне надо только малую часть трафика отправить на y.y.y.y) Часть сайтов открывается\пингуется, часть нет. Как то рандомно. Завтра могут поменяться. Те, кто открывались\пинговались сегодня, завтра не доступны. Причем, некоторые из тех, что не открываются - пингуются. DNS доступен, не в нем проблема. Как вариант, увеличил mtu на интерфейсе, но это вопрос не решило. Трассировка прерывается на интерфейсе q.q.q.q Ошибок в логах нет. Входящий трафик на x.x.144.3 идет от y.y.y.y, как и положено. может есть мысли? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Atlant Опубликовано 23 мая, 2019 · Жалоба Что говорит sh cef y.y.y.y detail ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Желающий Опубликовано 24 мая, 2019 (изменено) · Жалоба В 23.05.2019 в 11:28, Atlant сказал: Что говорит sh cef y.y.y.y detail ? Прошу прощения у форумчан: забыл вовремя отписаться. Проблема была в DPI, одновременно с новым каналом, инсталлировали и DPI, который почему то блокировал ресурсы не из реестра. После ребута DPI трафик начал проходить. Спасибо за помощь! Изменено 24 мая, 2019 пользователем Желающий Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...