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

ACIのEnd Pointの仕様

Takayuki Yagi
Level 1
Level 1

基本的なことかもしれませんがACIのEnd Point周りの仕様について確認させてください。

1.ACIのEnd Pointの学習方法について
ACIではARPだけではなく、データプレーンからも学習する認識でおりますが正しかったでしょうか。
この際、L2BD/L3BDで挙動が変わったりしますでしょうか。
また、IP/MACの学習それぞれで挙動が変わりますでしょうか。

2.ACIのEnd Pointのマッピング情報更新について
該当End Pointからの通信を契機にマッピング情報の更新が走るとの認識で正しいでしょうか。
(ARP応答やGARP,RARPなどでしか更新されない仕様などないでしょうか)
この際、フラッピング抑止などの目的などで更新までにラグなどありますでしょうか。
また、End PointがIFを跨いで移動した場合に挙動に差異はありますでしょうか。
(IFを跨いだ移動の場合は通信断が起きる可能性はありますでしょうか?)

3.End PointのAgingについて
学習したEnd PointのAgeはどれぐらいになりますでしょうか?

4.本事象を解析するにあたって、ACI側で確認すべきコマンドは何かありますでしょうか。

以下が必要になるかと考えております。
show endpoint
show mac address-table
show ip arp vrf all

--------------------------------------------------------------------------------------
■背景
弊社の環境でACIをGWとした仮想マシンをNSX-V環境からNSX-T環境へvMotionした際に、
タイミングによっては30秒弱の通信断が発生するという事象が確認されています。
(※NSX-VではESXi上のカネールモジュールでBridgeされ、
NSX-Tでは専用のEdgeVMでBridgeされるという差異はありますが同一のVLANを利用しています。)
仮想マシン上でパケットキャプチャを確認したところ、
GWのMACが変更されていないのにもかかわらずvMotionを契機にPingの応答がなくなり、
GWアドレスへのARPの解決要求が返ってきたタイミングで通信が復旧していました。

VMware 社で再現試験を行った場合は瞬断で収まり、同事象は起きていないとのことです。
VMware社の環境と異なる箇所がACIになるため動作の確認をさせていただいております。
1件の返信1

ARX0
Level 1
Level 1

質問された内容について ACI Endpoint Learning White Paperに情報があります。
https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-739989.html
また、日本語だと下の記事が参考になると思います。
https://community.cisco.com/t5/tkb-%E3%83%87%E3%83%BC%E3%82%BF%E3%82%BB%E3%83%B3%E3%82%BF%E3%83%BC-%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%88/aci%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA-8-aci-endpoint-learn...

>1.ACIのEnd Pointの学習方法について

これはdata-plane learningに関連する設定で挙動が変わりますが、どういった学習の挙動をするかについてはWhite Paperの「Table 2. Endpoint learning behaviors comparison」に詳しい比較があります。

>2.ACIのEnd Pointのマッピング情報更新について
>3.End PointのAgingについて

これらについてはWhite Paperの「Aging of endpoints」に詳しく書かれています。
フラッピングの抑止については「Rogue EP Control」に詳しく記載があります。
別のIFに移動した場合はACIがそのEPが別の場所に移動したことを認識するまでは、そのEP宛の通信が失敗すると思います。
(移動したことを認識しないと移動先にパケットを転送できないため)

>4.本事象を解析するにあたって、ACI側で確認すべきコマンドは何かありますでしょうか。

まず、ACIはendpoint tableでホストを管理しており、L3Out以外ではmac address tableやarp tableを利用しないため恐らく参考になりません。
これはWhite Paperの「Cisco ACI and endpoints」に書かれています。
下のページに書いてあるようなコマンドが参考になるんじゃないかと思います。
(show system internal epm endpoint mac や show system internal epm endpoint ip など)
https://community.cisco.com/t5/tkb-%E3%83%87%E3%83%BC%E3%82%BF%E3%82%BB%E3%83%B3%E3%82%BF%E3%83%BC-%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%88/endpoint-table-%E3%81%8B%E3%82%89%E3%81%AE-remote-leaf-%E3%81%AE%E7%89%B9%E5%AE%9A%E6%96%B9%E6%B...


>GWのMACが変更されていないのにもかかわらずvMotionを契機にPingの応答がなくなり、
>GWアドレスへのARPの解決要求が返ってきたタイミングで通信が復旧していました。

ふと思ったのですが、上は他のホストからvMotionしたVMにpingした場合ですか?
後、そのVMはvMotion後に自発的にパケットを出していないなどありませんか?
上の質問に両方とも「はい」なら、ACIがそのVMが別IF配下に移動したことを認識できないため、
vMotion前にいたIFにパケットが転送されて、ARP解決で認識してちゃんと転送されるようになったように見えます。

最後に細かいですが、使っているversionや機材や通信の詳細は書いたほうが良いと思います。。。