しかし、少し前に、LACP要求だけがあった2つのルーター間のトラフィックダンプを見つけました。 私は簡単にそれを走り抜け、見慣れない言葉であるスロープロトコルに目を留めました。
驚くべきことに、私はロシア語でこの標準に関する情報を実際には見つけませんでした。 これが802.3標準の一部であるという事実への参照のみがあります。
一方、特に興味深いのはLACPだけではないためです。
それは私がカットの下で短い教育プログラムをアレンジし、特定の条件下でどのような問題をキャッチできるかについてもっと伝えたかったものです。
そのため、イーサネットのさまざまな側面、つまりフロー制御を制御するように設計されたプロトコルのクラスがあります。 これらは802.3標準の一部であり、2つのタイプに分けられます。
- 速い 。 一般的にサービスの提供におけるパフォーマンスの低下と中断を防ぐために、即座に解決する必要があります。 原則として、それらはハードウェアに実装されます。 実際、このクラスの代表であるPAUSEメカニズムは、デバイスポートが処理できるよりも多くのトラフィックを受信すると、送信速度を下げる要求とともにPAUSEフレームを反対側のノードに送信します。
これは、GEのFEなど、異なる速度のインターフェイスを相互に接続するときに発生する可能性があります。 または、スイッチポートに速度制限を設定する場合。 インシデントも発生しますが 、そのような問題に対処する必要はありませんでした。
かつて、私は彼らの異常な行動でポーズフレームに出会いました。 その日、PAUSE Framesが受信したカウンターはインターフェース上で急速に成長し、監視システムは事故でdrれ、7日目に雨は止まりませんでした。 彼らは分析を開始しました。これらのインターフェースのトラフィック量は、数パーセントをほとんど超えず、ドロップもエラーもありませんでした。 さらに、最も驚くべきことは、反対側で、デバイスはこれらの同じPAUSE Frames-Pause Frame Outputカウンターをゼロに送信しませんでした。 中間的なデバイスすら存在しないため、ある種の狂信。
開発者の参加による深いデバッグにより、これらは何らかの内部的な鉄の問題であることが判明しました-スイッチングチップには小さなバッファがあり、ラインカードにPause Framesを送信してアクティビティを減らしますが、ボックス内のこのトリッキーな方法はすべてサービスに影響を与えません。
一時停止メカニズムは、全二重液の技術です。 半二重にはバックプレッシャーがあります。 これは非常に厳密であり、速度を落とすだけでなく、データ転送をブロックします。これは、送信スイッチに衝突があり、無駄な試行を停止する必要があることを実際に伝えるためです。 しかし、誰が今気にしていますか?
- 遅い -それらと同じ遅いプロトコル。 彼らは送信頻度と遅延に対してそれほど大きな欲求を持っていません。 それらはプログラムで実装されます。 OAMおよびLACPは、この特定のタイプに関連しています。
それらは特別なMACアドレスを使用します:-0180-s200-0002、およびEtherType 8809。
さらに、 この文書の非常に無料の翻訳は、標準の802.3に追加されます。
制限事項
まず、このタイプのプロトコルには次の制限が課されます。
1)1秒あたり10フレーム以下で送信する
2)EtherType 8809のプロトコルの最大数は10です。 理論的には、さらに多くの可能性がありますが、イーサネットヘッダーにはすでに異なるタイプがあります。
3)「低速」プロトコルのフレームサイズは128バイトに制限されています。 *公平に行われているとは言えません-たとえば、OAMPDUはこのサイズを簡単に超える可能性があります。
上記の制限には、ネットワーク上のサービストラフィックの量を減らすという単純な目標があります。
より高いレベルのプロトコルについては、特別に割り当てられたマルチキャストIPアドレス(OSPFの場合は224.0.0.5など)があり、「遅い」プロトコルには個別のマルチキャストMACアドレス01-80-C2-00-00-02があります。
このMACアドレスは、1つのリンクに制限されたプロトコルに対してISO / IEC 15802-3によって割り当てられた範囲に属します。 実際、これは、特定のアドレスに送信されたフレームをこの特定のリンクの外部にリダイレクトできないことを意味します。

ユニキャストフレーム転送を必要とする「遅い」プロトコルが存在する可能性があります-これは禁止されていません。 つまり、アドレス01-80-C2-00-00-02は必須ではありません-これは希望です。
「遅い」プロトコルは別のMACアドレスを使用できますが、「遅い」プロトコル以外のプロトコルはこれを使用できません(01-80-C2-00-00-02)。
前述したように、Slow Protocols(EtherType)グループのプロトコルタイプは8809です。 次に、サブタイプが定義されます-この栄光のクラスの特定の代表者のサブタイプ:
サブタイプ
サブタイプ | 行き先 |
---|---|
0 | 未使用の禁止サブタイプ |
1 | リンク集約制御プロトコル(LACP) |
2 | リンク集約—マーカープロトコル |
3 | 運用、管理、およびメンテナンス(OAM) |
4-9 | 予約済み |
10 | 組織固有の低速プロトコル(OSSP) |
11〜255 | 未使用の禁止サブタイプ |
ご覧のとおり、サブタイプには8ビットが割り当てられています。 以下にタイプ10について説明しますが、残りはすべて明確です。
1-私たちによく知られているLACP

2は、負荷分散、整然としたフレーム取得、最適化されたLAGリンク管理のためのLAGメカニズムの一部でもあります。
3-イーサネットOAMプロトコル。

低速プロトコルフレームを受信したときの動作方法
1)低速プロトコルの禁止サブタイプが示されているすべてのフレームを破棄します
2)既知のSlowプロトコル(既知のサブタイプ)を伝送するフレームをスキップし、適切なサービスに転送します。
3)有効であるが未知のプロトコルを伝送するフレームをスキップし、MACクライアントに渡します。
OSSPDU
実際、この標準を使用することが現在わかっている2つのプロトコルはLACPとOAMですが、一般に、ニーズに応じて独自の「低速」プロトコルを作成する機会があります。 これはまさに10 OSSP-Organization Specific Slow Protocolの ポイントです。
これは、特定のプロトコルを実装するための推奨事項を説明する付録57Bに適用されます。
他のプロトコルと同様に、フレームには名前(LACPDU、OAMPDU、BPDU)があり、OSSPにはこれらの目的のための一般化された用語-OSSPDUがあります。
以下は、ネットワークのOSSPDUフレーム構造と伝送ルールの完全に論理的な要件ですが、標準はすべての微妙な点を記述する標準です。
一般的に、私はそれをもう少し深く取りました。
OSSPDUフレーム形式とネットワークへの送信
組織固有の低速プロトコルデータユニットは、整数個のオクテットで構成されます。 各オクテットのビットには、0から7までの番号が付けられます。一連のオクテットを使用して数値を表す場合、最も重要なオクテットを最初に送信する必要があります。
フレーム構造:
a)オクテットは上から下に渡されます
b)オクテット内では、ビットは左から右に0から7であり、左から右にも送信されます。
c)オクテットのシーケンスが数値を表す場合、最も重要なオクテットを最初に送信する必要があります。
d)オクテットシーケンスがMACアドレスを表す場合、最初のオクテットの最下位ビットがMACアドレスの最初のビットを伝送します。 次の重要なオクテットビットは、MACアドレスの2番目のビットを伝送します。 8ビット目まで続きます。 同様に、2番目のオクテットの最下位ビットから最上位ビットまで、MACアドレスの9〜17ビットが割り当てられます。 そして彼は、彼らが言うように。
OSSPDUには次のフィールドが含まれている必要があります。
a)宛先のMACアドレス。 通常、低速プロトコルに割り当てられるマルチキャストアドレスは01-80-C2-00-00-02です。
b)送信者のMACアドレス。 送信インターフェイスのユニキャストアドレス(集約チャネルについて話している場合はLAG)
c)フィールド長/タイプにはEtherType 8809が含まれます
d)[サブタイプ]フィールドには値10(0x0A)が含まれます
e)OUIフィールド-組織的に一意の識別子。 データの識別子。
f)実際のプロトコルデータ
g)FCS。 しかし、イーサネットがそれを形成する場合、誰が気にしますか?
フレーム構造:

a)オクテットは上から下に渡されます
b)オクテット内では、ビットは左から右に0から7であり、左から右にも送信されます。
c)オクテットのシーケンスが数値を表す場合、最も重要なオクテットを最初に送信する必要があります。
d)オクテットシーケンスがMACアドレスを表す場合、最初のオクテットの最下位ビットがMACアドレスの最初のビットを伝送します。 次の重要なオクテットビットは、MACアドレスの2番目のビットを伝送します。 8ビット目まで続きます。 同様に、2番目のオクテットの最下位ビットから最上位ビットまで、MACアドレスの9〜17ビットが割り当てられます。 そして彼は、彼らが言うように。
OSSPDUには次のフィールドが含まれている必要があります。
a)宛先のMACアドレス。 通常、低速プロトコルに割り当てられるマルチキャストアドレスは01-80-C2-00-00-02です。
b)送信者のMACアドレス。 送信インターフェイスのユニキャストアドレス(集約チャネルについて話している場合はLAG)
c)フィールド長/タイプにはEtherType 8809が含まれます
d)[サブタイプ]フィールドには値10(0x0A)が含まれます
e)OUIフィールド-組織的に一意の識別子。 データの識別子。
f)実際のプロトコルデータ
g)FCS。 しかし、イーサネットがそれを形成する場合、誰が気にしますか?
これはこれらの単純な話の全体ですが、RuNetプロトコルではあまり説明されていません。
ところで、アプリケーションの複雑さ、プロトコルの仕事の無知から、いくつかの事件が生まれています。 ここにそれらの一部があり、私は直面しなければなりませんでした。 その後、実際、このトピックに興味を持つようになりました。
ピッキング用のpcapファイル 。