Sonne

Для инфинета достаточно одной ветки потому что - высокая цена, хорошее качество, прямая поддержка. Я сам строил сетку на Инфинете - 500 секторов, 3000 клиентов.

и Вам не кажется притоворечие между вашими умозаключениями применительно к контексту про мониторинг и управление CPE? Противоречие только в вашей голове, которая не понимает ничего в операторском бизнесе. Писать ничего не буду, даю задание найти свою ошибку. Я всегда стараюсь дать человеку шанс. То, что вы слышите, я уже понял. Ваш диапазон слуха ограничен видимо Черногорией. Куча инсталяций на том же опенмеш - это по вашему не успех? А ну да, его нет в ЧГ и в РФ, это не мерило успеха. Мерило успеха это сколько миллионов вы заработали на open-mesh? Если нисколько, то забудьте уже. Я скажу что директор европейского Ruckus перешел на работу в Камбуим. Я с ним недавно пил кофе. Так в чем там был успех, в том что директор от них сбежал? Дайте цифры динамики продаж Рукуса до и после внедрения меша. Сравним их, например, с UBNT. :) Разочарую вас - я вовсе не сисадмин. Извините, я слишком почтительно назвал вас сисадмином! Вы же спаммер обычный. То свой дурацкий wi-fi впаривали, теперь свой дурацкий никому не нужный мессенджер. Вы очень витиевато сознались в том что не понимаете обсуждаемого вопроса! Зачем вы лезете обсуждать то, в чем не понимаете? Зато угадали с биллингомя. Я сам пишу, точнее развиваю лет 20 как уже. Это дает мне очевидное конкурентое преимущество. Последний раз мы сэкономили 120 тысяч долларов написав свое. Не стыдно быть дилетантом среди программистов, потому что среди них есть люди разбогатевшие на десятки миллиардов долларов :) По мне так куда более стыдно прослыть успешным спаммером. Кстати, Убер - это тоже программисты. LOL - у нас нет бизнеса фай-фай! Это не бизнес, а косты! Нельзя вынести то, чего нет :))) Удивительно, но именно представитель опсосов рассказывал как им хочется использовать wi-fi: http://forum.nag.ru/forum/index.php?showtopic=114403 Мы не только не потеряем, а еще и заработаем на WiFi. Этот самый опсос и будет платить за качественный мониторинг Wi-Fi. У них так принято :) И вот тогда может появится бизнес wi-fi.

MobileOneWiFi Сколько миллионов вы заработали на open-mesh? Если нисколько, то не надо больше это вспоминать.

Оо. А когда я тут с регулярностью в год когда-то на этот факт указывал с предложением 'а почему бы не продать роутер оператору. Со встроенной системой мониторинга' - меня заклевывали. Я не клевал. Вопрос в том, что продать нельзя. Только если система будет бесплатной. Иначе гипотетические будущие косты на поддержку абонента будут замещены реальными сегодняшними костами на железо и софт. Именно поэтому Мобил идет в лес со своим OpenMesh. За деньги любой дурак может. Справедливости ради история учить, что по миру стоит миллиарды электрических розеток. И телефонных. Без всякой системы мониторинга на стороне абонента. И ничего - живет система. А миллиарды мобильных телефонов с ниибацо сложными системами мониторинга. Потому что радио! А вот, кстати, почему они не нравятся? Пусть устройство внутри себя все что угодно мониторит (как хочется). И в случае проблем - SNMP Trap шлет. Оно и через NAT пройдет из за того, что в другую сторону, и стандартное. А как раскопать snmpd и всунуть туда интеллект? А как управлять интеллектом snmpd если он за NAT? А как хипстеров заставить программировать SNMP? Короче придется все заново переписать.

А вот еще апдейт: Cambium Networks was created when Motorola Solutions sold the Canopy and Orthogon businesses in 2011. Cambium Networks has evolved the platform and expanded it to three product lines: Point to Point (PTP) (formerly Orthogon), Point to Multipoint (PMP) (formerly Canopy) and ePMP. Все ждал когда же увижу слово Камбиум :(

Не читал. Увы Он ее писал!

Короче почитал RFC-шки и выяснил следующее: 1. RESTCONF - прекрасная имплементация RESTFul протокола для создания систем управления сетевыми устройствами. Базируется на всей мощи NetCONF 2. NetCONF содержит такое понятие как ivent и stream, описанных в RFC5277. Если я вс правильно понял, то это как раз механизм отправлять с сервера (CPE) определенные уведомления, например о падении интерфейса. Однако же, никто не мешает отправлять хоть статистику интерфейса, хоть сигнал светофора - красный/желтый/зеленый. Приятно то, что подпиской управляет клиент (т.е. сервер мониторинга), а рассылку делает CPE. Если, допустим у нас падает половина сети, то вместо зависания половины SNMP опросников у нас будет просто в половину меньше уведомлений. 3. Ну и самое важное. Не дураки стандарт придумывали, поэтому заложили механизм пропуска NAT. Ведь сервер крутится на CPE, а оно может быть за NAT или получать динамические IP. Номера RFC пока нет: https://tools.ietf.org/html/draft-ietf-netconf-call-home-17 Приятно что модель велосипеда нового поколения в моей голове почти совпала с идеями завтрашнего дня самых крутых чуваков в сетях на свете. Можно пилить идеальный мониторинг своей мечты опираясь на современные стандартные шестеренки из титановых сплавов. wanderer_from хвалю за настойчивость и беру назад свои слова про отсутcтвие нормальной замены SNMP. Но с одним условием! Возможность использования NETCONF Event Notifications для отправки статистики пока что гипотеза. В RFC приводятся примеры отправки сообщений syslog или состояние порта Ethernet. Похоже больше на SNMP трапы.

я в статье шерсть раз написал - NetCONF Вот, например: https://sreeninet.wordpress.com/2014/06/28/netconf-and-yang/ Главный смысл NetCONF в возможности гранулированных операций - тразакций, отката и т.д. Так же используется достаточно развитая абстрактная модель, что делает возможным написание автоматизированных программ для конфигурации сети из действительно совместимых компонентов. А вот для мониторинга SNMP остается по-прежнему эффективным. Кто из присутствующих здесь использует SNMP для конфигурации, а не мониторинга? Если я не прав, дай какой нибудь вайтпейпер про статистику и монитринг с помощью NetCONF. Не нашел! Я для себя сделал простой вывод. Те стандарты, которые используют XML - они не годятся, слишком долго вымучивались. Академики любят XML, типа тех что создали OSI. Практики же используют JSON. Абсолютно глупый и бесмысленный критерий, но он почему то работает. И, чтобы два раза не вставать, люди которые делают NetCONF все понимают и ... делают RESTCONF: https://www.ietf.org/proceedings/88/slides/slides-88-netconf-3.pdf Вот RESTCONF это почти то что должно быть в гипотетическом новом протоколе. Только его еще не утвердили. Продолжают пока изобретать велосипед. Вот пример из презенташки RESTConf. 50% современных веб-разработчиков пример будет понятен без слов. Сравните с несколькими сотнями спецов на весь мир, которые понимают до конца как работает SNMP. А для TR-069 таких по-ходу вообще не нашлось. YANG Patch Example PATCH /restconf/config/example-jukebox:jukebox/ library/artist/Foo%20Fighters/album/Wasting%20Light HTTP/1.1 Host: example.com Accept: application/yang.patch-status+json Content-Type: application/yang.patch+json { "ietf-restconf:yang-patch" : { "patch-id" : "add-songs-patch", "edit" : [ { "edit-id" : 1, "operation" : "create", "target" : "/song", "value" : { "song" : { "name" : "Bridge Burning", "location" : "/media/bridge_burning.mp3", "format" : "MP3", "length" : 288 } } } ] } }

А где эта профильная тема?

По поводу размера страниц в веб-интерфейсе можно лишь сказать что это тренд. Печальная тенденция пожирания сетевой полосы: https://habrahabr.ru/post/278655/

Если вы не будете поддерживать своих клиентов, то вылетите с рынка. Если вас напрягает поддержка ваших клиентов, то вам просто не нужно работать в операторе связи или начинать такой бизнес. Изначально. Меш это узкая и малоинтересная тема. Нет смысла даже тратить время на его обсуждение. Я про эту лажу 10 лет слышу и ни одной истории успеха не знаю. Мы оператор связи. Сегодня 100% наших абонентов покупают wi-fi. Самый дешевый. В нашей местности это стоит 12-15 евро в закупке и 20-25 евро в розницу. Потом они ипут мозг техподдержке что у них плохо работает интернет из-за глюков wi-fi. Есть единственный способ решить эту проблему. Продавать роутеры заточенные на систему мониторинга. Поскольку у нас стандарт подключения Wireless Router c NAT и DHCP по историческим причинам, то SNMP и прочие ssh-и отпадают. Можно конечно прокидывать порт форвардинг, вбивать статикой IP, потом набивать вручную пачки настроек в центральном сервере SNMP мониторинга. Как прошлом веке, как в каменном веке. Будущее за интеллектуальными самоконфигурирующимися системами. Ну типа Интернета вещей, где вместо дурацких холодильников роль вещей будут исполнять вполне полезные роутеры. Доведите до ума хотя бы роутеры, потом уже можно браться за холодильники и кофеварки. А еще есть TR-069, который пока не взлетел. Нужно разобраться почему это происходит и либо допилить, либо сделать свое, новое и гениальное. Все идет к тому что wi-fi точек в мире будет столько же сколько линий доступа в интернет - это миллиарды. Кто то должен обслуживать и поддерживать эту систему по-новому. Мир уже готов к этому, но не готовы замшелые сисадмины типа вас.

К разработчикам новых продуктов есть две исчерпывающих претензии: 1. Зачем вы изобретаете велосипед? Ведь есть уже x,y,z! 2. Вы придумали какую то странную фигню, которую никто никогда не делал. Это никому не нужно. Этих двух претезий абсолютно достаточно чтобы гарантировано обосрать любую идею. MobileOneWiFi Я могу взять OpenMesh, поставить его на железку за 10$ Под каким нибудь OpenWRT и запустить бесплатно контроллер на своем сервере? Если нет - то пусть идут в жопу со своими wi-fi роутерами за 100 баксов. Что мониторить написано тут: https://habrahabr.ru/company/beeline/blog/244233/ Отличие в том, что TR-069 заточен на управление, а нужно сделать еще мониторинг. Вобще странно на форуме операторов встретить человека, который не поимает что такое техническая поддержка абонентов.

MobileOneWiFi И таки да, мераки испрльзует SNMP протокол: https://documentation.meraki.com/zGeneral_Administration/Monitoring_and_Reporting Т.е. мы обсуждаем будущее, а вы приводите примеры из прошлого.

Посмотрел Open Mesh, там есть интересные моменты. Проблема вот в чем- они никогда не продадут, не откроют и не сделают доступной для всех желающих свою систему. Это их know how. Если они сделают это, никто не станет покупать их железо по высоким ценам или кто то другой начнет продавать железки дешевле. И во всяком случае, пока не существует признаной замены стандарта snmp, поэтому в лучшем случае получается проприетарное решение. Хуже того, нет даже понимания чем плох snmp :)

MobileOneWiFi OpenMesh - это вобще не то. Очередная система хотспотов. У Мераки - есть система мониторингаи тоже хотспотов. Нигде ничего не увидел про принципиально новые протоколы и способы мониторинга. Например интеллект агентов. Может быть где то внутри у них есть нечто подобное, но какая разница если они это даже не продают? А если продают, то есть прекрасная бизнес-модель: сделать как cisco, только проще, дешевле и современее. Посмотрел доку мераки - у них есть дашборд со светофорами, молодцы! Я светофоры реализовал в одной из своих систем в 2005 году. ... Смысл вопроса - почему от ввода логин-пароля на WiFi (иногда даже - пришедшего по SMS. Вот счастье-то его оттуда в параметры соединения переносить) не избавились. Блин, ну избавились же! Вот обсуждение в соседней теме: http://forum.nag.ru/forum/index.php?showtopic=114403 Просто никто не в курсе.

По поводу систем мониторинга я размышлял вот тут: http://forum.nag.ru/forum/index.php?showtopic=109622 Вкраце иток обсуждений таков. Сисадмины не нимают зачем это нужно и почему нельзя использовать херню которую уже придумали 30 лет назад и она работает. Программисты вобще не понимают ч это и зачем, им категорически не интересном. В итоге я сейчас изучаю язык прораммирования Go специально, чтобы изобрести новый протокол мониторинга кучей распределенных объектов. Читал я с твоей подачи и про NetConf и про OpenFlow вывод очень простой: люди уже сели и изобрели OSI, но более простого TCP/IP который всех сделает пока не придумали. За время первого поста моего топика фирма Камбиум выпустила свою систему мониторинга, основанную на абсолютно тех же идеях. Пока не удалось пощупать изнутри. Я готов поучавствовать в разработке систем мониторинга на правах архитектора и разработчика. Только сделаю пару проетов для изучения языка программирования. Моя концепция - отказ от SNMP, взаимодействие только черз Http и прозрачно через NAT. активный агент переносится на CPE, сервер мониторинга собирает всю информацию в пассивном виде, но занимается ресурсоемкими вычислениями и анализом BigData. Пример приложения для операторов связи: 1. Трейсроут с агентов позволяет строить дерево маршрутизации сети и немедленно сигнализировать о любых проблемах в любой точке, которые видит КЛИЕНТ. 2. Измерение wi-fi сигналов подключенных клиентов, анализ трафика, хадержки и потерь в радио и создание светофора красный-желтый-зеленый... Клиент звонит с жалобой, а оператор уже знает качество его соединения. Бизнес клиенту звонит уже оператор, который узнает и сообщает о проблеме до тоо как клиент сам ееосознал. 3. Детектор аномального трафика на стороне клиента, когда агент сам присылает сообщение что обноружил у себя вирус. Что нужно для создания системы? Поддержка вендора - новый протокол мониторинга должен поддерживаться со стороны жестко ограниченных CPE.

На телевизионном канале ПРОеБИЗНЕС Извините, машинально!

Голосую за Ростелеком! Гуманитарный автор наконец то добился признания у въедливых технарей читателей! Ждем отзыв от Прохожего и Кипчатова. Ну эти двое точно в фейсбуке зависают.

Уже ответили Добавлю, что та же фигня бывает при ливнях с сильным ветром: капли воды задувает внутрь и плата выходит из строя. По гарантии умершие устройства не принимают. Я когда выбирал решение для пионер-нета увидел что плата Mikrotik SXT вобще не покрыта лаком и я отказался от использования Mikrotika в нашем климате. У нас бывают очень сильные дожди со шквалистым ветром. Я не знаю как устроена плата UBNT, потому что за 2 года не сломалось ни одного устройства, чтобы было что разобрать. Микротик мы оставили пионерам. Все пионеры у нас выживают за счет воровства интернет-каналов и близости к потребителя - когда он заходит в соседний дом и платят наличкой черный нал. Микротик не дает никакого преимущества в радио и вылезает исключительно только на дешивизне. Подумаешь, девайс умирает от ветра с дождем. Давайте сделаем контакты из пластика вместо меди и будем продавать еще на три копейки дешевле. Найдутся свои покупатели и на это.

Полное совпадение! В JSON выдается все то же самое что в SNMP GET/SET. Я писал шаблоны для Cacti, знаю о чем говорю. Глаз машинально зафиксировал все те же названия.

Короче надо все переделывать! 1. Разбить общий запрос/ответ на три разных объекта - обычные конфигурационные параметры, реалтаймовскую статистику базы и статистику клиентов. 2. На сервере разбить выдачу этих параметров на три независимых функции. 3. На клиенте анализировать какую страницу в данный момент смотрит пользователь и запрашивать только нужный раздел. 4. На клиенте тоже сделать три независимых функции обработки статистики. 5. Функцию обработки статистики сделать максимально легковестной. Выкинуть нафиг все фреймворки, только парсер JSON и AJAX обновление окон со статистикой. Начать с 1-2-3. По крайней мере сможем нормально жить при конфигурации. Кстати, интересно каким образом работает web сервер nginx? Я обратил внимание что время отклика при запросе css файла составляет почти 80-200 мс. Что там накрутили за nginx? Оригинальная openwrt luci json библиотека написана на lua для под nginx. Это работает чертовски быстро. Что там накрутили если не секрет - неужели php? Ну уж совершенно точно не C/C++!

Не согласен про кеширование! Каждые 5 секунд передается полная статистика по сути в текстовом формате - 8кб. Если на базе много абонентов то капает уже 100 кб при 60. Боюсь представить что там при 100 абонентах происходит. Про исполнение JS и постройку DOM - соглашусь. Очень сложная структура кода - невероятная глубина стека, навскидку несколько десятков уровней. При этом ужасно неэффективны код каждые 5 секунд нагружается огромным объем данных. Если честно, руки бы этим программистам оторвать бы!

там json со всей статистикой(~7Kb, максимум 10Kb) передается по умолчанию раз в 5сек. Итого должно быть 16кбит полезных(если усреднить за 5с), со всеми накладными l2/l3+tcp будет ну максимум 30кбит. Точно там ничего больше не происходит? ВОТ! Я понял! 8 кБайт передается на ваших тестовых конфигурациях. На живом секторе с кучей клиентов передаетсч 100 - СТО Килобайт, каждые 5 секунд!

Еще один фактор который влияет - поток трафика от веб клиента. Если запустить вебинтерфейс, то в мониторинге видно непрерывнй поток около 300 кбит. Это мягко говоря дофига. Что там передается в таком количестве? Так же тормозит пороц. На мониторинге видны долговременные всплески нагрузки процессора под 100 %. Хотя местный маркетолог нам говорит что это не страшно, на трафике не отражается (верю) и это чуть ли не хорошо! Вот в это я не верю, потому что гуй рендерит не святой дух а центральный процессор. Если он постоянно загружен на 100%, значит он может тормозить. Я никакой системы с загрузкой CPU не обнаружил.

С интересом перечитал топик с 2008 года. Нашел мой срач с jab-ом! С трудом уже вспомнил обстаятельства тех времен, но пикировки с джабом - как сегодняшние :) Ну кстати как из софта это настраивать я так и не нашел, но легко настраивается кнопкой сзади. На фотках SMT1000? Про кнопку не знал! Но у них спереди экран с управлением, в настройках конфигурации можно выбрать Power quality - Poor. Мы везде включаем на базовых станциях, тоже помогает при нестабильном напряжении.