キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
cancel
2130
閲覧回数
6
いいね!
0
コメント
Yoshitaka Yanomori
Cisco Employee
Cisco Employee

 

本ドキュメントでは、ACI L3Out Routing における基本的なトラブルシューティング例について説明します。

※ L3Outについては こちらを参照ください。
※ ACI Version 4.1 での確認結果をもとに掲載しております。
※ 実際のご利用環境の構築/設計/トラブルシューティングにあたっては Cisco.com に公開されているコンフィギュレーションガイド、デザインガイド、トラブルシューティングガイド等をご参照ください。
※ Cisco.com ドキュメントの記載と本ドキュメント記載に差異がある場合は Cisco.com ドキュメントの記載を優先してください。
※ 本ドキュメントは、下記 ACI構成におけるトラブルシューティング例になります。 

1. ACI構成

今回の以下のように 外部ネットワークから、Leaf103/104 (Server Leaf) に接続された Server-A にアクセスする例となります。また、論理的には 外部ネットワークは Tenant: Cisco(vrf1)、Server-A は Tenant: Datacenter(vrf2) に属しています。

Version は4.1(1i)、Leaf Switch は EXシリーズを使用しています。

Screen Shot 0031-04-22 at 11.03.21 PM.png

 

2. 設定のポイント

※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

3. Boarder Leafでの確認

先ず 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

 

4. Server Leafでの確認

次に 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 --

 

5. Contractの確認

 上記3,4の確認でルートがあるにも関わらず通信が出来ない場合は、Contractも確認してみてください。

事前準備として 対象の VRF VNID (scope)を確認しておきます。

 GUIから確認する場合は vrf policy の segment Id が VRF VNID (scope)にあたります。

Screen Shot 0031-04-17 at 11.21.59 AM.png

 コンソールから確認する場合は "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

 

6. SPAN / ELAM解析

 ルート及びContractの設定共に問題がないのに通信が出来ないようであれば、 先ずはDropポイントを見極めるためにSPAN の取得が有効です。

Dropポイントが判明した場合は ELAMも合わせて使うことで より早く原因を特定できる可能性が高まります。

SPANの設定は以下を参照ください。

SPAN 機能の基本設定と動作概要

ACI SPAN Data のデコード方法について (wireshark)

ELAMの設定は以下を参照ください。

ELAM Assistant の紹介

 

Appendix-1:  EPG  / External EPGの sclass (pcTag) の参照方法

 GUIからの確認手順例

<External EPG>

  Tenants > Tenant名 > Operational > Resource IDs > External Networks Instance Profile (Class ID)

Screen Shot 0031-04-17 at 2.29.16 PM.png

 以下からも確認可能

   Tenants > External Routed Networks > Networks > Networks Instance Profile (pcTag) 

 

<EPG>

  Tenant > Tenant名 > AP > EPG > policy > General > pcTag(sclass)

Screen Shot 0031-04-17 at 2.30.08 PM.png

 

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

 

Appendix-2: Nexthop Tableの確認方法

ルートテーブルの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 となります。(後述)

Screen Shot 0031-04-24 at 9.51.46 AM.png 

2) 次に vsh_lc -c "show plat int hal l3 nexthops" コマンドを入力し、HIT IDX (H)が 先程確認した NB HW Idx であるものを探します。

結果、Nexthopエントリの IP Address / Mac を確認することができます。

Screen Shot 0031-04-24 at 9.51.33 AM.png 

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エントリーです。

Screen Shot 0031-04-24 at 9.51.41 AM.png

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 


Reference

 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…

Getting Started

検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう

シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします