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. Такой подход устроит ?

Попробую ответить: 1. Третий коммутатор используется для того, чтобы можно было удаленно подключиться стенду. Собственно через "обнаруженную" циску персонал и подключается к мохам, чтобы смотреть что там происходит. Иначе надо ФИЗИЧЕСКИ присутствовать около железок; 2. Запрашиваемые Вами настройки сделаем - ради бога, только я не совсем понимаю чем плох медный линк или как при нормальной ситуации могут влиять BPDU на эффекты, проявляемые при настройках "РатеЛимитинг", тем более что для подключения используется ОДИН порт (петли не может быть по определению) и Турбо Чайн позиционируется именно как технология обеспечивающее подключение к ЛЮБОМУ внешнему телекому;

Приветствую. Попытались "поймать за хвост" обозначенную ранее проблему со "странной" реакцией новой прошивки 6728 в режиме "РатеЛимитинг". Собрали стенд - в кольце объединили два пустых коммутатора, прицепили к одному их них комп. и оставили все это поработать какое-то время. "Странность" проявилась, причем комп в это время "спал". Подробности (конфиги, логи и пр.) высылаю на почту техподдержки .....

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

Приветствую. Прошу прощения за назойливость, однако если проверяете озвученные мной "странности", то заодно посмотрите еще следующее на коммутаторе 6728, заливка 4.1 (включена политика "Рателимитинг" на блокировку порта): 1. Если через веб-морду зайти на вкладку, где показана статистика пакетов и нажать на ней кнопку "рефрешь", то тут-же отображается сработка блокировки портов; 2. Если после установки настроек "Рателимитинг" покрутить какие либо другие настройки, а потом вернуться в окно настройки "Рателимитинг", то можно увидеть, что сделанные ранее установки там "слетают". После перезагрузки коммутатора настройки "воскресают";

Большое спасибо, ожидаю результатов Вашего расследования по поводу новой заливки .....

Приветствую. 1. Конфиг выслал на support @moxa.ru; 2. Не могли бы Вы оперативно прислать ПРЕДЫДУЩУЮ прошивку для 6728 (НЕ PoE). Коллеги у меня полностью обновились, получили "неприятность", а теперь не могут откатится, т.к. не сохранили предыдущую версию .

Приветствую. Жду результаты Ваших "расследований" с нетерпением. 13 сентября объект выходит из останова, хотелось бы определить какую прошивку "заливать". Кстати хочу еще файлов приложить для предъявления "странностей", однако Ваш сайт пишет, что я могу залить только 1,62К файлов. В указанную цифру очень трудно что-то путное уместить, что даже возникает мысль не "издевка" ли это ....

Снова Приветствую. 1. Испытали Вашу ранее персонально присланную "секретную" заливку для 6728, а также новую "официальную" (появилась в начале сентября) в них обнаружились новые "чудеса" (в старых есть старые - не буду пока о них): - "Измеритель" количества пакетов работает "криво" и периодически/спонтанно выдает "странные" показания - смотри картинки во вложении (пришлось из зачернить, чтобы уменьшить размер файла). Если на коммутаторе включен "РатеЛимитинг", то эти "странные" показания отключают порты; - На "старой" заливке соответственно никакого отключения не происходит.

Спасибо, порадовали. что нет ограничений. Делать "ромашку" приходится, вследствие особенностей топологии связей и чтобы свести все лепестки на L-3 коммутаторы, где можно поднять акцесс-листы...

Приветствую. Еще вопрос: 1. Есть НЕСКОЛЬКО колец T.Ring, которые нужно отказоустойчиво связать между собой. Стандартный способ - с помощью каплинга собирается "цепочка из колец" (первое кольцо каплится ко второму, второе к третьему, третье к четвертому и т.д.) и все нормально работает. А вот если МНОГО колец каплевать на ОДНО (первое на второе, третье на второе, четвертое на второе и т.д.), то до каких масштабов это можно делать ? Реально работает (проверено), когда ДВА кольца каплюются на одно, а если добавить каплинг от ТРЕТЬЕГО (и более). то будет ли такая конструкция работать ? 2. Расширение предыдущего вопроса: Если каплевать на ОДНУ и ТУЖЕ пару коммутаторов или на РАЗНЫЕ - ситуация меняется ? Заранее спасибо ....