2019-04-24 10:01 AM - 最終編集日: 2023-10-06 01:51 PM 、編集者: JapanTAC_CSC
本ドキュメントでは、ACI L3Out Routing における基本的なトラブルシューティング例について説明します。
※ L3Outについては こちらを参照ください。
※ ACI Version 4.1 での確認結果をもとに掲載しております。
※ 実際のご利用環境の構築/設計/トラブルシューティングにあたっては Cisco.com に公開されているコンフィギュレーションガイド、デザインガイド、トラブルシューティングガイド等をご参照ください。
※ Cisco.com ドキュメントの記載と本ドキュメント記載に差異がある場合は Cisco.com ドキュメントの記載を優先してください。
※ 本ドキュメントは、下記 ACI構成におけるトラブルシューティング例になります。
今回の以下のように 外部ネットワークから、Leaf103/104 (Server Leaf) に接続された Server-A にアクセスする例となります。また、論理的には 外部ネットワークは Tenant: Cisco(vrf1)、Server-A は Tenant: Datacenter(vrf2) に属しています。
Version は4.1(1i)、Leaf Switch は EXシリーズを使用しています。
※Access Policyをはじめ、Tenant, VRF, BD、External Routed Network等の設定は全て済んでいることを前提としています。
ここでは設定のポイントを補足しておきます。
(1) External Routed Networks『External Network Instance Profile』のSubnets 設定で、1.2.3.4/32 を指定し、下記のScopeにチェックを入れます。これは VRF間でルートをShareさせて通信を許可するために必要です。
- External Subnets for the External EPG
- Shared Route Control Subnet
- Shared Security Import Subnet
(2) Server-Aのが属するEPGでSubnetを設定し、Scope "Shared between VRFs" にチェックを入れます。
Shared ServiceのBest Practiceとしては Provider側のEPG配下に Shared Subnet を設定する方法が推奨です。
(3) Contract設定
Server-A EPGで Provided Contractを設定し、それを Cisco TenantにExportさせます。
さらに、External Routed Networks『External Network Instance Profile』で Consumed Interface に適用します。
※ 参考: Configuring Inter-Context Communication
先ず Boarder Leafで 外部ルート (1.2.3.4/32)を学習しているかを確認します。
ここで学習していない場合は、L3Outの設定や外部ルータとのNeighbor確立(この例ではOSPF)、またはルート配信が正しく行われていないなどの問題が考えられます。
Boarder Leaf |
---|
leaf3# show ip route 1.2.3.4 vrf Cisco:vrf1 -- snip --
1.2.3.4/32, ubest/mbest: 1/0 *via 192.168.2.100, vlan104, [110/5], 1d23h, ospf-default, intra |
例)OSPF Neighborの確認方法
Boarder Leaf |
---|
leaf3# show ip ospf neighbors vrf Cisco:vrf1 OSPF Process ID default VRF Cisco:vrf1 Total number of neighbors: 2 Neighbor ID Pri State Up Time Address Interface 4.4.4.4 1 FULL/BDR 1d23h 192.168.2.201 Vlan104 1.2.3.4 1 FULL/DR 1d23h 192.168.2.100 Vlan104 |
また、Boarder Leaf 側には Server-Aの Subnet (100.125.255.0/24) が importされていることを確認してください。
このSubnetがない場合は 上記 2.設定のポイント(2)の設定で EPG のSubnet で"Shared between VRFs" がチェックされていないことが考えられます。
Boarder Leaf |
---|
leaf3# show ip route 100.125.255.0 vrf Cisco:vrf1 -- snip -- 100.125.255.0/24, ubest/mbest: 1/0, attached, direct, pervasive *via 10.0.112.65%overlay-1, [1/0], 00:00:50, static, tag 4294967295 recursive next hop: 10.0.112.65/32%overlay-1 |
次に Server Leafで 外部ルート(1.2.3.4/32) を学習しているかを確認します。
ここで学習していない場合は、2.設定のポイント(1)の設定で 必要なScopeにチェックが入ってない、または 2.設定のポイント(3)の Contract の設定が誤っているなども問題が考えられます。
下記の例では MP BGP経由で学習した Nexthop として tep address 10.0.64.127と10.0.136.65の2つ出力されていますが、これは Leaf4とLeaf3を指しています。
tep address がどのnodeを指しているかは acidiag fnvread で確認ができます。
Server Leaf |
---|
leaf1# show ip route 1.2.3.4 vrf Datacenter:vrf2 -- snip -- 1.2.3.4/32, ubest/mbest: 2/0 *via 10.0.64.127%overlay-1, [200/5], 1d23h, bgp-101, internal, tag 101 recursive next hop: 10.0.64.127/32%overlay-1 *via 10.0.136.65%overlay-1, [200/5], 1d23h, bgp-101, internal, tag 101 recursive next hop: 10.0.136.65/32%overlay-1 |
TEP と Node の確認
Server Leaf |
---|
leaf1# acidiag fnvread ID Pod ID Name Serial Number IP Address Role State LastUpdMsgId ---------------------------------------------------------------------------------------------------- 103 1 leaf3 FDO21162J7H 10.0.136.65/32 leaf active 0 104 1 leaf4 FDO21162HY8 10.0.64.127/32 leaf active 0 -- snip -- |
上記3,4の確認でルートがあるにも関わらず通信が出来ない場合は、Contractも確認してみてください。
事前準備として 対象の VRF VNID (scope)を確認しておきます。
GUIから確認する場合は vrf policy の segment Id が VRF VNID (scope)にあたります。
コンソールから確認する場合は "moquery -c l3Ctx" で確認できます。ここれでは egrep optionで必要な情報のみ出力させています。
Boarder Leaf |
---|
leaf3# moquery -c l3Ctx | egrep "\#|encap|ctxPKey|scope" -- snip -- # l3.Ctx encap : vxlan-3047430 ctxPKey : uni/tn-Cisco/ctx-vrf1 scope : 3047430 |
Server Leaf |
---|
leaf1# moquery -c l3Ctx | egrep "\#|encap|ctxPKey|scope" -- snip -- # l3.Ctx encap : vxlan-2850819 ctxPKey : uni/tn-Datacenter/ctx-vrf2 scope : 2850819 |
上記の方法で確認した VRF VNID(scope)を使って、Contract が適用されているかを確認していきます。
※ 以下では Boarder Leaf側で確認しますが、確認方法は Server Leaf側でも同じですので両方の Leafで確認するようにしてください。
先ず 適用されている Rule は show zoning-rule scope <VRF VNID> で確認できます。
Boarder Leaf |
---|
leaf3# show zoning-rule scope 3047430 +---------+--------+--------+----------+---------------+---------+---------+------------+----------+-----------------------+ | Rule ID | SrcEPG | DstEPG | FilterID | Dir | operSt | Scope | Name | Action | Priority | +---------+--------+--------+----------+---------------+---------+---------+------------+----------+-----------------------+ | 4122 | 0 | 0 | implicit | uni-dir | enabled | 3047430 | | deny,log | any_any_any(21) | | 4123 | 0 | 0 | implarp | uni-dir | enabled | 3047430 | | permit | any_any_filter(17) | | 4124 | 0 | 15 | implicit | uni-dir | enabled | 3047430 | | deny,log | any_vrf_any_deny(22) | | 5637 | 84 | 0 | implicit | uni-dir | enabled | 3047430 | | deny,log | shsrc_any_any_deny(12)| | 4252 | 5518 | 84 | 306 | bi-dir | enabled | 3047430 | server_ssh | permit | fully_qual(7) | | 4247 | 84 | 5518 | 307 |uni-dir-ignore | enabled | 3047430 | server_ssh | permit | fully_qual(7) | +---------+--------+--------+----------+---------------+---------+---------+------------+----------+-----------------------+ |
この例では、 DstEPG 5518 = External EPG、SrcEPG 84 = Server-A (100.125.255.10/24) を指しています。 この zoning-rule が無い場合は、Contractの設定に問題があることが考えられます。 EPG (External EPG 含め) sclass (pcTag) は GUIまたはCLIで確認出来ます ※ 末尾 Appendix-1を参照
上記の結果から、FilterID 306 / 307 の条件にマッチした 5518 --> 84 / 84 --> 5518 の通信が permit されていることがわかります。
この例では Filter ID は ssh (tcp22)の通信を許可しており、Contract Subjectで Reverse Filter Ports にチェック (bi-dir) を入れています。
show zoning-rule / filter ID の詳細な確認方法については、ACI: Contract/Filter の確認を確認ください。
次に policy-mgr stats を確認し、マッチする Rule ID のPktsがカウントされているかを確認します。
許可した通信が行われれば この例では Rule ID 4252がカウントされます。
ここがカウントしない場合は、Boarder Leaf 側で Server-Aの Subnet が import されていなかったり、Contractの設定に問題があることが考えられます。
また、許可しない通信が発生した場合は、暗黙のdeny である implicit deny の Rule ID がカウントされます。この例では Rule 4122 が 暗黙のdeny
Boarder Leaf |
---|
leaf3# show system internal policy-mgr stats | grep 3047430 Rule (4122) DN (sys/actrl/scope-3047430/rule-3047430-s-any-d-any-f-implicit) Ingress: 0, Egress: 0, Pkts: 11 RevPkts: 0 Rule (4123) DN (sys/actrl/scope-3047430/rule-3047430-s-any-d-any-f-implarp) Ingress: 0, Egress: 0, Pkts: 0 RevPkts: 0 Rule (4124) DN (sys/actrl/scope-3047430/rule-3047430-s-any-d-15-f-implicit) Ingress: 0, Egress: 0, Pkts: 0 RevPkts: 0 Rule (4247) DN (sys/actrl/scope-3047430/rule-3047430-s-84-d-5518-f-307) Ingress: 0, Egress: 0, Pkts: 0 RevPkts: 0 Rule (4252) DN (sys/actrl/scope-3047430/rule-3047430-s-5518-d-84-f-306) Ingress: 0, Egress: 0, Pkts: 32 RevPkts: 0 Rule (5637) DN (sys/actrl/scope-3047430/rule-3047430-s-84-d-any-f-implicit) Ingress: 0, Egress: 0, Pkts: 0 RevPkts: 0 |
ルート及びContractの設定共に問題がないのに通信が出来ないようであれば、 先ずはDropポイントを見極めるためにSPAN の取得が有効です。
Dropポイントが判明した場合は ELAMも合わせて使うことで より早く原因を特定できる可能性が高まります。
SPANの設定は以下を参照ください。
ACI SPAN Data のデコード方法について (wireshark)
ELAMの設定は以下を参照ください。
GUIからの確認手順例
<External EPG>
Tenants > Tenant名 > Operational > Resource IDs > External Networks Instance Profile (Class ID)
以下からも確認可能
Tenants > External Routed Networks > Networks > Networks Instance Profile (pcTag)
<EPG>
Tenant > Tenant名 > AP > EPG > policy > General > pcTag(sclass)
CLIからの確認コマンド
<External EPG> vsh -c "show system internal policy-mgr prefix"
Boarder Leaf |
---|
leaf3# vsh -c "show system internal policy-mgr prefix" | egrep "Class|1.2.3.4" Vrf-Vni VRF-Id Table-Id Table-State VRF-Name Addr Class Shared Remote Complete 3047430 12 0xc Up Cisco:vrf1 1.2.3.4/32 5518 True True False |
※ 3.2より前のVersionでは vsh_lc -c "show system internal aclqos prefix"
<EPG> show system internal epm endpoint ip 100.125.255.10
Server Leaf |
---|
leaf1# show system internal epm endpoint ip 100.125.255.10
MAC : 0050.5690.40e3 ::: Num IPs : 1 IP# 0 : 100.125.255.10 ::: IP# 0 flags : ::: l3-sw-hit: No Vlan id : 32 ::: Vlan vnid : 30065 ::: VRF name : Datacenter:vrf2 BD vnid : 16285706 ::: VRF vnid : 2850819 Phy If : 0x1a02c000 ::: Tunnel If : 0 Interface : Ethernet1/45 Flags : 0x80005c04 ::: sclass : 84 ::: Ref count : 5 |
ルートテーブルのNextHopエントリーに対して、ハードウェアテーブルの整合性を確認するには以下の方法で可能です。
学習したルートもNexthopも正しいのにパケットの送受信が出来ない、誤った宛先に転送してしまうといった問題が発生した場合のトラブルシューティングに有効です。
※対象 Leaf : EX/FX シリーズ
1) vsh_lc -c "show platform internal hal l3 routes" コマンドで L3 Route Tableを参照します。
登録されている Route から対象の External Route を探し、NB HW Idx 値を確認します。
この例であれば、1.2.3.4/32 の NB HW Idx が "802e" となってます。NB (NextBaseType) は A = Adjacency。
※ 対象のルートが ECMP となっている場合は、NB (NextBaseType) は E = Ecmp となります。(後述)
2) 次に vsh_lc -c "show plat int hal l3 nexthops" コマンドを入力し、HIT IDX (H)が 先程確認した NB HW Idx であるものを探します。
結果、Nexthopエントリの IP Address / Mac を確認することができます。
ECMPの場合
対象のルートが ECMP となっている場合は、 vsh_lc -c "show platform internal hal l3 routes" で出力される N (NextBaseType) は E = Ecmp となり確認方法が異なります。
1) vsh_lc -c "show platform internal hal l3 routes" コマンドで L3 Route Tableを参照します。N (Next Base ID) が "E" となっているエントリーが ECMPエントリーです。
2) vsh_lc -c "show platform internal hal l3 ecmp ecmp-id " の後に 0xで上記のNB-IDを指定します。この例では(0x24)
Server Leaf |
---|
leaf1# vsh_lc -c "show platform internal hal l3 ecmp ecmp-id 0x24" | grep Nhop Mbr[0] LID:0 NhopId:30315 L2ptr:0x8049 Mbr[1] LID:0 NhopId:30317 L2ptr:0x804b |
3) 上記の結果、NhopIdが複数確認できるので、vsh_lc -c "show platform internal hal l3 nexthop nexthop-id <XXXXX>" で指定すると ECMPの宛先 IPが得られます。
Server Leaf |
---|
leaf1# vsh_lc -c "show platform internal hal l3 nexthop nexthop-id 30315" | grep IPv4 IPv4 Address : 10.0.136.65 leaf1# leaf1# vsh_lc -c "show platform internal hal l3 nexthop nexthop-id 30317" | grep IPv4 IPv4 Address : 10.0.64.127 |
Cisco APIC Layer 3 Networking Configuration Guide, Release 4.0(1)
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/4-x/L3-configuration/Cisco-APIC-Layer-3-Networking…
検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう
シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします
下記より関連するコンテンツにアクセスできます