buckethead Опубликовано 27 сентября, 2016 · Жалоба Доброго времени суток! Пытаюсь разобраться с сабжевой фичей, чтобы в дальнейшем реализовать разделение абонентов с публичными адресами и приватными в разные VRF, с последующей доставкой через L3VPN одних до бордеров, других соответственно до NAT серверов. Вопрос, работает ли данный функционал у кого-нибудь на ISG? Удалось только передать с радиуса vrf-id и замапить подписчика в нужный VRF, однако появилась проблема с передачей сервисов с трафик классами. Например, csr1000v безбожно крашится, если передать какой-либо сервис для сессии. А в проде тестировать не совсем получается. aabbccddeeff Cleartext-Password := "cisco" Auth-Type := Accept, Cisco-Account-Info := "QU;10000;15000;D;10000;15000", Cisco-Account-Info += "ANAT", Cisco-Account-Info += "AInternet" NAT Cleartext-Password := "cisco" Cisco-AVPair := "ip:vrf-id=NAT", Internet Cleartext-Password := "cisco" Cisco-AVPair := "traffic-class=input access-group name All priority 20", Cisco-AVPair += "traffic-class=output access-group name All priority 20", Cisco-Service-Info := "QU;5000;7500;D;5000;7500" Реализуема ли задача? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 27 сентября, 2016 · Жалоба Через класс-мапу, внутри которой серые сети описаны, подвешивали сервис и было ок. Сервис был заведён локально Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
buckethead Опубликовано 28 сентября, 2016 · Жалоба Не совсем понял, как именно реализовано у вас. Получается, вы все тарифы храните на самом маршрутизаторе? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShyLion Опубликовано 28 сентября, 2016 · Жалоба Не совсем понял, как именно реализовано у вас. Получается, вы все тарифы храните на самом маршрутизаторе? Если продаешь абоненту тупо интернет, то никакого смысла городить сервисы где-то еще. Скорость с билинга спустил через Cisco-Account-Info := "QU;10000;15000;D;10000;15000" и все. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
buckethead Опубликовано 28 сентября, 2016 · Жалоба Если продаешь абоненту тупо интернет, то никакого смысла городить сервисы где-то еще. Скорость с билинга спустил через Cisco-Account-Info := "QU;10000;15000;D;10000;15000" и все. Согласен, можно отдать pipe в рамках всей сессии, но как же IX, локальный трафик? Хотелось бы хотя бы два TC передать с разной скоростью, плюс общее ограничение для всей сессии. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
skinner Опубликовано 28 сентября, 2016 · Жалоба Не совсем понял, как именно реализовано у вас. Получается, вы все тарифы храните на самом маршрутизаторе? Нет. имелось ввиду что в нужный врф у нас толкала при старте сессии клас мапа такого вида class-map type control match-any NAT44-USERS match source-ip-address 172.18.0.0 255.255.0.0 а дальше прилетал локально заведёный сервис policy-map type service NAT-SRV ip vrf forwarding NAT44 sg-service-type primary Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
buckethead Опубликовано 28 сентября, 2016 · Жалоба Спасибо за ответ, не знал о такой возможности. Вопросов теперь ещё больше, как я понимаю, при помощи этой class-map можно отделить мух от котлет, чтобы не передавать с RADIUS для определённых подписчиков сервис, в котором VRF указывается. А основные сервисы получается загружаются с RADIUS до? И как, например, при initiator dhcp будет этот class-map работать при старте сессии? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...