antonv Опубликовано 9 мая, 2017 · Жалоба Добрый день! Имеем Cisco CSR1000v, для которого пытаемся настроить сервисы. Кусок конфига: policy-map type service INET 250 class type traffic INET timeout absolute 180 accounting aaa list default ! ! policy-map type control ISG class type control ISG-IP-UNAUTH event timed-policy-expiry 1 service disconnect ! class type control always event session-start 1 service-policy type service name OPEN_GARDEN 5 set-timer UNAUTH-TIMER 5 10 service-policy type service name S_L4R 20 authorize aaa password secret identifier mac-address ! class type control always event timed-policy-expiry 1 service disconnect ! ! Желаемая логика такова: при появлении абонента спрашивать радиус, авторизовать сессию, навешивать сервисы редиректа на портал и опенгарден. На портале при успешной веб-авторизации через СоА привязать сервис INET. Это всё работает. Сервис должен пропускать трафик 180 секунд (или сколько там передадут в СоА), затем либо вся сессия должна дропаться, либо должны обратно навешиваться сервисы такие же, как при старте. Цель - снова завести абонента на портал. Но взамен из сессии просто пропадает сервис INET, сессия остается висеть авторизованной, трафик абонента продолжает ходить. Игры вокруг timed-policy-expiry, event session-stop толком ни к чему не привели. Посоветуйте плиз, куда копать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
buckethead Опубликовано 9 мая, 2017 · Жалоба Если состояние кастомера после того, как у него удалился INET, будет authen, то это нормальное поведение. Нужен второй CoA, чтобы обратно вернуть ему open garden/redirect. Потому что события session-start не будет происходить, сессия уже стартовала, а вы просто удалили у неё сервисы. Ищите способ дропнуть сессию или шлите CoA. Возможно, но маловероятно ещё посмотреть событие session-restart, может туда сессия попадает, а вы не матчите. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShyLion Опубликовано 19 июля, 2017 · Жалоба Столкнулся с подобной темой, если сеансу сразу при авторизации выдать Session-Timeout, то все нормально, сеанс безоговорочно помирает через указаный промежуток. Если просто послать CoA с новым Session-Timeout, то устанавливается новый лимит времени и сеанс также через указаное время отваливается. Но если при/перед/после этого изменить состав активных сервисов командами: Cisco-Command-Code=\"\x0c$svc\" Cisco-Command-Code=\"\x0b$svc\" то таймер начинает через некоторое время, обычно через минуту, хотя бывало что и через 5 секунд, скидываться в начало отсчета и сеанс становится вечным, пока не убъешь руками. Пробовал даже в разных версиях софта, правда одной ветки. Баг? Фича? ЧЯДНТ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShyLion Опубликовано 21 июля, 2017 · Жалоба Вобщем пришлось таймауты выдавать один раз, при старте сеанса. А тех кто долго сильно не вводил авторизационных данных вышибать скриптом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...