[alibek]

Есть ASR с IOS-XE asr1001x-universalk9.16.09.08.SPA.

Мне нужно получить список активных сессий, способом, минимально нагружающем железо и сеть.

Сессии PPPoE, список сессий в идеале должен содержать Acct-Session-Id, но в крайнем случае сойдет и IP-адрес, или username вместе с идентификатором интерфейса. Как получить список с Acct-Session-Id я не знаю, если такого способа нет, то можно использовать sh ppp all, sh subscriber session или sh sss session. Это в том случае, если подключаться по ssh и отправлять команды.

Но может быть есть более "экономный" и быстрый способ, например подходящий SNMP-запрос?

Количество активных сессий будет порядка 5-10 тысяч, выполняться запрос будет не реже одного раза в час, или чаще, если запрос будет "нетяжелым".

[fractal]

если создать eem который записывает значение в custom oid и дергать его?

 

хотя, вроде как есть готовый https://content.cisco.com/chapter.sjs?uri=/searchable/chapter/content/en/us/td/docs/ios-xml/ios/bbdsl/configuration/xe-16-8/bba-xe-16-8-book/bba-mon-pppoe-snmp-xe.html.xml

[AN111]

SNMP
 Получить по SNMP все username из списка субскрайберов: .1.3.6.1.4.1.9.9.786.1.1.1.1.24

 индекс после oid - номер сессии в snmp ветке, результат - username

 

 Если кроме pppoe есть другие типы подключений и надо разделить username по типу:

 получить по SNMP список субскрайберов по типам: oid .1.3.6.1.4.1.9.9.786.1.1.1.1.1

  для pppoe - тип = 4,  индекс после oid - номер сессии в snmp ветке

 

.1.3.6.1.4.1.9.9.786.1.1.1.1.22 - nas-port и т.д.

 

см. CISCO-SUBSCRIBER-SESSION-MIB

https://oidref.com/1.3.6.1.4.1.9.9.786.1.1.1.1

 

 

 

[alibek]

У меня только PPPoE.

Спасибо, попробую делать опрос по SNMP.

[alibek]

Такой вопрос.

 

В ветке 1.3.6.1.4.1.9.9.786.1.1.1.1 много узлов, если через SNMP загружать все дерево, то такой запрос выполняется достаточно долго. Да и лишние данные по сети впустую гоняются.

Мне из всего дерева фактически нужны только подразделы 22, 25, 24, ну и может быть 6.

Поэтому я скриптом загружаю 1.3.6.1.4.1.9.9.786.1.1.1.1.22, 1.3.6.1.4.1.9.9.786.1.1.1.1.25 и т.д.

Здесь в результатах запроса индекс после OID — это номер сессии в ветки. Насколько я понял, это просто последовательное число (начиная со 100000). И пропусков в этой последовательности я не вижу — то есть если какая-то сессия завершается, то вся ветка перенумеруется.

Но в связи с этим вопрос — нет ли риска, что между запросами (например 1.3.6.1.4.1.9.9.786.1.1.1.1.22 и 1.3.6.1.4.1.9.9.786.1.1.1.1.25) какая-то сессия завершится, индексы перенумеруются и индексы в 1.3.6.1.4.1.9.9.786.1.1.1.1.22 и 1.3.6.1.4.1.9.9.786.1.1.1.1.25 окажутся разными?

Нет ли способа гарантировать, что индексы сессий в ветке не изменятся в течение нескольких последовательных запросов?

[AN111]

>Нет ли способа гарантировать, что индексы сессий в ветке не изменятся в течение нескольких последовательных запросов?

ХЗ, не задавался вопросом.
Я использую только username

[UglyAdmin]

Список активных сессий должен быть в биллинге, просто по определению.

Сессии же по РАДИУСу поднимаются, аккаунтинг по ним регулярно летит...

Не вижу смысла с железа их получать.

[alibek]

Согласен.

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

Я сейчас выясняю, почему так получилось и как это исправить, но пока выясняю, хочу сделать костыльный скрипт, который такие "потерянные" сессии будет сбрасывать.

[UglyAdmin]

Если по этим сессиям приходит аккаунтинг, то либо их поднять на биллинге, как потерянные, либо прибить на БРАСе по CoA.