CRS518-16XS-2XQのS+RJ10銅線SFP+で約15%のパケットロス、直結100Gパスは正常
ラボのサーバーから100G QSFP28アップリンク経由でCRS518-16XS-2XQにトラフィックを流し、そこからMikroTik S+RJ10銅線SFP+を通って普通の1G RJ45ホストに出しています。受信側でパケットのかなりの割合が届いておらず、これといった原因が見当たりません。
構成:
- MikroTik CRS518-16XS-2XQ、トラフィック源から100G QSFP28アップリンク
- ケージの1つにMikroTik S+RJ10銅線SFP+、対向は1G RJ45デバイス
- 受信ホストでキャプチャを実行中
キャプチャで分かること:
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-500Mbpsでバースト的な送信元というのが話のすべてです。あなたのトラフィックは均一に分散していません。短いバーストが1Gbpsより速いレートで送信元を出て行き、その線を超えた分はすべて、1G側がはけるまでポートの送信バッファに溜まらなければなりません。バッファが満杯になるとスイッチはドロップします。これがrx-overflowの動きがまさに教えてくれていることで、直結100G接続で何も出ない理由もこれです。そこには速度の落差自体が存在せず、バッファする対象がありません。
トランシーバは無罪です。そのケージに何を挿しても、銅線でもファイバーでも同じ挙動になります。ドロップは100Gから1Gへの落差のところで起きているのであって、モジュールの中で起きているのではないからです。
やるべきことは2つです。本当の修正は送信側にあります。パケットがバーストで書き出されるのではなく均等に分散するようペースを調整してください。送信元が送信レートを超えるバーストを出さなくなれば、ロスは消えます。
スイッチ側ではバッファの状況を多少緩和できます。
これで余裕ができ、バーストをより長くやり過ごせるようになりますが、原因そのものはなくなりません。送信元が十分に強く長くバーストを出せば、どんなバッファサイズでも救えません。変更後もスイッチのQoS統計とrx-overflowカウンタを見続けて、まだ天井にぶつかっているのか、それともたまに触れる程度になったのかを確認してください。
覚えておく価値のある一般的な教訓があります。リンクがきれいでエラーもなくモジュールも健全なポートでも、ポート間の速度の落差だけで2桁パーセントのトラフィックをドロップすることがあるということです。
モジュールを疑う前に、ポートカウンタが実際に何を言っているか見てください。実行するのは
を100G入力ポートと、S+RJ10が挿さっているケージの両方で実行し、通常のrx/txエラーカウンタではなく、rx-overflowの行をねらって見てください。本当に壊れている銅線SFP+は、FCSエラーやリンクのフラッピングという形で自分から名乗り出ます。それ以外は健全なストリームからきれいに15%だけ削り取るような形にはなりません。
もう一つ、その経路の平均レートはどのくらいで、ピークについて何か心当たりはありますか。CPUが1%の状態で7パケットに1個が消えるというのは、トランシーバの故障というより、出力ポートのバッファ切れの匂いがはるかに強いです。
まずカウンタから。どちらのポートにもエラーはなく、リンクはずっとupのままで、モジュールも異常は何も報告していません。数字が動くのはrx-overflowだけです。
レートについては、この経路の平均は400-500Mbpsなので、机上の計算では1G側を飽和させるにはほど遠いです。ピークの測定はしていませんが、トラフィックは性質的にバースト的です。送信元がまとまった量を書き出してはしばらく静かになる、というパターンです。パケットが消えている間もCPUは1%のままです。
違う故障ですが、直感よりカウンタを信じるという教訓は同じです。SwOS 2.18のCRS354-48G-4S+2Q+RMで、両方のQSFP+ポートでRx FCS Errorsが着実に増え続け、Rx MAC Errorsもそれより低い割合で増えていくケースがありました。両ポートとも40Gフルデュプレックス、MTU 1500で、対向にはMellanox ConnectX-3 Pro CX324Aカードを積んだESXiホストがありました。
興味深いのは、NIC側は何一つ報告していなかったことです。
きれいなものでした。良好と分かっているケーブルに替えても何も変わらず、同じ箱の10G SFP+ポートはずっとエラーフリーのままでした。結局本当の診断には至りませんでした。スイッチをSwOSからRouterOSに移したらカウンタが消えましたが、これは解決したというより問題を隠しただけだと思っています。
最後まで使えた手法は、カウンタをクリアして、一定間隔で読み直し、エラーがトラフィック量に連動するかどうかを見ることです。あなたのケースではバーストに連動するでしょうし、自分のケースでは何にも意味のある連動をしませんでした。その違いだけで、どちら側を掘り続けるべきか分かります。
そのポートで実験している間、1つ覚えておいてください。強制的な速度とデュプレックスの設定を逃げ道にしないことです。MikroTikの銅線モジュール、S-RJ01もS+RJ10も同様ですが、ドキュメント上の仕様ではオートネゴシエーションを有効にした状態でしか動かないとされています。レートを静的に固定するとリンクはまったく上がりません。ただ実際にはこれと部分的に矛盾する報告もあり、一部のRB5009やRB4011のオーナーは逆で、1Gフルデュプレックスを強制することでようやくS-RJ01が安定したと言っています。なのでこれはルールというより「自分の機材で両方試してみる」類の話です。いずれにせよ、これはあなたの本当の問題、つまりバッファ側の問題からは外れた寄り道です。
後々のために知っておく価値のあるS+RJ10のもう一つの特性ですが、普通のオプティクスよりも明らかに消費電力が大きく発熱します。追加のエアフローなしのパッシブ冷却機器には推奨されません。もしこのモジュールが暖かいシャーシの中でおかしな挙動を始めたら、自分ならまず温度を確認します。