キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
cancel
1997
閲覧回数
0
いいね!
3
返信

CAMテーブルとARP

nwatarai
Level 1
Level 1

現在、Cat3750とCat2960で構成されたスイッチ環境でVLAN10と11を使用しています。Cat3750にはL3機能をそしてCat3750とCat2960はtrunkで接続しています。通常、端末AはVLAN10でCat3750に接続されており、端末BはVLAN11でCat2960に接続されL3を挟んで通信しています。端末Bは特殊な端末で端末Aからのポーリング(UDP)を持って応答を返すという動きで端末B自ら動き出すということはしません。

そのような環境下で端末Bを2960の現在接続されているPortの隣のPortに移動しました。もちろんVLAN11です。

ところが端末AからPingを実行してもリプライが返って来ません。

Cat2960のMAC Addressテーブルを見ましたがそこでは端末BのMACが見えません。

そこで念のためMACテーブルをクリアしましたが状況は変わらず。

一度元のPortに戻したところ正常に動きます。MACテーブル上にももちろん見えます。

再度隣のportへ接続しなおしCat2960のMACテーブルをクリアしましたがリプライが返って来ません。

そこで上位のCat3750のarpテーブルをクリアしたところ正常にリプライが返ってくるようになりました。

メカニズムが理解できません。お分かりになる方教えてください。

3件の返信3

t-yamashita
Level 7
Level 7

こんにちは。亀レスで恐縮ですが・・

L3 の ARP テーブルをクリアすると通信が可能になるとのことですが、IP と紐づけられている MAC アドレスについて教えてください。

  • 状況から考えると端末 B のものになるとは思いますが、正しいでしょうか?
  • また、端末 B を収容するポートの変更前と変更後でど同様のものでしょうか?
    違う場合は、それぞれどこの MAC アドレスになるかご確認ください。

どうぞよろしくお願いします。

返答準備中です。少々お時間を。

Yasuhiro Nakajima
Cisco Employee
Cisco Employee

こんにちは

>Cat2960のMAC Addressテーブルを見ましたがそこでは端末BのMACが見えません。

>そこで念のためMACテーブルをクリアしましたが状況は変わらず。

2960が端末BのMACを学習していないのであれば、端末Bは自身がソースとなるパケットを送信していない可能性があります。

もちろんEcho Replyもです。

Echo Replyを返さない原因としては、

-端末B宛てのEcho Requestが端末Bに届いていない

-端末B宛てのEcho Requestが端末Bに届いているが、何らかの理由でEcho Replyを送信できない

といった可能性が考えられます。

>そこで上位のCat3750のarpテーブルをクリアしたところ正常にリプライが返ってくるようになりました。

端末Bが複数NIC構成であり、Portを移動した際に端末Bの異なるInterfaceが2960に結線されていた(Macが変わる)という事はないでしょうか。

何れにせよ、この情報だけでは何が起こっているのか判断できませんので、この現象を詳細に確認したいという事であれば、現象が発生している際の以下の情報が必要だと思います。

----------------------------------------------------------

以下の機器のARP table

端末A

端末B

3750

以下の機器のMac Address table

3750

2960

以下の機器の設定情報(IP/MAC、Interface設定等)

端末A

端末B

3750

2960

-----------------------------------------------------------