BiTel

Форум BiTel
bgbilling.ru     docs.bitel.ru     wiki.bitel.ru     dbinfo.bitel.ru     bgcrm.ru     billing.bitel.ru     bitel.ru    
Текущее время: 16 июн 2024, 15:36

Часовой пояс: UTC + 5 часов [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 4 ] 
Автор Сообщение
 Заголовок сообщения: realm & check.duplicate
СообщениеДобавлено: 16 ноя 2016, 20:50 
Не в сети

Зарегистрирован: 27 сен 2016, 13:48
Сообщения: 71
Карма: 0
Привет.
В какой-то степени в продолжение темы https://forum.bitel.ru/viewtopic.php?f=44&t=12085, но все же проблема теперь в другом, поэтому создал новое обсуждение.

После того, как мы стали использовать разные realm-ы, распределяя таким образом абонентов по разным пулам адресов, возникла проблема дублирующихся сессий. Хотя в договоре, и в типе сервиса стоит лимит в одну сессию, а в настройках головного устройства указано radius.connection.checkDuplicate=5, все равно мы получаем порой по две сессии от одного и того же абонента, с идентичным mac-адресом. Первоначально проблема носила более массовый характер, но мы сверили тайм-зоны на наших серверах, и после их корректировки проблема приобрела единичный характер, но не исчезла совсем.

Собственно говоря вопрос - в чем это может быть связано? Может это как то быть связано с параметрами разрыва соединения после "молчания радиус-пакетов":

radius.realm.default.attributes=Idle-Timeout=120;
connection.suspend.timeout=900
connection.close.timeout=905
connection.finish.timeout=5

И кстати говоря, есть ли некий best practice по этим параметрам?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: realm & check.duplicate
СообщениеДобавлено: 17 ноя 2016, 14:38 
Не в сети

Зарегистрирован: 27 сен 2016, 13:48
Сообщения: 71
Карма: 0
Собственно, в продолжение наших наблюдений. Возможно, дубли были связаны элементарно с тем, что мы для разных реалмов не указали idle-timeout сессии. Сейчас он указан - пока наблюдаем. Однако, возникла другая проблема. Если клиент подключен не в дефолтном реалме, то его нельзя кикнуть из монитора, и у меня есть подозрение, что по той же причине не работает check.duplicate, хотя конечно, может быть я не прав. Но, вот что приходит на БРАС, если мы отключаем (обычное отключение, не зависшее) абонента:
Код:
Nov 17 08:24:01.236: RADIUS: POD  received from id 6 10.63.9.105:43893, POD Request, len 57
Nov 17 08:24:01.236: Getting session id for NONE(00000378) : db=7FFB3E43FB60
Nov 17 08:24:01.239: AAA/ACCT/NET(00000378): Pick method list 'PPPOE-CLIENTS'
Nov 17 08:24:01.239: AAA/ACCT/SETMLIST(00000378): Handle E6000009, mlist 7FFB3C490DF0, Name PPPOE-CLIENTS
Nov 17 08:24:01.239: AAA/ACCT/EVENT/(00000378): NET DOWN
Nov 17 08:24:01.239: AAA/ACCT/CLIENT(00000378): recv 1410065408bps xmit 1410065408bps
Nov 17 08:24:01.239: AAA/ACCT/HC(00000378): Update PPPoE/F4000378
Nov 17 08:24:01.239: AAA/ACCT/HC(00000378): no HC PPPoE/F4000378
Nov 17 08:24:01.239: AAA/ACCT/NET(00000378): Queueing record is STOP osr 1
Nov 17 08:24:01.239: AAA/ACCT(00000378): del node, session 845
Nov 17 08:24:01.239: AAA/ACCT/NET(00000378): free_rec, count 0
Nov 17 08:24:01.240: AAA/ACCT/EVENT/(00000378): NET DOWN
Nov 17 08:24:01.240: AAA/ACCT(00000378): Accounting method=BG-RADIUS-01 (RADIUS)
Nov 17 08:24:01.240: RADIUS/ENCODE(00000378):Orig. component type = PPPoE
Nov 17 08:24:01.240: RADIUS/ENCODE(00000378): Acct-session-id pre-pended with Nas Port = 0/0/0/3884
Nov 17 08:24:01.240: RADIUS: Format E value 0x34D for character U with bitmask 0xFFFFFFFF
Nov 17 08:24:01.240: RADIUS: Format E port 0x34D with bit 32 processed
Nov 17 08:24:01.240: RADIUS(00000378): Config NAS IP: 10.63.6.250
Nov 17 08:24:01.240: RADIUS(00000378): Config NAS IPv6: ::
Nov 17 08:24:01.240: RADIUS(00000378): Config NAS IP: 10.63.6.250
Nov 17 08:24:01.240: RADIUS(00000378): sending
Nov 17 08:24:01.240: AAA/ACCT/EVENT/(00000378): CALL STOP
Nov 17 08:24:01.240: AAA/ACCT(00000378) reccnt 0, osr 1
Nov 17 08:24:01.240: RADIUS(00000378): Send Accounting-Request to 10.63.9.105:1813 id 1646/11, len 426
Nov 17 08:24:01.240: RADIUS:  authenticator CB AB 8F D9 88 A4 C8 2C - 5C FD D4 77 2C 87 14 13
Nov 17 08:24:01.240: RADIUS:  Acct-Session-Id     [44]  29  "0/0/0/3884_51163FE20000034D"
Nov 17 08:24:01.240: RADIUS:  Framed-Protocol     [7]   6   PPP                       [1]
Nov 17 08:24:01.240: RADIUS:  Framed-IP-Address   [8]   6   77.245.214.251           
Nov 17 08:24:01.240: RADIUS:  Vendor, Cisco       [26]  53 
Nov 17 08:24:01.240: RADIUS:   Cisco AVpair       [1]   47  "ppp-disconnect-cause=Lower Layer disconnected"
Nov 17 08:24:01.240: RADIUS:  User-Name           [1]   8   "cisco3"
Nov 17 08:24:01.240: RADIUS:  Acct-Authentic      [45]  6   RADIUS                    [1]
Nov 17 08:24:01.240: RADIUS:  Vendor, Cisco       [26]  35 
Nov 17 08:24:01.240: RADIUS:   Cisco AVpair       [1]   29  "connect-progress=LAN Ses Up"
Nov 17 08:24:01.240: RADIUS:  Vendor, Cisco       [26]  31 
Nov 17 08:24:01.240: RADIUS:   Cisco AVpair       [1]   25  "nas-tx-speed=1410065408"
Nov 17 08:24:01.240: RADIUS:  Vendor, Cisco       [26]  31 
Nov 17 08:24:01.240: RADIUS:   Cisco AVpair       [1]   25  "nas-rx-speed=1410065408"
Nov 17 08:24:01.240: RADIUS:  Acct-Session-Time   [46]  6   16                       
Nov 17 08:24:01.241: RADIUS:  Acct-Input-Octets   [42]  6   4667                     
Nov 17 08:24:01.241: RADIUS:  Acct-Output-Octets  [43]  6   8067                     
Nov 17 08:24:01.241: RADIUS:  Acct-Input-Packets  [47]  6   43                       
Nov 17 08:24:01.241: RADIUS:  Acct-Output-Packets [48]  6   35                       
Nov 17 08:24:01.241: RADIUS:  Acct-Terminate-Cause[49]  6   admin-reset               [6]
Nov 17 08:24:01.241: RADIUS:  Vendor, Cisco       [26]  34 
Nov 17 08:24:01.241: RADIUS:   Cisco AVpair       [1]   28  "disc-cause-ext=Radius Disc"
Nov 17 08:24:01.241: RADIUS:  Acct-Status-Type    [40]  6   Stop                      [2]
Nov 17 08:24:01.241: RADIUS:  Calling-Station-Id  [31]  16  "00a0.d1a2.3423"
Nov 17 08:24:01.241: RADIUS:  NAS-Port-Type       [61]  6   PPPoEoVLAN                [33]
Nov 17 08:24:01.241: RADIUS:  NAS-Port            [5]   6   845                       
Nov 17 08:24:01.241: RADIUS:  NAS-Port-Id         [87]  12  "0/0/0/3884"
Nov 17 08:24:01.241: RADIUS:  Vendor, Cisco       [26]  41 
Nov 17 08:24:01.241: RADIUS:   Cisco AVpair       [1]   35  "client-mac-address=00a0.d1a2.3423"
Nov 17 08:24:01.241: RADIUS:  Service-Type        [6]   6   Framed                    [2]
Nov 17 08:24:01.241: RADIUS:  NAS-IP-Address      [4]   6   10.63.6.250               
Nov 17 08:24:01.241: RADIUS:  Event-Timestamp     [55]  6   1479371041               
Nov 17 08:24:01.241: RADIUS:  Nas-Identifier      [32]  20  "ASR-02.metromax.ru"
Nov 17 08:24:01.241: RADIUS:  Acct-Delay-Time     [41]  6   0                         
Nov 17 08:24:01.241: RADIUS(00000378): Sending a IPv4 Radius Packet
Nov 17 08:24:01.241: RADIUS(00000378): Started 5 sec timeout
Nov 17 08:24:01.244: RADIUS: Removing all radius source-int. pointing to Virtual-Access1.1
Nov 17 08:24:01.260: RADIUS: Received from id 1646/11 10.63.9.105:1813, Accounting-response, len 20
Nov 17 08:24:01.260: RADIUS:  authenticator 68 00 B5 88 17 EE E4 28 - 96 42 85 9C 76 7E B1 17
Nov 17 08:24:01.260: AAA/ACCT/NET(00000378): STOP protocol reply PASS
Nov 17 08:24:01.260: AAA/ACCT(00000378): Accounting response status = SUCCESS
Nov 17 08:24:01.260: AAA/ACCT(00000378): Send STOP accounting notification to EM successfully
ASR-02#
Nov 17 08:24:01.260: AAA/ACCT/NET(00000378): Cleaning up from Callback osr 0
Nov 17 08:24:01.260: AAA/ACCT/NET(00000378) Record not present
Nov 17 08:24:01.260: /AAA/ACCTNET(00000378) reccnt 0, csr TRUE, osr 0
Nov 17 08:24:01.260: AAA/ACCT/NET(00000378): Last rec in db, intf not enqueued


А вот это при реалмах:

Код:
Nov 17 08:24:55.710: RADIUS: POD  received from id 7 10.63.9.105:43893, POD Request, len 61
Nov 17 08:24:55.710: Getting session id for NONE(00000379) : db=7FFB3E425C98


В логах БГ-шки (в аккаунтинге), при условии задействованного не-default реалма, вообще нет намеков на то, что на БРАС отправляется что-то, кроме апдейтов о состоянии сессии. Т.е. ни STOP пакетов, ничего такого.

В чем может быть проблема?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: realm & check.duplicate
СообщениеДобавлено: 17 ноя 2016, 16:22 
Не в сети
Разработчик
Аватара пользователя

Зарегистрирован: 19 дек 2006, 21:04
Сообщения: 5970
Карма: 256
В мониторе соединений в поле Реалм - подмененный реалм?

В логах у вас начало совпадает - во втором случае просто больше ничего не пишет?

PoD/CoA пакеты отправляет InetAccess, т.е. смотреть нужно в его логах.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: realm & check.duplicate
СообщениеДобавлено: 17 ноя 2016, 17:45 
Не в сети

Зарегистрирован: 27 сен 2016, 13:48
Сообщения: 71
Карма: 0
Разобрались. Нужно было подменять realm в POD-пакетах. Сравнили вывод двух разных POD-ов и стало ясно в чем дело.

Код:
Nov 17 08:42:17.969: POD: 10.63.9.105 request queued
Nov 17 08:42:17.969:  ++++++ POD Attribute List ++++++
Nov 17 08:42:17.969: 7FFB33B30C30 0 00000081 username(450) 10 cisco3@smr
Nov 17 08:42:17.969: 7FFB33B31848 0 00000001 session-id(408) 4 847(34F)
Nov 17 08:42:17.969:
Nov 17 08:42:17.969: POD: Received Acct-Session-Id of 0/0/0/3881_51163FE20000034F
Nov 17 08:42:17.969: POD: Converted to internal Session-Id of 00000000000000000000000034F
Nov 17 08:42:17.969: POD: 10.63.9.105 user cisco3@smr 0.0.0.0i sessid 0x34F key 0x0
Nov 17 08:42:17.969: POD:      Line     User     IDB          Session Id Key

Nov 17 08:42:17.969: POD: Skip Virtual- cisco3   77.245.216.146 0x34F      0x0
Nov 17 08:42:17.969: POD: Added Reply Message: No Matching Session
Nov 17 08:42:17.969: POD: Added NACK Error Cause: Session Context Not Found
Nov 17 08:42:17.969: POD: Sending NAK from port 1700 to 10.63.9.105/55648
Nov 17 08:42:17.969: RADIUS:  18  21  4E6F204D61746368696E672053657373696F6E
Nov 17 08:42:17.969: RADIUS:  101 6   000001F7




Nov 17 08:44:37.640: POD: 10.63.9.105 request queued
Nov 17 08:44:37.640:  ++++++ POD Attribute List ++++++
Nov 17 08:44:37.640: 7FFB33B32460 0 00000081 username(450) 6 cisco3
Nov 17 08:44:37.640: 7FFB33B33C90 0 00000001 session-id(408) 4 848(350)
Nov 17 08:44:37.640:
Nov 17 08:44:37.640: POD: Received Acct-Session-Id of 0/0/0/3884_51163FE200000350
Nov 17 08:44:37.640: POD: Converted to internal Session-Id of 000000000000000000000000350
Nov 17 08:44:37.640: POD: 10.63.9.105 user cisco3 0.0.0.0i sessid 0x350 key 0x0
Nov 17 08:44:37.640: POD:      Line     User     IDB          Session Id Key

Nov 17 08:44:37.640: POD: KILL Virtual- cisco3   77.245.214.247 0x350      0x0
ASR-02#
Nov 17 08:44:37.640: POD: Sending ACK from port 1700 to 10.63.9.105/55648


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 4 ] 

Часовой пояс: UTC + 5 часов [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
POWERED_BY
Русская поддержка phpBB
[ Time : 0.112s | 26 Queries | GZIP : On ]