- PR -

スイッチングしていない？

1|2 次のページへ»
投稿者投稿内容
悩める子豚
会議室デビュー日: 2005/06/10
投稿数: 13
投稿日時: 2005-06-10 16:45
初めて投稿させていただきます。
もしお判りになる方いらっしゃいましたら、ご教授ください。

・Catalyst3550をサーバ接続用として使用
・下位へのポートは全てswitching、accessポート、同一VLANで設定
・現在３台のサーバを接続
・ある１台のサーバ上でパケットをキャプチャしたところ、他の２台の
　サーバ宛のパケット（ユニキャスト）を確認（数個というレベルで
　なく、大量に出ている)
・arpテーブル、macテーブルとも異常は見受けられない
・３台のサーバとも正常に稼動中

本来スイッチにてmac-address-tableから正しくスイッチングが
行われていれば、他のポートへデータは流れないはずです。
しかし、スイッチングがされていない、いわゆるバカハブのような
動きに見えます。

私の調べた限り、macテーブルにないパケットがきたことで
フラッディングする場合しかない気がするのですが、
３台とも正常に稼動しているということで、その可能性も
低いのではないかと思います。

似たような経験をお持ちの方いらっしゃいましたら、情報ご教授頂けないでしょうか。
m.ku
大ベテラン
会議室デビュー日: 2002/09/15
投稿数: 184
投稿日時: 2005-06-11 11:39
From/Toが何で、どのタイプのパケットが、どの程度流れているかを
具体的に調べてみれば良いのでは？　L3スイッチならその設定とポート次第で
ずいぶん変化がつきますが。クライアント→サーバ間でファイルを転送するなら
クライアント側でもパケット数は見えますし、詳しく知りたいなら各種プロトコル
シーケンスは専門書見れば載ってるので、必要に応じて資料を当たればよいかと。

つまり簡単に済ますなら、パケット数という物量で調査する方法がひとつ。
それで不足なら、トラフィック内容という中身まで突っ込んだ話での調査が
必要になります。なお、スイッチを含めた各機器上のログの有効活用も
時間節約には大事です。(詳細は各機器/ソフトの、マニュアル/WEB上のFAQを参照)
悩める子豚
会議室デビュー日: 2005/06/10
投稿数: 13
投稿日時: 2005-06-15 11:03
m.ku様、ご返信ありがとうございます。
他の皆様もご参照頂きありがとうございます。
色々調べごとをしていて返信が遅くなりました。

長文で恐縮ですが、もしよろしければご一読頂ければ幸いです。

ご教授頂いた通りパケットの数でもって状況を見てみました。スイッチに接続された３台の
サーバのうち、１台のサーバ上（※これをサーバA、他をサーバB,Cとします)で採取した
パケットを見ると、
(from:他セグメントPC to:サーバB,C)
というパケットが出ていました。
逆向き(from:サーバB,C to:他セグメントPC)はありませんでした。

片方向の余計なパケットしか出ていないことから、どうもスイッチ上にてフラッディングが
起きているのではないかと色々調べていたところ、該当するのではないかと思われる情報
にたどり付きました。

ポイントとしては、
・スイッチ上でHSRPで冗長化している(※activeをスイッチA、standbyをスイッチBとします）
・サーバAはスイッチBにのみ接続している
・サーバB,CはスイッチA,Bに接続している(teamingというようです)

（　　外部ネットワーク　　）
　│　　　　　　　　　│
　│　　　　　　　　　│
スイッチA　──　スイッチB
(active)　　　　(standby)
　│　　　　　　　　　│　│
　│　　┌────┘　│
　│　　│　　　　　　　　│
　サーバB,C　　　サーバA

この状況で、「スイッチB」上にて、「サーバB,Cのmacテーブルエントリがないときがある」
ことを実際に確認しています。
スイッチA,BともOSPFにて外部ネットワークと接続しており(スイッチA,B間もルーティング
しています)、等コストのため、外部ネットワークから送られてくるパケットはスイッチAで
受けることもあればスイッチBで受けることもあります。

以上より、
１．外部ネットワークから送られてくるパケットをスイッチBでうけとる
２．スイッチB上にサーバB,Cのmacテーブルエントリがない

…という状況となった時にフラッディングが発生し、サーバVLAN全ポートにパケットが
送出されているのではないかと考えています。

なおここでのスイッチはcatalyst3550です。catalyst6500でのVRRPでの動作実績は
あったのですが、3550ではVRRPが組めなかったため已む無くHSRPにした経緯があります。

なぜmacテーブルエントリがない状況があるのか、また、VRRPとHSRPの振る舞いに違いが
あるのかについて調査を進めている次第です。

過去ログにも似たような話題がありましたので、ご参考まで。

件名：冗長構成時のARP代理応答について(不具合では？)
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?mode=viewtopic&topic=18744&forum=11&start=0

件名：MACアドレスを共有する冗長化における、スイッチのMAC学習の影響
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=19888&forum=11

もしお気づきの点などありましたら、どんなことでも構いませんのでご教授下さい。
長々と大変失礼致しました。

[ メッセージ編集済み 編集者: 悩める子豚 編集日時 2005-06-15 11:06 ]

[ メッセージ編集済み 編集者: 悩める子豚 編集日時 2005-06-15 11:07 ]
m.ku
大ベテラン
会議室デビュー日: 2002/09/15
投稿数: 184
投稿日時: 2005-06-15 13:28
既読か否かは分かりませんけど、参考までに本家のリンクをひとつ。
catalyst3550 TECHNICAL SUPPORT
(下の方に類似の情報がありますし、巡っていけば対処方法なども幾つか載ってます)
悩める子豚
会議室デビュー日: 2005/06/10
投稿数: 13
投稿日時: 2005-06-16 10:45
m.ku様、情報ありがとうございます。

本家の方では、ここがまさに該当しているのではないかと思いました。
事例 8：非対称ルーティングと HSRP（HSRP を実行しているルータが接続された
ネットワークでの、ユニキャスト トラフィックの過剰なフラッディング）
http://www.cisco.com/japanese/warp/public/3/jp/service/tac/473/62-j.shtml#t8

込み入った内容ではありますが、一通り読み終えて、２つの疑問が出てきました。
もはやこのような疑問はメーカに直接問い合わせるべきなのかもしれませんが、
もしよろしければで結構ですので、以下ご一読下さい。

＜１つ目＞
　項番３で
　＞パケット(ホストAからホストBへのPING echo request)を受信したMSFC1は、
　　そのパケットを書き換えてホストBに転送します。
　VLAN2に属するホストBへの転送を、VLAN2standbyであるMSFC1がなぜ処理して
　しまうのか。HSRPの仕様？

＜２つ目＞

　当件の原因は、ARPタイムアウト(デフォルト４時間）に対し、MACエージングタイム
　(デフォルト５分）と短いため、MACテーブルから該当情報が消えた後、MACテーブル
　への再登録をさせる手段がないためである、と読み取りました。(唯一再登録させる
　手段は、ARP処理)

　＞この状況に対処するには、次の 3 通りの設定変更(MAC エージング タイムとARP
　タイムアウトを合わせる)が考えられます。

　MAC エージング タイムとARP タイムアウトを合わせることは理解できるが、タイム
　アウトとなる同期がとれていないと、結局同じ状況(ARPは登録されているがMACテー
　ブルにはない)が発生するのでは？

メーカに直接問い合わせたことはないので、問い合わせ可能かどうか不安はありますが、
なんとか解決したいと思います。

ご意見・お気づきの点などありましたら、どうぞよろしくお願い致します。

[ メッセージ編集済み 編集者: 悩める子豚 編集日時 2005-06-16 10:47 ]
くおん
大ベテラン
会議室デビュー日: 2004/07/26
投稿数: 154
投稿日時: 2005-06-16 11:30
こんにちわ。

引用:
＜１つ目＞
　項番３で
　＞パケット(ホストAからホストBへのPING echo request)を受信したMSFC1は、
　　そのパケットを書き換えてホストBに転送します。
　VLAN2に属するホストBへの転送を、VLAN2standbyであるMSFC1がなぜ処理して
　しまうのか。HSRPの仕様？

物理的にホストAはMSFC1に、ホストBはMSFC2に接続されています。そのため、ホストAからホストBへのパケットの転送で、
ホストAからMSFC1へ、MSFC1からMSFC2へ、そしてMSFC2からホストBという流れになります。
物理的に通過するインターフェイスが異なる為、パケットのMACアドレス部分は当然書き換える必要があります。
また、MSFC1がVLAN2Standbyであっても物理的に接続されている為、MSFC1が処理を行います。

引用:
＜２つ目＞

　当件の原因は、ARPタイムアウト(デフォルト４時間）に対し、MACエージングタイム
　(デフォルト５分）と短いため、MACテーブルから該当情報が消えた後、MACテーブル
　への再登録をさせる手段がないためである、と読み取りました。(唯一再登録させる
　手段は、ARP処理)

確かに１回目はずれが発生すると思いますが、２回目のARPでARPテーブルとMACテーブルで同期がとれる思います。
悩める子豚
会議室デビュー日: 2005/06/10
投稿数: 13
投稿日時: 2005-06-17 12:22
くおん様、ご返信頂きありがとうございます。

引用:
物理的に通過するインターフェイスが異なる為、パケットのMACアドレス部分は当然書き換える必要があります。
また、MSFC1がVLAN2Standbyであっても物理的に接続されている為、MSFC1が処理を行います。

私が難しく考えぎているのですが、こう考えてしまうのです。
・MSFC1はVLAN1→VLAN2へルーティングしようとする
・VLAN2へルーティングするためのVLAN2activeはMSFC2
・MSFC1はMSFC2へ転送(宛先macはMSFC2)(ルーティング処理)
・MSFC2はホストBへ転送(宛先macはホストB)(スイッチング処理)

でも実際はおそらくこうなんですよね。
・MSFC1はVLAN1→VLAN2へ内部ルーティング
・MSFC1はMSFC2へ転送(宛先macはホストB)(スイッチング処理)
・MSFC2はホストBへ転送(宛先macはホストB)(スイッチング処理)

ややこしい変な話をしてすみません。
そういうものである、と覚えた方がよいのでしょうか。。。

引用:
確かに１回目はずれが発生すると思いますが、２回目のARPでARPテーブルとMACテーブルで同期がとれる思います。

これは、ARPでmacエージングタイマがリセット(再登録)されると解釈したのですが、
合っていますでしょうか。確かにそれだと同期をとることができますね。
EL
会議室デビュー日: 2005/06/22
投稿数: 2
投稿日時: 2005-06-22 17:54
こんにちは

・MSFC1はVLAN1→VLAN2へルーティングしようとする
・VLAN2へルーティングするためのVLAN2activeはMSFC2

MSFC1自身がVLAN1で受け取ったパケットをVLAN2に転送するのに、
VLAN2のHSRPの状態は気にしないと思うのですが。
MSFC1の転送表では、VLAN2が自分のインタフェース直結されている
と見えているので、それを参照し、そのインタフェースに流すと思
います。

MSFC1,2が、VLAN2上でのHSRPの状態（ACTIVE/STANDBY）を参照するのは、
あくまで、VLAN2からうけとる他サブネット宛てのパケットを自分
が処理するか・否かを決める時だと思います。VLAN1についても同じ。

シスコのWEBの例ではVLANごとのACTIVEルータをMSFC1、MSFC2にわけてい
るので、通信（行きと戻りで通るルータ）が非対称となる、というふうに
書かれているのだと思います。
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）