概要
このドキュメントでは、パディング情報が破損または不正な場合に、Cisco Nexus 9000でイーサネットパケットが破損した場合のトラブルシューティング方法について説明します。
背景説明
イーサネットフレームの最小サイズは、VLANタグが存在するかどうかに関係なく、64バイトです。
最小のイーサネットペイロードサイズは次のとおりです。
- VLANタグがない場合は46バイト。
- VLANタグが存在する場合は42バイト。
この事実を確認できます。
イーサネットパケットの最小サイズは、VLANヘッダーが存在するかどうかに関係なく、64バイトです。サーバは、VLANを含む64バイト長のパケットを送信できます。これは、正しく受け入れられ、処理されます。
注:この動作は、Nexus 9000ではなくCatalyst 4500xによって正しく処理されます。
スイッチによるパケットの処理方法
ステップ1:有効な64バイトのイーサネットフレームを受信します。
ステップ2:フレームチェックシーケンス(FCS)を削除して、パケットの長さを60バイトにします。
ステップ3:VLANタグを削除して、パケットの長さを56バイトにします。
ステップ4:パディングを追加して、パケットの長さを60バイトにします。
ステップ5:FCSを追加し、パケットの長さを64バイトにします。
パケットがカットスルースイッチを通過する場合、パディングは変更されません。
トラフィックがN9Kを通過するときにタグ付きVLANでパディングが変更される
ゼロでパディングする代わりに、パケットはガベージキャラクタでパディングされます。ほとんどの場合、チェックサムが変更されず、これらのデータを使用するユーザがいないため、影響を受けません。ただし、お客様が特別な用途を持ち、チェックサムを再計算する必要がある場合、これらのガベージデータは最後にチェックサムの破損につながります(NAT/ロードバランサなどの他のアプライアンスでも問題が発生する可能性があります)。
デバイスはN9K 93120TX(最初は9372TXで検出されましたが)、バージョンは最新のNXOS 7.0(3)I2(2a)です。
ここで、N9Kに直接接続されたハードウェアを持つLinuxホストを使用します(いかなる仮想化も行いません)(1000base-Tリンク)。
次の設定を使用ます。
interface Ethernet1/59
switchport mode trunk
!
interface Ethernet1/60
switchport mode trunk
linux configurations:
inet 10.2.1.1/24 brd 10.2.1.255 scope global eth1 <= native vlan
inet 10.1.1.1/24 brd 10.1.1.255 scope global eth1.100 <= taggued vlan 100
または
Windowsホストを接続し、タグ付きフレームを送信するだけで、問題が発生します。さらに、ネットワークインターフェイスカード(NIC)にパケットのタグ付け機能があることを確認します。
スイッチは、通過するフレームにゼロ以外のパディングを追加します。
例:Host:[Trunk] N9K [Trunk] – ホスト
netcatを使用してパケットを送受信できます。
図に示すように、スイッチではサイド(タグ付きVLAN 100)ポートe1/59を送信します。
図に示すように、スイッチでサイド(タグ付きVLAN 100)ポートe1/60を受信します。
図に示すように、パケットが送信されます。
次の図に示すように、パケットが受信されます。
図に示すように、誤ったパディングが強調表示されます。
これは、パケットアナライザでも表示されます(別のパケットでは、データは前のスクリーンショットとは異なりますが、テストとバグは同じです)。
解決方法
このサーバが接続されているインターフェイスでバッファブーストを無効にすることが回避策です。
C9396PX-1(config)# int et 1/7
C9396PX-1(config-if)# no buffer-boost
関連の欠陥:
CSCva46849 N9kでのdot1qヘッダーL2スイッチングを使用した60バイトフレーム