IPOE зависшие сессии

[delphivcl]

Коллеги, очередной вопрос о том как бороться с зависшими сесииями на Cisco ISG ASR1002

Описываю ситуацию. Имеем стенд следующего вида:

 

Сервак с биллингом LB2 + ASR1002 + DES3200-52 + абонентский DIR

 

Все замечательно работает (сессии поднимаются абон гуляет в инете через RadCoA рулим абонентом) до тех пор пока у абонента не отрубят свет

Отрубился абонентский роутер а сессия на ISG как была активна так и осталась. По идее как мне говорят ISG не должна слать аккаунтинг и черз какое-то время биллинг по эвенту шлет на ISG команду убить

сессиию. Но в моем случае ISG исправно шлет аккаунтинг на биллинг, но в нем всегда постоянные значения, изменяется лишь время сессии.

Вопрос! Где и что надо докрутить? Всем заранее спасибо!

 

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:30] Authenticator: 9ac2ff781e695ce877fc0c7a89e45c96

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'Acct-Session-Id', value: "0A271F0500000259"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'Framed-Protocol', value: "1"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'Framed-IP-Address', value: "17*.21*.*5.30"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'User-Name', value: "fc75.161f.af65"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] VSA 'Cisco-AVPair', vendor Cisco, value: "connect-progress=Call Up"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] VSA 'ssg-control-info', vendor Cisco, value: "I0;53964"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] VSA 'ssg-control-info', vendor Cisco, value: "O0;175236"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'Acct-Session-Time', value: "2171"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'Acct-Input-Octets', value: "53964"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'Acct-Output-Octets', value: "175236"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'Acct-Input-Packets', value: "361"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'Acct-Output-Packets', value: "396"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'Acct-Authentic', value: "2"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'Acct-Status-Type', value: "3"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'Calling-Station-Id', value: "fc75.161f.af65"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'NAS-Port-Type', value: "5"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'NAS-Port', value: "0"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'NAS-Port-Id', value: "0/0/0/700"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] VSA 'circuit-id-tag', vendor Cisco, value: "000402bc0001"

03.12.2013 17:36:30 DEBUG 0x2ae90e803940 [ParseAttr:240] HWPORT: 1

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] VSA 'remote-id-tag', vendor Cisco, value: "0006acf1dfbc4250"

03.12.2013 17:36:30 DEBUG 0x2ae90e803940 [ParseAttr:229] HWNAME: "acf1dfbc4250"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] VSA 'Cisco-AVPair', vendor Cisco, value: "vendor-class-id-tag=udhcp 0.9.8"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'Class', value: "00130868"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'Service-Type', value: "2"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'NAS-IP-Address', value: "111.139.131.15"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'Event-Timestamp', value: "1386077582"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'NAS-Identifier', value: "ISG_BRAS_1"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [ParseBody:37] Attribute 'Acct-Delay-Time', value: "0"

03.12.2013 17:36:30 VERBOSE 0x2ae90e803940 [RunAcctRequest:1824] Acct-Status-Type = UPDATE

Edited December 4, 2013 by delphivcl

[zhenya`]

идл таймаут выставите и все.. сессия сама будет схлопываться и слать в билинг стоп.

[delphivcl]

Вопрос как выставить? Все говорят про этот загадочный айдл, а строчку конфига увы :)

Заранее спасибо!

[zhenya`]

радиусом выдавайте

Idle-Timeout = 1800

и

Cisco-AVPair = "subscriber:idle-timeout-direction=inbound"

[delphivcl]

Спасибо добрый человек. Помогло.

 

Теперь усложняю задачу.

например юзер сам вырвал кабель питания из роутера для инициализации новой сессии. если он попал в период таймаута то прицепляется к уже активной сессии.

так вот нужно не цеплять, а поднять новую. И вообще правильно ли это?

[vurd]

Зачем ему это делать? Если хотите так, то ловите трап со свитча о падении порта и через coa рвите ему чессию.

Имхо - бред

[zhenya`]

странные желания..

предыдущему +1

[delphivcl]

Это не желание - это вопрос! Я не знаю правильно так делать или нет. советуюсь. Ну выпало тут на мою душу заниматься конфигурированием ISG. опыта - 0

Ситуацию поясню. есть такой провайдер Ростелеком :)

так вот там иногда бывает так что трафик просто перестает идти, может косяк у них какой. приходится отключать роутер и ждать 30 минут (может и меньше надо) пока сессия не помрет.

реконнектимся и все работает дальше до очередного косяка, роутеры меняли (грешили на них), но не в них дело.

 

Многие абоненты не понимаю что надо выжидать некое время. и вообще далеки. Ломят саппорт - не работает интернет, когда банально надо просто реинит сессии сделать.

Edited December 4, 2013 by delphivcl

[darkagent]

с такими хотелками можно начать ковырять в сторону 802.1x

[vurd]

Охеренное решение проблемы. Вместо того чтобы разобраться ПОЧЕМУ пропадает достум, мы будем клирить сессии. И еще обвинять пользователя. Ваще слов нет.

[denis_vid]

Idle-Timeout = 120 и не паритесь, если нет статик сессий)

[delphivcl]

vurd

Почему Вы решили что это решение проблемы, я пока собираю все способы как сделать абоненту жизнь легче. У меня пока нет ни проблемы с абонентами - ничего. Это всего лишь стенд где я пытаюсь реализовать различные события, как и что сделать и использовать в дальнейшем. Я рассматриваю любые ситуации и меня интересует именно мнение профи.

 

приведу еще пример. есть технические линки где траф идет редко. сессию рвать нельзя. такое требование.

 

denis_vid

Idle-Timeout = 180 пока сделал для тестов. В общем оно работает.

У всех по такому сценарию разве все работает?

[denis_vid]

vurd

Почему Вы решили что это решение проблемы, я пока собираю все способы как сделать абоненту жизнь легче. У меня пока нет ни проблемы с абонентами - ничего. Это всего лишь стенд где я пытаюсь реализовать различные события, как и что сделать и использовать в дальнейшем. Я рассматриваю любые ситуации и меня интересует именно мнение профи.

 

приведу еще пример. есть технические линки где траф идет редко. сессию рвать нельзя. такое требование.

 

denis_vid

Idle-Timeout = 180 пока сделал для тестов. В общем оно работает.

У всех по такому сценарию разве все работает?

Нет, у меня сессии не "зависают"

[darkagent]

Вместо того чтобы разобраться ПОЧЕМУ пропадает достум, мы будем клирить сессии.

одно другому не мешает, даже наоборот - клиенты всякие бывают, а тут и клиент сам быстро исправит подвисание за счет передергивание линка (ребутом мыльницы к примеру), и можно будет мониторить сомнительные ситуации - отслеживать интенсивность link down event от отдельно взятых абонентов, и разбираться с причинами не дожидаясь гневных звонков.

[vurd]

Фиг знает. Лично у меня таймаут час по неактивности - проблем никаких. Но у меня эрики правда.

Ну и если действовать по моему варианту с ловлей трапов, то можно наткнуться на массу link down\link up в течении нескольких секунд, на сколько хорошо дергать брас из-за этого не понятно. Так что это не вариант.

Проблема ipoe в том, что вы никогда не можете узнать наверняка закончил ли клиент сеанс или нет, особенно если давать внешние адреса. В этом случае еще надо и абсолютный таймаут делать.

Что вообще такое "зависшая сессия"? По ней сами по себе перестали передаваться данные? Ну значит это системная ошибка конкретного вендора и вы полюбому ловите очень много обращений в саппорт.

 

Хочется еще высказаться по поводу анализа интенсивности link down и прочего мониторинга ошибок на портах и так далее. Я одно время пропагандировал идею о всеобъемлющем контроле и упреждении проблем у пользователей. Как показала практика, почти все абоненты, 95% из обзвонненных сказали "у нас нет никаких проблем, у нас всё хорошо". А такие темы как флап порта или CRC решить без захода в дом практически не реально. Вот и как понимать этот опыт?

[darkagent]

на сколько хорошо дергать брас из-за этого не понятно. Так что это не вариант.

никто не заставляет дергать брас на каждом флапе, тем более если помирает сетевуха или "кот погрыз шнурок" эти флапы будут тоннами. кидаем задачу в пул задач для coa, задаем для задачи ignore dublicate interval, и все что прилетает схожее втечение этого интервала просто игнорируем, но накручиваем отдельный счетчик для индикации проблемы.

Вот и как понимать этот опыт?

иногда всплывают такие случаи, когда наблюдаешь в рамках одного коммутатора флап сразу некоторого количества портов, и при детальном изучении делаешь предупредительные работы, вместо того чтоб ликвидировать аварию с массовым негодованием абонентов.

Из жизни:

- коммутатор залитый насквозь целиком и полностью голубиным говном (при том что находился в антивандальнике),

- коммутатор залитый дождевой/подвальной водой,

- коммутатор переживший потоп, но проржавевший в нулину,

- проженная оболочка кабелей в слаботочке/кабель-канале (вместе с кабель-каналом),

- кем-то дружелюбно намотанная фаза на пучок в слаботочке,

- происки конкурентов (ну этой теме тут и фотографии в свое время выкладывались),

и многое другое

[pppoetest]

коммутатор залитый насквозь целиком и полностью голубиным говном (при том что находился в антивандальнике),

По первости удивляло. КАК??? Можно настолько засрать девайс в ящике с не очень большими дырками.

Edited December 5, 2013 by pppoetest

[darkagent]

По первости удивляло. КАК??? Можно настолько засрать девайс в ящике с не очень большими дырками.

примерно в таких же условиях (на фото не наше, но у нас примерно такая же беда была):

http://i58.fastpic.ru/big/2013/1205/a7/af01c1bc12e2eb352c1a512c1d4e2da7.jpg