この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章の内容は、次のとおりです。
Cisco Application Centric Infrastructure(ACI)RBAC のルールによって、ファブリック全体へのアクセスを有効にするか、一部へのアクセスに制限します。たとえば、ベア メタル サーバ アクセス用のリーフ スイッチを設定するには、ログインしている管理者が infra ドメインに対する権限を持っている必要があります。デフォルトでは、テナント管理者は infra ドメインに対する権限を持っていません。この場合、リーフ スイッチに接続されているベア メタル サーバの使用を計画しているテナント管理者は、そのために必要なすべての手順を実行することはできません。テナント管理者は、infra ドメインに対する権限を持っているファブリック管理者と連携する必要があります。ファブリック管理者は、テナント管理者が ACI リーフ スイッチに接続されたベア メタル サーバを使用するアプリケーション ポリシーを導入するために使用するスイッチ設定ポリシーをセットアップします。
Application Policy Infrastructure Controller(APIC)ポリシーは、Cisco Application Centric Infrastructure(ACI)ファブリックの認証、認可、およびアカウンティング(AAA)機能を管理します。ユーザ権限、ロール、およびドメインとアクセス権限の継承を組み合わせることにより、管理者は細分化された方法で管理対象オブジェクト レベルで AAA 機能を設定することができます。これらの設定は、REST API、CLI、または GUI を使用して実行できます。
コア Application Policy Infrastructure Controller(APIC)の内部データ アクセス コントロール システムにより、マルチテナント分離が提供され、テナント間での個人情報の漏洩が防止されます。読み取り/書き込みの制約により、テナントによる他のテナントの設定、統計情報、障害、またはイベント データの参照が防止されます。管理者によって読み取り権限が割り当てられない限り、テナントはファブリックの設定、ポリシー、統計情報、障害、またはイベントの読み取りが制限されます。
APIC では、ロールベース アクセス コントロール(RBAC)を介してユーザのロールに従ってアクセスが提供されます。Cisco Application Centric Infrastructure(ACI)ファブリック ユーザは、次に関連付けられています。
ACI ファブリックは、管理対象オブジェクト(MO)レベルでアクセス権限を管理します。権限は、システム内の特定の機能に対するアクセスを許可または制限する MO です。たとえば、ファブリック機器は権限ビットです。このビットは、Application Policy Infrastructure Controller(APIC)によって物理ファブリックの機器に対応するすべてのオブジェクトで設定されます。
ロールは権限ビットの集合です。たとえば、「管理者」ロールが「ファブリック機器」と「テナント セキュリティ」に対する権限ビットに設定されていると、「管理者」ロールにはファブリックの機器とテナント セキュリティに対応するすべてのオブジェクトへのアクセス権があります。
セキュリティ ドメインは、ACI MIT オブジェクト階層の特定のサブツリーに関連付けられたタグです。たとえば、デフォルトのテナント「common」にはドメイン タグ common が付いています。同様に、特殊なドメイン タグ all の場合、MIT オブジェクト ツリー全体が含まれます。管理者は、MIT オブジェクト階層にカスタム ドメイン タグを割り当てることができます。たとえば、管理者は「solar」という名前のテナントにドメイン タグ「solar」を割り当てることができます。MIT 内では、特定のオブジェクトだけがセキュリティ ドメインとしてタグ付けできます。たとえば、テナントはセキュリティ ドメインとしてタグ付けすることができますが、テナント内のオブジェクトはできません。
ユーザを作成してロールを割り当てても、アクセス権は有効になりません。1 つ以上のセキュリティ ドメインにそのユーザを割り当てることも必要です。デフォルトでは、ACI ファブリックには事前作成された次の 2 つの特殊なドメインが含まれています。
(注) | ユーザのクレデンシャルが許可しない管理対象オブジェクトの読み取り操作の場合、「DN/Class Unauthorized to read」ではなく「DN/Class Not Found」というエラーが返されます。ユーザのクレデンシャルが許可しない管理対象オブジェクトへの書き込み操作の場合、「HTTP 401 Unauthorized」というエラーが返されます。GUI では、ユーザのクレデンシャルが許可しないアクションの場合、表示されないか、またはグレー表示されます。 |
事前に定義された一連の管理対象オブジェクト クラスをドメインに関連付けることができます。これらのクラスがオーバーラップすることはできません。ドメインの関連付けをサポートするクラスの例:
ドメインに関連付けることができるオブジェクトが作成されると、ユーザは、ユーザのアクセス権の範囲内でオブジェクトにドメインを割り当てる必要があります。ドメインの割り当てはいつでも変更できます。
仮想マシン管理(VMM)ドメインがセキュリティ ドメインとしてタグ付けされている場合、セキュリティ ドメイン内のユーザは、対応するタグ付き VMM ドメインにアクセスできます。たとえば、solar という名前のテナントに sun というセキュリティ ドメインのタグが付いており、VMM ドメインにも sun というセキュリティ ドメインのタグが付いている場合、solar テナント内のユーザは各自のアクセス権限に従って VMM ドメインにアクセスできます。
初期の設定スクリプトで、管理者アカウントが設定され、管理者はシステム起動時の唯一のユーザとなります。APIC は、きめ細かなロールベースのアクセス コントロール システムをサポートしており、そのシステムでは、権限が少ない管理者以外のユーザを含め、ユーザ アカウントをさまざまなロールで作成することができます。
ターゲット セキュリティ ドメインでローカル ユーザ アカウントを作成します。ターゲット ドメインが all である場合、新しいローカル ユーザの作成に使用するログイン アカウントは、all にアクセスできるファブリック全体の管理者である必要があります。ターゲット ドメインがテナントである場合、新しいローカル ユーザの作成に使用するログイン アカウントは、ターゲット テナント ドメインに対する完全な読み取り/書き込みアクセス権を持つテナント管理者である必要があります。
UNIX コマンド ssh-keygen を使用して公開キーを生成します。
ローカル ユーザを設定する代わりに、APIC を一元化された企業クレデンシャルのデータセンターに向けることができます。APIC は、Lightweight Directory Access Protocol(LDAP)、Active Directory、RADIUS、および TACACS+ をサポートしています。
(注) | APIC が少数側である(クラスタから切断されている)場合、ACI は分散システムであり、ユーザ情報が APICS に分散されるため、リモート ログインは失敗する可能性があります。ただし、ローカル ログインは APIC に対してローカルであるため、この場合も機能します。 |
外部認証プロバイダーを通じて認証されたリモート ユーザを設定するには、次の前提条件を満たす必要があります。
Cisco APIC では、管理者が外部認証サーバで Cisco AV ペアを設定する必要があります。Cisco AV ペアは、ユーザの RBAC ロールおよび権限に必要な APIC を指定します。Cisco AV ペアの形式は、RADIUS、LDAP、または TACACS+ のものと同じです。
外部認証サーバで Cisco AV ペアを設定するには、管理者が既存のユーザ レコードに Cisco AV ペアを追加します。Cisco AV ペアの形式は次のとおりです。
shell:domains = domainA/writeRole1|writeRole2|writeRole3/readRole1|readRole2, domainB/writeRole1|writeRole2|writeRole3/readRole1|readRole2 shell:domains = domainA/writeRole1|writeRole2|writeRole3/readRole1|readRole2, domainB/writeRole1|writeRole2|writeRole3/readRole1|readRole2(16003)最初の AV ペアの形式には UNIX ユーザ ID がなく、2 番目のものにはあります。すべてのリモート ユーザが同じロールを持ち、相互ファイル アクセスが許可される場合はどちらの形式でも問題ありません。UNIX ユーザ ID を指定しないと、APIC システムによって ID 23999 が適用され、AV ペア ユーザに対して複数のロールまたは読み取り権限が指定されます。これは、グループ設定で設定された権限より高いかまたは低い権限がユーザに付与される原因になることがあります。
(注) | APIC の Cisco AV ペアの形式は互換性があり、他の Cisco AV ペアの形式と共存できます。APIC はすべての AV ペアから最初に一致した AV ペアを選択します。 |
APIC は、次の正規表現をサポートしています。
shell:domains\\s*[=:]\\s*((\\S+?/\\S*?/\\S*?)(,\\S+?/\\S*?/\\S*?){0,31})(\\(\\d+\\))$ shell:domains\\s*[=:]\\s*((\\S+?/\\S*?/\\S*?)(,\\S+?/\\S*?/\\S*?){0,31})$
例:
shell:domains=domainA/writeRole1|writeRole2/
shell:domains=domainA//readRole1|readRole2
(注) | 文字「/」はログイン ドメインごとに writeRole と readRole の間を区切る記号で、使用するロールの種類が 1 つのみである場合も必要です。 Cisco AV ペアの文字列は、大文字と小文字が区別されます。エラーが表示されなくても、使用する大文字と小文字がドメイン名またはロールに一致していない場合は、予期しない権限が付与されることがあります。 |
オープン RADIUS サーバ(/etc/raddb/users)の設定例は次のとおりです。
aaa-network-admin Cleartext-Password := "<password>" Cisco-avpair = "shell:domains = all/aaa/read-all(16001)"
ベスト プラクティスとして、シスコは、bash シェルでユーザに割り当てられる AV ペアには 16000 ~ 23999 の範囲の一意の UNIX ユーザ ID を割り当てることを推奨します(SSH、Telnet または Serial/KVM のコンソールを使用)。Cisco AV ペアが UNIX ユーザ ID を提供しない状況が発生すると、そのユーザにはユーザ ID 23999 または範囲内の類似した番号が割り当てられます。これにより、そのユーザのホーム ディレクトリ、ファイル、およびプロセスに UNIX ID 23999 を持つリモート ユーザがアクセスできるようになってしまいます。
属性/値(AV)のペア文字列のカッコ内の数字は、セキュア シェル(SSH)または Telnet を使用してログインしたユーザの UNIX ユーザ ID として使用されます。
これで、APIC TACACS+ 設定手順は完了です。次に、RAIDUS サーバも使用する場合は、RADIUS 用の APIC の設定も行います。TACACS+ サーバのみを使用する場合は、次の ACS サーバ設定に関するトピックに進みます。
これで、APIC RADIUS 設定手順は完了です。次に、RADIUS サーバを設定します。
Cisco Secure Access Control Server(ACS)バージョン 5.5 がインストールされ、オンラインになっていること。
(注) | ここでは手順の説明に ACS v5.5 が使用されています。ACS の他のバージョンでもこのタスクを実行できる可能性がありますが、GUI の手順はバージョンによって異なる場合があります。 |
Cisco Application Policy Infrastructure Controller (Cisco APIC)の RADIUS キーまたは TACACS+ キーを使用できること(両方を設定する場合は両方のキー)。
Cisco APIC がインストールされ、オンラインになっていること。Cisco APIC クラスタが形成されて正常に動作していること。
RADIUS または TACACS+ のポート、認証プロトコル、およびキーを使用できること。
新しく作成された RADIUS および TACACS+ のユーザを使用して、Cisco APIC にログインします。割り当てられた RBAC ロールと権限に従って正しい Cisco APIC セキュリティ ドメインにアクセスできることを確認します。ユーザは、明示的に許可されていない項目にアクセスできてはなりません。読み取り/書き込みアクセス権が、そのユーザに設定されたものと一致している必要があります。
最初に LDAP サーバを設定し、次に Cisco Application Policy Infrastructure Controller (Cisco APIC)を LDAP アクセス用に設定する。
Microsoft Windows Server 2008 がインストールされ、オンラインになっていること。
Microsoft Windows Server 2008 サーバ マネージャの ADSI Edit ツールがインストールされていること。ADSI Edit をインストールするには、Windows Server 2008 サーバ マネージャのヘルプに記載されている手順に従ってください。
AciCiscoAVPair の属性の指定:Common Name = AciCiscoAVPair、LDAP Display Name = AciCiscoAVPair、Unique X500 Object ID = 1.3.6.1.4.1.9.22.1、Description = AciCiscoAVPair、Syntax = Case Sensitive String。
(注) | LDAP 設定のベスト プラクティスは、属性文字列として AciCiscoAVPair を使用することです。これにより、オブジェクト識別子(OID)の重複を許可しない一般的な LDAP サーバの制限に関連した問題が回避されます。つまり、ciscoAVPair OID がすでに使用されている場合です。 |
以下を行うことができる Microsoft Windows Server 2008 ユーザ アカウントを使用できること。
LDAP サーバは Cisco APIC にアクセスするように設定されます。
次の作業
Cisco APIC を LDAP アクセス用に設定します。
これで、APIC LDAP 設定手順は完了です。次に、APIC LDAP ログイン アクセスをテストします。
Cisco APIC では、管理者が外部認証サーバで Cisco AV ペアを設定する必要があります。これを行うには、管理者は既存のユーザ レコードに Cisco AV ペアを追加します。Cisco AV ペアは、ユーザの RBAC ロールおよび権限に必要な APIC を指定します。Cisco AV ペアの形式は、RADIUS、LDAP、または TACACS+ のものと同じです。AV ペアの形式には Cisco UNIX ユーザ ID が含まれるものと含まれないものがあります。すべてのリモート ユーザが同じロールを持ち、相互ファイル アクセスが許可される場合はどちらの形式でも問題ありません。UNIX ユーザ ID を指定しないと、APIC システムによって ID 23999 が適用され、AV ペア ユーザに対して複数のロールまたは読み取り権限が指定されます。これは、グループ設定で設定された権限より高いかまたは低い権限がユーザに付与される原因になることがあります。このトピックでは、許可されない動作を変更する方法について説明します。
NX-OS スタイル CLI を使用して欠落または不良 Cisco AV ペアを持つリモート ユーザのデフォルトの動作を変更するには、次の手順を実行します。
Cisco ACI ファブリックの APIC コントローラは、ユーザを認証するためにさまざまな方法を提供します。
主要な認証方式ではユーザ名とパスワードが使用され、APIC REST API は APIC に対するその後のアクセスに使用できる認証トークンを返します。これは、HTTPS が使用不可であるか有効でない状況では安全でないと見なされます。
(注) | また、リプレイ攻撃を防ぐためには HTTPS を使用する必要があります。 |
認証に X.509 証明書ベースの署名を使用する前に、次の必須タスクが完了していることを確認します。
次の注意事項と制約事項に従ってください。
ローカル ユーザの設定
ステップ 1 | メニュー バーで、 を選択します。 |
ステップ 2 | [Navigation] ペインで、[AAA Authentication] をクリックします。 |
ステップ 3 | [Work] ペインのデフォルトの [Authentication] フィールドで、[Realm] フィールドが [Local] と表示されていることを確認します。 |
ステップ 4 | [Navigation] ペインで、 を展開します。
管理ユーザはデフォルトで存在しています。 |
ステップ 5 | [Navigation] ペインで、[Local Users] をクリックし、[Create Local User] をクリックします。 |
ステップ 6 | [Security] ダイアログボックスで、ユーザに必要なセキュリティ ドメインを選択し、[Next] をクリックします。 |
ステップ 7 | [Roles] ダイアログボックスで、ユーザのロールを選択するためのオプション ボタンをクリックし、[Next] をクリックします。
読み取り専用または読み取り/書き込み権限を提供できます。 |
ステップ 8 | [User Identity] ダイアログボックスで、次の操作を実行します。 |
ステップ 9 | [Navigation] ペインで、作成したユーザの名前をクリックします。[Work] ペインで、[Security Domains] 領域のユーザの横にある [+] 記号を展開します。 ユーザのアクセス権限が表示されます。 |
ステップ 10 | [Work] ペインの [User Certificates] 領域で、ユーザ証明書の [+] 記号をクリックし、[Create X509 Certificate] ダイアログ ボックスで次の操作を実行します。 X509 証明書がローカル ユーザ用に作成されます。 |
例: method: POST url: http://apic/api/node/mo/uni/userext/user-userabc.json payload: { "aaaUser": { "attributes": { "name": "userabc", "firstName": "Adam", "lastName": "BC", "phone": "408-525-4766", "email": "userabc@cisco.com", }, "children": [{ "aaaUserCert": { "attributes": { "name": "userabc.crt", "data": "-----BEGIN CERTIFICATE-----\nMIICjjCCAfegAwIBAgIJAMQnbE <snipped content> ==\n-----END CERTIFICATE-----", }, "children": [] }, "aaaUserDomain": { "attributes": { "name": "all", }, "children": [{ "aaaUserRole": { "attributes": { "name": "aaa", "privType": "writePriv", }, "children": [] } }, { "aaaUserRole": { "attributes": { "name": "access-admin", "privType": "writePriv", }, "children": [] } }, { "aaaUserRole": { "attributes": { "name": "admin", "privType": "writePriv", }, "children": [] } }, { "aaaUserRole": { "attributes": { "name": "fabric-admin", "privType": "writePriv", }, "children": [] } }, { "aaaUserRole": { "attributes": { "name": "nw-svc-admin", "privType": "writePriv", }, "children": [] } }, { "aaaUserRole": { "attributes": { "name": "ops", "privType": "writePriv", }, "children": [] } }, { "aaaUserRole": { "attributes": { "name": "read-all", "privType": "writePriv", }, "children": [] } }, { "aaaUserRole": { "attributes": { "name": "tenant-admin", "privType": "writePriv", }, "children": [] } }, { "aaaUserRole": { "attributes": { "name": "tenant-ext-admin", "privType": "writePriv", }, "children": [] } }, { "aaaUserRole": { "attributes": { "name": "vmm-admin", "privType": "writePriv", }, "children": [] } }] } }] } } |
例: #!/usr/bin/env python from cobra.model.pol import Uni as PolUni from cobra.model.aaa import UserEp as AaaUserEp from cobra.model.aaa import User as AaaUser from cobra.model.aaa import UserCert as AaaUserCert from cobra.model.aaa import UserDomain as AaaUserDomain from cobra.model.aaa import UserRole as AaaUserRole from cobra.mit.access import MoDirectory from cobra.mit.session import LoginSession from cobra.internal.codec.jsoncodec import toJSONStr APIC = 'http://10.10.10.1' username = ‘admin’ password = ‘p@$$w0rd’ session = LoginSession(APIC, username, password) modir = MoDirectory(session) modir.login() def readFile(fileName=None, mode="r"): if fileName is None: return "" fileData = "" with open(fileName, mode) as aFile: fileData = aFile.read() return fileData # Use a dictionary to define the domain and a list of tuples to define # our aaaUserRoles (roleName, privType) # This can further be abstracted by doing a query to get the valid # roles, that is what the GUI does userRoles = {'all': [ ('aaa', 'writePriv'), ('access-admin', 'writePriv'), ('admin', 'writePriv'), ('fabric-admin', 'writePriv'), ('nw-svc-admin', 'writePriv'), ('ops', 'writePriv'), ('read-all', 'writePriv'), ('tenant-admin', 'writePriv'), ('tenant-ext-admin', 'writePriv'), ('vmm-admin', 'writePriv'), ], } uni = PolUni('') # '' is the Dn string for topRoot aaaUserEp = AaaUserEp(uni) aaaUser = AaaUser(aaaUserEp, 'userabc', firstName='Adam', email='userabc@cisco.com') aaaUser.lastName = 'BC' aaaUser.phone = '555-111-2222' aaaUserCert = AaaUserCert(aaaUser, 'userabc.crt') aaaUserCert.data = readFile("/tmp/userabc.crt") # Now add each aaaUserRole to the aaaUserDomains which are added to the # aaaUserCert for domain,roles in userRoles.items(): aaaUserDomain = AaaUserDomain(aaaUser, domain) for roleName, privType in roles: aaaUserRole = AaaUserRole(aaaUserDomain, roleName, privType=privType) print toJSONStr(aaaUser, prettyPrint=True) cr = ConfigRequest() cr.addMo(aaaUser) modir.commit(cr) # End of Script to create a user |
次の情報が用意されている必要があります。
ステップ 1 | HTTP メソッド、REST API URI、およびペイロードをこの順序で連結し、ファイルに保存します。
OpenSSL で署名を計算するには、この連結データをファイルに保存する必要があります。この例では、ファイル名 payload.txt を使用します。秘密キーは userabc.key というファイルにあることに注意してください。 例:GET の例: GET http://10.10.10.1/api/class/fvTenant.json?rsp-subtree=childrenPOST の例: POST http://10.10.10.1/api/mo/tn-test.json{"fvTenant": {"attributes": {"status": "deleted", "name": "test"}}} | ||
ステップ 2 | OpenSSL を使用して、秘密キーとペイロード ファイルを使用して署名を計算します。 例: openssl dgst -sha256 -sign userabc.key payload.txt > payload_sig.bin生成されたファイルには、複数行に印字された署名があります。 | ||
ステップ 3 | Bash を使用して、署名から改行文字を取り除きます。 例: $ tr -d '\n' < payload_sig.base64 P+OTqK0CeAZjl7+Gute2R1Ww8OGgtzE0wsLlx8fIXXl4V79Zl7 Ou8IdJH9CB4W6CEvdICXqkv3KaQszCIC0+Bn07o3qF//BsIplZmYChD6gCX3f7q IcjGX+R6HAqGeK7k97cNhXlWEoobFPe/oajtPjOu3tdOjhf/9ujG6Jv6Ro=
| ||
ステップ 4 | 署名を文字列内に配置し、APIC が署名をペイロードと照合して確認できるようにします。
この完全な署名が、要求のヘッダー内のクッキーとして APIC に送信されます。 例: APIC-Request-Signature=P+OTqK0CeAZjl7+Gute2R1Ww8OGgtzE0wsLlx8f IXXl4V79Zl7Ou8IdJH9CB4W6CEvdICXqkv3KaQszCIC0+Bn07o3qF//BsIplZmYChD6gCX3f 7qIcjGX+R6HAqGeK7k97cNhXlWEoobFPe/oajtPjOu3tdOjhf/9ujG6Jv6Ro=; APIC-Certificate-Algorithm=v1.0; APIC-Certificate-Fingerprint=fingerprint; APIC-Certificate-DN=uni/userext/user-userabc/usercert-userabc.crt
| ||
ステップ 5 | 署名を使用して APIC と通信するには、Python SDK の CertSession クラスを使用します。
次のスクリプトは、ACI Python SDK の CertSession クラスを使用して、署名を使用して APIC に要求する方法の例です。 例: #!/usr/bin/env python # It is assumed the user has the X.509 certificate already added to # their local user configuration on the APIC from cobra.mit.session import CertSession from cobra.mit.access import MoDirectory def readFile(fileName=None, mode="r"): if fileName is None: return "" fileData = "" with open(fileName, mode) as aFile: fileData = aFile.read() return fileData pkey = readFile("/tmp/userabc.key") csession = CertSession("https://ApicIPOrHostname/", "uni/userext/user-userabc/usercert-userabc.crt", pkey) modir = MoDirectory(csession) resp = modir.lookupByDn('uni/fabric') pring resp.dn # End of script
|
ACI ファブリック アカウンティングは、障害およびイベントと同じメカニズムで処理される以下の 2 つの管理対象オブジェクト(MO)によって処理されます。
aaaSessionLR MO は、APIC およびスイッチでのユーザ アカウントのログイン/ログアウト セッション、およびトークン更新を追跡します。ACI ファブリック セッション アラート機能は、次のような情報を保存します。
aaaModLR MO は、ユーザがオブジェクトに対して行う変更、およびいつ変更が発生したかを追跡します。
AAA サーバが ping 可能でない場合は、使用不可としてマークされ、エラーが表示されます。
aaaSessionLR と aaaModLR の両方のイベント ログが、APIC シャードに保存されます。データがプリセットされているストレージ割り当てサイズを超えると、先入れ先出し方式でレコードを上書きします。
(注) | APIC クラスタ ノードを破壊するディスク クラッシュや出火などの破壊的なイベントが発生した場合、イベント ログは失われ、イベント ログはクラスタ全体で複製されません。 |
aaaModLR MO と aaaSessionLR MO は、クラスまたは識別名(DN)でクエリできます。クラスのクエリは、ファブリック全体のすべてのログ レコードを提供します。ファブリック全体の aaaModLR レコードはすべて、GUI の
セクションから入手できます。APIC GUI の オプションを使用すると、GUI に示された特定のオブジェクトのイベント ログを表示できます。標準の syslog、callhome、REST クエリ、および CLI エクスポート メカニズムは、aaaModLR MO と aaaSessionLR MO のクエリ データで完全にサポートされます。このデータをエクスポートするデフォルト ポリシーはありません。
APIC には、一連のオブジェクトまたはシステム全体のデータの集約を報告する、事前設定されたクエリはありません。ファブリック管理者は、aaaModLR および aaaSessionLR のクエリ データを定期的に syslog サーバにエクスポートするエクスポート ポリシーを設定できます。エクスポートされたデータを定期的にアーカイブし、システムの一部またはシステム ログ全体のカスタム レポートを生成するために使用できます。
APIC は、共有サービスとしての外部ネットワークへのルーテッド接続用に設定されたポート(l3extInstP EPG)からバイト カウントとパケット カウントでの課金統計情報を収集するように設定できます。任意のテナントの任意の EPG が、外部ネットワークへのルーテッド接続用に l3extInstP EPG を共有できます。課金統計情報は、共有サービスとして l3extInstP EPG を使用する任意のテナント内の EPG ごとに収集できます。l3extInstP がプロビジョニングされているリーフ スイッチは課金統計情報を APIC に転送し、そこで課金情報が集約されます。定期的に課金統計情報をサーバにエクスポートするようにアカウンティング ポリシーを設定できます。