2018-01-26 10:13 PM - 最終編集日: 2018-04-13 11:19 AM 、編集者: JapanTAC_CSC
はじめに
ACI に関しては、ACI How To というポータルサイトに情報を集約しています。 そのため、設定やトラブルシューティング等、ACI に関する情報収集はまず、ACI How To をご参照ください。
このコンテンツも Atomic Counter の基本 というタイトルで同様の内容が掲載されています。
Configure Atomic Counter Policies に "This feature allows you to monitor the traffic drops/excess packets on your fabric." という記載があることからわかるように、これは ACI Fabric 内の packet drop/excess を調べるための機能です。
Atomic Counter には、OnDemand Atomic Counter と OnGoing Atomic Counter の 2 種類があります。
OnDemand Atomic Counter には、下記のような様々な種類があります。 Default では動作しておらず、監視を行いたい EP-EP, EP-EPG 等を手動で設定する必要があります。 設定は Tenant > Troubleshoot Policies > Atomic Counter and Latency Policies より行います。 設定方法は Configure Atomic Counter Policies に記載されているのでここでは省略します。
These types of on-demand atomic counter policies can be configured: EP to EP EP to EPG EP to Ext EPG to EP EPG to EPG EPG to IP Ext to IP IP to EPG The meaning of each acronym is as follows: EP - Endpoint EPG - Endpoint Group Ext - External Network IP - IP address Configure Atomic Counter Policies - Cisco
OnGoing Atomic Counter は、Traffic Map とも呼ばれる、Switch(TEP) 間の drop/excess を監視している機能です。 この機能は常に有効になっています。
Operations > Visualization > Atomic Counter で確認できます。
上記 Settings を Click すると、mode を変更することができます。
Mode には、path と trail の 2 種類があります。 path mode では、leaf 間の通信を、trail mode では、leaf 間だけでなく、どの spine を経由したのかまでを監視しています。
ただし、trail mode は、TEP 数が 64 以上になると自動的に path mode になります。
A breakdown of per-spine traffic is available only when the number of TEPs, leaf or VPC, is less than 64. Cisco Application Centric Infrastructure Fundamentals - Troubleshooting [Cisco Application Policy Infrastructure Cont…
Traffic map の色がついている箇所を click すると、下記のような画面になります。 今回は、左 103 - 上 104 の交わっている箇所を click しています。
(元の画面に戻る場合、Back To Traffic Map を click します。)
上記は、Tx Node 103, Rx Node 104、つまり node103 から送信され、node104 で受信した packet になります。
直近 30 sec では、node103 から 11 packet を送信、node104 が 11 packet を受信したことを示しています。
もし、node103 から 11 packet 送信、node104 が 10 packet を受信した場合、Drop Pkts が 1 増加します。
もし、node103 から 10 packet 送信、node104 が 11 packet を受信した場合、Excess Pkts が 1 増加します。
上記は node103 tx pkts = node104 rx pkts のため、drop は 0 になっています。
Atomic Counter には、様々な注意事項があります。 特に、NTP を使用していない場合や Full mesh ではない構成では、正常に動作しないため、注意が必要です。
また、
Guideline/Restriction が下記に記載されています。
Atomic Counters Guidelines and Restrictions • Use of atomic countersis notsupported when the endpoints are in different tenants or in different contexts (VRFs) within the same tenant. • In pure layer 2 configurations where the IP address is not learned (the IP address is 0.0.0.0), endpoint-to-EPG and EPG-to-endpoint atomic counter policies are not supported. In these cases, endpoint-to-endpoint and EPG-to-EPG policies are supported. External policies are virtual routing and forwarding (VRF)-based, requiring learned IP addresses, and are supported. • When the atomic counter source or destination is an endpoint, the endpoint must be dynamic and not static. Unlike a dynamic endpoint (fv:CEp), a static endpoint (fv:StCEp) does not have a child object (fv:RsCEpToPathEp) that is required by the atomic counter. • In a transit topology, where leaf switches are not in full mesh with all spine switches, then leaf-to-leaf (TEP to TEP) counters do not work as expected. • For leaf-to-leaf (TEP to TEP) atomic counters, once the number of tunnels increases the hardware limit, the system changes the mode from trail mode to path mode and the user is no longer presented with per-spine traffic. • The atomic counter does not count spine proxy traffic. • Packets dropped before entering the fabric or before being forwarded to a leaf port are ignored by atomic counters. • Packets that are switched in the hypervisor (same Port Group and Host) are not counted. • Atomic counters require an active fabric Network Time Protocol (NTP) policy. • Atomic counters work for IPv6 sources and destinations but configuring source and destination IP addresses across IPv4 and IPv6 addresses is not allowed. • An atomic counter policy configured with fvCEp as the source and/or destination counts only the traffic that is from/to the MAC and IP addresses that are present in the fvCEp managed objects (MOs). If the fvCEp MO has an empty IP address field, then all traffic to/from that MAC address would be counted regardless of the IP address. If the APIC has learned multiple IP addresses for an fvCEp, then traffic from only the one IPaddress in the fvCEp MO itself is counted as previously stated. In order to configure an atomic counter policy to/from a specific IPaddress, use the fvIp MO asthe source and/or destination. • If there is an fvIp behind an fvCEp, you must add fvIP-based policies and not fvCEp-based policies. Using the Cisco APIC Troubleshooting Tools (page 12) https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/troubleshooting/b_APIC_Troubleshooting/b_APIC_…
Atomic Counter で使用している class を調べてみます。 Configure Atomic Counter Policies - Cisco の REST API の設定例から、dbgac... という class 名であることが推測できますが、念のため、APIC Postman の紹介 で紹介されている APIC Postman を用い、keyword に atomic を用い、class を検索してみます。 予想通り dbgac という class がたくさん表示されました。
次に、visore (https://[apic address]/visore.html) で、dbgac と入力し、関連 class を検索してみます。 (3.0 より前の version では、候補が表示されないため、visore で keyword を入れて class 検索を行うことはできません。)
dbgAcPath(Rx/Tx) とか、dbgAcTrail(Rx/Tx) という class が確認できます。
そこで、dbgAcPath を表示すると、下記のような出力が確認できます。 下記例では、1 つの object の出力のみですが、下の方へ scroll していくと、全部で 16 個の object が確認できます。 (Total objects shown: 16)
これは、srcNodeId 103, dstNodeId 105 の object になります。 上の出力例は src: 103, dst: 104 なので、それを検索してみます。
visore の画面を scroll して探しても良いのですが、tool 紹介の意味もかねて、今回は moquery を用いて class を表示してみます。
特に難しいことはなく、apic に ssh login して、moquery -c [class 名] と入力するだけです。
表示の都合上、-f option を使用し、src: 103, dst: 104 の node の出力のみ取得しています。
apic1# moquery -c dbgAcPath -f 'dbg.AcPath.dstNodeId=="104" and dbg.AcPath.srcNodeId=="103"' Total Objects shown: 1 # dbg.AcPath srcNodeId : 103 dstNodeId : 104 childAction : dn : dbgs/ac/path-103-to-104 dropPkt : 0 dropPktPercentage : 0 dstNodeId2 : 0 excessPkt : 0 excessPktPercentage : 0 lcOwn : local modTs : 2018-03-28T06:56:37.943+09:00 monPolDn : uni/fabric/monfab-default pathType : nodeToNode rn : path-103-to-104 rxPkt : 11 seqNo : 226686 skip : 0 srcNodeId2 : 0 status : suspect : no totDropPkt : 87909 totDropPktPercentage : 6 totExcessPkt : 1099 totExcessPktPercentage : 0 totRxPkt : 1227071 totTxPkt : 1313881 ts : 2018-01-26T14:56:50.846+09:00 txPkt : 11 apic1#
Traffic map と同じような出力が確認できました。
ちなみに、visore, moquery 共に、leaf switch に対して実行することも可能です。
https://[switch address]/visore.html で visore に、ssh で switch に login することで、moquery を実行することができます。
ただし、apic と switch は全く同じ object を持っているわけではないため、同じ class で検索しても見つからないことがあります。
dbgAcPath もその 1 つです。
fab3-leaf3# moquery -c dbgAcPath No Mos found fab3-leaf3#
これは、node103 tx, node104 rx の情報をそれぞれの leaf switch から取得し、その情報を元に作られたのが dbgAcPath の mo だからです。
dbgAcPathRx, dbgAcPathTx は、apic/switch 両方にあるので、node 103 で dbgAcPathTx を node 104 で dbgAcPathRx を取得してみます。
(src: 103, dst: 104 で filter しています。)
fab3-leaf3# moquery -c dbgAcPathTx -f 'dbg.AcPathTx.dstNodeId=="104" and dbg.AcPathTx.srcNodeId=="103"' Total Objects shown: 2 # dbg.AcPathTx srcNodeId : 103 dstNodeId : 104 admitB : 0 admitP : 0 admitTotB : 14472 admitTotP : 76 childAction : dn : ndbgs/ac/og/b1/pathTx-103-to-104 dropB : 0 dropP : 0 dropTotB : 0 dropTotP : 0 dstNodeId2 : 0 firstCollTs : 2018-01-23T09:04:10.211+09:00 lastCollTs : 2018-01-26T14:56:10.309+09:00 lcOwn : local modTs : 2018-03-28T06:55:55.642+09:00 pathDn : pathType : nodeToNode rn : pathTx-103-to-104 seqNo : 4673 srcNodeId2 : 0 status : # dbg.AcPathTx srcNodeId : 103 dstNodeId : 104 admitB : 3432 admitP : 11 admitTotB : 14562876 admitTotP : 49155 childAction : dn : ndbgs/ac/og/b0/pathTx-103-to-104 dropB : 0 dropP : 0 dropTotB : 0 dropTotP : 0 dstNodeId2 : 0 firstCollTs : 2018-01-23T09:04:40.215+09:00 lastCollTs : 2018-01-26T14:56:40.313+09:00 lcOwn : local modTs : 2018-03-28T06:56:25.646+09:00 pathDn : pathType : nodeToNode rn : pathTx-103-to-104 seqNo : 4673 srcNodeId2 : 0 status : fab3-leaf3# fab3-leaf4# moquery -c dbgAcPathRx -f 'dbg.AcPathRx.dstNodeId=="104" and dbg.AcPathRx.srcNodeId=="103"' Total Objects shown: 2 # dbg.AcPathRx srcNodeId : 103 dstNodeId : 104 admitB : 3432 admitP : 11 admitTotB : 14559636 admitTotP : 49144 childAction : dn : ndbgs/ac/og/b0/pathRx-103-to-104 dropB : 0 dropP : 0 dropTotB : 0 dropTotP : 0 dstNodeId2 : 0 firstCollTs : 2018-01-23T09:04:40.333+09:00 lastCollTs : 2018-01-26T14:56:40.345+09:00 lcOwn : local modTs : 2018-03-28T06:56:25.677+09:00 pathDn : pathType : nodeToNode rn : pathRx-103-to-104 seqNo : 4673 srcNodeId2 : 0 status : # dbg.AcPathRx srcNodeId : 103 dstNodeId : 104 admitB : 0 admitP : 0 admitTotB : 14472 admitTotP : 76 childAction : dn : ndbgs/ac/og/b1/pathRx-103-to-104 dropB : 0 dropP : 0 dropTotB : 0 dropTotP : 0 dstNodeId2 : 0 firstCollTs : 2018-01-23T09:05:10.319+09:00 lastCollTs : 2018-01-26T14:56:10.341+09:00 lcOwn : local modTs : 2018-03-28T06:55:55.673+09:00 pathDn : pathType : nodeToNode rn : pathRx-103-to-104 seqNo : 4672 srcNodeId2 : 0 status : fab3-leaf4#
それぞれ、dn に b0, b1 という値を持つ object が表示されます。 (data の不整合が起きないよう、bank0, bank1 という 2 つの object を交互に使用しています。)
これは何回か同じ command を実行し、この object の片方が 30 秒ごとに更新されていくことからも確認できます。
14:56:10 に bank1 が、14:56:40 に bank0 が、14:57:10 に bank1 が、14:57:40 に bank0 が... のように 30 秒間の統計情報が順番に更新されます。
apic でも同様の出力が確認できますが、user がどちらの bank を使用しているか意識しなくても良いように、さらにもう 1 つ object があります。
moquery -d dbgs/ac/path-103-to-104/pathTx-103-to-104 のように、class ではなく、dn を指定すれば user は、常に最新の情報を取得することができます。
apic1# moquery -c dbgAcPathTx -f 'dbg.AcPathTx.dstNodeId=="104" and dbg.AcPathTx.srcNodeId=="103"' Total Objects shown: 3 # dbg.AcPathTx srcNodeId : 103 dstNodeId : 104 admitB : 0 admitP : 0 admitTotB : 14472 admitTotP : 76 childAction : dn : topology/pod-1/node-103/ndbgs/ac/og/b1/pathTx-103-to-104 dropB : 0 dropP : 0 dropTotB : 0 dropTotP : 0 dstNodeId2 : 0 firstCollTs : 2018-01-23T09:04:10.211+09:00 lastCollTs : 2018-01-26T14:56:10.309+09:00 lcOwn : local modTs : 2018-03-28T06:55:55.642+09:00 pathDn : pathType : nodeToNode rn : pathTx-103-to-104 seqNo : 4673 srcNodeId2 : 0 status : # dbg.AcPathTx srcNodeId : 103 dstNodeId : 104 admitB : 3432 admitP : 11 admitTotB : 14562876 admitTotP : 49155 childAction : dn : topology/pod-1/node-103/ndbgs/ac/og/b0/pathTx-103-to-104 dropB : 0 dropP : 0 dropTotB : 0 dropTotP : 0 dstNodeId2 : 0 firstCollTs : 2018-01-23T09:04:40.215+09:00 lastCollTs : 2018-01-26T14:56:40.313+09:00 lcOwn : local modTs : 2018-03-28T06:56:25.646+09:00 pathDn : pathType : nodeToNode rn : pathTx-103-to-104 seqNo : 4673 srcNodeId2 : 0 status : # dbg.AcPathTx srcNodeId : 103 dstNodeId : 104 admitB : 3432 admitP : 11 admitTotB : 14562876 admitTotP : 49155 childAction : dn : dbgs/ac/path-103-to-104/pathTx-103-to-104 dropB : 0 dropP : 0 dropTotB : 0 dropTotP : 0 dstNodeId2 : 0 firstCollTs : 2018-01-23T09:04:40.215+09:00 lastCollTs : 2018-01-26T14:56:40.313+09:00 lcOwn : local modTs : 2018-03-28T06:56:25.785+09:00 pathDn : pathType : nodeToNode rn : pathTx-103-to-104 seqNo : 4673 srcNodeId2 : 0 status : apic1# apic1# moquery -c dbgAcPathRx -f 'dbg.AcPathRx.dstNodeId=="104" and dbg.AcPathRx.srcNodeId=="103"' Total Objects shown: 3 # dbg.AcPathRx srcNodeId : 103 dstNodeId : 104 admitB : 3432 admitP : 11 admitTotB : 14559636 admitTotP : 49144 childAction : dn : topology/pod-1/node-104/ndbgs/ac/og/b0/pathRx-103-to-104 dropB : 0 dropP : 0 dropTotB : 0 dropTotP : 0 dstNodeId2 : 0 firstCollTs : 2018-01-23T09:04:40.333+09:00 lastCollTs : 2018-01-26T14:56:40.345+09:00 lcOwn : local modTs : 2018-03-28T06:56:25.677+09:00 pathDn : pathType : nodeToNode rn : pathRx-103-to-104 seqNo : 4673 srcNodeId2 : 0 status : # dbg.AcPathRx srcNodeId : 103 dstNodeId : 104 admitB : 0 admitP : 0 admitTotB : 14472 admitTotP : 76 childAction : dn : topology/pod-1/node-104/ndbgs/ac/og/b1/pathRx-103-to-104 dropB : 0 dropP : 0 dropTotB : 0 dropTotP : 0 dstNodeId2 : 0 firstCollTs : 2018-01-23T09:05:10.319+09:00 lastCollTs : 2018-01-26T14:56:10.341+09:00 lcOwn : local modTs : 2018-03-28T06:55:55.673+09:00 pathDn : pathType : nodeToNode rn : pathRx-103-to-104 seqNo : 4672 srcNodeId2 : 0 status : # dbg.AcPathRx srcNodeId : 103 dstNodeId : 104 admitB : 0 admitP : 0 admitTotB : 0 admitTotP : 0 childAction : dn : dbgs/ac/path-103-to-104/pathRx-103-to-104 dropB : 3432 dropP : 11 dropTotB : 14559636 dropTotP : 49144 dstNodeId2 : 0 firstCollTs : 2018-01-23T09:04:40.333+09:00 lastCollTs : 2018-01-26T14:56:40.345+09:00 lcOwn : local modTs : 2018-03-28T06:56:25.817+09:00 pathDn : pathType : nodeToNode rn : pathRx-103-to-104 seqNo : 4673 srcNodeId2 : 0 status : apic1#
ちなみに、最初に取得した dbgAcPath は、この dbgAcPathTx, dbgAcPathRx を用いて計算しています。
基本的に、
dbgAcPathTx admitP = dbgAcPath txPkt
bgAcPathRx admitP = dbgAcPath rxPkt
になり、
dbgAcPath txPkt > dbgAcPath rxPkt の場合、drop に
dbgAcPath txPkt < dbgAcPath rxPkt の場合、excess になります。
つまり、APIC は、送信側 leaf の tx と受信側 leaf の rx を比較し drop/excess を判断していて、実際に packet を drop させて counter を増加させているわけではありません。 そのため、NTP の設定を行なっていない等、時刻が不正確な場合、各 leaf switch が統計情報を取得している時刻が異なってしまうため、計算結果にズレが生じ、drop/excess が頻繁に発生するようになります。 Atomic Counter の Fault で、drop/excess が交互に出力されるような場合、設定/構成に問題がある場合や、表示上の不具合である場合やほとんどで、実際に packet drop/excess が発生していることはほとんどありません。
# dbg.AcPath srcNodeId : 103 dstNodeId : 104 childAction : dn : dbgs/ac/path-103-to-104 dropPkt : 0 dropPktPercentage : 0 dstNodeId2 : 0 excessPkt : 0 excessPktPercentage : 0 lcOwn : local modTs : 2018-03-28T06:56:37.943+09:00 monPolDn : uni/fabric/monfab-default pathType : nodeToNode rn : path-103-to-104 rxPkt : 11 seqNo : 226686 skip : 0 srcNodeId2 : 0 status : suspect : no totDropPkt : 87909 totDropPktPercentage : 6 totExcessPkt : 1099 totExcessPktPercentage : 0 totRxPkt : 1227071 totTxPkt : 1313881 ts : 2018-01-26T14:56:50.846+09:00 txPkt : 11 # dbg.AcPathTx srcNodeId : 103 dstNodeId : 104 admitB : 3432 admitP : 11 admitTotB : 14562876 admitTotP : 49155 childAction : dn : dbgs/ac/path-103-to-104/pathTx-103-to-104 dropB : 0 dropP : 0 dropTotB : 0 dropTotP : 0 dstNodeId2 : 0 firstCollTs : 2018-01-23T09:04:40.215+09:00 lastCollTs : 2018-01-26T14:56:40.313+09:00 lcOwn : local modTs : 2018-03-28T06:56:25.785+09:00 pathDn : pathType : nodeToNode rn : pathTx-103-to-104 seqNo : 4673 srcNodeId2 : 0 status : # dbg.AcPathRx srcNodeId : 103 dstNodeId : 104 admitB : 3432 admitP : 11 admitTotB : 14559636 admitTotP : 49144 childAction : dn : dbgs/ac/path-103-to-104/pathRx-103-to-104 dropB : 0 dropP : 0 dropTotB : 0 dropTotP : 0 dstNodeId2 : 0 firstCollTs : 2018-01-23T09:04:40.333+09:00 lastCollTs : 2018-01-26T14:56:40.345+09:00 lcOwn : local modTs : 2018-03-28T06:56:25.817+09:00 pathDn : pathType : nodeToNode rn : pathRx-103-to-104 seqNo : 4673 srcNodeId2 : 0 status :
switch が apic に atomic counter の情報を送っている log は、svc_ifc_dbgrelem.log で、apic がその情報を処理した log は、svc_ifc_dbgr.bin.log で確認できます。
(apic は、leaf から情報が遅延して送られてくることを考慮して、10 秒後に処理を行い dbgs/ac/path-103-to-104 の情報を更新します。)
fab3-leaf3# cat /var/log/dme/log/svc_ifc_dbgrelem.log | grep 14:56:40 | head -1 8938||18-01-26 14:56:40.313+09:00||ifc_dbgrelem||DBG4||co=doer:0:0:0x32a9f:1||AC: Sending Bank 0 Data to IFC||../dme/svc/dbgrelem/src/gen/ifc/app/./imp/timers/AcExportToIFCTimerCbImp.cc||350 bico 35.312 fab3-leaf3# fab3-leaf4# cat /var/log/dme/log/svc_ifc_dbgrelem.log | grep 14:56:40 | head -1 9019||18-01-26 14:56:40.345+09:00||ifc_dbgrelem||DBG4||co=doer:0:0:0x3041b:1||AC: Sending Bank 0 Data to IFC||../dme/svc/dbgrelem/src/gen/ifc/app/./imp/timers/AcExportToIFCTimerCbImp.cc||350 bico 35.344 fab3-leaf4# apic1# cat /var/log/dme/log/svc_ifc_dbgr.bin.log | grep 14:56:50 | grep DDBEAAGcAaAA= 5143||18-01-26 14:56:50.979+09:00||mit_update||INFO||co=doer:32:3:0x2142978:15,dn='"DDBEAAGcAaAA="'||MIT MODIFY InstanceId: 4058:1400309 MoLocal || control bits = 104||../common/src/framework/./core/mo/Changer.cc||733 apic1#
Fault Code | name |
---|---|
F1545 | fltDbgAcPathAOnGoingAtomicCounterDropsMajor |
F1546 | fltDbgAcPathAOnGoingAtomicCounterDropsMinor |
F1547 | fltDbgAcPathAOnGoingAtomicCounterExcessMajor |
F1548 | fltDbgAcPathAOnGoingAtomicCounterExcessMinor |
F1549 | fltDbgAcTrailOnGoingAtomicCounterTrailDropsMajor |
F1550 | fltDbgAcTrailOnGoingAtomicCounterTrailDropsMinor |
F1551 | fltDbgAcTrailOnGoingAtomicCounterTrailExcessMajor |
F1552 | fltDbgAcTrailOnGoingAtomicCounterTrailExcessMinor |
上記は、Atomic Counter に関する Fault 一覧です。
Path となっている F1545-F1548 が path mode で Trail となっている F1549 - F1552 が trail mode の fault です。
Drops となっている F1545, F1546, F1549, F1550 が dbgAcPath の txPkt > rxPkt となっている場合で、Excess となっている F1547, F1548, F1551, F1552 が dbgAcPath の txPkt < rxPkt となっている場合です。
Major となっている F1545, F1547, F1549, F1551 が drop/excess rate が 5% 以上で、Minor となっている F1546, F1548, F1550, F1552 が drop/excess rate 1-4% の場合です。
ネットワーク初心者にもとても分かりやすいです。ありがとうございます。
検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう
シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします