stesv Posted July 12, 2018 Author Share Posted July 12, 2018 Приветствую. После долгого молчания хочу продолжить обсуждение "МОХА-глюков", начнем с RateLimityng (далее RL): 1. Во время останова оборудования обновили прошивки (Старая версия: 4.1, Текущая версия: 5.4) коммутаторов (например Модель: IKS-6728A Серийный номер: TAEKD1019357) и получили "чудеса" в работе счетчиков RL - смотри вложение (там есть просто "безумные" цифры); 2. Причем отображаются НЕ просто "странные" цифры, но и идут "сработки" со всеми вытекающими последствиями, хотя трафика на интерфейсах практически НЕТ (можно даже его дамп выслать); 3. ? Кто виноват и что делать ? Заранее спасибо .... ; 3. ? Что Link to comment
Незнайка Posted July 12, 2018 Share Posted July 12, 2018 Здравствуйте. Тут, конечно, есть над чем подумать, но я хочу спросить о другом: есть ли (у Вас) объяснение столь значительному количеству отброшенных (Discard) кадров на обоих коммутаторах? Link to comment
stesv Posted July 16, 2018 Author Share Posted July 16, 2018 Приветствую. 1. Если "врут" счетчики пакетов, то "нет веры" и счетчикам отброшенных пакетов. Поэтому мое объяснение - это "вранье" счетчиков ; 2.Картинки взяты с клиентских портов, куда включены хосты, на некоторых из которых мы пишем дампы (вайршарком), чтобы разобраться в ситуации. Так вот по дампам никаких "пропаж" пакетов не обнаруживается; 3. Более того, есть интересная особенность - "чудят" в основном счетчики на пассивных портах хостов, где в нормальной ситуации вообще НЕТ "уникаст" исходящего трафика, хост генерирует только тестирующие пакеты с типом "Intel ANS" (может быть моха НЕ любит именно такой тип пакетов). Типичная статистика загрузки портов во вложении (кстати на одной картинке четко видна сработка RL) Link to comment
stesv Posted July 16, 2018 Author Share Posted July 16, 2018 До кучи во вложении логи со следами сработки RL .... moxa-vpu-2_RL.LOG Link to comment
stesv Posted July 18, 2018 Author Share Posted July 18, 2018 Извините за назойливость, однако получу ли я какое либо разъяснение ситуации ? "Странная" работа RL создает нам реальные проблемы (во вложении картинка из системы мониторинга), который могут "до цугундера довести" .... Link to comment
Незнайка Posted July 18, 2018 Share Posted July 18, 2018 Используете GVRP или VLAN описаны статикой? Даже если статикой - GVRP включен или выключен? Link to comment
stesv Posted July 18, 2018 Author Share Posted July 18, 2018 1. Если мне не изменяет память, то GVRP на мохах включен по умолчанию, посему его специально НЕ отключали. 2. Вланы прописаны статически. Link to comment
stesv Posted July 18, 2018 Author Share Posted July 18, 2018 Если поможет, но конфиг одного коммутатора со "странно работающим" RL во вложении .... moxa-vpu-1.ini Link to comment
Незнайка Posted July 18, 2018 Share Posted July 18, 2018 Отключайте GVRP (во всей топологии) и приложите картинки счётчиков по новой, когда на них снова будут такие огромные величины. Предположу, что Discard должен будет уйти. Перед отключением проверьте корректность топологии VLAN, скорее всего там есть ошибки. Link to comment
stesv Posted July 18, 2018 Author Share Posted July 18, 2018 Ок., отключим GVRP, по поводу "ошибок" в вланах - сильно сомневаюсь, при их наличии были бы проблемы с продуктивным трафиком. Кстати, пообщался с своими коллегами, обслуживающими ДРУГИЕ системы и оборудование, так вот там тоже обнаружилась проблема "безумных" счетчиков в моха-коммутаторах (смотри картинки из системы мониторинга во вложении), другое дело что при отключенном RL неприятностей это не создавало .... Link to comment
Незнайка Posted July 18, 2018 Share Posted July 18, 2018 С включенным GVRP проблем вы бы не ощутили, если access был бы правильно весь описан. Про последние картинки: в Ethernet Port 2 так же включен "волшебный" ПЛК? Link to comment
stesv Posted July 18, 2018 Author Share Posted July 18, 2018 1. Не понял реплику про правильное описание акцеса; 2. Последние картинки из ДРУГОГО ПТК с другими коммутаторами (510); 3. Отключение GVRP НЕ помогло, после УЖЕ снова произошла сработка, лог во вложении (смотри в нем последние сообщения). Другое дело, что GVRP отключен НЕ на всех коммутаторах ("боязно" их крутить при работающем оборудовании) и если счетчики плохо реагируют именно на пакеты этого протокола, то дозу "лекарства" надо делать "лошадиную" (на все коммутаторы). 4. А еще вероятно было бы неплохо перезагрузить коммутаторы после отключения GVRP..... moxa-vpu-2.log Link to comment
Незнайка Posted July 18, 2018 Share Posted July 18, 2018 Сам по себе GVRP тут не при чём. Я немного поясню ход мысли: сами по себе значения счётчиков берутся прямо с чипа. По идее. То есть, если чип считает, что на него падает такое кол-во кадров - то, видимо, оно так и есть. Почему оно так не было в 4.1 я пытаюсь выяснить. Вообще попытаемся понять, что изменилось в алгоритмах обработки этих величин между 4.1 и 5.4. Теперь про Discard: есть несколько причин заполнения этого счётчика, но основных две: неправильный VLAN ID и переполнение буфера порта. Учитывая, что мы говорим про абонентские порты - взяться незнакомым VID там вроде-бы неоткуда, но всё таки хочется в этом убедиться. Именно поэтому и прошу отключить GVRP. Ну а если он заполняется по причине переполнения буфера порта - тогда это looping problem, со всеми вытекающими. Link to comment
stesv Posted July 18, 2018 Author Share Posted July 18, 2018 Позволю себе несколько реплик: 1. Рассуждения вызывают определенные сомнения, т.к. счетчики показывают именно "безумные" цифры, т.е. количество пакетов, которого НЕ может быть ТЕОРЕТИЧЕСКИ (просто такое число пакетов НЕ "убирается" в скорость на порту) - посмотрите на ЧИСЛО пакетов, терабайты и гигабиты на интерфейсах; 2. Буфер переполнять НЕЧЕМ, т.к. НЕТ трафика для его переполнения, дампы, записываемые на РАЗНЫХ хостах/портах это показывают; 3.Возможно, что "аппаратные" счетчики ЕСТЬ и считают что-то правильно, однако информация через веб-морду и снмп выдается "странная", а значит она может и обрабатываться "странным" образом уже НЕ аппаратно, а на уровне ПО (думаю RL именно там работает); 4. GVRP сейчас отключили ВЕЗДЕ, ждем результатов; 5. По поводу версий ПО - если посмотреть более раннюю переписку, то проблема обнаружилась еще при смене более ранних версий. Сейчас у нас есть ТРИ одинаковых ПТК на разных объектах, работающих на ТРЕХ разных версиях ПО на моха коммутаторах. Обсуждаемая проблема КРИТИЧЕСКИ проявляется только на ОДНОМ объекте, где крутится самое новое ПО, на объекте с самым старым ПО описываемых проблем НЕТ. Link to comment
Незнайка Posted July 18, 2018 Share Posted July 18, 2018 Да, тут соглашусь, 148810 кадров/сек по 64 байта на 100 мбит в одну сторону. Подумаем. Но на мой взгляд, переполнение буфера на порту всё же имеет место быть, даже (предположим) с неправильными цифрами. Иначе бы счётчик Discard был бы 0. Link to comment
stesv Posted July 19, 2018 Author Share Posted July 19, 2018 Продолжу: 1. Тотальное отключение GVRP НЕ помогло, сработки RL на фоне "безумных" значений счетчиков продолжаются; 2. Не совсем понял переполнение какого буфера имеется ввиду, попробую пояснить свое видение: - сработка происходит по счетчику ВХОДЯЩИХ пакетов, т.е. уже ПРИНЯТЫХ коммутатором; - Значит речь идет о переполнении входного буфера. По какой причине ему переполнятся, если трафик хоста по дампу (а также по SNMP c самого коммутатора) минимальный; - Чтобы буфер переполнился, пакет в нем должен "застрять", не совсем понимаю какие причины могут к этому привести при НОРМАЛЬНОЙ работе коммутатора; - Если разобраться, что такое "дискарт" (а НЕ ошибка) на приеме, то это типа ПРАВИЛЬНО принятый пакет (на аппаратном уровне), но отброшенный коммутаторам по "разным причинам" (на программном уровне). Например это может быть блокировка на резервном каплинг-порту, т.е. это может быть НОРМАЛЬНОЕ событие. - Если ЯВНО врет счетчик ВСЕГО пакетов, то почему мы должны ВЕРИТЬ счетчику отброшенных пакетов ? - ? Или я что-то не понимаю ? 3. Мне кажется, что проблема все таки в ПО, создается впечатления, что НЕЧТО начинает писать в ЧУЖУЮ область памяти, искажает там значения счетчиков и далее происходит то, что происходит ..... Link to comment
Незнайка Posted July 19, 2018 Share Posted July 19, 2018 https://yadi.sk/d/mCyZl2PD3ZLkC7 устанавливайте и пробуйте. Но коммутатор придётся перезагружать. Link to comment
stesv Posted July 19, 2018 Author Share Posted July 19, 2018 Спасибо, попробуем. Еще одну наглядную картинку приведу - статистика из дампа на порту, где "чудит" RL. Видно, что исходно трафик НЕ большой, все нормально работает, а потом начинает RL блочить порт на 30 сек., снова его поднимать и снова блочить ..... Link to comment
stesv Posted July 20, 2018 Author Share Posted July 20, 2018 Приветствую. Анонсированная заливка оказалась "странной", а именно: 1. Взяли тестовый коммутатор, воткнули его в офисную сеть и залили предложенную заливку; 2. Начали смотреть счетчики и увидели, что показания пакетов ВСЕГО совпадают с показаниями за последние 5 сек. - смотри картинку; 3. ? Это нормально ? Link to comment
Незнайка Posted July 20, 2018 Share Posted July 20, 2018 Ерунда какая то...... И Discard всё равно множится Link to comment
stesv Posted July 20, 2018 Author Share Posted July 20, 2018 Коммутатор включен ОДНИМ портом, с него и картинка. Дискарды и у меня вызывают недоумение, в общем яснее ситуация не стала, попрошу своих ребят логи и конфиг прислать .... Link to comment
stesv Posted July 20, 2018 Author Share Posted July 20, 2018 Вот обещанное ... test_switch.ini test_switch.log Link to comment
Незнайка Posted July 20, 2018 Share Posted July 20, 2018 А в этом сценарии (с тестовым коммутатором) можно wireshark получить? Пока не получается воспроизвести... Link to comment
Незнайка Posted July 20, 2018 Share Posted July 20, 2018 + На мой взгляд, надо искать причину Discard'ов. Потому что когда их нет - нет и ошибок, получается. В порт 1-1 подсоединён обычный ПК, так ведь? Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now