BiTel

Есть два типа сервиса для одного и того-же устройства.
На первом галочками отмечены "Устройство" и "Идентификатор"
На втором: "Интерфейс", "VLAN", "Устройство", "MAC-адрес", "Идентификатор"

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

На устройстве добавил один порт, указал его в сервисе на новом договоре. Ну еще vlan.resource.category указал.
И номер/название порта и вланы взяты были с потолка, т.е. не соответствовали действительности.

В итоге у сервисов, которые работали до добавления интерфейсов на устройстве, перестали создаваться сессии. Пару дней просто тишина.
А у "нового" сервиса, сессии были. Т.е. у сервисов с типом где галка "Интерфейс" не стояла - сессии пропали.

Пока не удалил этот единственный интерфейс с устройства, сессии не появлялись.

Если у вас стоит инициализация сессии по сигналу, то сессия не должна создаваться пока access не найдет сервис. Если это dhcp, то поиск происходит по пришедшей option82. А так как у вас интерфейс фейковый, access не может найти сервис по номеру порта и accounting не поднимает сессию.

В данном случае сессия по трафику. А вопрос в том, что в первом типе сервиса не указана необходимость интерфейса, поэтому access и не должен по идее искать сервисы по интерфейсу.

Как указана привязка netflow? flow.agent.link={@deviceId}:-1 или не указано?
Кто является источником - тоже самое устройство?
Если указано источником является тоже самое устройство, к которому привязан сервис и на нем указан интерфейс, то Accounting начинает дополнительно фильтровать по номеру интерфейса. Если так - похоже номер интерфейса не совпадает с номером, который приходит в netflow; фильтрование должно пропасть, если прописать flow.agent.link={@deviceId}:-1, или можно прописать ifIndex на самом устройстве для каждого интерфейса.

Это же устройство и есть источник.


А параметры типа сервиса ничего не значат при этом? То есть одно устройство - один тип?


Номер интерфейса вообще не мог ни с чем совпасть, я его "от балды" ввел. Но тем не менее, сессия на новом сервисе создавалась.

Я правильно понимаю - если я хочу чтобы на одном и том же устройстве были разные типы сервиса, то нужно создать фейковое устройство, указать в его конфиге flow.agent.link={@deviceId}:-1 и тип сервиса с интерфейсами привязать к нему?

Не совсем. Просто если устройство - само источник и на нем заведены интерфейсы и один из интерфейсов прописан на сервисе, то Inet считает что именно этот интерфейс подключен к абоненту, т.е. netflow должен идти именно с этим интерфейсом.
Таким образом можно, например, обсчитывать по SNMP вместо Netflow или просто давать серые, пересекающиеся сети на разные интерфейсы.
Если же вам не нужна такая фильтрация, попробуйте указать flow.agent.link={@deviceId}:-1 (не создавая отдельное устройство) - таким образом все сервисы при обработке Netflow будут привязаны к виртуальному интерфейсу -1 (ANY), что должно исключить фильтрацию сервиса по его интерфейсу.

Т.е. например у меня устройство с id=9, я в его-же конфигурации указываю flow.agent.link=9:-1 и далее использую интерфейсы как хочу? Т.е. Inet даст мне в сервисе выбирать интерфейсы, но сам их использовать при обработки нетфлоу не будет?

Да. Можно указать в типе устройства flow.agent.link={@deviceId}:-1 - это будет означать тоже самое, что в каждом устройстве данного типа прописать flow.agent.link=<id устройства>:-1.

типе устройства... устройстве данного типа...

Т.е. либо так:


либо так:

Да. Просто, чтобы не писать практически одно и то же в каждом устройстве, если их несколько (gw11, gw12, gw13...).