Сброс сессии на SSG через CoA

[alibek]

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

 

Есть пользователи, которые подключаются по PPPoE, сессии терминируются на Ericsson SE и Cisco ASR.

Был скрипт на PHP (с модулем php-radius), который управлял некоторыми сессиями, для действий, который не умеет биллинг. В основном это сброс сессий и изменение скорости доступа.

В программном исполнении это был radius_create_request (с типом RADIUS_COA_REQUEST или RADIUS_DISCONNECT_REQUEST), формирование параметров запроса (radius_put_attr и radius_put_vendor_attr), отправка запроса, обработка результатов.

Все это работало на десктопном ПК уже несколько лет и внимания не требовало. PHP был старой версии (кажется 5.2), ОС еще старше.

 

Недавно пришлось обновить ОС, поставил Ubuntu 24. Из коробки там ставится PHP версии 8.2 или 8.3, если постараться, то можно поставить 7.4. Но проблема в том, что модуль PECL php-radius несовместим с PHP8. Вместо него нужно использовать библиотеку dapphp/radius (чистый PHP).

Скрипт адаптировал, в чем-то эта библиотека даже удобнее, чем php-radius. Но почему-то на Cisco не работает сброс сессий.

 

На Ericsson сессии сбрасываются. Для идентификации сессии указываю атрибуты Acct-Session-Id, Framed-IP-Address, RBN-Context_Name, User-Name, затем отправляю запрос с типом 40 (TYPE_DISCONNECT_REQUEST) и сессия разрывается. В логах все прозрачно:

Скрытый текст

2026-03-06 12:44:38 DEBUG: Added Attribute 26 (Vendor-Specific), format vsa, value 0x0000093004075050504f45
2026-03-06 12:44:38 DEBUG: Added Attribute 1 (User-Name), format T, value ***
2026-03-06 12:44:38 DEBUG: Added Attribute 8 (Framed-IP-Address), format A, value ***.***.***.***
2026-03-06 12:44:38 DEBUG: Added Attribute 49 (Acct-Terminate-Cause), format I, value 6
2026-03-06 12:44:38 DEBUG: Added Attribute 55 (Event-Timestamp), format I, value 1772801078
2026-03-06 12:44:38 DEBUG: Connect to 10.255.***.***:1700
2026-03-06 12:44:38 DEBUG: Packet type 40 (Disconnect-Request) sent to 10.255.***.***
2026-03-06 12:44:38 DEBUG: Attribute 26 (Vendor-Specific), length (11), format vsa, value 0x0000093004075050504f45
2026-03-06 12:44:38 DEBUG: Attribute 1 (User-Name), length (7), format T, value ***
2026-03-06 12:44:38 DEBUG: Attribute 8 (Framed-IP-Address), length (4), format A, value ***.***.***.***
2026-03-06 12:44:38 DEBUG: Attribute 49 (Acct-Terminate-Cause), length (4), format I, value 6
2026-03-06 12:44:38 DEBUG: Attribute 55 (Event-Timestamp), length (4), format I, value 1772801078
2026-03-06 12:44:38 DEBUG: Packet type 41 (Disconnect-ACK) received
2026-03-06 12:44:38 DEBUG: Attribute 101 (Error-Cause Attribute), length 4, format I, value 200
2026-03-06 12:44:38 DEBUG: Attribute 55 (Event-Timestamp), length 4, format I, value 1772801078

 

В принципе набор атрибутов избыточен, достаточно и одного только Acct-Session-Id или Framed-IP-Address.

 

А вот для Cisco этого недостаточно:

Скрытый текст

2026-03-06 12:47:58 DEBUG: Added Attribute 44 (Acct-Session-Id), format S, value 255/6/16/***
2026-03-06 12:47:58 DEBUG: Added Attribute 26 (Vendor-Specific), format vsa, value 0x0000093004075050504f45
2026-03-06 12:47:58 DEBUG: Added Attribute 1 (User-Name), format T, value ***
2026-03-06 12:47:58 DEBUG: Added Attribute 8 (Framed-IP-Address), format A, value ***.***.***.***
2026-03-06 12:47:58 DEBUG: Added Attribute 49 (Acct-Terminate-Cause), format I, value 6
2026-03-06 12:47:58 DEBUG: Added Attribute 55 (Event-Timestamp), format I, value 1772801278
2026-03-06 12:47:58 DEBUG: Connect to 10.255.***.***:1700
2026-03-06 12:47:58 DEBUG: Packet type 40 (Disconnect-Request) sent to 10.255.***.***
2026-03-06 12:47:58 DEBUG: Attribute 44 (Acct-Session-Id), length (21), format S, value 255/6/16/***
2026-03-06 12:47:58 DEBUG: Attribute 26 (Vendor-Specific), length (11), format vsa, value 0x0000093004075050504f45
2026-03-06 12:47:58 DEBUG: Attribute 1 (User-Name), length (8), format T, value ***
2026-03-06 12:47:58 DEBUG: Attribute 8 (Framed-IP-Address), length (4), format A, value ***.***.***.***
2026-03-06 12:47:58 DEBUG: Attribute 49 (Acct-Terminate-Cause), length (4), format I, value 6
2026-03-06 12:47:58 DEBUG: Attribute 55 (Event-Timestamp), length (4), format I, value 1772801278
2026-03-06 12:47:58 DEBUG: Packet type 42 (Disconnect-NAK) received
2026-03-06 12:47:58 DEBUG: Attribute 18 (Reply-Message), length 19, format T, value No Matching Session
2026-03-06 12:47:58 DEBUG: Attribute 101 (Error-Cause Attribute), length 4, format I, value 404

 

Запрос отклоняется (NAK), в ответе сообщает Reply-Message:No-Matching-Session и Error-Cause:Invalid-Request. Не могу понять, чего ему не хватает.

 

При этом если попробовать не сбросить сессию, а изменить ее таймаут, то переданных атрибутов достаточно для идентификации сессии:

Скрытый текст

2026-03-06 12:52:06 DEBUG: Added Attribute 44 (Acct-Session-Id), format S, value 255/6/16/***
2026-03-06 12:52:06 DEBUG: Added Attribute 26 (Vendor-Specific), format vsa, value 0x0000093004075050504f45
2026-03-06 12:52:06 DEBUG: Added Attribute 1 (User-Name), format T, value ***
2026-03-06 12:52:06 DEBUG: Added Attribute 8 (Framed-IP-Address), format A, value ***.***.***.***
2026-03-06 12:52:06 DEBUG: Added Attribute 27 (Session-Timeout), format I, value 100000
2026-03-06 12:52:06 DEBUG: Added Attribute 55 (Event-Timestamp), format I, value 1772801526
2026-03-06 12:52:06 DEBUG: Connect to 10.255.***.***:1700
2026-03-06 12:52:06 DEBUG: Packet type 43 (CoA-Request) sent to 10.255.***.***
2026-03-06 12:52:06 DEBUG: Attribute 44 (Acct-Session-Id), length (21), format S, value 255/6/16/***
2026-03-06 12:52:06 DEBUG: Attribute 26 (Vendor-Specific), length (11), format vsa, value 0x0000093004075050504f45
2026-03-06 12:52:06 DEBUG: Attribute 1 (User-Name), length (8), format T, value ***
2026-03-06 12:52:06 DEBUG: Attribute 8 (Framed-IP-Address), length (4), format A, value ***.***.***.***
2026-03-06 12:52:06 DEBUG: Attribute 27 (Session-Timeout), length (4), format I, value 100000
2026-03-06 12:52:06 DEBUG: Attribute 55 (Event-Timestamp), length (4), format I, value 1772801526
2026-03-06 12:52:06 DEBUG: Packet type 44 (CoA-ACK) received
2026-03-06 12:52:06 DEBUG: Attribute 26 (Vendor-Specific), length 19, format vsa, Vendor-Id: 9, Vendor-type: 250, Attribute-specific: S***.***.***.***
2026-03-06 12:52:06 DEBUG: Attribute 26 (Vendor-Specific), length 27, format vsa, Vendor-Id: 9, Vendor-type: 250, Attribute-specific: $IVirtual-Access2.623

 

Запрос выполняется успешно (ACK), причем тут достаточно одного только Acct-Session-Id или Framed-IP-Address.

 

Чего Cisco не хватает, чтобы сессию сбросить?

[alibek]

Логи Cisco ASR:

Скрытый текст

Mar  6 16:14:07: POD: 10.1.144.3 request queued
Mar  6 16:14:07:  ++++++ POD Attribute List ++++++
Mar  6 16:14:07: 7F1267ECC4A0 0 00000001 session-id(408) 4 2930282(2CB66A)
Mar  6 16:14:07: 7F1267ECA460 0 00000081 username(450) 8 ***
Mar  6 16:14:07: 7F1267ECA4A0 0 00000001 addr(8) 4 ***.***.***.***
Mar  6 16:14:07: 7F1267ECA4E0 0 00000001 nas-ip-address(600) 4 10.255.***.***
Mar  6 16:14:07: 7F1267ECA520 0 00000001 disc-cause(434) 4 admin-reset
Mar  6 16:14:07: 7F1267ECA560 0 00000001 Event-Timestamp(445) 4 1772802847(69AAD31F)
Mar  6 16:14:07: 7F1267EC9190 0 00000081 Message-Authenticator(274) 16 DE 20 D7 98 C1 EC 54 55 1A 9E 5C AB 3D 5B 3A 66 
Mar  6 16:14:07: 
Mar  6 16:14:07: POD: Received Acct-Session-Id of 255/6/16/402_002CB66A
Mar  6 16:14:07: POD: Converted to internal Session-Id of 002CB66A
Mar  6 16:14:07: POD: 10.1.144.3 Unsupported attribute type 26 for component
Mar  6 16:14:07: POD: 10.1.144.3 Unsupported attribute type 49 for component
Mar  6 16:14:07: POD: 10.1.144.3 Unsupported attribute type 55 for component
Mar  6 16:14:07: POD: 10.1.144.3 Unsupported attribute type 80 for component
Mar  6 16:14:07: POD: 10.1.144.3 user *** ***.***.***.***i sessid 0x2CB66A key 0x0 DROPPED
Mar  6 16:14:07: POD: Added Reply Message: No Matching Session
Mar  6 16:14:07: POD: Added NACK Error Cause: Invalid Request
Mar  6 16:14:07: POD: Sending NAK from port 1700 to 10.1.144.3/47197
RADIUS:  18  21  4E6F204D61746368696E672053657373696F6E
RADIUS:  101 6   00000194

 

 

[Andrei]

У меня для cisco asr сброс рррое-сессий реализован так:

#!/bin/sh
# Input args: Session ID, login, assigned IP, NAS IP
SNMPWALK=`which snmpwalk`
SNMPSET=`which snmpset`
COMMUNITY="ххххххххх"
NAS="$4"
USER_IP="$3"
LOGFILENAME="/var/log/billing/lbarcd_handler.log"

#date >> $LOGFILENAME

#echo "NAS - CISCO - ""$NAS" >> $LOGFILENAME
test -z "$USER_IP" && exit 1
INT_NUM=`$SNMPWALK -On -v 1 -c $COMMUNITY $NAS .1.3.6.1.2.1.4.24.4.1.5.$USER_IP.255.255.255.255.0.0.0.0.0 | awk '{print $4}'`
#echo "$*" >> $LOGFILENAME
test -z "$INT_NUM" && exit 1
$SNMPSET -v 1 -c $COMMUNITY $NAS .1.3.6.1.2.1.2.2.1.7.$INT_NUM i 2 >/dev/null 2>&1
echo "=== successfully ===" >> $LOGFILENAME
exit 0

 

[alibek]

Я раньше разные способы пробовал — и SNMP, и telnet/ssh, и CoA.

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

Поэтому хотелось бы понять, что не нравится циске в моем запросе.

 

Судя по отладочному выводу с ASR — переданных атрибутов недостаточно для идентификации сессии. Вроде как полный комплект включает в себя acct-session-id, nas-ip-address, framed-ip-address и acct-session-key. NAS-IP-Address я добавлял (не помогло), а что такое session-key я не понял.

В интернетах пишут, что возможно нужно изменить настройки aaa pod server.

Но непонятно, почему для CoA-запросов этого достаточно (запрос выполняется, и более того, в ответе даже возвращается IP-адрес и интерфейс найденной сессии), а для сброса сессии недостаточно.