Перейти к содержимому
Калькуляторы

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

Коллеги, очередной вопрос о том как бороться с зависшими сесииями на 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

Изменено пользователем delphivcl

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Idle-Timeout = 1800

и

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Имхо - бред

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

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

Изменено пользователем delphivcl

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

vurd

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

 

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

 

denis_vid

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

vurd

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

 

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

 

denis_vid

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Из жизни:

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем pppoetest

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.