Ложка дегтя в бочке меда

[stesv]

Приветствую.

После долгого молчания хочу продолжить обсуждение "МОХА-глюков",  начнем с RateLimityng (далее RL):

1. Во время останова оборудования обновили прошивки (Старая версия: 4.1, Текущая версия: 5.4) коммутаторов  (например Модель: IKS-6728A Серийный номер: TAEKD1019357) и получили "чудеса" в работе счетчиков RL - смотри вложение (там есть просто "безумные" цифры);

2. Причем отображаются НЕ просто "странные" цифры, но и идут "сработки" со всеми вытекающими последствиями, хотя трафика на интерфейсах практически НЕТ (можно даже его дамп выслать);

3. ? Кто виноват и что делать ?

Заранее спасибо ....

;

3. ? Что

 

[Незнайка]

Здравствуйте.

Тут, конечно, есть над чем подумать, но я хочу спросить о другом: есть ли (у Вас) объяснение столь значительному количеству отброшенных (Discard) кадров на обоих коммутаторах?

[stesv]

Приветствую.

1. Если "врут" счетчики  пакетов, то "нет веры" и счетчикам отброшенных пакетов. Поэтому мое объяснение - это "вранье" счетчиков ;

2.Картинки взяты с клиентских портов, куда включены хосты, на некоторых из которых мы пишем дампы (вайршарком), чтобы разобраться в ситуации. Так вот по дампам никаких "пропаж" пакетов не обнаруживается;

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

[stesv]

До кучи во вложении логи со следами  сработки RL ....

moxa-vpu-2_RL.LOG

[stesv]

Извините за назойливость, однако получу ли я какое либо разъяснение ситуации ?

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

[Незнайка]

Используете GVRP или VLAN описаны статикой? Даже если статикой - GVRP включен или выключен?

[stesv]

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

2. Вланы прописаны статически.

[stesv]

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

moxa-vpu-1.ini

[Незнайка]

Отключайте GVRP (во всей топологии) и приложите картинки счётчиков по новой, когда на них снова будут такие огромные величины. Предположу, что Discard должен будет уйти. Перед отключением проверьте корректность топологии VLAN, скорее всего там есть ошибки.

[stesv]

Ок., отключим GVRP, по поводу "ошибок" в вланах - сильно сомневаюсь, при их наличии были бы проблемы с продуктивным трафиком.

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

[Незнайка]

С включенным GVRP проблем вы бы не ощутили, если access был бы правильно весь описан.

Про последние картинки: в Ethernet Port 2 так же включен "волшебный" ПЛК?

 

[stesv]

1. Не понял реплику про правильное описание акцеса;

2. Последние картинки из ДРУГОГО ПТК с другими коммутаторами (510);

3. Отключение GVRP НЕ помогло, после УЖЕ снова произошла сработка, лог во вложении (смотри в нем последние сообщения). Другое дело, что GVRP отключен НЕ на всех коммутаторах ("боязно" их крутить при работающем оборудовании) и если счетчики плохо реагируют именно на пакеты этого протокола, то дозу "лекарства" надо делать "лошадиную" (на все коммутаторы). 

4. А еще вероятно было бы неплохо перезагрузить коммутаторы после отключения GVRP.....

moxa-vpu-2.log

[Незнайка]

Сам по себе GVRP тут не при чём. Я немного поясню ход мысли: сами по себе значения счётчиков берутся прямо с чипа. По идее. То есть, если чип считает, что на него падает такое кол-во кадров - то, видимо, оно так и есть. Почему оно так не было в 4.1 я пытаюсь выяснить.  Вообще попытаемся понять, что изменилось в алгоритмах  обработки этих величин между 4.1 и 5.4. Теперь про Discard: есть несколько причин заполнения этого счётчика, но основных две: неправильный VLAN ID и переполнение буфера порта. Учитывая, что мы говорим про абонентские порты - взяться незнакомым VID там вроде-бы неоткуда, но всё таки хочется в этом убедиться.  Именно поэтому и прошу отключить GVRP. Ну а если он заполняется по причине переполнения буфера порта - тогда это looping problem, со всеми вытекающими.

[stesv]

Позволю себе несколько реплик:

1. Рассуждения вызывают определенные сомнения, т.к. счетчики  показывают именно "безумные" цифры, т.е. количество пакетов, которого НЕ может быть ТЕОРЕТИЧЕСКИ (просто такое число пакетов НЕ "убирается" в скорость на порту) - посмотрите на ЧИСЛО пакетов, терабайты и гигабиты на интерфейсах;

2. Буфер переполнять НЕЧЕМ, т.к.  НЕТ трафика для   его переполнения, дампы, записываемые на РАЗНЫХ хостах/портах это показывают;

3.Возможно, что "аппаратные" счетчики ЕСТЬ и считают что-то правильно, однако информация через веб-морду и снмп выдается "странная", а значит она может и обрабатываться "странным" образом уже НЕ аппаратно, а на уровне ПО (думаю RL именно там работает);

4. GVRP  сейчас отключили ВЕЗДЕ, ждем результатов;

5. По поводу версий ПО - если посмотреть более раннюю переписку, то проблема обнаружилась еще при смене более ранних версий. Сейчас у нас есть ТРИ одинаковых ПТК на разных объектах, работающих на  ТРЕХ разных версиях ПО на моха коммутаторах.  Обсуждаемая проблема КРИТИЧЕСКИ проявляется только на ОДНОМ объекте, где крутится самое новое ПО, на объекте с самым старым ПО описываемых проблем НЕТ. 

[Незнайка]

Да, тут соглашусь, 148810 кадров/сек по 64 байта на 100 мбит в одну сторону. Подумаем.

Но на мой взгляд, переполнение буфера на порту всё же имеет место быть, даже (предположим) с неправильными цифрами. Иначе бы счётчик Discard был бы 0.

[stesv]

Продолжу:

1. Тотальное отключение GVRP НЕ помогло, сработки RL на фоне "безумных" значений счетчиков продолжаются;

2. Не совсем понял переполнение какого буфера имеется ввиду, попробую пояснить свое видение:

- сработка происходит по счетчику ВХОДЯЩИХ пакетов, т.е. уже ПРИНЯТЫХ коммутатором;

- Значит речь идет о переполнении входного буфера.  По какой причине ему переполнятся, если трафик хоста по дампу (а также по SNMP c самого коммутатора) минимальный;

- Чтобы буфер переполнился, пакет в нем должен "застрять", не совсем понимаю какие причины могут к этому привести при НОРМАЛЬНОЙ работе коммутатора;

- Если разобраться, что такое "дискарт"  (а НЕ ошибка) на приеме, то это типа ПРАВИЛЬНО принятый пакет (на аппаратном уровне), но отброшенный коммутаторам по "разным причинам" (на программном уровне). Например это может быть блокировка на резервном каплинг-порту, т.е. это может быть НОРМАЛЬНОЕ событие.

- Если ЯВНО врет счетчик ВСЕГО пакетов, то почему мы должны ВЕРИТЬ счетчику отброшенных пакетов ?

- ? Или я что-то не понимаю ?

3. Мне кажется, что проблема все таки  в ПО, создается впечатления, что НЕЧТО начинает писать в ЧУЖУЮ область памяти, искажает там значения счетчиков и далее происходит то, что происходит .....

[Незнайка]

https://yadi.sk/d/mCyZl2PD3ZLkC7 устанавливайте и пробуйте. Но коммутатор придётся перезагружать. 

[stesv]

Спасибо, попробуем.

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

[stesv]

Приветствую.

Анонсированная заливка оказалась "странной", а именно:

1. Взяли тестовый коммутатор, воткнули его в офисную сеть и залили предложенную заливку;

2. Начали смотреть счетчики и увидели, что показания пакетов ВСЕГО совпадают с показаниями за последние 5 сек. - смотри картинку;

3. ? Это нормально ?

 

[Незнайка]

Ерунда какая то...... И Discard всё равно множится

[stesv]

Коммутатор включен ОДНИМ портом, с него и картинка.

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

 

[stesv]

Вот обещанное ...

test_switch.ini

test_switch.log

[Незнайка]

Ок, спасибо, думаем

[Незнайка]

А в этом сценарии (с тестовым коммутатором) можно wireshark получить? Пока не получается воспроизвести...

[Незнайка]

+ На мой взгляд, надо искать причину Discard'ов. Потому что когда их нет - нет и ошибок, получается. В порт 1-1 подсоединён обычный ПК, так ведь?