Configuring Monitoring

Configuring Syslog

Configuring a Logging Server Group

In the ACI fabric, one or more logging server-groups can be configured with one or more logging destination servers.

Procedure

  Command or Action Purpose
Step 1

configure

Example:

apic1# configure

Enters global configuration mode.

Step 2

logging server-group server-group-name

Example:

apic1(config)# logging server-group myLoggingGroup

Configure a grouping of servers for monitoring.

Step 3

[no] description text

Example:

apic1(config-logging)# logging description "This is my logging server group"

Specifies

Step 4

[no] console [severity {alerts | critical | emergencies}]

Example:

apic1(config-logging)# console severity critical

Enables logging to the console (only for switches) and optionally sets the minimum severity level for logging.

Step 5

[no] logfile [severity {alerts | critical | debugging | emergencies | errors | information | notifications | warnings}]

Example:

apic1(config-logging)# logfile severity critical

Enables logging to the logfile and optionally sets the minimum severity level for logging.

Step 6

[no] server ip-address-or-hostname [facility local-level] [severity severity-level] [mgmtepg {inb | oob}] [port port-number]

Example:

apic1(config-logging)# server reach.example.com level local4 mgmtepg inb port 514

Adds a destination logging server and optionally sets the minimum severity level for logging.

  • facility —Local facility in the form local n

  • severity —Minimum severity level for logging. Can be one of the options shown in the logfile command.

  • mgmt —Management endpoint group, either inb (inband) or oob (out of band).

  • port —Service port number of the logging server.

Examples

This example shows how to configure a syslog destination server group. 


apic1# configure
apic1(config)# logging server-group myLoggingGroup
apic1(config-logging)# logging description "This is my logging server group"
apic1(config-logging)# console severity critical
apic1(config-logging)# logfile severity critical
apic1(config-logging)# server reach.example.com level local4 mgmtepg inb port 514

What to do next

Configure syslog with this logging server group as the logging destination.

Configuring Syslog

In order to receive and monitor system log messages, you must specify a syslog destination, which can be the console, a local file, or one or more remote hosts running a syslog server. In addition, you can specify the minimum severity level of messages to be displayed on the console or captured by the file or host.

Before you begin

Configure a logging server-group containing the servers to which syslog messages will be sent.

Procedure

  Command or Action Purpose
Step 1

configure

Example:

apic1# configure

Enters global configuration mode.

Step 2

syslog common

Example:

apic1(config)# syslog common

Enters syslog common policy configuration mode.

Step 3

[no] logging description text

Example:

apic1(config-syslog)# logging description "This is the common logging policy"

Adds descriptive text about the policy.

Step 4

[no] logging severity {alerts | critical | debugging | emergencies | errors | information | notifications | warnings}

Example:

apic1(config-syslog)# logging severity notifications

Specifies the minimum severity level for sending syslog messages.

Step 5

[no] logging server-group server-group-name

Example:

apic1(config-syslog)# logging server-group myLoggingGroup

Specifies a destination logging server group.

Step 6

[no] logging audit

Example:

apic1(config-syslog)# logging audit

Enables audit logs to the policy.

Step 7

[no] logging event

Example:

apic1(config-syslog)# logging event

Enables event logs to the policy.

Step 8

[no] logging fault

Example:

apic1(config-syslog)# logging fault

Enables fault logs to the policy.

Step 9

[no] logging session

Example:

apic1(config-syslog)# logging session

Enables session logs to the policy.

Examples

This example shows how to configure syslog for messages of 'notification' severity or higher. Syslog messages from fault and event logs are sent to servers in server-group myLoggingGroup. 


apic1# configure
apic1(config)# syslog common
apic1(config-syslog)# logging description "This is the common logging policy"
apic1(config-syslog)# logging severity notifications
apic1(config-syslog)# logging server-group myLoggingGroup
apic1(config-syslog)# logging audit
apic1(config-syslog)# logging event

Configuring Call Home

Configuring the Call Home Policy

In the ACI fabric, Cisco Call Home configuration can be added in the common monitoring policy.

Procedure

  Command or Action Purpose
Step 1

configure

Example:

apic1# configure

Enters global configuration mode.

Step 2

callhome common

Example:

apic1(config)# callhome common

Enters Call Home common policy configuration mode.

Step 3

[no] logging audit

Example:

apic1(config-callhome)# logging audit

Enables audit logs to the policy.

Step 4

[no] logging event

Example:

apic1(config-callhome)# logging event

Enables event logs to the policy.

Step 5

[no] logging fault

Example:

apic1(config-callhome)# logging fault

Enables fault logs to the policy.

Step 6

[no] logging severity {alert | critical | debug | emergency | error | info | notice | warning}

Example:

apic1(config-callhome)# logging severity notice

Specifies the minimum severity level for logging.

Step 7

[no] periodic-inventory notification schedule scheduler

Example:

apic1(config-callhome)# periodic-inventory notification schedule EveryEightHours

Configures a periodic notification scheduler. The scheduler must be previously configured.

Step 8

show callhome common [destination-profile | query-profile | transport-email]

Example:

apic1(config-callhome)# show callhome common

Shows Call Home configuration.

Examples

This example shows how to configure a basic Call Home policy. 


apic1# configure
apic1(config)# callhome common
apic1(config-callhome)# logging event
apic1(config-callhome)# logging fault
apic1(config-callhome)# logging severity notice
apic1(config-callhome)# periodic-inventory notification schedule EveryEightHours
apic1(config-callhome)# end
apic1# show callhome common
Callhome : common

Logging Enabled  : event,faults
Logging Severity : notice

Destination-Profile : 

Admin State         : Enabled
Contract-id         : 12345678
Customer-id         : ABCDEFG
Email-addr          : admin@example.com
From email-addr     : apic1@example.com
Reply-To email-addr : apic1@example.com
Phone Number        : +14085551212
SMTP Port num       : 25

SMTP Server : smtp.example.com

Destination   Email-addr          Format   Message-Size   Message-Level
-----------   -----------------   ------   ------------   -------------
SanJose       admin@example.com   xml      40000          alert

Query-Profile :

Query Name    Query Type   Dn/Class   Target   Respones Subtree   Response Include
-----------   ----------   --------   ------   ----------------   ------------------------------
myUserQuery   class        User       self     children           ep-records,fault-records,stats

What to do next

Configure a destination profile and (optionally) a query profile.

Configuring a Call Home Destination Profile

You must configure at least one destination profile for Call Home. If the destination profile uses email message delivery, you must specify a Simple Mail Transfer Protocol (SMTP) server.

Procedure

  Command or Action Purpose
Step 1

configure

Example:

apic1# configure

Enters global configuration mode.

Step 2

callhome common

Example:

apic1(config)# callhome common

Enters Call Home common policy configuration mode.

Step 3

[no] destination-profile

Example:

apic1(config-callhome)# destination-profile

Configures a destination profile.

Step 4

[no] destination dest-name

Example:

apic1(config-callhome-destnprof)# destination SanJose

Configures a destination where the Call Home messages will be sent, including the format of the messages and the severity level for sending.

Note 

You can configure more than one destination.

Step 5

[no] email-addr email

Example:

apic1(config-callhome-destnprof-destn)# email-addr alerts@example.com

Configures the e-mail address that will receive the Call Home messages. Up to 255 alphanumeric characters are accepted in e-mail address format.

Step 6

[no] format {aml | xml | short-txt}

Example:

apic1(config-callhome-destnprof-destn)# format xml

Configures the format for Call Home messages, which can be sent in the following formats:

  • aml —Adaptive Messaging Language (AML) XML schema definition (XSD)

  • xml —The XML format enables communication with the Cisco Systems Technical Assistance Center (TAC).

  • short-txt —Short text format provides a one or two line description of the fault that is suitable for pagers or printed reports.

Step 7

[no] message-level {alert | critical | debug | emergency | error | info | notice | warning}

Example:

apic1(config-callhome-destnprof-destn)# message-level alert

Configures the minimum severity level for sending messages.

Step 8

[no] message-size size

Example:

apic1(config-callhome-destnprof-destn)# message-size 40000

Configures the size of the messages. The range is 0 to 5000000 characters.

Step 9

exit

Example:

apic1(config-callhome-destnprof-destn)# exit

Returns to destination profile configuration mode.

Step 10

Configure the destination profile.

Example:

apic1(config-callhome-destnprof)# (various commands)

Use the commands in Call Home Destination Profile Configuration Commands

Step 11

show callhome common [destination-profile | query-profile | transport-email]

Example:

apic1(config-callhome-destnprof)# show callhome common transport-email

Shows Call Home configuration.

Examples

This example shows how to configure Call Home to send email messages of severity 'alert' or higher to alerts@example.com. 


apic1# configure
apic1(config)# callhome common
apic1(config-callhome)# destination-profile
apic1(config-callhome-destnprof)# destination SanJose
apic1(config-callhome-destnprof-destn)# email-addr alerts@example.com
apic1(config-callhome-destnprof-destn)# format xml
apic1(config-callhome-destnprof-destn)# message-level alert
apic1(config-callhome-destnprof-destn)# message-size 40000
apic1(config-callhome-destnprof-destn)# exit
apic1(config-callhome-destnprof)# contract-id 12345678
apic1(config-callhome-destnprof)# customer-id ABCDEFG
apic1(config-callhome-destnprof)# description "Example Corporation"
apic1(config-callhome-destnprof)# site-id XYZ123
apic1(config-callhome-destnprof)# street-address "1 Cisco Way"
apic1(config-callhome-destnprof)# phone-contact +14085551212
apic1(config-callhome-destnprof)# email-contact admin@example.com
apic1(config-callhome-destnprof)# transport email from apic1@example.com
apic1(config-callhome-destnprof)# transport email reply-to apic1@example.com
apic1(config-callhome-destnprof)# transport email mail-server smtp.example.com mgmtepg inb port 25
apic1(config-callhome)# end
apic1# show callhome common transport-email
From email-addr : apic1@example.com
SMTP Port num   : 25

SMTP Server : smtp.example.com

Call Home Destination Profile Configuration Commands

These commands are entered in the Call Home destination profile ( config-callhome-destnprof ) configuration mode.

Command

Purpose

contract-id contract-id

The Call Home contract number for the customer.

customer-id customer-id

The CCO ID that includes the contract numbers for the support contract in its entitlements.

description text

Descriptive text about this customer site.

email-contact email

The email address for the main contact.

phone-contact phone-num

The telephone number for the main contact.

site-id site-id

The unique Call Home identification number for the customer site.

street-address address

The mailing address for the main contact.

transport email from email

The email address that should appear in the From field on Call Home alert messages sent by the system.

transport email reply-to email

The return email address that should appear in the From field on Call Home alert messages sent by the system.

transport email mail-server smtp-server mgmtepg {inb | oob} port port-number

The IP address or hostname of the SMTP server and the port number the system should use to talk to the SMTP server.

Configuring a Call Home Query

When an event triggers the sending of a Call Home report, information from your selected queries is included in the report. You can configure a query based on a class name or a distinguished name, and you can further qualify the query based on subtrees.

Before you begin

Procedure

  Command or Action Purpose
Step 1

configure

Example:

apic1# configure

Enters global configuration mode.

Step 2

callhome common

Example:

apic1(config)# callhome common

Enters Call Home common policy configuration mode.

Step 3

[no] query-profile

Example:

apic1(config-callhome)# query-profile

Enters Call Home query profile configuration mode.

Step 4

[no] query query-name type {class class-name | dn name}

Example:

apic1(config-callhome-queryprof)# query myUserQuery type class User

Configures a query profile.

Step 5

[no] response-subtree {full | children | no}

Example:

apic1(config-callhome-queryprof-query)# response-subtree children

Configures the response subtree. You can choose to include the full subtree, only children, or no subtree information.

Step 6

[no] response-incl {option[,option[,option...]]}

Example:

apic1(config-callhome-queryprof-query)# response-incl ep-records,fault-records,stats

Configures the specific subtree information categories to be included in the response. Multiple categories can be specified in a comma-separated list. The available categories are listed in Query Subtree Categories.

Step 7

[no] target {children | self | subtree}

Example:

apic1(config-callhome-queryprof-query)# target self

Configures the query target.

Step 8

show callhome common [destination-profile | query-profile | transport-email]

Example:

apic1(config-callhome-queryprof-query)# show callhome common query-profile

Shows Call Home configuration.

Examples

This example shows how to configure a Call Home query. 


apic1# configure
apic1(config)# callhome common
apic1(config-callhome)# query-profile
apic1(config-callhome-queryprof)# query myUserQuery type class User
apic1(config-callhome-queryprof-query)# response-subtree children
apic1(config-callhome-queryprof-query)# response-incl ep-records,fault-records,stats
apic1(config-callhome-queryprof-query)# target self
apic1(config-callhome)# end
apic1# show callhome common destination-profile
Query-Profile :

Query Name    Query Type   Dn/Class   Target   Respones Subtree   Response Include
-----------   ----------   --------   ------   ----------------   ------------------------------
myUserQuery   class        User       self     children           ep-records,fault-records,stats

Query Subtree Categories

Query Category

Description

add-mo-list

audit-logs

config-only

count

custom-path-hop

deployment

deployment-records

ep-records

event-logs

fault-count

fault-records

faults

full-deployment

health

health-records

local-prefix

no-scoped

none

port-deployment

record-subtree

relations

relations-with-parent

required

state

stats

tasks

Configuring TACACS External Logging

Creating a TACACS External Logging Destination Group Using the NX-OS-Style CLI

You can use the NX-OS-style command line interface (CLI) to configure TACACS destination groups and destinations. A TACACS destination group enables you to create a list of remote TACACS server destinations to which AAA logging data is sent. You can create one or more destinations in a group. After the destination group is created, you can associate it with a TACACS source, either for a fabric policy, an external access policy, or a specific tenant policy configured on the Cisco Application Policy Infrastructure Controller (Cisco APIC).

Note

You must have administrator rights to access the TACACS External Logging commands in the NX-OS-style CLI.

The following example CLI commands show how to configure a TACACS destination group and destination using the NX-OS-style CLI:

Procedure

Step 1

Enter the configuration mode.

Example:

apic1# config
Step 2

Create a TACACS destination group.

Example:

In the following command, a TACACS destination group named "tacacs-dest-grp-1" is created:

apic1(config)# tacacslog-group tacacs-dest-grp-1
Step 3

Create a TACACS destination in the new destination group.

Example:

In the following command, a remote TACSCS destination with an IP address of "1.1.1.1" is created and includes the default port number 49: 

apic1(config-tacacslog-group)# remote-dest 1.1.1.1 port 49
Note 

You can have logs sent to multiple ports on the same IP address by including additional port numbers after the port keyword.
Step 4

Configure specific parameters for the new remote TACACS destination.

Example:

In the following command example, the following characteristics are configured for the new remote destination:

  • Authentication key: 12345

  • Authentication protocol: MS-CHAP

  • Management EPG: Out-of-Band

apic1(config-remote-dest)# key
Enter Key: 12345
Enter Key again: 12345
apic1(config-remote-dest)# protocol mschap
apic1(config-remote-dest)# management-epg oob
The result of this configuration is the creation of a TACACS destination group containing a remote TACACS server destination. If you want the same AAA logging data sent to multiple remote TACACS servers, you can repeat steps 3 and 4 as many times as needed.

Creating a TACACS External Logging Source Using the NX-OS-Style CLI

You can use the NX-OS-style CLI to configure TACACS sources. In this configuration, the source is associated with a TACACS destination group. Where a TACACS source is created determines which set of AAA logging data is sent. For example, if you create the TACACS source in Fabric Policies, all AAA logging data for the Cisco Application Centric Infrastructure (Cisco ACI) fabric supported by Cisco Application Policy Infrastructure Controller (Cisco APIC) is sent to the associated TACACS destinations. You can create one or more sources to support different destination groups.

The following example CLI commands show how to configure a TACACS source using the NX-OS-style CLI:

Procedure

Step 1

Enter the configuration mode.

Example:

apic1# config
Step 2

Create a TACACS source.

Example:

In the following command, a TACSCS source named "tacacs-src-1" is created:

apic1(config)# tacacslog-monitoring common tacacslog-src tacacs-src-1
Step 3

Associate the TACACS source with a TACACS destination group.

Example:

In the following command, a TACSCS destination group named "tacacs-dest-grp-1" is associated with the new TACACS source:

apic1(config-tacacslog-monitoring)# server-group tacacs-dest-grp-1
The result of this configuration is the creation of a TACACS source for the entire fabric and the association of a destination group containing a remote TACACS server destination. All AAA logging data for the entire fabric is then sent to the associated TACACS destination(s).

Sending an On-Demand Tech Support File Using the NX-OS Style CLI


Note

Do not trigger tech support file collection from more than five nodes simultaneously, especially if they are to be exported into the APIC or to an external server with insufficient bandwidth and compute resources.

To avoid excessive storage usage in APIC, remove locally-stored tech support files promptly.

Before you begin

Configure a remote path for exporting the tech support file.

Procedure

  Command or Action Purpose
Step 1

trigger techsupport {all | controllers switch node-id} [remotename remote-path-name]

Example:

apic1# trigger techsupport switch 101,103 remotename remote5

Triggers the export of a tech support file from the controllers, switches, or all to the remote path. For switches, you can specify a range or a comma-separated list. If no remote host is specified, the file is collected in the controller itself.

Step 2

trigger techsupport host host-id

Example:

apic1# trigger techsupport host

Triggers the export of a tech support file from the specified host to the remote host. If no remote host is specified, the file is collected in the controller itself.

Step 3

trigger techsupport local

Example:

apic1# trigger techsupport local

Triggers the export of a local tech support file to the remote host. If no remote host is specified, the file is collected in the controller itself.

Step 4

show techsupport {all | controllers switch node-id} status

Example:

apic1# show techsupport switch 101 status

After a tech support file is triggered, this command shows the status of the tech support report.

Examples

This example shows how to trigger a tech support file for switch 101, to be stored locally on the apic1 controller. 


apic1# trigger techsupport switch 101

Triggering techsupport for Switch 101 using policy supNode101, setting filters to default value

Triggered on demand tech support successfully for Switch 101, will be available at: /data/techsupport on 
the controller. Use 'show techsupport' with your options to check techsupport status.

Configuring a Remote Path for File Export

In the ACI fabric, you can configure one or more remote destinations for exporting techsupport or configuration files.

Procedure

  Command or Action Purpose
Step 1

configure

Example:

apic1# configure

Enters global configuration mode.

Step 2

[no] remote path remote-path-name

Example:

apic1(config)# remote path myFiles

Enters configuration mode for a remote path.

Step 3

user username

Example:

apic1(config-remote)# user admin5

Sets the user name for logging in to the remote server. You are prompted for a password.

Step 4

path {ftp | scp | sftp} host [:port] [remote-directory ]

Example:

apic1(config-remote)# path sftp filehost.example.com:21 remote-directory /reports/apic

Sets the path and protocol to the remote server. You are prompted for a password.

Examples

This example shows how to configure a remote path for exporting files. 


apic1# configure
apic1(config)# remote path myFiles
apic1(config-remote)# user admin5
You must reset the password when modifying the path:
Password:
Retype password:
apic1(config-remote)# path sftp filehost.example.com:21 remote-directory /reports/apic
You must reset the password when modifying the path:
Password:
Retype password:

Using Show Commands for Monitoring

About Using the Show Commands

The show commands for faults, events, health, statistics, and audit logs can be filtered to display specific types of information or information from specific entities, such as controllers, leaf switches, spine switches, or tenants.

Broad queries are expensive in terms of system resources and storage. For example, using the show faults, events, or audit commands without entity filters retrieves all logs or records from the entire system. We recommend that you make use of the available data and entity filters to narrow your query as much as possible. For example, the following command would result in a quicker and more filtered response by limiting the query to the most recent 45 minute period: 

show audits last-minutes 45

Tip

At each point in the command, typing ‘ ?’ displays all possible keywords and options that can be used at that point along with a brief explanation of each.

Using the show faults Command

The show faults command can combine several data filters and an entity filter to deliver a specific set of faults. The command syntax is:

show faults [filter1 [filter2... ]] [entity-filter]

Entity filters restrict the output to faults of a controller, leaf, spine, or tenant. The available entity filters are listed in Entity Filters for Show Commands.

Data filters are provided to make the task of querying faults easier for the user. The available data filters are:

Filter

Description

ack {yes | no}

acknowledgment status

cause name

cause

code fault-code

fault code

controller

controller information

detail

detailed faults information

end-time YYYY-MM-DDTHR-MM:SS

fault activity up to this time

history

historical information

id fault-id

fault ID

l4l7-cluster[cluster name | tenant name]

L4 L7 device information

l4l7-graph[cluster name | tenant name]

L4 L7 graph information

last-days days

fault activity in the last N days

last-hours hours

fault activity in the last N hours

last-minutes minutes

fault activity in the last N minutes

lc lc-state

lifecycle state

leaf [leaf-id]

leaf switch information

microsoft domain name

Microsoft domain information

min-severity severity-value

minimum severity

severity severity-value

severity

spine [spine-id]

spine switch information

start-time YYYY-MM-DDTHR-MM:SS

fault activity starting from this time

tenant [name]

tenant information

type fault-type

fault type

vmware domain name

VMware domain information

Examples

This example shows all faults that occurred in the past five days with code “F110473”, severity “warning”, lifecycle “raised” and acknowledgment status “no” for the tenant TSW_Tenant0. 


apic1# show faults code F110473 last-days 5 severity warning lc raised ack no tenant TSW_Tenant0
Code            : F110473
Severity        : warning
Last Transition : 2015-11-03T01:19:04.913+00:00
Lifecycle       : raised
DN              : uni/tn-TSW_Tenant0/BD-tsw0ctx0BD1/fault-F110473
Description     : TCA: ingress drop bytes rate(l2IngrBytesAg15min:dropRate)  
                 value 160462 raised above threshold 100000

Using the show events Command

The show events command can combine several data filters and an entity filter to deliver a specific set of events. The command syntax is:

show events [filter1 [filter2... ]] [entity-filter]

Entity filters restrict the output to events of a controller, leaf, spine, or tenant. The available entity filters are listed in Entity Filters for Show Commands.

Data filters are provided to make the task of querying events easier for the user. The available data filters are:

Filter

Description

cause fault-value

cause

code event-code

event code

controller

controller information

detail

detailed events information

end-time YYYY-MM-DDTHR-MM:SS

event activity up to this time

id event-id

event ID

last-days days

event activity in the last N days

last-hours hours

event activity in the last N hours

last-minutes minutes

event activity in the last N minutes

leaf [leaf-id]

leaf switch information

spine [spine-id]

spine switch information

start-time YYYY-MM-DDTHR-MM:SS

event activity starting from this time

tenant [name]

tenant information

Examples

This example shows all events on leaf 101. 


apic1# show events leaf 101

Severity        : info
Affected Object : topology/pod-1/node-101/sys/phys-[eth1/28]
Code            : E4208843
ID              : 8589934758
Cause           : transition
Description     : PhysIf eth1/28 modified
Creation Time   : 2015-11-03T01:11:16.763+00:00

Using the show health Command

The show health command can combine several data filters and an entity filter to deliver a specific health report. The command syntax is:

show health [filter1 [filter2... ]] [entity-filter]

Entity filters restrict the output to health scores of a controller, leaf, spine, or tenant. The available entity filters are listed in Entity Filters for Show Commands.

Data filters are provided to make the task of querying health easier for the user. The available data filters are:

Filter

Description

end-time YYYY-MM-DDTHR-MM:SS

health activity up to this time

history

historical information

max-change percentage

minimum change in health score percentage

min-hs score

maximum health score

start-time YYYY-MM-DDTHR-MM:SS

health activity starting from this time

Examples

This example shows a brief health report for all tenants. 


apic1# show health tenant
Tenant              Score     Change(%)     Created
------------------------------------------------------------------------
infra               100       0             2015-05-12 18:45:47PDT
common              100       0             2015-05-12 18:45:47PDT
TSW_Tenant0         98        0             2015-05-12 18:20:58PDT
mgmt                100       0             2015-05-12 18:45:47PDT

This example shows all historical health records from the 4th of November that have a maximum health score of 75 that have had a minimum change of 10% for the tenant TSW_Tenant0. 


apic1# show health max-hs 75 min-change 10 start-time 2015-11-04T01:55:48 history tenant TSW_Tenant0

Using the show audits Command

The show audits command can be used to view the audit-logs as well as the session logs for an entity. The command can combine several data filters and an entity filter to deliver a specific set of audit logs. The command syntax is:

show audits [filter1 [filter2... ]] [entity-filter]

Entity filters restrict the output to logs of a controller, leaf, spine, or tenant. The available entity filters are listed in Entity Filters for Show Commands.

Data filters are provided to make the task of querying audit logs easier for the user. The available data filters are:

Filter

Description

action {creation | deletion | failure | modification | special | state-transition}

object action indicator

controller

controller information

detail

detailed log information

end-time YYYY-MM-DDTHR-MM:SS

log activity up to this time

id log-id

log ID

last-days days

log activity in the last N days

last-hours hours

log activity in the last N hours

last-minutes minutes

log activity in the last N minutes

leaf [leaf-id]

leaf switch information

spine [spine-id]

spine switch information

start-time YYYY-MM-DDTHR-MM:SS

log activity starting from this time

tenant [name]

tenant information

user user-name

name of user

Examples

This example shows all audit logs in the last 45 minutes for the tenant TSW_Tenant0. 


apic1# show audits last-minutes 45 tenant TSW_Tenant0
Creation Time   : 2015-11-03T01:11:05.708+00:00
ID              : 12884902085
User            : admin
Action          : creation
Affected Object : uni/tn-TSW_Tenant0/out-T0-sub-L3OUT-1/instP-               
                 l3extInstP-1/extsubnet-[192.5.1.0/24]                       
Description     : Subnet 192.5.1.0/24 created

Using the show stats Command

The show stats command can combine data filters and an entity filter to deliver a specific set of statistics. The command syntax is:

show stats granularity granularity [cumulative] [history] [entity-filter]

Entity filters restrict the output to statistics of a leaf, spine, or tenant. The available entity filters are listed in Entity Filters for Show Commands.

Data filters are provided to make the task of querying statistics easier for the user. The available data filters are:

Filter

Description

cumulative

cumulative statistics information

granularity {5min | 15min | 1h | 1d | 1w | 1mo | 1qtr | 1year}

the sampling interval size which can be 5 minutes, 15 minutes, 1 hour, 1 day, 1 week, 1 month, 1 quarter, or 1 year

history

historical statistics information

Examples

This example shows 15 minute granularity statistics for the tenant TSW_Tenant0. 


apic1# show stats granularity 15min tenant TSW_Tenant0

This example shows 15 minute granularity statistics for a specific port. 


apic1# show stats granularity 15min leaf 101 interface ethernet 1/1

Entity Filters for Show Commands

Entity filters can extend many show commands to restrict the output to faults of a controller, leaf, spine, or tenant. The available entity filters are:

Filter

controller

leaf node-id [fex]

leaf node-id interface [ethernet slot/port | l3instance [instance-name] | mgmt [mgmt0] | portchannel | tunnel [tunnel-name] ]

leaf node-id inventory {chassis [number] | fans [number] | module [number] | powersupply [number] | supervisor [number] }

leaf node-id protocol {arp | bgp | coop | ipv4 | ipv6 | isis | lldp | ospf | ospfv3}

leaf node-id vpc {

leaf node-id vrf [vrf-name]

spine node-id

spine node-id interface [ethernet slot/port | l3instance [instance-name] | mgmt [mgmt0] | tunnel [tunnel-name] ]

spine node-id inventory {chassis [number] | fabric [number] | fans [number] | module [number] | powersupply [number] | supervisor [number] | system [number] }

spine node-id protocol {arp | bgp | coop | ipv4 | ipv6 | isis | lldp | ospf | ospfv3}

spine node-id vrf [vrf-name]

tenant tenant-name

tenant tenant-name application [app-name] [epg]

tenant tenant-name bridge-domain [bd-name]

tenant tenant-name interface bridge-domain [bd-name]

Configuring SNMP

Before you begin

To allow SNMP communications, you must configure an out-of-band contract allowing SNMP traffic, which is normally on UDP:161.

Procedure

  Command or Action Purpose
Step 1

configure

Example:

apic1# configure

Enters global configuration mode.

Step 2

template snmp-fabric snmp-fabric-template-name

Example:

apic1(config)# template snmp-fabric Pol1

Enters template snmp-fabric mode.
Step 3

[no] snmp-server protocol enable

Example:

apic1(config-template-snmp-fabric)# snmp-server protocol enable

Enables (or disables) SNMP protocol support.

Step 4

[no] snmp-server community community-name

Example:

apic1(config-template-snmp-fabric)# snmp-server community mysecret

The community is required for SNMPv2 only.

Step 5

snmp-server contact contact-name

Example:

apic1(config-template-snmp-fabric)# snmp-server contact admin80

.

Step 6

snmp-server location location-name

Example:

apic1(config-template-snmp-fabric)# snmp-server location SanJose

Sets the location for the SNMP server.
Step 7

exit

Example:

apic1(config-template-snmp-fabric)# exit

Returns to global configuration mode
Step 8

template pod-group pod-group-template-name

Example:

apic1(config)# template pod-group allPods

Configures a pod-group template (policy).
Step 9

inherit snmp-fabric snmp-fabric-template-name

Example:

apic1(config-pod-group)# inherit snmp-fabric Pol1

Associates the pod-profile with the previously configured pod group.

Examples

The following example configures an out-of-band contract allowing SNMP traffic in the fabric.

apic1# configure
apic1(config)# template snmp-fabric Pol1
apic1(config-template-snmp-fabric)# snmp-server protocol enable
apic1(config-template-snmp-fabric)# snmp-server community mysecret
apic1(config-template-snmp-fabric)# snmp-server contact admin80
apic1(config-template-snmp-fabric)# snmp-server location SanJose
apic1(config-template-snmp-fabric)# exit
apic1(config)# template pod-group allPods 
apic1(config-pod-group)# inherit snmp-fabric Pol1 
apic1(config-pod-group)# exit
apic1(config)#

Configuring SNMP Policy Using CLI

Use this procedure to configure SNMP policy.

Procedure

  Command or Action Purpose
Step 1

configure

Example:


apic1# configure

Enters configuration mode.
Step 2

template snmp-fabric default

Example:


apic1(config)# template snmp-fabric default

Creates a SNMP policy.
Step 3

snmp-server clientgroup

Configures SNMP client group. A client group is a group of client IP addresses that allows SNMP access to routers or switches.
Step 4

snmp-server community

Example:


apic1(config-template-snmp-fabric)# snmp-server community abc

Configures SNMP community. The SNMP community profile enables access to the router or switch statistics for monitoring.

Step 5

snmp-server contact

Configures SNMP contact information.

Step 6

snmp-server host

Example:


apic1(config-template-snmp-fabric)# snmp-server host 2001:420:28e:2020::10 traps-version 2c abc
apic1(config-template-snmp-fabric)# snmp-server host 2001:420:28e:2020::2 traps-version 2c abc
apic1(config-template-snmp-fabric)# snmp-server host 2001:420:28e:2020::11 traps-version 2c abc

Configures SNMP trap host.

Step 7

snmp-server location

Configures SNMP location.

Step 8

snmp-server protocol

Example:


apic1(config-template-snmp-fabric)# snmp-server protocol enable

Configures SNMP protocol.

Step 9

snmp-server trap-fwd-server

Example:


apic1(config-template-snmp-fabric)# snmp-server trap-fwd-server 172.31.128.199

Configures SNMP trap forwarding server.

Step 10

snmp-server user

Example:


apic1(config-template-snmp-fabric)# snmp-server user test_user auth hmac-md5-96 '' priv none privacy-passphrase ''

Configures SNMP user. The SNMP user profile is used to associate users with SNMP policies for monitoring devices in a network.

Step 11

show running-config

Verifies the configuration.

Configuring Smart Callhome

About Smart Callhome

Smart Callhome provides an email-based notification for critical system policies in a similar way as Callhome. However, Smart Callhome collects a more specific selection of faults to deliver in email messages.


Note

Smart Callhome only collects and delivers faults.

The fault triggers that are typical of the Smart Callhome feature correspond to the kind of events that threaten to disrupt your network. Examples are:

  • Temperature Faults: The temperature of a sensor exceeds a threshold.

  • Fan/ Power Supply Faults: A fan or power supply unit goes offline.

  • Disk Utilization Faults: The disk usage of a device exceeds a threshold.

Smart Callhome collects faults and emails them to a network support engineer, a Network Operations Center, or to Cisco Smart Callhome services to generate a case with the Technical Assistance Center (TAC).

Creating a Smart Callhome Destination Group Using the NX-OS-Style CLI

Smart Callhome collects faults and emails them to a network support engineer, a Network Operations Center, or to the Cisco Technical Assistance Center (TAC).

You can use the NX-OS-style CLI to configure Smart Callhome destination groups and destinations. A Smart Callhome destination group enables you to create a list of email destinations to which fault data is sent. You can create one or more destinations in a group. After the destination group is created, you can associate it with a Smart Callhome source, either for the entire switch fabric supported by the Cisco Application Policy Infrastructure Controller (Cisco APIC) or for a specific Tenant.

The following example CLI commands show how to configure a Smart Callhome destination group and destination using the NX-OS-style CLI:

Procedure

Step 1

Enter the configuration mode.

Example:

apic1# config
Step 2

Enter the Smart Callhome common policy configuration mode.

Example:

apic1(config)# smartcallhome common
Note 

The default name for the common policy configuration mode is "common". It is the only name that can be created.
Step 3

Create a Smart Callhome destination group.

Example:

In the following command, a Smart Callhome destination group is created:

apic1(config-smartcallhome)# destination-profile
Step 4

Configure an SMTP server in the new destination group.

Example:

In the following command, an SMTP server with an IP address of "10.10.10.2" is added to the destination group:

apic1(config-callhome-destnprof)# transport email mail-server 10.10.10.2
Step 5

Configure profile parameters about the new Smart Callhome destination group.

Example:

The following commands provide additional information about the destination group:

  • contract-id: The service contract ID of the customer.

  • customer-id: The customer ID.

  • description: A description for the Smart Callhome destination profile.

  • email-contact: The customer contact e-mail address.

  • phone-contact: The customer contact phone number.

  • site-id: The ID of the site where the network is deployed.

  • street-address: The street address of the site.

Step 6

Create a Smart Callhome destination in the new destination group.

Example:

In the following command, a remote Smart Callhome destination named "sch-dest-1" is created:

apic1(config-callhome-destnprof)# destination sch-dest-1
Step 7

Configure specific parameters for the new remote Smart Callhome destination.

Example:

In the following command example, the following characteristics are configured for the new remote destination:

  • Email address: net-admin@site.com

  • Message format: Short text

  • RFC Compliant: True

apic1(config-callhome-destnprof-destn)# email-addr net-admin@site.com
apic1(config-callhome-destnprof-destn)# format short-txt
apic1(config-callhome-destnprof-destn)# rfc-compliant true
The result of this configuration is the creation of a Smart Callhome destination group containing a remote email destination. If you want the same Smart Callhome fault data sent to multiple email destinations, you can repeat steps 5 and 6 as many times as needed.