Мониторинг подключений и портов

[iris1009]

Появилось желание автоматизировать процесс технической поддержки. Собственно нажатием одной кнопки нужно видеть состояние порта абонента - апнеап, и тп.

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

[pppoetest]

Взял за основу sw_toolz, так как не имел представления к чему стремится. И разумеется своё лучше.

[iris1009]

И как он себя показал?

[s.lobanov]

Если все тех. данные есть, позволяющие по адресу/номеру договора найти IP+порт свитча, то сделать скрипт получения статистики к биллингу/тех.учёту(где эти данные хранятся) это делов на день (если интерфейс модифицировать нельзя, то формочку наклепать за 5 минут можно). Вот если тех.данных нет и нет реальной картины кто куда подключены, то всё куда сложнее...

[iris1009]

Обнаружились такие проблемы:

При подключении /по статике/ и по pppoe. Данные кроссировок - кто с какого порта не всегда корректны. И по этому нужно вести какую- то историю связки mac - ip адрес и mac - логин . Далее как то узнать на каком порту какой mac был до того как случился инцидент.

[s.lobanov]

В общем и в целом, это гемор конечно. Статики у вас много? Скорее всего придётся актуализировать в полуручном режиме. PPPoE shared vlan можно актуализировать тремя способами:

1. mac notification + radauth/radacct-логи/выгрузки в БД - не все свитчи умеют

2. pppoe+(tr-101 pppoe-ia) + radauth/radacct-логи/выгрузки в БД - умеют почти все свитчи, но бывает, что pppoe+ тупит (т.е. это софтфича). пожалуй, самый простой способ, т.к. ВСЯ инфа будет в логах радиуса

3. сбор mac table + radauth/radacct-логи/выгрузки в БД - самый универсальный способ, но нужно "поймать" всех абонентов, т.е. собирать часто пока всех не разгребёте

[iris1009]

Статики конечно много, еще момент. На есть есть количество des1100-16, которые не умеют snmp

[s.lobanov]

Ну соберёте по вебу(curl/libcurl) или по телнету(expect), смотря что оно умеет

[iris1009]

s.lobanov помочь в реализации сможете?

[s.lobanov]

ответил в лс

[~AsmodeuS~]

Появилось желание автоматизировать процесс технической поддержки. Собственно нажатием одной кнопки нужно видеть состояние порта абонента - апнеап, и тп.

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

 

в ABillS есть такой мониторинг пусть поддержка многочисленного оборудования

[iris1009]

С ABillS тяжелее будет я думаю, это все-таки биллинг больше

[vlad11]

Лучше внедряйте Noc.Project.

[xcme]

Данные кроссировок - кто с какого порта не всегда корректны. И по этому нужно вести какую- то историю связки mac - ip адрес и mac - логин . Далее как то узнать на каком порту какой mac был до того как случился инцидент.

Это больше административная проблема и не стоит пытаться ее решить технически. Если где то ошибка - надо отправлять ответственного за участок чтобы разобрался и навел порядок. MAC-адреса, конечно, лучше логировать, но больше для истории и удобства, а не для того, чтобы абонентов по ним различать.

 

У нас техподдержка просто не смогла бы работать, если бы не было жесткой привязки абонента к порту. Так то они и ошибки смотрят и состояние кабеля и маки и тому подобные вещи. А абоненту-призраку как помочь?

[Negator]

Это больше административная проблема и не стоит пытаться ее решить технически.

А как ее по другому решить?

 

Мы вот отдаем адреса по opt_82. Когда вводили - бардака с перепутанными портами было масса.

Сейчас нет совсем. Потому что если у абонента неправильный порт - ничего не заработает вообще.

То же самое и с PPPoE.

[crank]

Negator

Если привязка идёт по opt82, то каким образом вы решили проблему, когда в порт первого абонента подключается второй, получает адрес первого и начинает спокойно работать?

[xcme]

А как ее по другому решить?

Инструкциями. Хочешь сделать изменение - звони бригадиру. Сделал изменение - звони бригадиру или админу. Новое подключение, замена коммутатора и т.п. вещи - все контролируется через офис. Потому и порядок.

Когда локалки мелкими были все друг друга знали и многие сети свои кабели даже не считали нужным маркировать - вся сеть и так в голове. Потом дошли до необходимости подписей, потом - до необходимости ведения БД.

 

А по поводу вопроса выше про опцию 82 тоже присоединюсь. :)

Edited February 17, 2016 by xcme

[~AsmodeuS~]

С ABillS тяжелее будет я думаю, это все-таки биллинг больше

 

но постоянно ведутся работы для улучшения управления хозяйством провайдера и качества обслуживания клиентов

[iris1009]

У меня задача больше для первой линии. Открыл оператор карточку клиента, нажал "Проверить подключение" - и в зависимости от результата дальнейшее общение с клиентом уже идет по тому или иному сценарию...

[Svyatoybog]

Для таких целей Вам нужно написать мониторинг вашего оборудования и хранить все данные в базе, мак клиента и на каком оборудование он зафиксирован, потом уже исходя из этих данных уже обращаются к оборудованию за которым клиент был зафиксирован и дальше вариантов много как вы спросите у свича что с клиентом (snmp, web, ssh, telnet). Ну а кнопочку прикрутить к карточке клиента это мелочи)). Ну и конечно с такой базой можно реализовать чтобы при звонке клиента в С/П ему уже отвечало что у него с интернетом

[roysbike]

Статики конечно много, еще момент. На есть есть количество des1100-16, которые не умеют snmp

почему? есть прошивка с cli+snmp и он отдает статус порта , через telnet можно забрать fdb, костыль но работает

Edited February 28, 2016 by roysbike