Согласен. ТД будучи правильно настроенной при минимуме трафика кушает мало. Я о предельных случаях. ТД в большом зале с кучей абонентов с быстрым трафиком. Согласно Циске туда нужно подтянуть 2 верёвки категории 7а, поставить комут с хорошим бюджетом и отдать на нём 2 порта в 1 точку. Или использовать их инжектора. Мой первый вопрос как инженера: нахуа так городить? Как манагера: вы оуели такую стоимость одной точки в проект закладывать? А при сборной солянке на комуте (2 ТД, 5 телефонов, 3 камеры) конечно гигабитный свич с бюджетом 200вт.

Я всегда завидую проектам где готовы покупать точки доступа с ценой >500 долларов

Я всегда завидую проектам где готовы покупать точки доступа с ценой >500 долларов

Не завидуйте. Если не компетентные проектировщики и манагеры закладывают в них дефолтные решения это слезы. Иногда с кровью.

Лол. Купить пачку AIR-AP4800-E-K9, понатыкать рандомно, а потом швырнуть в сетевиков - мол, чот тормозит, чините - это как за пивом выйти. А у меня от контроллера цисковского глаз дёргается =/ Веб морда глючит как мразь. Я бы на убиках всё собрал, но кто ж меня спросит)))

Лол. Купить пачку AIR-AP4800-E-K9, понатыкать рандомно, а потом швырнуть в сетевиков - мол, чот тормозит, чините - это как за пивом выйти. А у меня от контроллера цисковского глаз дёргается =/ Веб морда глючит как мразь. Я бы на убиках всё собрал, но кто ж меня спросит)))

Все так плохо? Кошек наблюдаю со стороны, дрессировать не приходилось. Видел как то их мануал по роумингу. Впечатлило. Хотя возможно гладко было на бумаге... 🤣🤣🤣

Кто ж знает, это разбираться надо, а я до него ещё не скоро доползу)

Лол. Купить пачку AIR-AP4800-E-K9, понатыкать рандомно, а потом швырнуть в сетевиков - мол, чот тормозит, чините - это как за пивом выйти. А у меня от контроллера цисковского глаз дёргается =/ Веб морда глючит как мразь. Я бы на убиках всё собрал, но кто ж меня спросит)))

Ну это уже проеб проектировщиков. И чаще всего проблема когда в принципе нет бюджета на wifi (вот вам пара дешевых роутеров, сделайте конфетку из говна и палок) Когда бюджет есть, как правило и подход грамотный

Ну это уже проеб проектировщиков. И чаще всего проблема когда в принципе нет бюджета на wifi (вот вам пара дешевых роутеров, сделайте конфетку из говна и палок) Когда бюджет есть, как правило и подход грамотный

Неееееее, не факт!!! Про любить можно все!!! Деньги вообще на раз!!! Нужны только тупые исполнители.

Добрый день коллеги. dlink des-3028, в каком формате передаются Circuit-ID и Remote-ID?

Добрый день коллеги. dlink des-3028, в каком формате передаются Circuit-ID и Remote-ID?

мне всю дорогу казалось что оно всегда шестнадцатеричка.. Или возможны варианты?

по идее - octet string но это не точно (рекомендую смотреть для каждой модели и КАЖДОЙ прошивке) бывает так, что в другой прошивке уже что то не так. смотреть несложно. если задаете такой вопрос, - значит разберетесь

мне всю дорогу казалось что оно всегда шестнадцатеричка.. Или возможны варианты?

Да вот смотрю акулой, прилетает в binare

Коллеги, есть DGS-1210-52P-ME с последней доступной прошивкой. Стоит далеко в RSTP кольце. Работает, гоняет через себя трафик - всё ОК. По какому-то странному стечению обстоятельств с неустановленной периодичностью он перестаёт отвечать на пинги, что регистрирует система мониторинга. Веб-морда соответсвенно тоже становится недоступна. В логах ничего, RSTP не рвётся, просто пропадают пинги. Чуть раздражает. У кого какие мысли есть на этот счёт?

тех, кто девайсы мониторят пингом до интерфейса надо закапывать кверху жопкою... Ладно-б пинговали что-то _за_ комутом.. но нет-же, интерфейс комута, который в принципе не обязан на icmp отвечать.. и уж совсем не обязан отвечать на них в высоком приоритете (максимально быстро).

всё, что до цпу поднимается анкновн уникаст, снупинги всякие да даже снмп может покарать, причём как pps, так и каким-нибудь заковыристым oid

но если пользовательский трафик при этом не деградирует, наверно можно не сильно переживать

а еще не обязан, ssh, telnet, web, snmp. траффик пропускать обязан.... иногда. а еще зависает при сохранении конфигруации (тоже не обязан)

попробуйте перепрошить его на той же прошивке. было предположение о деградации флэш. коммутаторы старые. вроде помогало.

Добрый день всем. Кто-нибудь имел дело с настройкой ZTE ZXR10-2928E?

а еще не обязан, ssh, telnet, web, snmp. траффик пропускать обязан.... иногда. а еще зависает при сохранении конфигруации (тоже не обязан)

а что, клиент жалуется на недоступность телнета или чего-то еще?

тех, кто девайсы мониторят пингом до интерфейса надо закапывать кверху жопкою... Ладно-б пинговали что-то _за_ комутом.. но нет-же, интерфейс комута, который в принципе не обязан на icmp отвечать.. и уж совсем не обязан отвечать на них в высоком приоритете (максимально быстро).

Спасибо за столь радушные пожелания к погребению... За коммутом только устройства с динамической адресацией и это не самое удобное что можно придумать. Не обязан, вопросов нет, пусть не отвечает быстро, пусть ответит медленно... ну хоть раз в минутку... ну хоть чуть... а то получается, он коммутирует, а управлять им нельзя.... и когда нагрузки ноль, и всё же неплохо бы и ответить - он не отвечает.

но если пользовательский трафик при этом не деградирует, наверно можно не сильно переживать

я ж не переживаю, говорю что чуть раздражает

попробуйте перепрошить его на той же прошивке. было предположение о деградации флэш. коммутаторы старые. вроде помогало.

Там два образа, я перешивал тот, что был младше и переключал на него. На предыдущей версии и другом образе были те же проблемы

клиент жалуется на недоступность в т.ч. WEB. причем она не связана с нагрузкой CPU и прочее. коммутатор перестает отвечать по любому протоколу и навсегда до перегрзки

тех, кто девайсы мониторят пингом до интерфейса надо закапывать кверху жопкою... Ладно-б пинговали что-то _за_ комутом.. но нет-же, интерфейс комута, который в принципе не обязан на icmp отвечать.. и уж совсем не обязан отвечать на них в высоком приоритете (максимально быстро).

и да, у меня в сети таких железок 20-30 штук наверное... все пингуются по адресу интерфейса, а косячит только одна...

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

да и это не вопрос дискуссии. Есть в описании возможность - значит она должна быть. обсуждать тут нечего

Спасибо за столь радушные пожелания к погребению... За коммутом только устройства с динамической адресацией и это не самое удобное что можно придумать. Не обязан, вопросов нет, пусть не отвечает быстро, пусть ответит медленно... ну хоть раз в минутку... ну хоть чуть... а то получается, он коммутирует, а управлять им нельзя.... и когда нагрузки ноль, и всё же неплохо бы и ответить - он не отвечает.

Радуйся, даже после смерти ты будешь приносить пользу обществу - можно будет велосипеды парковать. Неправильный метод, неправильная реализация, зачем вообще делать такой "мониторинх"?

Радуйся, даже после смерти ты будешь приносить пользу обществу - можно будет велосипеды парковать. Неправильный метод, неправильная реализация, зачем вообще делать такой "мониторинх"?

я к сожалению не знаю какие ещё есть более простые и не нагруженные методы определения доступности сетевого устройства. Есть эхо запрос. Отправил пакет, устройтво ответило - оно в сети и живо. Не ответило - не живо.

Радуйся, даже после смерти ты будешь приносить пользу обществу - можно будет велосипеды парковать. Неправильный метод, неправильная реализация, зачем вообще делать такой "мониторинх"?

Тем не менее у Zabbix во всех шаблонах по умолчанию (не только для D-Link) сделано именно так.

Добавлю еще свои 5 копеек - а почему бы не использовать ICMP как дополнительный канал мониторинга? Например, после масштабной проблемы в сети автоматически пропингать 1-2 тысячи свичей, кто не ответил - с ними уже разбираться дальше

я к сожалению не знаю какие ещё есть более простые и не нагруженные методы определения доступности сетевого устройства. Есть эхо запрос. Отправил пакет, устройтво ответило - оно в сети и живо. Не ответило - не живо.

Ну в теории можно обойтись и «No SNMP data collection» (у которого, кстати, по умолчанию зависимость на пинг).

Добавлю еще свои 5 копеек - а почему бы не использовать ICMP как дополнительный канал мониторинга? Например, после масштабной проблемы в сети автоматически пропингать 1-2 тысячи свичей, кто не ответил - с ними уже разбираться дальше

Обычно пингуется всё постоянно... и при правильно настроенных триггерах можно быстро заметить косвенные проблемы: Чуть деграднул канал в регион, всё работало, пользователи не заметили проблем, но по всем железкам выросли задержки и сработали пару триггеров, канал переключили руками.

Ну в теории можно обойтись и «No SNMP data collection» (у которого, кстати, по умолчанию зависимость на пинг).

Да там по дефолту зависимости, да и задержки до некоторых девайсов нужны

Мы немного не так делаем. У нас постоянно мониторится Observium-ом, но там задержка большая между проблемой и отображением. А массовые проблемы на сети - это когда авария у энергетиков,и погасло пол- района. И хорошо, если просто погасло, а не скакнуло сначала на 2 фазы. Вот тогда пингаем и смотрим, кого надо ребутнуть по питанию, а кого и заменить.

C:\Users\J0kER>tracert www.google.com Трассировка маршрута к www.google.com [2607:f8b0:4023:100b::93] с максимальным числом прыжков 30: 1 2 ms <1 мс <1 мс 2001:470:1f0b:d95::1 2 124 ms 93 ms 93 ms tunnel936643.tunnel.tserv6.fra1.ipv6.he.net [2001:470:1f0a:d92::1] 3 * 91 ms 90 ms ve118.core2.fra1.he.net [2001:470:0:69::1] 4 * * * Превышен интервал ожидания для запроса. 5 125 ms 205 ms 124 ms ipv6.de-cix.fra.de.as15169.google.com [2001:7f8::3b41:0:1] 6 128 ms 248 ms 124 ms 2001:4860:0:1::3b8b 7 * * * Превышен интервал ожидания для запроса. 8 114 ms 117 ms 206 ms 2001:4860::c:4003:364e 9 103 ms 102 ms * 2001:4860::8:4000:d325 10 277 ms 175 ms 175 ms 2001:4860::c:4002:aa4e 11 240 ms 190 ms 190 ms 2001:4860::c:4002:1224 12 215 ms 215 ms 308 ms 2001:4860::8:4000:ca1a 13 202 ms 350 ms * 2001:4860::c:4001:e559 14 211 ms 205 ms 204 ms 2001:4860::c:4003:79ca 15 * * * Превышен интервал ожидания для запроса. 16 * * * Превышен интервал ожидания для запроса. 17 * * * Превышен интервал ожидания для запроса. 18 * * * Превышен интервал ожидания для запроса. 19 645 ms 316 ms 205 ms lcdfwe-in-f147.1e100.net [2607:f8b0:4023:100b::93] Трассировка завершена. C:\Users\J0kER>

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

понять бы теперь, как связаны трассировки в "мир" и необходимость мониторинга сетевого железа

и это не какойнить там, это хурикейн и гугл, ъ..

понять бы теперь, как связаны трассировки в "мир" и необходимость мониторинга сетевого железа

ощень просто, на icmp никто отвечать не обязан.

ответы на icmp в приоритете идут бэкграндом. есть процессорное время - ответим. нет - нет.

но вы продолжайте пинговать.

именно за этим и пингуем, чтобы обнаружить, что с процессорным временем какая-то чепушня

до того, как это начнёт влиять на сервис)

ответы на icmp в приоритете идут бэкграндом. есть процессорное время - ответим. нет - нет.

в случае traceroute там скорее какой-нибудь rate limit на ответы кому попало

как процессорное время влияет на продвижение в пределах коммутационной матрицы?

и ключевая разница в вашем примере, и в задаче по мониторингу: в вашем случае icmp - это датаплейн (для всех пакетов, кроме TTL <=1), и сеть за пределами вашего контроля в противовес контрол плейну и сети под собственным контролем

в случае traceroute там скорее какой-нибудь rate limit на ответы кому попало

а мошт освежить как трасерт рабоает? обычный сраный icmp м подрезанным ttl\

или udp) нечего тут линуксы ущемлять)

ну там куча вариантов, в том числе и tcptraceroute есть, но в любом случае сплошь и рядом либо сами такие пакеты, либо ответы на них часто фильтруются по разным причинам

но опять-таки есть существенная разница между ping/traceroute неизвестного узла с публичным адресом (куда какое только говнище неизвестного происхождения не прилетает), и запросами на интерфейс управления коммутатора (где в нормальной ситуации никакого мусорного трафика быть не должно)

ну и да, вы же теперь большие дяди? комки датацентр-класса, тридент 3 все дела ну и вот, нечего к iсmp пренебрежительно относиться, без него дебажить фабрики грустно очень

https://www.youtube.com/watch?v=GplrogPlxQg

ощень просто, на icmp никто отвечать не обязан.

потише-потише :) мои свичи в моей сети на мой ICMP мне отвечать обязаны. Даже больше скажу - они так и делают. Никаких нареканий к ICMP мониторингу на последние 10 лет не было

и если коммутатор не нашёл свободного процессорного времени, чтобы ответить на ICMP из сети управления, возникает вопрос, а чем же он таким занят, и что ещё из того, что должно обрабатываться процессором, он успел потерять

а мошт освежить как трасерт рабоает? обычный сраный icmp м подрезанным ttl\

в линуксе - нет :) чтобы линуксовый traceroute работал по ICMP - его надо специально попросить.

в линуксе - нет :) чтобы линуксовый traceroute работал по ICMP - его надо специально попросить.

а где-то видно что я с линукса трасерил?

а где-то видно что я с линукса трасерил?

пример некорректный просто. мы и ICMP не ping'ом отправляем, если что

Пинг не панацея, но как триггер что что-то не так в сети оправдывает себя уже много лет ... оборвало оптику, флуд в сегменте, нарушение маршрутизации и тому подобное влияет на него и уже дальше начинаешь выяснять ... а что касается DGS-1210-28/ME, если он перестает отвечать на пинг, но при этом у клиентов всё работает, то всё равно в ближайшее время его надо будет перезагружать. Со временем (в течении часа или дня) у всех клиентов на железке начнутся проблемы.

Господа! Вы просто теряете акценты и вам пудрят мозги. 1 На счет плохой или хороший мониторинг - еще раз внимательно - КОММУТАТОР перестает отвечать на ЛЮБЫЕ запросы. Акцентируйте пожалуйста на этом. не на пинге. В какой то момент времени он перестает отвечать на ping,web, snmp, ssh, telnet. Точка 2 Вопрос ping или не ping - это пусть каждый для себя решает. Здесь - в спецификации указаны функции и возможности. Есть ping, Значит должен быть. Без дискуссий, правильно это или нет. Не уходите в сторону о правильности или правомерности. Ваш выбор - это ваш выбор.

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

Аргументация связана с тем, что на пинг отвечает "процессор". А коммутируют чипы Но в общем я с вами согласен

Вот кстати интересно, если есть возможность у задавшего вопрос подцепиться к коммутатору по консоли, посмотреть cpu. или он и на консоли не ответит? А если будет загрузка 100% погасить WEB - упадет нагрузка? появится пинг без перегрузки? интересно на чем там сделан httpd

95% что по консоли он доступен

А вот использовать веб - это сразу мимо. Это зло надо отключать

там все будет видно )

Как я понял речь про /me версию. У него максимальная консоль

нуууууу в общем да. но иногда бывает, так чтобы быстро.... и так харит...

Консоль всмысле cli

Как я понял речь про /me версию. У него максимальная консоль

в тот момент когда когда DGS-1210-28/ME перестает отвечать на пинг, не работает web, при подключении по консоли просто черный экран. Тоже ноль реакции. Но трафик может гонять. Свитч за ним может доступен и пингами и по web и у клиентов проблем не будет.

в тот момент когда когда DGS-1210-28/ME перестает отвечать на пинг, не работает web, при подключении по консоли просто черный экран. Тоже ноль реакции. Но трафик может гонять. Свитч за ним может доступен и пингами и по web и у клиентов проблем не будет.

Софт последний?

значит это не CPU! )))

единственно что остается - корежит память на которой все работает. от времени, от температуры ....

Да значит это оболочка крашится скорее всего Я такое у allied telesis ловил))

Софт последний?

https://dlink.ru/ru/products/1/2046.html с переодичностью проверю страничку ))

https://dlink.ru/ru/products/1/2046.html с переодичностью проверю страничку ))

Тут лучше писать в саппорт, софт далеко не сразу выкладывают

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

Свичи разные или конкретный?

DGS-1210-28/ME только с этой моделью, но не на одном

В саппорт. Без него вы вряд-ли решите эту проблему