イーサネットフレームについて知りたいが、尋ねるのが怖かったすべての理由

記事は非常に膨大であることが判明し、議論されたトピックは、Ethenetフレーム形式、L3ペイロードサイズの境界、イーサネットヘッダーサイズの進化、ジャンボフレーム、ベイビージャイアント、および通過する多くのことでした。 データ伝送ネットワークに関するレビュー文献ですでに見たことがありますが、多くの研究をしていなければ、間違いなく多くの人に出会ったことはありません。



まず、キュー内のイーサネットフレームヘッダーの形式を調べて、その誕生を見てみましょう。

Ehternetフレームをフォーマットします。

1）イーサネットII

図 1



プリアンブル -ビットのシーケンス。実際には、ETHヘッダーの一部ではなく、イーサネットフレームの始まりを定義します。



DA（宛先アドレス） -宛先MACアドレス;ユニキャスト、マルチキャスト、ブロードキャストが可能です。



SA（送信元アドレス） -送信者のMACアドレス。 常にユニキャスト。



E-TYPE（EtherType） -L3プロトコルを識別します（たとえば、0x0800-Ipv4、0x86DD-IPv6、0x8100-は、フレームに802.1qなどのタグが付けられていることを示します。すべてのEtherTypeのリストはstandard.ieee.org/develop/regauth/です。 ethertype / eth.txt ）



ペイロード-46〜1500バイトのL3パケットサイズ



FCS（フレームチェックシーケンス） -送信エラーの検出に使用される4バイトのCRC値。 送信者によって計算され、FCSフィールドに配置されます。 受信側はこの値を独自に計算し、受信した値と比較します。



このフォーマットは、DEC、Intel、Xeroxの3社と共同で作成されました。 この点で、この標準はDIXイーサネット標準とも呼ばれます 。 標準のこのバージョンは1982年に公開されました（最初のバージョン、Ehernet I-1980年）。バージョンの違いは小さく、全体としての形式は変更されていません。 1997年 今年、IEEE標準が802.3標準に追加され、現時点では、イーサネットネットワークのパケットの大部分がこの標準に従ってカプセル化されています。

2）Ethernet_802.3 / 802.2（LLCヘッダー付き802.3）

図 2



ご承知のとおり、IEEE委員会は、権力、お金、女性が文字通り自分の手から抜け出すのを冷静に見ることができませんでした。 したがって、より差し迫った問題で忙しく、イーサネットテクノロジーの標準化に時間がかかりました（1980年にビジネスになり、1983年に世界にドラフトを、1985年に標準そのものを提供しました）が、大きな熱意を持っていました。 主要な原則として革新と最適化を宣言した後、委員会は図2に示す次のフレーム形式を発行しました。



まず、「不要な」E-TYPEフィールドが長さフィールドに変換され、このフィールドに続くFCSフィールドの前のバイト数を示すという事実に注目します。 これで、OSIシステムの第2レベルで誰が長かったのかがわかりました。 人生は良くなりました。 人生はもっと楽しくなりました。



しかし、第3レベルのプロトコルのタイプへのポインターが必要であり、IEEEは世界に次のイノベーションを提供しました-各1バイトの2つのフィールド-ソースサービスアクセスポイント（ SSAP ）と宛先サービスアクセスポイント（ DSAP ）。 目標は、同じものですが、優れたプロトコルを特定することですが、それはなんと実装です！ 現在、同じセッション内に2つのフィールドが存在するため、異なるプロトコル間でパケットを送信したり、同じセッションの両端で同じプロトコルを異なる方法で呼び出したりできます。 え？ なに？ あなたのスコルコボはどこですか？



注：人生では、これはほとんど役に立たず、SSAP / DSAP値は通常一致します。 たとえば、SAP for IP-6、STP-42（値の完全なリストはstandard.ieee.org/develop/regauth/llc/public.htmlです ）



休憩をとることなく、IEEEはSSAPとDSAPで1ビットを予約しました。 SSAPではコマンドまたは応答パケットの下、DSAPではグループまたは個々のアドレスの下にあります（図6を参照）。 イーサネットネットワークでは、これらのものは配信されませんでしたが、SAPフィールドのビット数は7に削減され、上位プロトコルを示すために考えられる数は128のみになりました。 私たちはこの事実を覚えています、私たちはそれに戻ります。



地球上で最高のフレーム形式を作成するという私たちの探求で停止することはすでに難しく、IEEEフレーム形式には1バイトの制御フィールドが表示されます。 コネクションレスまたはコネクション指向の接続に対して、多くの責任ではなく、少なからず！



あなたの発想を吐き出し、調べた後、IEEEは休憩することにしました。



注 ：問題の3つのフィールドはDSAP、SNAP、およびControlであり、LLCヘッダーです。

3）「生」802.3

図 3



この「非標準」は、ノベルの世界で明らかにされました。 それは威勢のいい80年代で、誰もがベストを尽くして生き延びました。ノベルも例外ではありませんでした。 開発の過程で標準の802.3 / 802.2の仕様を取得し、手首を軽く振ってLLCヘッダーを投げると、Novellはかなり良いフレーム形式（2番目のレベルで長さを測定する機能を備えています！）を取得しましたが、1つの重要な欠点は、より高いプロトコルを指定する機能がないことです。 しかし、あなたがすでに推測しているかもしれないが、そこで働いていた人たちは愚かではなく、一般的な考えで解決策を見つけました-「私たちの欠点を私たち自身のメリットに変えましょう」、このフレーム形式をIPXプロトコルに限定しました。 アイデアは良く、計画は戦略的に正しいものでしたが、歴史が示しているように、フォルタヌロではありません。

4）SNAPヘッダー付きの802.3。

時間が経ちました。 IEEE委員会は、プロトコル番号と資金が不足していることを認識していました。 感謝の意を表するユーザーは、編集オフィスを文字で満たしました。3バイトのLLCヘッダーは、犬に5番目の足、または女性の解剖学を最適化するために使用できるスリーブを装備するなどの人類の革新に匹敵します。 さらに待つことは不可能であり、世界を再確認する時でした。





図 4



また、プロトコル番号の不足（合計で128に達する可能性があります—前述）を抱える人々を支援するために、IEEEは新しいイーサネットSNAPフレーム標準を導入しました（図4）。 主なイノベーションは、5バイトのSubnetwork Access Protocol（SNAP）フィールドの追加です。このフィールドは、3バイトのOrganizationally Unique Identifier（OUI）フィールドと2バイトのProtocol ID（PID）の2つの部分で構成されています。 5。





図 5



OUIまたはベンダーコード-ベンダーを示すことにより、独自のプロトコルを識別できます。 たとえば、WireSharkでPVST +パケットをキャッチすると、OUIフィールドにコード0x00000cが表示されます。これはCisco Systemsの識別子です（図6）。





図 6



注： 802.3 SNAPフレーム形式でのパケットのカプセル化は非常に簡単で、現在はすべてのプロトコルがSTPファミリーのプロトコルであり、CDP、VTP、DTPのプロトコルです。



PIDフィールドは、基本的にDIX Ethernet IIの同じEtherTypeフィールドであり、高レベルのプロトコルを示すための2バイトです。 以前、このために、LLCヘッダーのDSAPおよびSSAPフィールドが使用され、SNAPフィールドで上位プロトコルのタイプを調べる必要があることを示すため、DSAPおよびSSAPフィールドは0xAAの固定値を取ります（図6も参照）



注： LLC / SNAPフレーム形式を使用してIPパケットを転送する場合、IP MTUはそれぞれ1500バイトから1497バイトと1492バイトに削減されます。



フレーム形式の見出しによれば、原則としてすべてです。 フレーム形式の別のポイントであるペイロードサイズに注目したいと思います。 この範囲はどこから来たのですか-46バイトから1500バイトまで？

サイズL3ペイロード。

おそらく最初のCCNAカリキュラムを少なくとも読んだ人なら誰でも、下限がどこから来たのかを知っているでしょう。 この制限は、CSMA / CD方式によって重畳された64バイト（64バイト-14バイトL2ヘッダー-4バイトFCS = 46バイト）のフレームサイズ制限の結果です-ネットワークインターフェイスによる64バイトの送信に必要な時間は、環境内の衝突を判断するために必要で十分ですイーサネット

注：衝突が除外される最新のネットワークでは、この制限はもはや関係ありませんが、要件は残ります。 この時点で残った「付録」だけではありませんが、別の記事でそれらについて説明します。



しかし、これらの悪名高い15​​00バイトはどこから来たのか、問題はもっと複雑です。 私は次の説明を見つけました-フレームサイズの上限を導入するためのいくつかの前提条件がありました：

• 伝送遅延-フレームが大きいほど、伝送時間が長くなります。 コリジョンドメインがポートに限定されず、すべてのステーションが転送の完了を待たなければならなかった初期のネットワークでは、これは重大な問題でした。
• フレームが大きいほど、送信中にフレームが破損する可能性が高くなり、再送信が必要になり、コリジョンドメイン内のすべてのデバイスが再び待機するように強制されます。
• インターフェイスに使用されるバッファのメモリによって課される制限-当時（1979年）、バッファの増加により、インターフェイスのコストが大幅に増加しました。
• [長さ/タイプ]フィールドによって導入される制限は、1536を超えるすべての値（05-DDから05-FFまで）の規格で規定されています。それぞれEtherTypeを示し、長さは05-DC未満でなければなりません。 （これは前提よりも結果であるという疑いが本当にありますが、標準802.3の開発者からの情報のようです）

合計で、802.3標準では、フレームサイズは上から1518バイトに制限され、ペイロードは1500バイトに制限されていました（したがって、イーサネットインターフェイスのデフォルトMTUサイズ）。



注： 64バイト未満のフレームはラントと呼ばれ、1518バイトを超えるフレームはジャイアントと呼ばれます。 インターフェイスで受信したこのようなフレームの数は、 show interface gigabitEthernet module/number



およびshow interface gigabitEthernet module/number counters errors.



さらに、IOS 12.1（19）より前では、誤ったCRSと正しいCRSの両方のフレームがカウンターに行きました（後者は常にドロップしませんでしたが、プラットフォームと条件に依存します）。 しかし、12.1（19）からは、これらのラントとジャイアントフレームのみが、間違ったCRS、64バイト未満のフレームを持ち、正しいCRSを持つこれらのカウンターに表示されます（発生の理由は通常、802.1Q検出またはフレームソースに関連し、問題ではありません物理レベル）このバージョンからアンダーサイズカウンターに落ちる、彼らはドロップ、または前方に進む、プラットフォームに依存します。

イーサネットヘッダーサイズの進化。

技術と仕様の開発に伴い、IEEE 802ラインは変更され、フレームサイズが変更されました。 メインのさらなるフレームのサイズ変更（MTUではありません！）：

• 802.3AC-最大フレームサイズを1522に増やします-Qタグを追加します-802.1Q（VLANタグ）および802.1p（COSのビット）に関する情報を伝達します
• 802.1AD-最大フレームサイズを1526に増やし、QinQをサポート
• 802.1AH（MIM）-MacのプロバイダーブリッジバックボーンMac +フレームサイズに30バイト
• MPLS-ラベルスタック1518 + n * 4のフレームサイズを増やします。nはスタック上のラベルの数です。
• 802.1AE-Macセキュリティ、セキュリティタグ、メッセージ認証コードフィールド+フレームサイズ68バイトが標準フィールドに追加されます。

これらの特大のフレームはすべて同じ名前でグループ化されています-Baby -Giantフレーム。 Baby-Giantの暗黙の上限サイズは1600バイトです。 最新のネットワークインターフェイスは、HW MTUの値を変更しなくても、これらのフレームを転送することがよくあります。



それとは別に、802.3AS仕様に注意を払います-最大フレームサイズを2000に増やします（ただし、MTUサイズは1500バイトのままです！）。 増加はタイトルと予告編に該当します。 最初は、128バイトでの増加が計画されていました-上記の拡張の802.3標準によるネイティブサポートのために、最終的には2千に収束し、明らかに2回は収集されません（またはIEEEが言うように、このフレームサイズは予見可能な将来のカプセル化要件をサポートします）。 この規格は2006年に承認されましたが、IEEEのプレゼンテーションとは別に、私はそれを満たしていません。 誰かがここに（そしてここだけではなく）追加するものがある場合-コメントを歓迎します。 一般に、PAYLOADサイズを維持しながらフレームサイズを大きくする傾向があるため、選択した移動方向の正確性について、私の頭の中に漠然とした疑念が生じます。



注： FCoEフレームは上記とは別に設定されます-フレームサイズは最大2500バイトで、これらのフレームはミニジャンボと呼ばれます。 サポートするには、ジャンボフレームサポートを有効にする必要があります。



そして最後のイーサネットのろくでなしはジャンボフレームです（ジャンボを翻訳すると、Hodorが迫っている可能性が高くなります-Game of Thronesへの参照）。 1518バイトの標準サイズを超えるすべてのフレームは、上記で説明したものを除き、この説明に該当します。 ジャンボパッケージは802.3の仕様に反映されていないため、実装は特定のベンダーの良心にとどまります。 ただし、イーサネットが存在する限り、ジャンボフレームは存在します。 次のように定義されます。

1. ペイロード対ヘディング比の利点。 この比率が大きいほど、通信回線をより効率的に使用できます。 もちろん、ここでのギャップは、TCPセッションで64バイトと1518バイトのパケットを使用する場合と比較して同じではありません。 ただし、トラフィックの種類に応じて、3〜8％を獲得できます。
2. ヘッダーの数が大幅に少ないと、Forwading Engineおよびサービスエンジンの負荷が小さくなります。 たとえば、1500バイトのフレームをロードした10Gリンクのフレームレートは812 744フレーム/秒に等しく、9000バイトのジャンボフレームをロードした同じリンクは、わずか138 587フレーム/秒のフレームレートを生成します。 図7は、使用されているフレームサイズのタイプに応じて、Alteon Networksレポートのグラフを示しています（リンクは記事の下部にあります）CPU使用率とギガビットリンク。
3. MTUのサイズを変更する際のTCPスループットの増加-staff.psc.edu/rreddy/networking/mtu.html

図 7



このコインには欠点があります：

1. フレームが大きいほど、送信される時間が長くなります（図8）。
2. ネットワークデバイスのメモリ内のバッファはより速くいっぱいになり、望ましくない結果を引き起こす可能性があります。 実際、機器設計の段階で解決できますが、コストが増加します。
3. 各メーカーの独自の実装-すべてのデバイスは、同じジャンボフレームサイズまたはサイズセットをサポートする必要があります。
4. 実際、ジャンボフレーム検出メカニズムがないため、異なる管理制御下で大規模なネットワークエリアを使用することはできません。中間ノードは、ジャンボフレームをまったくまたは特定のサイズでサポートしない可能性があります。

図8



要するに、ジャンボフレームを使用する長所と短所は、このフレームサイズをどこで使用できるかを明確に示しています。 それで、データセンターのどのアプリケーションで、すべての利益のためにジャンボフレームを使用できますか？ このようなリストがあります（アドオンは大歓迎です）：

• サーバークラスター内
• バックアップするとき
• ネットワークファイルシステム（NFS）プロトコル
• iSCSI SAN
• FCoE SAN

注：ジャンボMTUにはサイズの上限もあります。 FCSフィールドのサイズ（4バイト）と巡回冗長検査アルゴリズムによって決定され、11 455バイトです。 実際には、ジャンボMTUは通常、9216バイト、一部のプラットフォームでは9000バイト、古いハードウェアでは8092バイトに制限されています（Ciscoについて話してください）。



ふう、基本的にすべて。 理論的に考えたいこと、考えたこと。 MTUサイズの構成と、これら3文字の背後にあるかすかな理論によると、前回の記事「Maximum Transmission Unit（MTU）。 神話とサンゴ礁。」



結論として、Alteon Networksレポート「次世代イーサネットの拡張フレームサイズ」への約束されたリンク-staff.psc.edu/mathis/MTU/AlteonExtendedFrames_W0601.pdf 、および次の記事の小さなアナウンス-物理層まで、さらに低くなります- CSMA / CD、エンコーディングの重い遺産に対処し、歩き回って、話題から何かをキャッチします。