ACI Fabric(leaf/spine) Switch に関する不具合で、1 ヶ月間に関連 SR の報告が多かったもの Best 5 です。 あくまで、TAC Service Request (SR) として問い合わせのあったもので、Partner や User 自身で解決したものは含まれていないため、実際に発生した件数の Ranking ではないのでご注意ください。   2019 年 1 月 BugId Title CSCvk33286 Nexus 9300-EX on 3.1 Kernel Panics with Unexpected SERR, no PCIE errors found CSCve35542 ACI: kernel panic due to PCIE error CSCvi83497 mfdm core while creating 2000 EPGs CSCvm57328 EPM cores repeatedly when leafs on mismatched versions CSCvj17665 EP Announce support for stale IP remote endpoints 2019 年 2 月 BugId Title CSCvo32832 ACI 40G Leaf Downlink to UCS-FI-6332 Not Coming Up CSCvk33286 Nexus 9300-EX on 3.1 Kernel Panics with Unexpected SERR, no PCIE errors found CSCvj43529 aci leaf will learn ep mac via lldp multicast pack which dmac is 0180.c200.0003 or 0180.c200.0000 CSCvm48676 Switch reloaded unexpectedly due to "nfm hap reset" CSCvj17665 EP Announce support for stale IP remote endpoints 2019 年 3 月 BugId Title CSCvo45816 SDK_HAL Crash on EX leafs up for 500+ days due to heartbeat loss CSCvm48676 Switch reloaded unexpectedly due to "nfm hap reset" CSCvd16972 l2IngrPkts:drop should not include Forward Drop CSCvi46036 ACI Leaf N9K-C93180YC-EX crashed with SDKHAL core, reset-requested-due-to-fatal-module-error CSCvg28464 Read only admin user unable to run show commands on the CLI of ACI spines and leaves 2019 年 4 月 BugId Title CSCvo45816 SDK_HAL Crash on EX leafs up for 500+ days due to heartbeat loss CSCvm26708 QSFP-40/100-SRBD fails to link up in 100G and latches to 40G speed on 40/100 supported platforms CSCvp32562 Link with active copper cables (ACU) do not come up under certain conditions. CSCvj17665  EP Announce support for stale IP remote endpoints CSCvm09903 100Gb, 40Gb, 2x20Gb, 25Gb ports stay Down on N9K-C93180YC-EX Leafs 2019 年 5 月 BugId Title CSCvo80686 Cisco Nexus 9000 Series Fabric Switches ACI Mode Default SSH Key Vulnerability CSCvo72253 Cisco Nexus 9000 Series Fabric Switches ACI Mode Root Privilege Escalation Vulnerability CSCvk40347 Stale VLANs programmed on switches&apos interfaces using EPG deployment under AAEP. CSCvj17665 EP Announce support for stale IP remote endpoints CSCvp65259 ACI leaf crash with multiple cores including NFP and sdkhal 2019 年 6 月 BugId Title CSCvo45816 SDK_HAL Crash on EX leafs up for 500+ days due to heartbeat loss CSCvk33286 Nexus 9300-EX on 3.1 Kernel Panics with Unexpected SERR, no PCIE errors found CSCvo80686 Cisco Nexus 9000 Series Fabric Switches ACI Mode Default SSH Key Vulnerability CSCvm01561 DOM data varies between software - ACI and NXOS CSCvn72699 Nexus 9000 with BigSky or Heavenly ASIC falsely incrementing input total drops ... View more

ACI APIC に関する不具合で、1 ヶ月間に関連 SR の報告が多かったもの Best 5 です。 あくまで、TAC Service Request (SR) として問い合わせのあったもので、Partner や User 自身で解決したものは含まれていないため、実際に発生した件数の Ranking ではないのでご注意ください。   2019 年 1 月 BugId Title CSCvn88191 ACI - APIC - Updating interface description requires Override name CSCvn13119 MegaSAS.log File in / Directory on APIC Not Rolling Over Causing Disk to Fill CSCvn57629 [FMR]: Unable to show an Access Leaf IPG config (Policy Groups) when the number of IPGs more than 40 CSCvj51711 Leaf health score low with no active faults CSCvm83098 Create Attachable Access Entity Profile and Configure Interface Wizard fail to load content 2019 年 2 月 BugId Title CSCvn13119 MegaSAS.log File in / Directory on APIC Not Rolling Over Causing Disk to Fill CSCvk45056 APIC reloaded unexpectedly with vmcore generated CSCvf12024 Nodes are undiscoverable after KVM install performed on APICs CSCvm12554 ACI - contract preferred group l3out prefix/bd-subnet not deployed on ingress leaf in VPC or non-VPC CSCvj24627 Invalid APIC Fan Fault F1322 2019 年 3 月 BugId Title CSCvn13119 MegaSAS.log File in / Directory on APIC Not Rolling Over Causing Disk to Fill CSCvm11162 iostat.log file size misreporting CSCvo64552 F2547 faults raised for invalid-pod id after node decommission CSCvd36006 Files Named *.log Do Not Autorotate Properly CSCvm12554 ACI - contract preferred group l3out prefix/bd-subnet not deployed on ingress leaf in VPC or non-VPC 2019 年 4 月 BugId Title CSCvn13119 MegaSAS.log File in / Directory on APIC Not Rolling Over Causing Disk to Fill CSCvp23141 APIC raises fault "Power supply unit on Node X is failed" even though the CIMC doesn't. CSCvp21606 F1940 Faults for APIC PSUs after upgrading CIMC to 4.0(2f) CSCvj81562 vmmmgr process continually crashing in 3.2 due to duplicate folder name in VC CSCvp25660 Stale firmware group after upgrade from pre 4.0 to 4.0 2019 年 5 月 BugId Title CSCvn13119 MegaSAS.log File in / Directory on APIC Not Rolling Over Causing Disk to Fill CSCvk45865 M5: PSU operational state is Fail on APIC M5 CSCvp23141 APIC raises fault "Power supply unit on Node X is failed" even though the CIMC doesn&apost. CSCvp21606 F1940 Faults for APIC PSUs after upgrading CIMC to 4.0(2f) CSCvm12790 RL advertising static route to APIC into IPN 2019 年 6 月 BugId Title CSCvn13119 MegaSAS.log File in / Directory on APIC Not Rolling Over Causing Disk to Fill CSCvk45865 PSU operational state is Fail on APIC CSCve84297 Docker0 address on APIC should be configurable CSCvm11162 iostat.log file size misreporting CSCva13697 insieme_installer.log is getting huge due to postupgrade_cleanup.py ... View more

ACI Fabric(leaf/spine) Switch に関する不具合で、1 ヶ月間に関連 SR の報告が多かったもの Best 5 です。 あくまで、TAC Service Request (SR) として問い合わせのあったもので、Partner や User 自身で解決したものは含まれていないため、実際に発生した件数の Ranking ではないのでご注意ください。   2018 年 10 月 BugId Title CSCvk33286 Nexus 9300-EX on 3.1 Kernel Panics with Unexpected SERR, no PCIE errors found CSCvm48676 Switch reloaded unexpectedly due to "nfm hap reset" CSCvf67718 [ACI]The Fabric module was crashed and reloaded because the PCIE Uncorrectable error encountered. CSCvm43204 Link fails to come up after powered-down module brought to service CSCve35542 ACI: kernel panic due to PCIE error   2018 年 11 月 BugId Title CSCvm57328 EPM cores repeatedly when leafs on mismatched versions CSCvn02710 Link Should Err-Disable after continous link flaps CSCvg38710 IPFIB core on border leaf CSCvm43204 Link fails to come up after powered-down module brought to service CSCvj94174 Cisco FXOS/NXOS Software Link Layer Discovery Protocol Denial of Service Vulnerability   2018 年 12 月 BugId Title CSCve75260 EP update issue in the Coop table on Peer Site after EP move CSCvi11291 XR L3 learn on BL even with "Disabled remote EP learn" enabled given a pkt with src/dst port of 179 CSCvm48676 Switch reloaded unexpectedly due to "nfm hap reset" CSCvn57622 ACI generating a "power supply is missing" fault for a B22 FEX device which has no power supply. CSCvm60216 OOB Contract not being Enforced on Fabric Switches   ... View more

ACI APIC に関する不具合で、1 ヶ月間に関連 SR の報告が多かったもの Best 5 です。 あくまで、TAC Service Request (SR) として問い合わせのあったもので、Partner や User 自身で解決したものは含まれていないため、実際に発生した件数の Ranking ではないのでご注意ください。   2018 年 10 月 BugId Title CSCvj81562 vmmmgr process continually crashing in 3.2 due to duplicate folder name in VC CSCvj24627 Invalid APIC Fan Fault F1322 CSCvd36006 Files Named *.log Do Not Autorotate Properly CSCvb13193 [nginx]access.log of nginx is not auto rotated CSCvk44519 coppFilter missing in PM after upgrade to 3.2.2 2018 年 11 月 BugId Title CSCvm83098 Create Attachable Access Entity Profile and Configure Interface Wizard fail to load content CSCvj51711 Leaf health score low with no active faults CSCvj24627 Invalid APIC Fan Fault F1322 CSCve06658 After changing looseNode address, EPGs removed from switch CSCvd36006 Files Named *.log Do Not Autorotate Properly 2018 年 12 月 BugId Title CSCvm83098 Create Attachable Access Entity Profile and Configure Interface Wizard fail to load content CSCvj51711 Leaf health score low with no active faults CSCvd36006 Files Named *.log Do Not Autorotate Properly CSCvn77440 ACI : Can't open Leaf Access Port policy groups when above 40 policies CSCvn15374 invalid apic AV sent during upgrade ... View more

  ACI に関しては、ACI How To というページがあり、設定やトラブルシューティング等、一般的な内容についてはそちらの方が充実しています。 設定やトラブルシューティングについては、今後 ACI How To を中心に更新していく予定のため、ACI に関する情報収集はまず、ACI How To を参考にしてください。 このコンテンツも APIC GUI の Troubleshooting というタイトルで掲載しています。 フォーマットがずれて読みにくい場合、こちらのページをご参照ください。   はじめに   APIC の GUI 表示に問題がある場合、Browser が受け取っている情報そのものがおかしい場合と、受け取った情報の出力に問題がある場合のどちらかになります。 Browser が受け取っている情報がおかしいかどうかを確認するための Tool としては、API Inspector があり、この Tool については既に   API Inspector の活用   で紹介しています。 そのため、ここでは受け取った情報をどのように出力しているかを調べる方法について紹介します。     1. 問題   今回は、例として上記 Leaf Switch の Management port がなぜ orange になっているのかを調べていきます。 mgmt0 の Properties を見ると、Admin State, Oper State どちらも up になっているし、色も green になっているにも関わらず、左側の mgmt0 icon では orange 出力になっているので、その理由が気になります。 そこで、 どのような条件で色付けをしているのか Browser に実装されている Tool を用いて調べていくことにします。     2. Google Chrome Developer Tools     右上の設定 icon から Developer Tool を起動できます。   今回は Google Chrome を使用していますが、 他 Browser でも同様に起動できると思い ます。     port を orange 表示させる時にどのような処理が行われているのかを確認するため、Developer Tool の Console を表示させた状態で、Management Interfaces を click して見ると、上のように大量の console message が出力されます。 その中に layout/Pannel.js という気になる出力があるので、この file を開いて書かれている内容を調べてみます。     javascript の内容を確認すると port の色を取得していると思われる関数 getPortStatusColor を呼び出しているので、その関数が書かれているところを検索し file を開きます。         その file の最初の comment 欄に、各状態と色の対応が書かれています。 下記に書かれている通り、switchingSt というのが disabled になっていると orange になることがわかります。     /** * Users: Catalin Dumitru & Fabio Ingrao * Copyright 2012-2018 Insieme Networks, Inc. */ /* * interface.adminSt  ethpm.operSt           interface.switchingSt  color           port.adminSt ----------------   ------------------     --------------------   ----------      ------------- up            -                       -                     white            portDisabled up            up                      enabled               green            portEnabled up            up                      disabled              orange           portDisabledSwitching up            link-up          -                   yellow           portDisabledLink up            down                -                     red              portEnabledError * */ Ext.define('insieme.stromboli.topology.PortInfo', { alternateClassName: 'insieme.PortInfo', singleton: true,     colorToStatus: {         white: 'portDisabled',         green: 'portEnabled',         orange: 'portDisabledSwitching',         yellow: 'portDisabledLink',         red: 'portEnabledError'     }, // colorConsts keeps track between the status of an interface and the status mark's color colorConsts: { portDisabled: "white", portEnabled: "green", portDisabledSwitching: "orange", portDisabledLink: "yellow", portEnabledError: "red" }, // statusConts keeps track of all the status options statusConsts: { enabled: "enabled", disabled: "disabled", up: "up", down: "down", linkUp: "link-up", trunking: "trunking" }, // paramConst keeps track of all the params needed in order to apply a state; paramConst: { operSt: "operSt", adminSt: "adminSt", switchingSt: "switchingSt", },     determineColor: function(interfaceMo) {         // this method is used in order to determine the color of the status mark for Interfaces and Interface related objects         // rules used are described in the table present at the beginning of this file         var statusConsts = this.statusConsts;         var colorConsts = this.colorConsts;         var adminSt = interfaceMo.adminSt;         var operSt, className, switchingSt;         if (adminSt === statusConsts.down || adminSt === statusConsts.disabled) {             return colorConsts.portDisabled;         }         operSt = interfaceMo.operSt;         className = interfaceMo.className;         switchingSt = interfaceMo.switchingSt;         if (operSt && adminSt) {             if (operSt === statusConsts.up && adminSt === statusConsts.up) {                 if (switchingSt === statusConsts.enabled || className === 'insieme.stromboli.model.def.l1FcPhysIf') {                     return colorConsts.portEnabled;                 } else if (switchingSt === statusConsts.disabled) {                     return colorConsts.portDisabledSwitching;                 }                 return colorConsts.portDisabledLink;             }             else if (operSt === statusConsts.down && adminSt === statusConsts.up) {                 return colorConsts.portEnabledError;             }         }         if (operSt === statusConsts.linkUp){             return colorConsts.portDisabledLink;         }         // for FEX ports where FEX-to-leaf is disabled         if (className === "insieme.stromboli.model.def.l1PhysIf" && !operSt) {             return colorConsts.portDisabled;         }     }, buildMoFromL1PhysAndEthpmPhys: function(interfaceObj, ethpmObj) { // this method builds an object containing the required params in order to determine a status color var interfaceMo = { className: interfaceObj.$className, adminSt: "", operSt: "", switchingSt: "" }; interfaceMo.adminSt = interfaceObj.get(this.paramConst.adminSt) ? interfaceObj.get(this.paramConst.adminSt) : null; if (ethpmObj) { interfaceMo.operSt = ethpmObj.get(this.paramConst.operSt) ? ethpmObj.get(this.paramConst.operSt) : null; // for some objects I was unable to find the swState, so I will set it if undefined or null as true until further updates // for those objects we will check the operSt and adminSt interfaceMo.switchingSt = ethpmObj.get(this.paramConst.switchingSt) ? ethpmObj.get(this.paramConst.switchingSt) : interfaceObj.get(this.paramConst.switchingSt); } else { interfaceMo.operSt = interfaceObj.get(this.paramConst.operSt); interfaceMo.switchingSt = interfaceObj.get(this.paramConst.switchingSt); } if (!interfaceMo.switchingSt || interfaceMo.switchingSt === true) { interfaceMo.switchingSt = this.statusConsts.enabled; } if (interfaceMo.operSt === this.statusConsts.trunking) { interfaceMo.operSt = this.statusConsts.up; } return interfaceMo; },     getPortStatusColor: function(interfaceObj, ethpmObj) { // this method returns the status color for the provided interface var state; state = this.determineColor(this.buildMoFromL1PhysAndEthpmPhys(interfaceObj, ethpmObj));         return state; } });     3. 結論   上記 code から switchingSt が disabled になっている場合、orange になることがわかりました。 APIC GUI では、switchingSt という項目は表示されていないようですが、実際に mgmt0 が持っている mo 情報を Object Store Browser を用いて確認してみます。     Object Store Browser (Visore) で確認すると、switchingSt が disabled になっていることが確認できます。 つまり、mgmt0 が orange になっているのは code 上は期待通りに動作していると言えます。 ちなみに、switchingSt は、port に対して policy が適用されると up になりますが、management port の場合、常に disabled になります。 そのため、mgmt0 は正常時は orange で、link down 等なんらかの問題がある場合は red になります。   3.2 で動作を確認した時は上記のように switchingSt が出力されていないため、確かに、"あれ？" と思ってしまいますが、4.1 では下記のように Switching State という項目が GUI に追加されているので、そもそもこう言った疑問を抱かないかもしれません。     APIC の表示部分の Troubleshooting は今回の例のように、ある程度細かい条件まで自分で調査することが可能です。 ACI の Troubleshooting は一般的な linux command や汎用の Tool を使って切り分け可能なことが多く、 cisco.com 内に document はなく、 検索 engine 等ですぐに見つかることも多々あります。 そのため、Troubleshooting を行う前に、自分が確認したいことは、ACI 固有の知識を必要とするのか、それ以外の知識を必要とするのかを切り分けた上で最適な方法で検索することをお勧めします。 ... View more

ACI に関しては、ACI How To というページがあり、設定やトラブルシューティング等、一般的な内容についてはそちらの方が充実しています。 設定やトラブルシューティングについては、今後 ACI How To を中心に更新していく予定のため、ACI に関する情報収集はまず、ACI How To を参考にしてください。 このコンテンツも   Fault に出力されている path が見つからない時の調べ方   というタイトルで掲載しています。 フォーマットがずれて読みにくい場合、こちらのページをご参照ください。   はじめに   ACI では初期設定時に admin user password を設定し、新たに user を作らない限り、admin user で設定や troubleshooting を行なっていきます。 まれに、troubleshooting や software 不具合の回避策として root access が必要になります ( ACI: root アクセスと root パスワードの発行方法‌ ) 。 ここでは、admin user と root user の path の違いについて紹介し ます。   1. chroot   admin user が全ての file に access できる必要はなく、 Security の観点から必要な情報のみを表示できることが望ましいです。 そのため、apic に admin login を行なった場合、chroot を行い、root user とは異なる場所を root に変更しています。 user の root と path の root どちらも root で混乱するかもしれないので、一応図を書くと下記のような構造になっています。   [root@apic1 /]# pwd;find . | sort | sed '1d;s/^\.//;s/\/\([^/]*\)$/|--\1/;s/\/[^/|]*/| /g' / <<== root の場合、ここが root (起点) |--" | |--var | | |--run | | | |--bashroot <<== admin の場合、ここが root (起点) | | | | |--cgroup" [snip]    そのため、ls / で root の file を確認すると、結果が異なります。 (それぞれ、上記起点となっている directory にある file が表示されます。)   ## admin apic1# ls / aci bin controller data data2 debug dev etc firmware home lib lib64 mgmt mit opt proc sbin sys tmp usr var apic1#   ## root [root@apic1 /]# ls / " MegaSAS.log-20190120-1547971262.gz boot data2 etc fwrepos lib lxc opt root securedata tmp 1 MegaSAS.log-20190122-1548115261.gz cgroup dev firmware gluster lib64 media proc run srv usr 2 MegaSAS.log-20190124-1548259261.gz config dmecores forcefsck home logs mgmt rfs1 sbin sys var MegaSAS.log bin data efiboot fsckoptions ifabric lost+found mnt rfs2 scratch techsupport [root@apic1 /]#   ちなみに、login 時の user resource 管理は scriptcontainer process が行なっていて、その log からも、/var/run/bashroot へ chroot していることが確認できます。 下記 command は admin user でも実行できるため、admin user でも、login 時の root(起点) は / ではなく、/var/run/bashroot であることが確認できます。   apic1# ps aux | grep scriptcontainer admin 2286 0.0 0.0 9056 908 pts/2 S+ 15:40 0:00 grep scriptcontainer root 14808 0.0 0.0 16920 3004 pts/2 D 10:24 0:00 /mgmt/usr/bin/scriptcontainer -b admin 14809 0.0 0.0 16920 3004 pts/2 S 10:24 0:00 /mgmt/usr/bin/scriptcontainer -b root 31418 0.0 0.0 16920 2888 pts/0 D 09:14 0:00 /mgmt/usr/bin/scriptcontainer -b admin 31419 0.0 0.0 16920 2888 pts/0 S 09:14 0:00 /mgmt/usr/bin/scriptcontainer -b apic1# apic1# cd /var/run/mgmt/log apic1# tail -f scriptcontainer.log ## admin user で login 19-00-25 13:18:29||scriptcontainer||INFO||||../svc/scripthandler/src/container/ScriptContainer.cc||1337|| chroot to /var/run/bashroot complete 19-00-25 13:18:29||scriptcontainer||INFO||||../svc/scripthandler/src/container/ScriptContainer.cc||1762||calling shell 1 19-00-25 13:18:29||scriptcontainer||INFO||||../svc/scripthandler/src/container/ScriptContainer.cc||894||Launching zsh... 19-00-25 13:18:29||scriptcontainer||INFO||||../svc/scripthandler/src/container/ScriptContainer.cc||618|| Username admin ## exit で logout 19-00-25 13:18:38||scriptcontainer||INFO||||../svc/scripthandler/src/container/ScriptContainer.cc||982||Child1 exited with 0 19-00-25 13:18:38||scriptcontainer||INFO||||../svc/scripthandler/src/container/ScriptContainer.cc||590||Cleaning up    apic が fault を検知しているので、その fault に書かれている path を調べようとすると、下記のように file/directory が存在しないと言われるのは、root が fault を検知し、その path を出力しているためです。   apic1# ls /data/log ls: cannot access /data/log: No such file or directory apic1# [root@apic1 /]# ls /data/log | head -3 access.log access.log-20190118-1547809261.gz access.log-20190120-1547964061.gz [root@apic1 /]#   2. mount   先ほどの章で login した時の起点が違うことは理解できたと思うので、次は、それぞれの user が login した時に disk をどのように mount しているのかを見ていきます。 apic は lvm を使用していますが pvdisplay, vgdisplay, lvdisplay 等、lvm 関連の command は root でしか実行できません。 名前からだいたい想像できると思いますが、名前に ssd がついていないものが HDD で、ssd がついているものが SSD になります。   [root@apic1 /]# lvdisplay | grep Path LV Path /dev/vg_ifc0/rfs1 LV Path /dev/vg_ifc0/rfs2 LV Path /dev/vg_ifc0/securedata LV Path /dev/vg_ifc0/logs LV Path /dev/vg_ifc0/dmecores LV Path /dev/vg_ifc0/techsupport LV Path /dev/vg_ifc0/firmware [snip] LV Path /dev/vg_ifc0_ssd/data [root@apic1 /]#   上記は、root user でしか確認できませんが、/etc/fstab は admin user でも確認できるので、admin user であっても、だいたいどの directory がどの logical volume を使用しているのか想像できると思います。   apic1# cat /etc/fstab /dev/vg_ifc0/logs /logs ext4 defaults 0 0 /dev/vg_ifc0/boot / ext4 defaults 1 1 /dev/vg_ifc0/config /config ext4 defaults 0 2 /dev/vg_ifc0/techsupport /techsupport ext4 defaults 0 0 /dev/vg_ifc0/firmware /firmware ext4 defaults 0 0 /dev/vg_ifc0/scratch /scratch ext4 defaults 0 0 /dev/vg_ifc0_ssd/data /data ext4 defaults 0 0 /dev/vg_ifc0/dmecores /dmecores ext4 defaults 0 0 /dev/vg_ifc0/data2 /data2 ext4 defaults 0 0 tmpfs /tmp tmpfs defaults,size=16G 0 0 apic1#    apic の log の多くは、/data/log 以下 (root) に保存されていますが、一部 file の logrotate を忘れていたために、/data/log の disk 容量が一杯になるという不具合が過去に数件ありました。 CSCvb13193 ‌‌ にも "F1529 - topology/pod-1/node-3/sys/ch/p-[/data/log]-f-[tmpfs] : Storage unit /data/log on Node 3 mounted at /data/log is 90% full" が出力されるという記載があります。   この /data/log は admin user の /var/log/dme/log と同じ場所を mount しています。 いますと言われても、一般 user は root access できないので、調べるのが難しいかもしれませんが、上記 fstab の結果 (admin user で実行可能) と、mount の出力結果 (admin user で実行可能) からおおよその見当をつけることが可能です。   上記 fstab の結果から /data は /dev/vg_ifc0_ssd/data を mount していることが確認できます。 そこで、vg_ifc0_ssd を mount している directory を調べると下記のような結果が表示されます。( lvm の場合、/dev/vg_aaa/bbb と /dev/mapper/vg_aaa-bbb はどちらも、/dev/dm-ccc の symbolic link になっているので、どちらも同じところを mount しています。)   apic1# mount | grep vg_ifc0_ssd /dev/mapper/vg_ifc0_ssd-data on /data/challenge.plugin type ext4 (ro,relatime,data=ordered) /dev/mapper/vg_ifc0_ssd-data on /controller/sbin type ext4 (rw,relatime,data=ordered) /dev/mapper/vg_ifc0_ssd-data on /data/devicescript type ext4 (rw,relatime,data=ordered) /dev/mapper/vg_ifc0_ssd-data on /data/log.lastupgrade type ext4 (ro,relatime,data=ordered) /dev/mapper/vg_ifc0_ssd-data on /var/log/dme type ext4 (rw,relatime,data=ordered) /dev/mapper/vg_ifc0_ssd-data on /var/log/dme/nginx type ext4 (rw,relatime,data=ordered) /dev/mapper/vg_ifc0_ssd-data on /var/run/mgmt/log type ext4 (rw,relatime,data=ordered) apic1#    /data/log が一杯ということなので、上記 directory 配下に log directory があるか ls で確認して見ます。 下記出力の結果から /var/log/dme の配下に log directory が存在することが確認できます。 この結果から、/data/log (root) = /var/log/dme/log (admin) ではないかと推測できます。   apic1# mount | grep "vg_ifc0_ssd" | awk '{print $3}' | xargs ls - ls: cannot access -: No such file or directory /data/challenge.plugin   /controller/sbin: acidiag admin.cookie avread category.yaml cluster_health.py collectLocalDbs.py parse.py techsupport-filter trimtechsupport.py   /data/devicescript: CISCO.ASA.1.2 CISCO.ASA_FI.1.2 F5.BIGIP.1.2.0 F5.iWorkflow.2.0-APIC Fortinet.FGAPIC.1.2 Fortinet.FGAPIC.1.3 cache install upload CISCO.ASA.1.2_CONT CISCO.ASA_FI.1.2_CONT F5.BIGIP.1.2.0_CONT F5.iWorkflow.2.0-APIC_CONT Fortinet.FGAPIC.1.2_CONT Fortinet.FGAPIC.1.3_CONT images unpack /data/log.lastupgrade: /var/log/dme: core log log.lastupgrade nginx oldlog   /var/log/dme/nginx: access.log error.log netstat.log nginx.pid /var/run/mgmt/log: ishell-13726.error.log ishell-15374.error.log ishell-15374.log.1.gz ishell-15374.log.3.gz ishell-15374.log.5.gz scriptcontainer.log ishell-13726.log ishell-15374.log ishell-15374.log.2.gz ishell-15374.log.4.gz pam.module.log apic1#     fault が出力され、よくわからない path が表示された場合、それは root user から見た path の場合があります。 そのときは、上記例のように調べると、admin user で使用している path を見つけることができるかもしれません。   ... View more

ACI APIC に関する不具合で、過去 1 ヶ月間に関連 SR の報告が多かったもの Best 5 です。 あくまで、TAC Service Request (SR) として問い合わせのあったもので、Partner や User 自身で解決したものは含まれていないため、実際に発生した件数の Ranking ではないのでご注意ください。   2018 年 7 月 BugId Title CSCvd36006 Files Named *.log Do Not Autorotate Properly CSCvj81562 vmmmgr process continually crashing in 3.2 due to duplicate folder name in VC CSCvk44519 coppFilter missing in PM after upgrade to 3.2.2 CSCvk54346 Enh: Add support for EIGRP Authentication CSCvf12024 Nodes are undiscoverable after KVM install performed on APICs   2018 年 8 月 BugId Title CSCvk67458 Rename Config Zone Modes of Enabled/Disabled to Inactive/Active CSCvk67459 Add Column to 'acidiag fnvread' to Indicate Nodes that are in a Config Zone CSCvd36006 Files Named *.log Do Not Autorotate Properly CSCvh52171 Feature Request: Add banner warning when config zones have pending changes CSCvk44519 coppFilter missing in PM after upgrade to 3.2.2   2018 年 9 月 BugId Title CSCuy61214 ACI: Enhancement to Send Test to SNMP Destinations CSCvb13193 [nginx]access.log of nginx is not auto rotated CSCvj24627 Invalid APIC Fan Fault F1322 CSCvm11162 iostat.log file size misreporting CSCvd36006 Files Named *.log Do Not Autorotate Properly ... View more

ACI Fabric(leaf/spine) Switch に関する不具合で、過去 1 ヶ月間に関連 SR の報告が多かったもの Best 5 です。 あくまで、TAC Service Request (SR) として問い合わせのあったもので、Partner や User 自身で解決したものは含まれていないため、実際に発生した件数の Ranking ではないのでご注意ください。   2018 年 7 月 BugId Title CSCvb42851 Memory leak/sw crash in "stats_manager" process from add/del of AAEP profiles or interface flaps, CSCvf67718 [ACI]The Fabric module was crashed and reloaded because the PCIE Uncorrectable error encountered. CSCvj58567 N9K-C9364C : Fixed 10Gig ports cant resolve arp for Multipod CSCuz12913 ACI: a contract is not applied to directly connected subnets on L3OUT CSCve35542 ACI: kernel panic due to PCIE error   2018 年 8 月 BugId Title CSCvb42851 Memory leak/sw crash in "stats_manager" process from add/del of AAEP profiles or interface flaps, CSCvf67718 [ACI]The Fabric module was crashed and reloaded because the PCIE Uncorrectable error encountered. CSCvm09903 Port 51 stay Down on N9K-C93180YC-EX Leafs after upgrade to 3.2(2) CSCvc01738 DMR1:SB tor went to kdb due to Kernel panic - not syncing: Unexpected SERR CSCve35542 ACI: kernel panic due to PCIE error CSCvh79628 DHCP memory leak due to multiple dhcp_sisf_reply_pkt_create api calls   2018 年 9 月 BugId Title CSCvk03229 Commission of Spine/Tor after maintenance mode is not working CSCvf67718 [ACI]The Fabric module was crashed and reloaded because the PCIE Uncorrectable error encountered. CSCve35542 ACI: kernel panic due to PCIE error CSCvi83497 mfdm core while creating 2000 EPGs CSCve26184 Unexpected Reload of Leaf due to EPMC HAP Reset CSCvd87231 Fan tray missing faults are raised even though the fans are healthy   ... View more

  ACI に関しては、ACI How To というページがあり、設定やトラブルシューティング等、一般的な内容についてはそちらの方が充実しています。 設定やトラブルシューティングについては、今後 ACI How To を中心に更新していく予定のため、ACI に関する情報収集はまず、ACI How To を参考にしてください。 このコンテンツも   ELAM Assistant の紹介   というタイトルで掲載しています。 フォーマットがずれて読みにくい場合、こちらのページをご参照ください。    1. ELAM とは   ELAM (Embedded Logic Analyzer Module) は、Cisco ASIC 内の packet 転送を確認するための Tool で、ACI 固有の Tool ではなく、一部の Catalyst や Nexus Series Switch 上でも動作します。   Nexus 9000 シリーズ製品: ELAM の概要   に、Standalone mode での使用方法や説明が記載されているので、ELAM についてはそちらの document もご参照ください。 ELAM の設定や出力は ASIC によって異なるため注意が必要です。   2. ELAM Assistant とは   ELAM 設定を APIC GUI 上で設定できる Tool で、Cisco ACI App Center   から download して使用することができます。 APIC Postman の紹介   に記載されている方法で install することができます。 ACI Apps を使用したことがない人は   APIC Postman の紹介   もご参照ください。   ACI Fabric は、複数台の Leaf/Spine Switch によって構成されているため、packet が drop している箇所を特定するために、複数台の switch で ELAM capture を行う必要があり、各　switch に login して設定を行う必要がありますが、この Tool を使うことで、APIC 上で、複数台の switch に対して一度に設定を行うことができます。 また、ELAM Assistant が support している switch は、第二世代の   (EX, FX Series)   switch になりますが、これら switch の ELAM 出力は、ASIC の内部構造を理解していないと読むことができない、難解な出力になっていますが、ELAM Assistant は、解析に必要な部分を human readable な形式に変換してくれるため、比較的簡単に結果を確認することができます。   例えば、下記のような出力は、      *** Parsed Outer l2 vector sug_elam_in_l2v_da_sa_qtag0_vntag_cmd: 0x00000000000005DE1000100010751000000000752   sug_elam_in_l2v_da_sa_qtag0_vntag_cmd.da: 0x000000752   sug_elam_in_l2v_da_sa_qtag0_vntag_cmd.sa: 0x100010751   sug_elam_in_l2v_da_sa_qtag0_vntag_cmd.qtag0_vld: 0x1   sug_elam_in_l2v_da_sa_qtag0_vntag_cmd.qtag0_cos: 0x0   sug_elam_in_l2v_da_sa_qtag0_vntag_cmd.qtag0_de: 0x0   sug_elam_in_l2v_da_sa_qtag0_vntag_cmd.qtag0_vlan: 0x2EF   sug_elam_in_l2v_da_sa_qtag0_vntag_cmd.vntag_vld: 0x0   sug_elam_in_l2v_da_sa_qtag0_vntag_cmd.vntag_svif: 0x0   sug_elam_in_l2v_da_sa_qtag0_vntag_cmd.vntag_dvif: 0x0   sug_elam_in_l2v_da_sa_qtag0_vntag_cmd.vntag_e: 0x0   sug_elam_in_l2v_da_sa_qtag0_vntag_cmd.vntag_l: 0x0   sug_elam_in_l2v_da_sa_qtag0_vntag_cmd.vntag_p: 0x0   sug_elam_in_l2v_da_sa_qtag0_vntag_cmd.vntag_spare: 0x0   sug_elam_in_l2v_da_sa_qtag0_vntag_cmd.cmd_vld: 0x0   sug_elam_in_l2v_da_sa_qtag0_vntag_cmd.cmd_sgt_vld: 0x0   sug_elam_in_l2v_da_sa_qtag0_vntag_cmd.cmd_sgt: 0x0   sug_elam_in_l2v_da_sa_qtag0_vntag_cmd.cmd_dgt_vld: 0x0   sug_elam_in_l2v_da_sa_qtag0_vntag_cmd.cmd_dgt: 0x0 *** Parsed Outer l3 vector sug_elam_in_l3v_ipv4: 0x302A0CC0702A0CC0807FC002   sug_elam_in_l3v_ipv4.l3_type: 0x2   sug_elam_in_l3v_ipv4.v6: 0x0   sug_elam_in_l3v_ipv4.dscp: 0x0   sug_elam_in_l3v_ipv4.ecn: 0x0   sug_elam_in_l3v_ipv4.df: 0x0   sug_elam_in_l3v_ipv4.mf: 0x0   sug_elam_in_l3v_ipv4.ttl: 0xFF   sug_elam_in_l3v_ipv4.prot: 0x1   sug_elam_in_l3v_ipv4.da: 0xC0A83302   sug_elam_in_l3v_ipv4.sa: 0xC0A83301 *** Parsed Outer l4 vector   こんな感じに表示されます。   3. ELAM Assistant の使い方   すでに install が完了していて、すぐに使える状態になっていることを前提で進めていきます。 まだ install していない人は、APIC Postman の紹介‌   を参考に install してください。 下記のように Apps -> Apps で   ELAM Assistant が表示されていれば install が完了しています。   上記 Open を click すると、下記のような画面が表示されます。 Leaf/Spine Switch に log するために、まずは Username/Password を入力し、Validate & Save を click してください。     確認/初期化が完了すると、下記のような画面が表示されるので、この pop up を消し、指示の通り、Capture Packet を click します。 上記画面を scroll させると、使い方が書いてあるので、その通りに進めていきます。     現在、2. まで進んだので、3 - 5 の ELAM capture を行いたい switch を選択し設定を行います。 今回は、1 つの EPG 上に leaf101 eth1/21 encap vlan 751 と leaf102 eth1/21 encap vlan 752 を static binding で設定し、bridge する構成で行なっています。 同一 EPG 内の通信のため、contract は設定していません。 Tenant 設定は下記になります。     上記設定で、node-101 eth1/21 に、端末 192.168.75.1 が、node-102 eth1/22 に、端末 192.168.75.2 が接続されているので、192.168.75.1 -> 192.168.75.2 へ ping を実行した時に各 leaf が、packet を受信できているかどうかを確認するため、ELAM capture を行なってみます。   指示通り、まずは、capture 対象の node を選択 (今回は node-101, node-102 を追加) します。   今回は、fontport からの通信を capture するため、direction は default のままで、node-101 は icmp echo を capture するため、dst_ip を 192.168.51.2 に、node-102 は icmp echo reply を capture するため、src_ip を 192.168.51.2 にして Set ELAM を click。     これで、capture を行う準備ができたので、ping を実行し、6 - 9 の指示通りに進めていきます。 Check Trigger を click すると、capture が完了しているため、Status が Triggered に変更されます。 capture できなかった場合、Set のままです。 また、ELAM は、条件に match した最初の packet を capture すると Triggered になり capture が終了します。 そのため、packet が流れ続けている環境で parameter 設定を適当に行うと、意図した packet とは異なる packet を capture していまうため、注意が必要です。     上記 Triggered になった場合、ELAM report が生成されているため、左側の menu から switch を選択し、内容を確認することができます。 今回は、node-101 の capture 結果を見てみることにします。     node-101 を撰択し、Parse を click することで PARSE RESULT に結果が表示されます。 下記は、PARSE RESULT の Express の結果です。 Raw を click すると、先ほどの難しい出力結果が表示されます。     Packet が ACI Fabric 内で drop しているときの Troubleshooting では、最後の drop reason の出力を確認します。 問題なく通過している場合には no drop になりますが、EPG 間通信で contract を設定せずに packet drop が発生した場合は、SECURITY DENY と表示される等、drop した理由が表示されます。   ちなみに、raw data は、apic の /data2/gluster/gv0/Cisco_ElamAssistant/ directory の中にあります。   leaf/spine switch に login し、 CLI で elam capture を行なった場合、elam report は下記のように switch の /var/log/dme/log/elam_report.txt に保存されますが、ELAM Assistant の場合、その情報を、/data2/gluster/vg0/Cisco_ElamAssistant へ copy しています。 copy する際に、node 名が追加され node-101_elam_report.txt のような形式の file になります。 elam parameter で option として存在する name your capture に何か入力すると、elam_report.txt の部分がその入力した値になります。   ## node-101 leaf switch fab3-leaf1# ls -l /var/log/dme/log/elam_report.txt -rw-rw-rw- 1 root root 701595 Jul  4 16:58 /var/log/dme/log/elam_report.txt fab3-leaf1# fab3-leaf1# head -30 /var/log/dme/log/elam_report.txt   #########################SUGARBOWL ELAM REPORT START######################### Dumping report for asic type 6 inst 0 slice 0 a_to_d 1 insel 6 outsel 0 LUA captured data with :    SRCID: 0    PKTID: ca *** All outer vector: sug_elam_in_vec.all_outer_vec: 0x000000000000000000000000000000000000000000000000E31E1001600000000000000000000000000181506602000000000000000000000001815066042E1E03FE0000015000540440000000000000000005DE100000000000100010751000000000752   sug_elam_in_vec.all_outer_vec.l2vec0: 0x00000000000005DE100000000000100010751000000000752   sug_elam_in_vec.all_outer_vec.l3vec0: 0x00000000000000000000000000C0A83301000000000000000000000000C0A83302170F01FF000000A8002A022   sug_elam_in_vec.all_outer_vec.l4vec0: 0x000000000000000000000000718F0800B   sug_elam_in_vec.all_outer_vec.spare_bit_padding: 0x00000000000000000 *** Parsed l2 vector sug_pr_lu_vec_l2v: 0x00000000000005DE100000000000100010751000000000752   sug_pr_lu_vec_l2v.da: 0x000000752     sug_pr_lu_vec_l2v.da.trill: 0x000000752       sug_pr_lu_vec_l2v.da.trill.ce_da: 0x000000752     sug_pr_lu_vec_l2v.da.ce_da: 0x000000752     sug_pr_lu_vec_l2v.da.dce_da: 0x000000752   sug_pr_lu_vec_l2v.sa: 0x100010751     sug_pr_lu_vec_l2v.sa.trill: 0x100010751       sug_pr_lu_vec_l2v.sa.trill.irbid: 0x751       sug_pr_lu_vec_l2v.sa.trill.erbid: 0x1       sug_pr_lu_vec_l2v.sa.trill.spare: 0x1     sug_pr_lu_vec_l2v.sa.ce_sa: 0x100010751     sug_pr_lu_vec_l2v.sa.dce_sa: 0x100010751   sug_pr_lu_vec_l2v.vntag_vld: 0x0   sug_pr_lu_vec_l2v.ivntag_vld: 0x0   sug_pr_lu_vec_l2v.vir: 0x0     sug_pr_lu_vec_l2v.vir.vntag: 0x0 fab3-leaf1#   ## apic apic1# ls -l /data2/gluster/gv0/Cisco_ElamAssistant/node-101_elam_report.txt -rw-r--r-- 2 root root 701595 Jul  4 16:58 /data2/gluster/gv0/Cisco_ElamAssistant/node-101_elam_report.txt apic1#    ACI Fabric 内の traffic flow の解析を行う上で、ELAM capture はとても有効ですが、設定した条件に match する最初の packet しか取得できないため、parameter 設定を慎重に行う必要があります。 条件が明確になっていない場合、意図せぬ packet を capture してしまい、Troubleshooting が行えないこともあります。 そのため、まずは SPAN を行い、drop している packet の特性を確認した上で、ELAM capture を行うことをお勧めします。 SPAN については、SPAN 機能の基本設定と動作概要   もあわせてご参照ください。 ... View more

ACI に関しては、ACI How To というページがあり、設定やトラブルシューティング等、一般的な内容についてはそちらの方が充実しています。 設定やトラブルシューティングについては、今後 ACI How To を中心に更新していく予定のため、ACI に関する情報収集はまず、ACI How To を参考にしてください。 このコンテンツも  ACI: Software Version の見方   というタイトルで掲載しています。 フォーマットがずれて読みにくい場合、こちらのページをご参照ください。 1. はじめに   このページでは、ACI の Software Version 表記の基本的な考え方について説明します。 これを理解することで、Bug Search Tool‌ で表示される Known Fixed Releases を見て、自分の使用している Version がその不具合に該当する Version かどうかを調べることが可能になります。     2. APIC Software Version と ACI Switch Software Version の関係について   APIC Version + 10 = Switch Version になっています。 つまり、APIC Version 1.2(1i) に対応する Switch Version は 11.2(1i) になります。   APIC と Switch の Version は基本的に合わせて使用する必要がありますが、数十台/数百台の Switch を一度に同じ Version へ Upgrade することが困難なため、2.2(1n) 以降、Version の混在環境 (Mixed OS) を Support しています。 これにより、長い期間をかけ、順番に Switch の Version を Upgrade していくことが正式に Support されました。 (その間、Support されている機能の設定変更も可能です。)     Starting from Release 2.2(1n), Cisco Application Policy Infrastructure Controller supports the following features for network configuration capabilities and changes during mixed OS operation.  [snip] Important Notes It is required that all the Cisco APICs must be first upgraded to the newer version and after the upgrade is completed, the supported network configuration operations may be performed. The supported network configuration operations cannot be performed during an upgrade of an Cisco APIC.   Cisco APIC Management, Installation, Upgrade, and Downgrade Guide    Mixed OS を Support しているといっても、自由に好きな Version を使用しても良いわけではなく、最初に APIC の Version を上げる必要があります。 Switch の Software 不具合が見つかったからといって、Switch の Version のみを上げることは　2018 年 4 月現在、Support されていません。 また、Support されている機能は限られていて、VPC pair は同じ Version を使用しなければならない等、いくつかの制限事項があります。 そのため、Mixed OS を使用する場合、事前に上記 Link 先を確認してください。 3.0 以前の場合、Mixed OS を Support している Version であっても、Warning Banner が表示されるため、それ以降の Version の使用をお勧めします。     3. APIC Version について   ACI の場合、最初の小数点付きの数字 (2.2(1n) の場合、2.2 にあたる部分) は Major Release と呼ばれています。   新しい機能や新製品の Support 開始は、この時に追加されます。 後半のかっこ内の数字 (2.2(1n) の場合、1 にあたる部分) は Mainor Release もしくは、Maintenance Release(MR) と 呼ばれていて、主に不具合修正を適用した Version になります。 最後の alphabet (2.2(1n) の場合、n にあたる部分) は、特定の不具合修正のみを適用した Patch Release になります。 Maintenance Release まで待てないような脆弱性対応 patch 等をあてると、この値が増加します。     下記は、2018 年 4 月現在、CCO から Download 可能な APIC Version (2.0 - 3.1) の一覧です。 Patch Release を入れると複雑になるので、Maintenance Release の最初の Version (Patch Release の一番古いもの) のみ抜き出しています。   Version Release Date 2.0(1m) 2016/07/07 2.0(2f) 2016/08/22     2.1(1h) 2016/10/01 2.1(2e) 2017/02/17 2.1(3g) 2017/08/09 2.1(4a) 2018/03/14     2.2(1n) 2017/01/18 2.2(2e) 2017/04/11 2.2(3j) 2017/09/07 2.2(4f) 2018/04/09     2.3(1e) 2017/06/13     3.0(1k) 2017/08/10 3.0(2h) 2017/10/09     3.1(1i) 2017/12/22 3.1(2m) 2018/03/06   上記表からわかるように、Major Release   2.0(1), 2.1(1), 2.2(1), 2.3(1), 3.0(1), 3.1(1), ...   は、だいたい、3, 4 ヶ月ごとに新しい Version が Release されます。 ということで、3.2 はまもなく Release されます。 (2018 年 4 月現在)   また、2.1, 2.2 だけ、Maintenance Release が多いことが確認できると思います。 これは、2.1, 2.2 が、Long-lived Release になっているためです。 頻繁に Major Release を変更したくないような環境では、Long-lived Release の使用をお勧めします。 (Release Number が、2.1(4x), 2.2(4x) ではなく、2.1(3x), 2.2(3x) になっているのは、Software が Release されたのが最近で、Document がまだ update されていないからだと思います。 また、次の 3.2 が long-lived になるという話が出ているので、3.2 が long-lived になった場合、2.1 は long-lived から外される可能性があります。 あくまで噂です。)   Updated:March 3, 2018 Recommended Cisco APIC and Cisco Nexus 9000 Series ACI-Mode Switches Releases     上の表を見やすくしたものが下記になります。 横軸がおおよそのタイムラインです。 Maintenance Release を一列に並べています。 新しい Major Release を作成するために、それ以前の Version から Branch が作られます。 どの Version の Base としているかは公開していません。 正式 Release 前の Version は 0.xxx になります。 例えば、2.2 の場合、2.2(0.xxx) として開発が始まり、最終的に正式版は 2.2(1.x) の形式で Release されます。 Maintenance Release はそのまま、2.2(1.xxy), 2.2(1.xxz) のように修正が追加されていきます。 最終的に正式版は 2.1(2.x) の形式になります。   Bug Search Tool   の Known Fixed Releases に、開発途中と思われる (0.123) や (1.234) という Version は表記されているのはこのためです。 2.2(0.123) や 2.2(0.124) に適用された修正は基本的に、2.2(1.x) に適用されています。 2.2(1.234) や 2.2(1.235) に適用された修正は基本的に、2.2(2.x) に適用されています。 つまり、かっこ内の Version で小数点がついている修正に関しては、整数部分を繰り上げた Version に修正が適用されています。   実際の例として、CSCvb42851 Memory leak/sw crash in "stats_manager" process from add/del of AAEP profiles or interface flaps,   で確認してみます。 Known Fixed Releases は下記のようになっています。   これは、Switch 側の不具合のため、12.x となっています。 APIC の不具合の場合、この数字が 2.x のようになります。 この修正は Switch で行われています。 順番に Version を見ていくと、 12.2(0.49) となっているので、次の Major Release である 12.2(1) に修正が適用されています。 つまり、上の図の 2.2(1n) 以降に修正が適用されています。 12.1(2g) となっているので、2.1(2e), 2.1(2f) には修正は適用されておらず、2.1(2g) 以降 (2.1(2h), 2.1(2i),...) に修正が適用されています。 12.1(2.68) となっているので、次の Maintenance Release である 12.1(3) 以降に修正が適用されています。   Patch Release の場合、Maintenance Release 以降、特定の不具合のみ修正を適用しているため、Known Fixed Release に修正が適用されている Version が入ります。 Major/Maintenance Release の場合、かっこ内の小数点以下を繰り上げた Version に修正が適用されています。     また、Bug Search Tool   には、Known Affected Releases という箇所もありますが、これは不具合が確認された Version が書かれています。 この不具合が発生した最初のお客様が使用していた Version が書かれているだけということが多いので、この Version はあまりあてになりません。 ほとんどの場合、Known Fixed Releases に書かれているよりも前の Version 全てがその不具合に該当しています。 ... View more

はじめに ACI に関しては、ACI How To というポータルサイトに情報を集約しています。 そのため、設定やトラブルシューティング等、ACI に関する情報収集はまず、ACI How To をご参照ください。 このコンテンツも Atomic Counter の基本  というタイトルで同様の内容が掲載されています。  1. 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 になっています。     2. 注意事項   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_…       3. Class/MO 確認   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 :     4. おまけ   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#     5. おまけ2   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% の場合です。 ... View more

はじめに ACI に関しては、ACI How To というポータルサイトに情報を集約しています。 そのため、設定やトラブルシューティング等、ACI に関する情報収集はまず、ACI How To をご参照ください。 このコンテンツも APIC Postman の紹介 というタイトルで同様の内容が掲載されています。    1. APIC Postman とは   REST クライアントを用いた設定   や   Python を用いた設定   で、REST API を用いた設定例が書かれていますが、最初にユーザ認証を行う必要があるため、簡単に動作を確認したい場合に不便です。 そういった煩わしさを解消してくれる便利なツールが ACI App Center に公開されました。 それが APIC Postman です。 3.0(2h) 以降で対応しています。     APIC は、2.2(1n) 以降で ACI App Center という機能をサポートしていて、ユーザが作成したアプリケーションを APIC にインストールすることができます。 他のユーザが作成したアプリケーションは   Cisco ACI App Center   からダウンロード可能です。 (大半が Cisco のエンジニアが作成したものですが。) APIC Postman も Cisco のエンジニアが作成した App の 1 つです。   2. APIC Postman のインストール   1) 3.0(2h) 以降の APIC に login します。   2) 上のタブの Apps をクリックするとインストールされている App の一覧が表示されます。   3) 右側の Download Application アイコンをクリックすると Cisco ACI App Center が開くのでそこから APIC Postman をダウンロードします。(事前にダウンロードしておいても構いません。)   4) Download Application アイコンの隣の Upload Application アイコンをクリックし、ダウンロードしておいた APIC Postman(Cisco-APICPostman-3.1.aci) を指定し Submit します。(3.1 の箇所はバージョンが入るため、異なる可能性があります。)   5) Enable をクリックし、APIC Postman を有効にします。   6) Security Domain を選択し、Enable をクリックすると有効になります。   7) インストールが完了すると、下記のように Enable となっていたボタンが Open に代わり、App を使用できるようになります。   3. APIC Postman の使用方法   上記 Open をクリックすると APIC Postman が起動します。 画面左側の Search ボックスにキーワードを入れると Class を検索することができます。 下記例では、Tenant を作成するために tenant というキーワードを入れています。 検索結果として fv:Tenant が表示されるので、これをダブルクリックします。   fv:Tenant をダブルクリックすることで右側にアイコンが表示され、下段に Properties と Post Preview が表示されます。 この Properties の値をダブルクリックし、値を編集することで各クラスのパラメータを設定できます。   下記は、name に demo と入力した時の出力例です。 name を変更すると、それに伴い dn/rn も変化し、右側の Post Preview の値も変更されます。 この時点では、まだ設定は反映されていません。   設定を反映するためには、上段の POST ボタンをクリックし、データを POST する必要があります。 APIC に login することで既に認証が完了しているので、データを POST するときにユーザ認証は必要ありません。   POST しても良いか確認画面が表示されるので、Yes をクリックすると設定が反映されます。   Tenants > demo で実際にテナントが作成されていることが確認できます。     Apps > APIC Postman で元の画面に戻ると先ほどの画面は消えていて何も表示されないので、先ほどの設定を表示するため  https://[apic  addr]/apic/node/mo/uni/tn-demo.json と入力 (先ほど POST した情報、POST ボタン左側の矢印をクリックすると履歴が残っているので手動入力する必要はありません) し、GET ボタンをクリック。   Tenant demo の情報が出力されます。 tenant 作成時に自動的に作られる vns:SvcCont や fv:RsTenantMonPol も表示されています。   Tenant demo の配下に Application Profile を作成するため、先ほど同様、左側の Search ボックスに application と入力し検索します。   fv:Ap をダブルクリックすると fv:Ap が追加されます。 今回は、name に ap01 と入力しています。 丸印が青く塗りつぶされているのが現在選択している class(instance) になります。 右クリックすると、このインスタンスを削除したりクローンすることができます。   クローンし、名前を変更することで似たような設定を簡単に設定することができます。(POST するまでは設定は反映されないので注意が必要です。)   上記設定を POST した後に、再度 Tenant demo を確認すると、Application Profile が 2 つ (ap01, ap02) できていることが確認できます。   上記は、APIC Postman の説明のため、1 から Tenant/Application Profile を作成しましたが、単に設定を行うだけの場合、普通に GUI を作成した方が早いので、今度は、EPGx2, BDx2, VRFx1 を GUI で作成し、それを APIC Postman で表示させてみます。各設定は下記になります。 epg01 - bd01 - vrf01, epg02 - bd02 - vrf01 が関連づけられています。   Apps > APIC Postman に戻り、tn-demo.json を GET すると下記のように表示されます。 関連付けを見る場合、GUI よりもこちらの方が見やすいかもしれません。   情報が多すぎて表示が小さくなってしまいましたが、epg について着目したいような場合、epg を選択し、右クリック > Root Here を選択することで、この epg 配下の情報のみ表示することができます。 (GET 先が uni/tn-demo.json から uni/tn-demo/ap-ap01/epg-epg01.json に変更になっています。)   Post Preview に該当箇所の設定が表示されるので、GUI で 右クリック > Save As を用いて設定を保存するよりも簡単に設定が確認できて便利です。 GUI や python script を用いた方が便利なことも多いですが、APIC Postman は簡単に json/xml 形式で設定が確認でき、関連付けもわかりやすいため、使い方次第ではとても便利なツールです。 ... View more

[toc:faq]   ACI に関しては、ACI How To というポータルサイトに情報を集約しています。 そのため、設定やトラブルシューティング等、ACI に関する情報収集はまず、ACI How To をご参照ください。 このコンテンツも ユーザーロール・権限の設定  というタイトルで同様の内容が掲載されています。 Cisco Support Community は、Font や Format がくずれてしまうのでこのコンテンツも ACI How To での閲覧をお勧めします。   環境や利用用途によっては、ユーザー毎に役割を設け、それに応じたアクセス権を付与したい場合があります。ここでは、ACI でユーザーロール・権限を決定し、設定するまでの 1 つの例を示します。   1. 変更したい設定の権限確認   今回は、Bridge Domain 内の Subnet 設定を変更可能なユーザーを作成します。 まず最初に、テナントを作成し、実際に変更を行いたい設定の class を確認します。 その後、その class に必要な権限を確認します。   1a. Tenant の作成 apic にログインし、Tenants > Add Tenant をクリックし、テナントを作成します。同時に Security Domain も作成します。   1b. BD, Subnet の作成 Bridge Domains を右クリックし、Create Bridge Domain を選択することで Bridge Domain を作成することができます。 Bridge Domain の下の階層に Subnets があるので、そこを右クリックすることで Subnet を作成することができます。     1c. class の確認 画面右上のユーザー名をクリックすると、メニューが表示されます。 ここで Show Debug Info を有効にすることで画面下部に class や dn が表示されるようになります。 今回の Subnet で使用している class は fvSubnet になります。   1d. class の権限確認 class 名がわかったので、APIC Management Information Model Reference でこの class を確認してみます。 このドキュメントは、Documentation > API Documentation から開けます。   左側の Classes から fv:Subnet を探し、クリックすることで下記右側の画面が表示されます。 ブラウザの検索機能を使用した方が簡単に見つかります。 また、このドキュメントの場合、fv と Subnet の間に : があるので検索するときに注意してください。     この出力結果より、admin もしくは tenant-connectivity-l2 の権限が必要なことがわかります。     2. tenant-connectivity-l2 権限を持つユーザー作成   Cisco ACI AAA RBAC Rules and Privileges   で、 tenant-connectivity-l2 権限を持つロールを確認することができます。 最初から用意されているロールを使用することをお勧めしますが、今回は、ロールも作成してみたいと思います。   2a. Role の作成   Admin > AAA > Security Management > Roles を右クリックすることでロールを新規作成できます。     2b. ユーザー作成   Local Users を右クリックし、Create Local User を選択することで新規ユーザーを作成することができます。 今回、最初に作った Security Domain   を使用します。 ロールも先ほど作成したものを使用します。 ユーザー名とパスワードを設定すればユーザー作成は完了です。       ... View more

ACI に関しては、ACI How To というポータルサイトに情報を集約しています。 そのため、設定やトラブルシューティング等、ACI に関する情報収集はまず、ACI How To をご参照ください。 このコンテンツも APIC GUI の手引き 2 というタイトルで同様の内容が掲載されています。 Cisco Support Community は、Font や Format がくずれてしまうのでこのコンテンツも ACI How To での閲覧をお勧めします。   はじめに APIC GUI 手引き には GUI 上部の Tab について説明が書かれていますが、右上にもう 1 つ重要な項目が残っています。 このコンテンツでは、welcome [username] を click したときに表示される項目について簡単に説明します。   AAA Login している user の、認証に関する設定変更が可能です。自分自身の設定ではなく、異なる user の認証に関する設定は、Admin > AAA から設定可能です。 Show API Inspector GUI から行った設定に関する Troubleshooting を行う時の必須項目です。Show API Inspector を起動すると、別 window が開き、GUI に対して行なっている HTTP request を表示することができます。画面表示に関しては GET method が、設定に関しては POST method が使用されるため、POST で filter を行うと、GUI で行った設定のみを表示することが可能です。API Inspector に関しては、より詳細な内容が API Inspector の活用 にも記載されています。 Documentation それぞれ、API, Cobra SDK, APIC の CCO Documentation が表示されます。 API Documentation は、 Class を調べるだけでなく、Event, Fault, Syslog に関して調査を行う場合にも使用します。 Start Remote Logging API Inspector の外部出力用です。URL を入力すると、その server へ情報を転送します。 簡易 Server として、 SimpleAciUiLogServer が GitHub 上に公開されています。 詳細な使用方法は、GitHub を参照してください。python script なので、download した後に、SimpleAciUiLogServer を python で実行するだけで動作します。(Port を開けるため、Firewall の設定を変更する必要があるかもしれません。) Object Store Browser 別 window で object store browser (別名 Visore) が起動します。 class や dn を入力することで mo が確認できます。moquery command の GUI 版のようなものです。 直接 https://[apic address]/visore.html と入力しても access 可能です。 Show Debug Info 現在表示している page の class や dn が画面一番下に表示されるようになります。Object Store Browser で入力する class や dn を調べたい時に役立ちます。 About 現在の APIC の version が表示されます。 Settings UI の一部設定を変更できます。 Toggle GUI Mode Advanced/Basic mode を切り替えることができます。 Change Deployment Settings 設定変更/削除時の Warning 出力を変更できます。           ... View more