Около 15% потерь пакетов через медный SFP+ S+RJ10 на CRS518-16XS-2XQ, тогда как прямой путь 100G чист
Мы гоним трафик с лабораторного сервера в CRS518-16XS-2XQ по аплинку 100G QSFP28, а из коммутатора он выходит через медный SFP+ MikroTik S+RJ10 на обычный хост с RJ45 1G. Принимающая сторона теряет значительную долю пакетов, и я не могу привязать это ни к чему очевидному.
Схема:
- MikroTik CRS518-16XS-2XQ, аплинк 100G QSFP28 от источника трафика
- MikroTik S+RJ10 медный SFP+ в одной из клеток, на дальнем конце устройство RJ45 1G
- захват трафика идёт на принимающем хосте
Что показывает захват:
100G QSFP28 uplink -> CRS518-16XS-2XQ -> S+RJ10 -> 1G RJ45 host
capture on the 1G host: ~15% of the packets never arrive
same source, direct 100G connection: nothing missing
switch CPU load: 1%Что пробовал:
- подключил тот же источник напрямую на 100G - потерь вообще нет, значит сам отправитель в порядке
- снизил нагрузку CPU коммутатора, сейчас она держится на 1%, а потери всё равно есть
- переустановил S+RJ10 и поменял патч-корд к устройству 1G
Сейчас медный модуль - мой главный подозреваемый, но линк чист и интерфейс не показывает вообще никаких ошибок. Известно ли за S+RJ10 такое поедание трафика, или мне стоит искать где-то ещё внутри коммутатора?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
Средние 400-500 Мбит/с при пульсирующем отправителе - вот и вся история. Ваш трафик распределён неравномерно: короткие всплески покидают источник быстрее, чем 1 Гбит/с, и всё, что выше этой линии, должно сидеть в буфере на выходе порта, пока сторона 1G его не разгрузит. Когда буфер заполняется, коммутатор дропает. Именно об этом и говорит рост rx-overflow, и именно поэтому прямое соединение 100G ничего не показывает - там просто нет ступени понижения скорости, о которую можно буферизоваться.
Трансивер здесь ни при чём. Что угодно в этой клетке, медь или оптика, вело бы себя точно так же, потому что дроп происходит на ступени понижения со 100G до 1G, а не внутри модуля.
Есть два дела. Настоящее исправление - на стороне отправителя: сгладить его так, чтобы пакеты распределялись равномерно, а не писались всплесками. Как только источник перестанет создавать всплески выше скорости выхода, потери исчезнут.
На коммутаторе можно сделать ситуацию с буфером менее враждебной:
Это даёт запас и позволяет всплеску продержаться дольше, но не устраняет причину - если отправитель выдаст всплеск достаточно сильный и достаточно долгий, никакой размер буфера не спасёт. Продолжайте следить за статистикой QoS коммутатора и счётчиками rx-overflow после изменения, чтобы видеть, упираетесь ли вы всё ещё в потолок или только изредка его касаетесь.
Общий урок стоит запомнить: порт с чистым линком, без ошибок и здоровым модулем всё равно может дропать двузначный процент трафика исключительно из-за ступени понижения скорости между портами.
Прежде чем винить модуль, посмотрите, что реально говорят счётчики порта. Выполните
на входном порту 100G и на клетке с S+RJ10, и обратите внимание именно на строку rx-overflow, а не на обычные счётчики ошибок rx/tx. По-настоящему сломанный медный SFP+ заявляет о себе ошибками FCS или дёргающимся линком, а не аккуратной стрижкой 15% с в целом здорового потока.
Второй вопрос: какова средняя скорость по этому пути, и есть ли представление о пиках? Потеря одного пакета из семи при загрузке CPU в 1% пахнет куда больше нехваткой буфера на выходном порту, чем неисправностью трансивера.
Сначала счётчики: ошибок нет ни на одном порту, линк держится всё время, и модуль не сообщает ничего необычного. rx-overflow - единственное место, где цифры вообще двигаются.
По скорости путь в среднем даёт 400-500 Мбит/с, так что на бумаге это далеко от насыщения стороны 1G. Пиковых измерений у меня нет, но трафик пульсирующий по своей природе - отправитель пишет порцию и затем какое-то время молчит. CPU по-прежнему 1%, пока пакеты пропадают.
Другой отказ, тот же урок про доверие счётчикам, а не интуиции. У меня был CRS354-48G-4S+2Q+RM на SwOS 2.18 со стабильно растущими Rx FCS Errors на обоих портах QSFP+ и Rx MAC Errors с меньшей частотой. Оба порта стояли на 40G полный дуплекс с MTU 1500, а на дальней стороне были хосты ESXi с картами Mellanox ConnectX-3 Pro CX324A.
Интересная деталь: сторона сетевой карты вообще ничего не сообщала.
Чисто. Заведомо исправные кабели ничего не меняли, а порты SFP+ 10G того же устройства оставались безошибочными всё это время. Настоящего диагноза я так и не получил - перевод коммутатора со SwOS на RouterOS заставил счётчики исчезнуть, что я считаю скорее сокрытием проблемы, чем её решением.
Методика, которая себя оправдала: сбросить счётчики, снять их снова через фиксированный интервал и посмотреть, следуют ли ошибки за объёмом трафика. В вашем случае они будут следовать за всплесками, в моём они не следовали ни за чем полезным, и уже одна эта разница подсказывает, на какой стороне копать дальше.
Ещё кое-что стоит иметь в виду, пока вы экспериментируете на этом порту: не хватайтесь за принудительную скорость и дуплекс как за выход. Задокументированное поведение медных модулей MikroTik, и S-RJ01, и S+RJ10, таково, что они работают только с включённым автосогласованием - зафиксируйте скорость статически, и линк вообще не поднимется. Практика этому отчасти противоречит: несколько владельцев RB5009 и RB4011 сообщают обратное и добились стабильности S-RJ01, только принудительно выставив 1G полный дуплекс, так что это скорее вопрос «проверьте оба варианта на своём железе», чем строгое правило. В любом случае это отвлечение от вашей настоящей проблемы, которая на стороне буфера.
Ещё одна деталь про S+RJ10, полезная на будущее: он потребляет заметно больше энергии, чем обычная оптика, и сильно греется, так что его не рекомендуют использовать в устройстве с пассивным охлаждением без дополнительного обдува. Если этот модуль когда-нибудь начнёт капризничать в тёплом шасси, температура - первое, что я бы проверил.