Pull to refresh

Comments 9

Ради такого дела даже зарегистрировался.
Планируете реализовать VMPS на базе MACMonitor?
В своё время была неплохая задумка у Swisscom, называлась FreeNAC, но сейчас она «умерла», а аналог пока не нашли.
У меня были идеи насчет смены vlan'ов портов сетевых устройств в зависимости от mac адреса подключенного конечного устройства, но дальше этого дело не шло, поскольку не было необходимости в этой функциональности. В настоящий момент в план разработки не входит реализация функционала на подобии VMPS (VLAN Management Policy Server). Но если такая функциональность будет интересна пользователям программы, то я готов к ним прислушаться.
Компания у нас очень большая и сетей очень много. VMPS удобен с точки зрения контроля подключения сетевых устройств ну и управления тем «КУДА» пользователь будет подключен.

Спасибо за ответ. Буду с удовольствием наблюдать за развитием вашего проекта.
Совет на будущее — добавить телеграм, делается это крайне просто, а удобство по сравнению с почтой выше.
Я смотрю свич в кунцевщине — какой-то макгайвер, апйтам к 7 годам стремится )))
Произвели, собрали, доставили, подключили к розетке и все.
Да. Аптайм реальный. Источники бесперебойного питания творят чудеса :-)

Не знаю зачем привязывать мониторинг сети к одним только свичам если есть уже куча готовых программных продуктов для мониторинга устройств в сети и куда больше: распознавание трафика на уровне L7, мониторинг SYN, FLOOD и других сетевых аномалий, которые уже давно доведены до идеала, например: ntopNG. Что умеет ваша разработка чего не умеет приведенный продукт? (Мож я чё не уловил)

Постараюсь объяснить на простых примерах.
Пример 1. На компьютере пользователя пропало сетевое подключение. Пользователь создает инцидент с описанием проблемы. Технический специалист вместо того, чтобы сразу идти к пользователю и смотреть на месте, заходит в программу и смотрит к какому коммутатору, порту коммутатора, патч-панели и сетевой розетке компьютер пользователя был подключен в последний раз, когда был доступен. Смотрит статус порта коммутатора. Далее смотрит одно ли пользовательское устройство наблюдать на этом порту коммутатора. Если не одно, значит есть промежуточный неуправляемый коммутатор. Специалист смотрит доступны ли ранее наблюдаемые устройства сейчас. Если недоступны: велика вероятность выхода из строя промежуточного коммутатора. На основании этой информации специалист принимает решение о дальнейших действиях и быстро решает проблему.
Добавлю, что раньше (до использования программы) на решение такой проблемы могло уйти и до часа времени, поскольку не известно, куда был подключен компьютер пользователя. Сейчас, используя программу, редко когда уходит больше чем 10 минут.

Пример 2. Утеря конечного устройства. Работал сотрудник и уволился. По какой-либо причине, информации о том, что его компьютер можно изъять, не дошла до соответствующих служб. Компьютер остался стоять в его кабинете. Проходит полгода и при инвентаризации выясняется, что отсутствует компьютер этого пользователя, но никто уже не помнит и не знает, где сидел этот пользователь и где был его кабинет. Зайдя в программу, можно вычислить сетевую розетку, куда был подключен компьютер. А по ней вычислить кабинет. В этом кабинете с большой вероятностью и будет стоять его компьютер.

Распознавание трафика на уровне L7, мониторинг SYN, FLOOD и других сетевых аномалий никак не помогут в вышеперечисленных примерах.
Sign up to leave a comment.