trunkポートにunknown unicast traffic 最終的にudp通信になったことが影響しているというケースでの事象がありました。
情報元はこちら。
unicast nfs traffic seen on all trunks - Cisco Community
以下は質問の抜粋です。
すべてのトランクリンクで確立されたnfsトラフィックを（スニフ経由で）確認している状況です。
確立されたnfsトラフィックを確認しています。srcとdestのIPを見ることができ、特定のデータベースジョブが実行されると、トラフィックカウントが増加します。
特定のデータベースジョブが実行されると、トラフィック数が増加します。しかし、srcの最初のブロードキャストの後に、どのようにして
なぜ各トランクリンクでトラフィックが見られるのか、srcの最初のブロードキャストでdest ipを見つけた後、解明できません。
各トランク・リンクにトラフィックが発生する理由がわかりません。基本的なハブ＆スポークで、コアには6509、スポークには4000が使用されています。
ディレクテッド・ブロードキャストも許されません。
例を挙げます。コアAとB、スポークC,D,E,F,G
トラフィックはCからコア(A/B)を通ってDに戻りますが、E,F,Gのトランクリンクは
トラフィックを確認します。
この件について、何かご意見がありましたら、あるいは他にどこを調べればよいか教えてください。
すべてのtrunkポートにて、NFS通信のunicast バーストトラフィックがでたというものです。
通常、これは未知のユニキャストフラッディングが行われることを意味します。理由はいくつかあります。まず、トラフィックを受信しているホストが、MAC アドレステーブルのタイムアウト（デフォルトでは 5 分）以内に送信元 MAC を持つフレームを送信していない可能性があります。解決策：このホストから1分ごとにpingを実行してください（小さなスクリプト）。
次に、HSRPとスパニングツリーが関係している可能性があります。基本的な理由と可能な問題解決策は、以下のサイトにある「Unicast Flooding in Switched Campus Networks」でよく説明されています。
http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00801d0808.shtml
これで問題が解決したかどうか、確認していただけますか？解決していない場合は、お客様のシナリオに関する詳細な情報を提供してください。
お役に立てれば幸いです。評価システムをご利用ください。
基本的にはNWの構成によって非対称通信が発生する場合におこります。
この記事は以前にも見たことがあります。簡単な形で言うと、2つのホストが1つのスイッチを経由して、ftpやnfsを行うというものです。ターゲットのmacアドレスがmacテーブルから外れてしまい、フラッディングの原因となります。ターゲットへのpingを設定し、5分未満（エイジアウト前）にpingを行うと、フラッディングは全く発生しません。非常に長いftpセッションやnfsの間に、ターゲットのmacがage outになることが理解できません。 よろしくお願いします。
非常に長いftpセッションやnfsの間に、ターゲットのmacがage outになることが要因となっています。
これは結局 udp トラフィックでした。nfsサーバは、クライアントに対して、tcp接続の確認やキープアライブなどの応答を一切行いません。そのため、サーバーのマクダディがタイムアウトし、スイッチはそれがどこにあるのかわからず、トラフィックが殺到してしまいます。サーバーに定期的に（5分未満）pingを打つように設定すると、テーブルの中でmac-addを新鮮に保つことができ、フラッディングが止まりました。nfsクライアントとサーバーの間でkeep aliveを送信することや、フラッディングを制限するためにプルーニングを有効にすることを検討しています。
 |
