Перейти к содержимому
Калькуляторы

dnk.nbd

Пользователи
 Просмотреть профиль  Активность

  • Публикации

    77

  • Зарегистрирован

  • Посещение

 Тип публикации 

Сообщения, опубликованные пользователем dnk.nbd

  2. Опубликовано · Жалоба на ответ

    Реально виснет каждый божий день.

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

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

    Тоже повторяться не буду, один в один все те же проблемы. Вернул прошивку на изначальную. Комфортно с аппаратами работать невозможно, станция - астер.

  3. Опубликовано · Жалоба на ответ

    Вбито статически, в этом и проблема ) Опять МАС который был 00:1a:4d:ff:ba:74 теперь arp: 00:00:4d:ff:ba:74 attempts to modify permanent entry for для этого айпи.

    Так часто врядли пользователь винду меняет.

    Да, именно эта ситуация и была. Даже статика не помогала. Сейчас уже не помню с каким интервалом, но очень часто сетевая меняла адрес, при перезагрузке компьютера все норм, но через произвольный промежуток 5-30 минут ситуация повторяется. Помогло только замена сетевых плат у всех абонентов, кому попали сетевые с этой партии. Благо почти сразу обнаружили, много установить не успели. Всю партию вернули.

    Реально попробуйте как-то попасть к абоненту и от него уже посмотреть/проверить, т.к. конечно есть вероятность что что-то подцепили. И параллельно абонентский порт зазеркалить и послушать трафик.

    Либо просто дать сетевую абоненту и посмотреть вылечится или нет.

  4. Опубликовано · Жалоба на ответ

    Аналогично, исходя из опыта, когда у многих абонентов меняется самопроизвольно мак, была глючная сетевуха. Оказалась вся партия такая. Производитель был ASUS. Причем смена мака происходила не при перезагрузке, а на лету. Устранялось только заменой сетевки.

  5. Опубликовано · Жалоба на ответ

    Нет конечно, я имел ввиду что съем данных по SNMP не нагибает коммутаторы. А уж просмотр, заббикс например.

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

  6. Опубликовано · Жалоба на ответ

    3828, 3028, 3200 не загибаются. Норм молотят.

    Думаю 3528 тоже справится. Только с интервалом съема данных не наглейте.

    А АТ9000 действительно управление отваливается до ребута, а вот молотит норм.

  7. Опубликовано · Жалоба на ответ

    terrible правильно подсказал, дело не в ос. Точнее не совсем в ос. Послушайте трафик от клиента с вистой\семеркой и хр до сервера и сравните, что хочет виста и семерка чтобы не рвать соединение.

  11. Опубликовано · Жалоба на ответ

    Уже прошел месяц, оборудования так и нет.

    Кому либо что то доставили хоть?

    Прошло еще больше недели, вам пришло оборудование? На мое предложение приехать и посмотреть так и нет ответа тоже.

  12. Опубликовано · Изменено пользователем dnk.nbd · Жалоба на ответ

    Куплю б/у или новое по небольшой цене:

    DLink DES-3028 или DES-3200-28. Предпочтение серии 3200.

    Требуется пока 10 шт, но можно и по частям.

    Так же требуются DES-3200-10.

    Оплата безнал.

     

    С предложениями на почту kupimsw@gmail.com или в личку.

  14. Опубликовано · Жалоба на ответ

    2 конвертера. TX первого на RX второго и TX второго на RX первого, т.е. конвертеры образуют пару и только тогда будут работать. Для того чтобы реализовать схему выше, вам потребуется 5 пар. А топологию кольца, правильно выше сказали, организуют коммутаторами.

  16. Опубликовано · Изменено пользователем dnk.nbd · Жалоба на ответ

    Буквально в первую неделю эксплуатации неожиданно "завис", причем намертво даже не отвечал на консоль, помогла только перезагрузка. После переписки с поставщиком было решено обновить JunOS. После обновления был еще один случай такого же "unexpected behavior" и больше не повторялся. Проследить какой либо зависимости не удалось.

    Так же агрегируем каналы, но с DLink3627, работал нормально, но буквально недавно начались проблемы с обучением MAC адресам, отказывался вообще коммутировать трафик. При входе через консоль куча сообщений вида "...MRVL-L2:mrvl_fdb_mac_entry_uc_set(),910:Sending FDb MAC add to SFI failed(22) for VLANIdx=...". Перезапуск служб и самого коммутатора проблемы не решал. В итоге помогло только перезапуск коммутатора и после полной загрузки, передергиваем все патч-корды и после down/up порта сразу начиналась коммутация. Прослеживатся зависимость от настроек LACP, т.е. любое изменение конфигурации агрегированных интерфейсов, после commit, приводило к такому ступору коммутатора. На данный момент все интерфейсы агрегации разобраны, ждем новую прошивку.

  22. Опубликовано · Изменено пользователем dnk.nbd · Жалоба на ответ

    3200-28F эксплуатируем. Ставились на замену 3028. Пока полет нормальный в течении 3-х месяцев примерно.

    Используемый функционал 802.1q, Traffic Segmentation, ACL.

    Можно ли узнать причину замены 3028 ...?

    В сегментах появились непонятные разрывы связи, потери, причем спонтанные. Никогда не могли угадать когда они появятся. Диагностирование в течении долгого времени указывало явно на коммутатор, что только не пробывали сделать - непомогало. Заменили просто на другой, какой был под рукой. Все пришло в норму, ну а потом заменили на 3200-28Ф, заодно и от корзин избавились с медиками :) И далее во избежание заменили все.

    Трафик через коммутаторы большой.

  23. Опубликовано · Изменено пользователем dnk.nbd · Жалоба на ответ

    3200-28F эксплуатируем. Ставились на замену 3028. Пока полет нормальный в течении 3-х месяцев примерно.

    Используемый функционал 802.1q, Traffic Segmentation, ACL.