stesv

Вот обещанное ... test_switch.ini test_switch.log

Коммутатор включен ОДНИМ портом, с него и картинка. Дискарды и у меня вызывают недоумение, в общем яснее ситуация не стала, попрошу своих ребят логи и конфиг прислать ....

Приветствую. Анонсированная заливка оказалась "странной", а именно: 1. Взяли тестовый коммутатор, воткнули его в офисную сеть и залили предложенную заливку; 2. Начали смотреть счетчики и увидели, что показания пакетов ВСЕГО совпадают с показаниями за последние 5 сек. - смотри картинку; 3. ? Это нормально ?

Спасибо, попробуем. Еще одну наглядную картинку приведу - статистика из дампа на порту, где "чудит" RL. Видно, что исходно трафик НЕ большой, все нормально работает, а потом начинает RL блочить порт на 30 сек., снова его поднимать и снова блочить .....

Продолжу: 1. Тотальное отключение GVRP НЕ помогло, сработки RL на фоне "безумных" значений счетчиков продолжаются; 2. Не совсем понял переполнение какого буфера имеется ввиду, попробую пояснить свое видение: - сработка происходит по счетчику ВХОДЯЩИХ пакетов, т.е. уже ПРИНЯТЫХ коммутатором; - Значит речь идет о переполнении входного буфера. По какой причине ему переполнятся, если трафик хоста по дампу (а также по SNMP c самого коммутатора) минимальный; - Чтобы буфер переполнился, пакет в нем должен "застрять", не совсем понимаю какие причины могут к этому привести при НОРМАЛЬНОЙ работе коммутатора; - Если разобраться, что такое "дискарт" (а НЕ ошибка) на приеме, то это типа ПРАВИЛЬНО принятый пакет (на аппаратном уровне), но отброшенный коммутаторам по "разным причинам" (на программном уровне). Например это может быть блокировка на резервном каплинг-порту, т.е. это может быть НОРМАЛЬНОЕ событие. - Если ЯВНО врет счетчик ВСЕГО пакетов, то почему мы должны ВЕРИТЬ счетчику отброшенных пакетов ? - ? Или я что-то не понимаю ? 3. Мне кажется, что проблема все таки в ПО, создается впечатления, что НЕЧТО начинает писать в ЧУЖУЮ область памяти, искажает там значения счетчиков и далее происходит то, что происходит .....

Позволю себе несколько реплик: 1. Рассуждения вызывают определенные сомнения, т.к. счетчики показывают именно "безумные" цифры, т.е. количество пакетов, которого НЕ может быть ТЕОРЕТИЧЕСКИ (просто такое число пакетов НЕ "убирается" в скорость на порту) - посмотрите на ЧИСЛО пакетов, терабайты и гигабиты на интерфейсах; 2. Буфер переполнять НЕЧЕМ, т.к. НЕТ трафика для его переполнения, дампы, записываемые на РАЗНЫХ хостах/портах это показывают; 3.Возможно, что "аппаратные" счетчики ЕСТЬ и считают что-то правильно, однако информация через веб-морду и снмп выдается "странная", а значит она может и обрабатываться "странным" образом уже НЕ аппаратно, а на уровне ПО (думаю RL именно там работает); 4. GVRP сейчас отключили ВЕЗДЕ, ждем результатов; 5. По поводу версий ПО - если посмотреть более раннюю переписку, то проблема обнаружилась еще при смене более ранних версий. Сейчас у нас есть ТРИ одинаковых ПТК на разных объектах, работающих на ТРЕХ разных версиях ПО на моха коммутаторах. Обсуждаемая проблема КРИТИЧЕСКИ проявляется только на ОДНОМ объекте, где крутится самое новое ПО, на объекте с самым старым ПО описываемых проблем НЕТ.

1. Не понял реплику про правильное описание акцеса; 2. Последние картинки из ДРУГОГО ПТК с другими коммутаторами (510); 3. Отключение GVRP НЕ помогло, после УЖЕ снова произошла сработка, лог во вложении (смотри в нем последние сообщения). Другое дело, что GVRP отключен НЕ на всех коммутаторах ("боязно" их крутить при работающем оборудовании) и если счетчики плохо реагируют именно на пакеты этого протокола, то дозу "лекарства" надо делать "лошадиную" (на все коммутаторы). 4. А еще вероятно было бы неплохо перезагрузить коммутаторы после отключения GVRP..... moxa-vpu-2.log

Ок., отключим GVRP, по поводу "ошибок" в вланах - сильно сомневаюсь, при их наличии были бы проблемы с продуктивным трафиком. Кстати, пообщался с своими коллегами, обслуживающими ДРУГИЕ системы и оборудование, так вот там тоже обнаружилась проблема "безумных" счетчиков в моха-коммутаторах (смотри картинки из системы мониторинга во вложении), другое дело что при отключенном RL неприятностей это не создавало ....

Если поможет, но конфиг одного коммутатора со "странно работающим" RL во вложении .... moxa-vpu-1.ini

1. Если мне не изменяет память, то GVRP на мохах включен по умолчанию, посему его специально НЕ отключали. 2. Вланы прописаны статически.

Извините за назойливость, однако получу ли я какое либо разъяснение ситуации ? "Странная" работа RL создает нам реальные проблемы (во вложении картинка из системы мониторинга), который могут "до цугундера довести" ....

До кучи во вложении логи со следами сработки RL .... moxa-vpu-2_RL.LOG

Приветствую. 1. Если "врут" счетчики пакетов, то "нет веры" и счетчикам отброшенных пакетов. Поэтому мое объяснение - это "вранье" счетчиков ; 2.Картинки взяты с клиентских портов, куда включены хосты, на некоторых из которых мы пишем дампы (вайршарком), чтобы разобраться в ситуации. Так вот по дампам никаких "пропаж" пакетов не обнаруживается; 3. Более того, есть интересная особенность - "чудят" в основном счетчики на пассивных портах хостов, где в нормальной ситуации вообще НЕТ "уникаст" исходящего трафика, хост генерирует только тестирующие пакеты с типом "Intel ANS" (может быть моха НЕ любит именно такой тип пакетов). Типичная статистика загрузки портов во вложении (кстати на одной картинке четко видна сработка RL)

Приветствую. После долгого молчания хочу продолжить обсуждение "МОХА-глюков", начнем с RateLimityng (далее RL): 1. Во время останова оборудования обновили прошивки (Старая версия: 4.1, Текущая версия: 5.4) коммутаторов (например Модель: IKS-6728A Серийный номер: TAEKD1019357) и получили "чудеса" в работе счетчиков RL - смотри вложение (там есть просто "безумные" цифры); 2. Причем отображаются НЕ просто "странные" цифры, но и идут "сработки" со всеми вытекающими последствиями, хотя трафика на интерфейсах практически НЕТ (можно даже его дамп выслать); 3. ? Кто виноват и что делать ? Заранее спасибо .... ; 3. ? Что

Снова поспамлю: 1. По моему ограничение в 100 метров идет еще со времен 10 Мбит, а уж никак не от 1G и оно мне кажется не касается физического уп/дауна. Также хочется отметить, что на клиентских портах, где собственно и возможен уп/даун (вследствие засыпания ПК) Ваши протоколы не работают, а циска свой порт сама и НЕ опускает никогда; 2. Первоначально мы эффект поймали, где вообще были одни только Мохи. Циска появилась только в стенде и только потому, что офисная сеть на них работает из которой надо наблюдать за экспериментом; 3. Предлагаю такую схему эксперимента: - Собираем T.Ring на двух мохах на 1G медных портах; - в свободные 1G порты мох включаем ПК, запускаем на них "прослушку" и какой либо прикладной трафик; - Включаем на ПК-портах мох "рателимитинг" на блокировку порта; - свободный порт на одной мохе переводим в режим 100М дуплекс; - на циске делаем тоже самое + "убиваем" RSTP на порту, заготовленном для женитьбы с мохой; - женим циску с мохой через ОДИН порт, через который же наблюдаем ситуацию (а еще пишем сислог). - Далее ловим за хвост "странную ситуацию" и все "доказательства" сообщаем Вам; 4. Такой подход устроит ?