пром обновлен?

Кстати про ddm, раз уж тут есть человече, который им пользуется Я никогда не пользовался, посему хотелось бы уточнить, он нормально работает? глюков нет, или как обычно?) Подумал тут начать мониторить силы сигнала и подобные штуки, но боюсь упереться как обычно в какие-нибудь глюки

Хотя не, у меня он включен, но показания не снимает

что значит не снимает?

Пробовать сдавать по гарантии (очень сложно из-за логистики) или есть способы его пролечить?

пусто там. Предположительно из-за SFP-шек Не в заббикс, а так отлавливать на серваке и в случае понижения сигнала орать

ну так сами по себе орать из сервера не будут)) пусто там, это где?

2019 год! Ну зачем вам двухглазая SFP????

о, местных экспертов не спросили какие модули и где нам юзать) слишком абстракный вопрос, чтобы на него отвечать, зачем-затем, сори за грубость

о, местных экспертов не спросили какие модули и где нам юзать) слишком абстракный вопрос, чтобы на него отвечать, зачем-затем, сори за грубость

в show ddm ports status На большинстве железок не снимает ничего

Да и какая логистика у SFP... SFP это расходник, должна быть в ЗИПе...

ммм, вкратце, тётя из бухгалтерии отвязывает её из баланса, пьяный вася на хромой кобыле везёт её за 1000 верст в представительство, потом всё в обратную сторону. И если у вас не крутой корпорат на овер999 сотрудников, то всё это не очень радужно выглядит и особенно для собственной жопы

Поэтому расходник должен быть на месте и быть готовым к замене по приходу на объект!

Dir-300 можно узнать както пароль от роутера не скидая его к заводским?

Dir-300 можно узнать както пароль от роутера не скидая его к заводским?

99 проблем из 100 мы создаем сами себе

Ни уровня сигнала, ни инфе о модели модема Только производитель Но работают как надо! Интернет раздают через роутер :)

На той прошивке была ещё недоделана usb часть, щас уже должно быть лучше

Ни уровня сигнала, ни инфе о модели модема Только производитель Но работают как надо! Интернет раздают через роутер :)

Кстати про ddm, раз уж тут есть человече, который им пользуется Я никогда не пользовался, посему хотелось бы уточнить, он нормально работает? глюков нет, или как обычно?) Подумал тут начать мониторить силы сигнала и подобные штуки, но боюсь упереться как обычно в какие-нибудь глюки

давайте вкратце расскажу по ddm`ности.. в классике у каждой неDDM sfp есть свой "паспорт" - на разъем в сторону коммутатора просто стоит serialeeprom (мелкая последовательная флешка), в которой прописано что это за модуль, что умеет по скоростям, к какому классу относится, кто производитель итдтп.. тоесть, когда вы подключаете sfp к комуту вы заодно и подключаете 24c02 флешку, на шину i2c. Проц комута читает эту флешку и понимает "кого ему принесли". когда придумывали ddm исходили из простой посылки "а давайте вместо 24с02 воткнем какойнить микроконтроллер, который будет с модуля мониторить параметры в меру возможностей, а в сторону комутатора он будет прикидываться все тем-же 24c02". И тут возникает несколько потенциальных граблей. "прикидываться 24с02" могут не все, а кто может - делает это с разной степенью успешности. Борьба за рынок методом "уроним цену удешевив все что можно" приносит свои плоды и в деле sfpстроения - стараются ставить что подешевле. И тут немаловажно что sfp подключается к i2c шине - шина прямо в проц, если вдруг отвечающаю сторона начнет выдавать что-то с задержкой, или отвечать не то, или совсем не отвечать, то все это скажется на работе проца. из последних примеров - стоял себе DES_3200-28F/C1, кормил понемногу 20 клиентов и все было хорошо. добавили еще одного клиента, и стало все переодически плохо - раз в 3-4 дня комут уводил проц в полку, при этом никаких аномалий ни в трафике по сети, ни в трафике "интересном" процессору не наблюдалось, транзитный траффик все так-же коммутировался. Просто проц в 100% загрузке, интерфейс тормозит, на snmp отвечает через раз.. Заменили на другой экземпляр последнюю установленную sfpшку и все нормализовалось. А еще шило с прошивкой модуля - если в обычной sfp прошивку поменять несложно, то в ddmном нужно или какуюнить ногу подтягивать, или в какойнить регистр чтонить записывать для снятия RO или командами специальными кормить модуль.. А что в плюсе? как по мне-только возможность отслеживать деградацию оптики... Сомнительно, помоему... Если сварные нелохи и оптика не из дерьма то она очень не скоро деградирует (особенно на классических для провайдеров расстояниях). все остальные данные - или костанта, на которую невозможно повляить (ну зачем вам напряжение питания модуля? А темпреатура?) или стата с интерфейса. ТАк что плюсы ddm сомнительны, а гемора оно иногда добавляет. Имхо.

давайте вкратце расскажу по ddm`ности.. в классике у каждой неDDM sfp есть свой "паспорт" - на разъем в сторону коммутатора просто стоит serialeeprom (мелкая последовательная флешка), в которой прописано что это за модуль, что умеет по скоростям, к какому классу относится, кто производитель итдтп.. тоесть, когда вы подключаете sfp к комуту вы заодно и подключаете 24c02 флешку, на шину i2c. Проц комута читает эту флешку и понимает "кого ему принесли". когда придумывали ddm исходили из простой посылки "а давайте вместо 24с02 воткнем какойнить микроконтроллер, который будет с модуля мониторить параметры в меру возможностей, а в сторону комутатора он будет прикидываться все тем-же 24c02". И тут возникает несколько потенциальных граблей. "прикидываться 24с02" могут не все, а кто может - делает это с разной степенью успешности. Борьба за рынок методом "уроним цену удешевив все что можно" приносит свои плоды и в деле sfpстроения - стараются ставить что подешевле. И тут немаловажно что sfp подключается к i2c шине - шина прямо в проц, если вдруг отвечающаю сторона начнет выдавать что-то с задержкой, или отвечать не то, или совсем не отвечать, то все это скажется на работе проца. из последних примеров - стоял себе DES_3200-28F/C1, кормил понемногу 20 клиентов и все было хорошо. добавили еще одного клиента, и стало все переодически плохо - раз в 3-4 дня комут уводил проц в полку, при этом никаких аномалий ни в трафике по сети, ни в трафике "интересном" процессору не наблюдалось, транзитный траффик все так-же коммутировался. Просто проц в 100% загрузке, интерфейс тормозит, на snmp отвечает через раз.. Заменили на другой экземпляр последнюю установленную sfpшку и все нормализовалось. А еще шило с прошивкой модуля - если в обычной sfp прошивку поменять несложно, то в ddmном нужно или какуюнить ногу подтягивать, или в какойнить регистр чтонить записывать для снятия RO или командами специальными кормить модуль.. А что в плюсе? как по мне-только возможность отслеживать деградацию оптики... Сомнительно, помоему... Если сварные нелохи и оптика не из дерьма то она очень не скоро деградирует (особенно на классических для провайдеров расстояниях). все остальные данные - или костанта, на которую невозможно повляить (ну зачем вам напряжение питания модуля? А темпреатура?) или стата с интерфейса. ТАк что плюсы ddm сомнительны, а гемора оно иногда добавляет. Имхо.

давайте вкратце расскажу по ddm`ности.. в классике у каждой неDDM sfp есть свой "паспорт" - на разъем в сторону коммутатора просто стоит serialeeprom (мелкая последовательная флешка), в которой прописано что это за модуль, что умеет по скоростям, к какому классу относится, кто производитель итдтп.. тоесть, когда вы подключаете sfp к комуту вы заодно и подключаете 24c02 флешку, на шину i2c. Проц комута читает эту флешку и понимает "кого ему принесли". когда придумывали ddm исходили из простой посылки "а давайте вместо 24с02 воткнем какойнить микроконтроллер, который будет с модуля мониторить параметры в меру возможностей, а в сторону комутатора он будет прикидываться все тем-же 24c02". И тут возникает несколько потенциальных граблей. "прикидываться 24с02" могут не все, а кто может - делает это с разной степенью успешности. Борьба за рынок методом "уроним цену удешевив все что можно" приносит свои плоды и в деле sfpстроения - стараются ставить что подешевле. И тут немаловажно что sfp подключается к i2c шине - шина прямо в проц, если вдруг отвечающаю сторона начнет выдавать что-то с задержкой, или отвечать не то, или совсем не отвечать, то все это скажется на работе проца. из последних примеров - стоял себе DES_3200-28F/C1, кормил понемногу 20 клиентов и все было хорошо. добавили еще одного клиента, и стало все переодически плохо - раз в 3-4 дня комут уводил проц в полку, при этом никаких аномалий ни в трафике по сети, ни в трафике "интересном" процессору не наблюдалось, транзитный траффик все так-же коммутировался. Просто проц в 100% загрузке, интерфейс тормозит, на snmp отвечает через раз.. Заменили на другой экземпляр последнюю установленную sfpшку и все нормализовалось. А еще шило с прошивкой модуля - если в обычной sfp прошивку поменять несложно, то в ddmном нужно или какуюнить ногу подтягивать, или в какойнить регистр чтонить записывать для снятия RO или командами специальными кормить модуль.. А что в плюсе? как по мне-только возможность отслеживать деградацию оптики... Сомнительно, помоему... Если сварные нелохи и оптика не из дерьма то она очень не скоро деградирует (особенно на классических для провайдеров расстояниях). все остальные данные - или костанта, на которую невозможно повляить (ну зачем вам напряжение питания модуля? А темпреатура?) или стата с интерфейса. ТАк что плюсы ddm сомнительны, а гемора оно иногда добавляет. Имхо.

ребят кто последнюю ночншку ставил? wifi как рабтает?

у меня где то месяц назад по wifi вебинтерфейс пропадал

К релизу 4.0 на 825г1?)

да сдался вам этот релиз, чем ночнухи не устраивают, если работают?))