Cisco Release 4.x Enterprise Network Function Virtualization Infrastructure Software User Manual

Sample Syslog messages:
2017 Jun 16 11:20:22 nfvis %SYS-6-AAA_TYPE_CREATE: AAA authentication type tacacs created successfully AAA authentication set to use tacacs server
2017 Jun 16 11:20:23 nfvis %SYS-6-RBAC_USER_CREATE: Created rbac user successfully: admin
2017 Jun 16 15:36:12 nfvis %SYS-6-CREATE_FLAVOR: Profile created: ISRv-small
2017 Jun 16 15:36:12 nfvis %SYS-6-CREATE_FLAVOR: Profile created: ISRv-medium
2017 Jun 16 15:36:13 nfvis %SYS-6-CREATE_IMAGE: Image created: ISRv_IMAGE_Test
2017 Jun 19 10:57:27 nfvis %SYS-6-NETWORK_CREATE: Network testnet created successfully
2017 Jun 21 13:55:57 nfvis %SYS-6-VM_ALIVE: VM is active: ROUTER

Note To refer to the complete list of syslog messages, see Syslog Messages

Configure a Remote Syslog Server
To send syslogs to an external server, configure its IP address or DNS name along with the protocol to send syslogs and the port number on the syslog server.
To configure a remote Syslog server:
configure terminal system settings logging host 172.24.22.186 port 3500 transport tcp commit

Note A maximum of 4 remote syslog servers can be configured. The remote syslog server can be specified using its IP address or DNS name. The default protocol for sending syslogs is UDP with a default port of 514. For TCP, the default port is 601.

Configure Syslog Severity
The syslog severity describes the importance of the syslog message.
To configure syslog severity:
configure terminal
system settings logging severity <debug | informational | notice | warning| error| critical | alert | emergency>

Table 1: Syslog Severity Levels

Severity Level| Description| Numeric Encoding for Severity in
the Syslog Message Format
---|---|---
debug| Debug-level messages| 6
informational| Informational messages| 7
notice| Normal but significant condition| 5
warning| Warning conditions| 4
error| Error conditions| 3
critical| Critical conditions| 2
alert| Take action immediately| 1
emergency| System is unusable| 0

Note By default, the logging severity of syslogs is informational which means all syslogs at informational severity and higher will be logged. Configuring a value for severity will result in syslogs at the configured severity and syslogs which are more severe than the configured severity.

Configure Syslog Facility
The syslog facility can be used to logically separate and store syslog messages on the remote syslog server.
For example, syslogs from a particular NFVIS can be assigned a facility of local0 and can be stored and processed in a different directory location on the syslog server. This is useful to separate it from syslogs with a facility of local1 from another device.
To configure syslog facility:
configure terminal system settings logging facility local5

Note The logging facility can be changed to a facility from local0 to local7 By default, NFVIS sends syslogs with the facility of local7

Syslog Support APIs and Commands

• /api/config/system/settings/logging
• /api/operational/system/settings/logging| • system settings logging host
• system settings logging severity
• system settings logging facility

NETCONF Event Notifications

Cisco Enterprise NFVIS generates event notifications for key events. A NETCONF client can subscribe to these notifications for monitoring the progress of configuration activation and the status change of the system and VMs.
There are two types of event notifications: nfvisEvent and vmlcEvent (VM life cycle event) To receive event notifications automatically, you can run the NETCONF client, and subscribe to these notifications using the following NETCONF operations:

• –create-subscription=nfvisEvent
• –create-subscription=vmlcEvent

You can view NFVIS and VM life cycle event notifications using the show notification stream nfvisEvent and show notification stream vmlcEvent commands respectively. For more information see, Event Notifications.

SNMP Support on NFVIS

Introduction about SNMP
Simple Network Management Protocol (SNMP) is an application-layer protocol that provides a message format for communication between SNMP managers and agents. SNMP provides a standardized framework and a common language used for the monitoring and management of devices in a network.
The SNMP framework has three parts:

• SNMP manager – The SNMP manager is used to control and monitor the activities of network hosts using SNMP.
• SNMP agent – The SNMP agent is the software component within the managed device that maintains the data for the device and reports these data, as needed, to managing systems.
• MIB – The Management Information Base (MIB) is a virtual information storage area for network management information, which consists of collections of managed objects.

A manager can send the agent requests to get and set MIB values. The agent can respond to these requests.
Independent of this interaction, the agent can send unsolicited notifications (traps or informs) to the manager to notify the manager of network conditions.

SNMP Operations
SNMP applications perform the following operations to retrieve data, modify SNMP object variables, and send notifications:

• SNMP Get – The SNMP GET operation is performed by a Network Management Server (NMS) to retrieve SNMP object variables.
• SNMP Set – The SNMP SET operation is performed by a Network Management Server (NMS) to modify the value of an object variable.
• SNMP Notifications – A key feature of SNMP is its capability to generate unsolicited notifications from an SNMP agent.

SNMP Get
The SNMP GET operation is performed by a Network Management Server (NMS) to retrieve SNMP object variables. There are three types of GET operations:

• GET: Retrieves the exact object instance from the SNMP agent.
• GETNEXT: Retrieves the next object variable, which is a lexicographical successor to the specified  variable.
• GETBULK: Retrieves a large amount of object variable data, without the need for repeated GETNEXT operations.
  The command for SNMP GET is :
  snmpget -v2c -c [community-name] [NFVIS-box-ip] [tag-name, example ifSpeed].[index value]

SNMP Walk
SNMP walk is an SNMP application that uses SNMP GETNEXT requests to query a network entity for a tree of information.
An object identifier (OID) may be given on the command line. This OID specifies which portion of the object identifier space will be searched using GETNEXT requests. All variables in the subtree below the given OID are queried and their values presented to the user.
The command for SNMP walk with SNMP v2 is: snmpwalk -v2c -c [community-name] [nfvis-box-ip]

snmpwalk -v2c -c myUser 172.19.147.115 1.3.6.1.2.1.1
SNMPv2-MIB::sysDescr.0 = STRING: Cisco NFVIS
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.9.12.3.1.3.1291
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (43545580) 5 days, 0:57:35.80
SNMPv2-MIB::sysContact.0 = STRING:
SNMPv2-MIB::sysName.0 = STRING:
SNMPv2-MIB::sysLocation.0 = STRING:
SNMPv2-MIB::sysServices.0 = INTEGER: 70
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00
IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifIndex.2 = INTEGER: 2
IF-MIB::ifIndex.3 = INTEGER: 3
IF-MIB::ifIndex.4 = INTEGER: 4
IF-MIB::ifIndex.5 = INTEGER: 5
IF-MIB::ifIndex.6 = INTEGER: 6
IF-MIB::ifIndex.7 = INTEGER: 7
IF-MIB::ifIndex.8 = INTEGER: 8
IF-MIB::ifIndex.9 = INTEGER: 9
IF-MIB::ifIndex.10 = INTEGER: 10
IF-MIB::ifIndex.11 = INTEGER: 11
IF-MIB::ifDescr.1 = STRING: GE0-0
IF-MIB::ifDescr.2 = STRING: GE0-1
IF-MIB::ifDescr.3 = STRING: MGMT
IF-MIB::ifDescr.4 = STRING: gigabitEthernet1/0
IF-MIB::ifDescr.5 = STRING: gigabitEthernet1/1
IF-MIB::ifDescr.6 = STRING: gigabitEthernet1/2
IF-MIB::ifDescr.7 = STRING: gigabitEthernet1/3
IF-MIB::ifDescr.8 = STRING: gigabitEthernet1/4
IF-MIB::ifDescr.9 = STRING: gigabitEthernet1/5
IF-MIB::ifDescr.10 = STRING: gigabitEthernet1/6
IF-MIB::ifDescr.11 = STRING: gigabitEthernet1/7
…
SNMPv2-SMI::mib-2.47.1.1.1.1.2.0 = STRING: “Cisco NFVIS”
SNMPv2-SMI::mib-2.47.1.1.1.1.3.0 = OID: SNMPv2-SMI::enterprises.9.1.1836
SNMPv2-SMI::mib-2.47.1.1.1.1.4.0 = INTEGER: 0
SNMPv2-SMI::mib-2.47.1.1.1.1.5.0 = INTEGER: 3
SNMPv2-SMI::mib-2.47.1.1.1.1.6.0 = INTEGER: -1
SNMPv2-SMI::mib-2.47.1.1.1.1.7.0 = STRING: “ENCS5412/K9”
SNMPv2-SMI::mib-2.47.1.1.1.1.8.0 = STRING: “M3”
SNMPv2-SMI::mib-2.47.1.1.1.1.9.0 = “”
SNMPv2-SMI::mib-2.47.1.1.1.1.10.0 = STRING: “3.7.0-817”
SNMPv2-SMI::mib-2.47.1.1.1.1.11.0 = STRING: “FGL203012P2”
SNMPv2-SMI::mib-2.47.1.1.1.1.12.0 = STRING: “Cisco Systems, Inc.”
SNMPv2-SMI::mib-2.47.1.1.1.1.13.0 = “”
…
The following is a sample configuration of SNMP walk with SNMP v3:
snmpwalk -v 3 -u user3 -a sha -A changePassphrase -x aes -X changePassphrase -l authPriv -n snmp 172.16.1.101 system
SNMPv2-MIB::sysDescr.0 = STRING: Cisco ENCS 5412, 12-core Intel, 8 GB, 8-port PoE LAN, 2 HDD, Network Compute System
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.9.1.2377
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (16944068) 1 day, 23:04:00.68
SNMPv2-MIB::sysContact.0 = STRING:
SNMPv2-MIB::sysName.0 = STRING:
SNMPv2-MIB::sysLocation.0 = STRING:
SNMPv2-MIB::sysServices.0 = INTEGER: 70
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00

SNMP Notifications
A key feature of SNMP is the ability to generate notifications from an SNMP agent. These notifications do not require that requests be sent from the SNMP manager. Unsolicited  asynchronous) notifications can be generated as traps or inform requests. Traps are messages alerting the SNMP manager to a condition on the network. Inform requests (informs) are traps that include a request for confirmation of receipt from the SNMP manager. Notifications can indicate improper user authentication, restarts, the closing of a connection, loss of connection to a neighbor router, or other significant events.

Note
Starting from Release 3.8.1 NFVIS has SNMP Trap support for switch interfaces. If a trap server is setup in the NFVIS snmp configuration, it will send trap messages for both NFVIS and switch interfaces. Both the interfaces are triggered by the link state up or down by unplugging a cable or setting admin_state up or down when a cable is connected.

SNMP Versions

Cisco enterprise NFVIS supports the following versions of SNMP:

• SNMP v1—The Simple Network Management Protocol: A Full Internet Standard, defined in RFC 1157. (RFC 1157 replaces the earlier versions that were published as RFC 1067 and RFC 1098.) Security is based on community strings.
• SNMP v2c—The community-string based Administrative Framework for SNMPv2. SNMPv2c (the “c” stands for “community”) is an Experimental Internet Protocol defined in RFC 1901, RFC 1905, and RFC 1906. SNMPv2c is an update of the protocol operations and data types of SNMPv2p (SNMPv2 Classic), and uses the community-based security model of SNMPv1.
• SNMPv3—Version 3 of SNMP. SNMPv3 is an interoperable standards-based protocol defined in RFCs 3413 to 3415. SNMPv3 provides secure access to devices by authenticating and encrypting packets over the network.

The security features provided in SNMPv3 are as follows:

• Message integrity—Ensuring that a packet has not been tampered with in transit.
• Authentication—Determining that the message is from a valid source.
• Encryption—Scrambling the contents of a packet to prevent it from being learned by an unauthorized source.

Both SNMP v1 and SNMP v2c use a community-based form of security. The community of managers able to access the agent MIB is defined by an IP address Access Control List and password.
SNMPv3 is a security model in which an authentication strategy is set up for a user and the group in which the user resides. A security level is the permitted level of security within a security model. A combination of a security model and a security level determines which security mechanism is employed when handling an SNMP packet.
Authentication of the community with the user configuration is implemented even though SNMP v1 and v2 traditionally do not require a user configuration to be set. For both SNMP v1 and v2 on NFVIS, the user must be set with the same name and version as the corresponding community name. The user group must also match an existing group with the same SNMP version for snmpwalk commands to work.

SNMP MIB Support

Table 2: Feature History

NFVIS hostname using SNMP.
SNMP VM Monitoring MIB| NFVIS Release 4.4.1| Support added for SNMP VM
monitoring MIBs.

The following MIBs are supported for SNMP on NFVIS:
CISCO-MIB starting from Cisco NFVIS Release 4.11.1:
CISCO-MIB OID 1.3.6.1.4.1.9.2.1.3. hostname
IF-MIB (1.3.6.1.2.1.31):

• ifDescr
• ifType
• ifPhysAddress
• ifSpeed
• ifOperStatus
• ifAdminStatus
• ifMtu
• ifName
• ifHighSpeed
• ifPromiscuousMode
• ifConnectorPresent
• ifInErrors
• ifInDiscards
• ifInOctets
• ifOutErrors
• ifOutDiscards
• ifOutOctets
• ifOutUcastPkts
• ifHCInOctets
• ifHCInUcastPkts
• ifHCOutOctets
• ifHCOutUcastPkts
• ifInBroadcastPkts
• ifOutBroadcastPkts
• ifInMulticastPkts
• ifOutMulticastPkts
• ifHCInBroadcastPkts
• ifHCOutBroadcastPkts
• ifHCInMulticastPkts
• ifHCOutMulticastPkts

Entity MIB (1.3.6.1.2.1.47):

• entPhysicalIndex
• entPhysicalDescr
• entPhysicalVendorType
• entPhysicalContainedIn
• entPhysicalClass
• entPhysicalParentRelPos
• entPhysicalName
• entPhysicalHardwareRev
• entPhysicalFirmwareRev
• entPhysicalSoftwareRev
• entPhysicalSerialNum
• entPhysicalMfgName
• entPhysicalModelName
• entPhysicalAlias
• entPhysicalAssetID
• entPhysicalIsFRU

Cisco Process MIB (1.3.6.1.4.1.9.9.109):

• cpmCPUTotalPhysicalIndex (.2)
• cpmCPUTotal5secRev (.6.x)*
• cpmCPUTotal1minRev (.7.x)*
• cpmCPUTotal5minRev (.8.x)*
• cpmCPUMonInterval (.9)
• cpmCPUMemoryUsed (.12)
• cpmCPUMemoryFree (.13)
• cpmCPUMemoryKernelReserved (.14)
• cpmCPUMemoryHCUsed (.17)
• cpmCPUMemoryHCFree (.19)
• cpmCPUMemoryHCKernelReserved (.21)
• cpmCPULoadAvg1min (.24)
• cpmCPULoadAvg5min (.25)
• cpmCPULoadAvg15min (.26)

Note

• indicates the support data required for a single CPU core starting from NFVIS 3.12.3 release.

Cisco Environmental MIB (1.3.6.1.4.1.9.9.13):

• Voltage Sensor:
• ciscoEnvMonVoltageStatusDescr
• ciscoEnvMonVoltageStatusValue
• Temperature Sensor:
• ciscoEnvMonTemperatureStatusDescr
• ciscoEnvMonTemperatureStatusValue
• Fan Sensor
• ciscoEnvMonFanStatusDescr
• ciscoEnvMonFanState

Note Sensor support for the following hardware platforms:

• ENCS 5400 series: all
• ENCS 5100 series: none
• UCS-E: voltage, temperature
• UCS-C: all
• CSP: CSP-2100, CSP-5228, CSP-5436 and CSP5444 (Beta)

Cisco Environmental Monitor MIB notification starting from NFVIS 3.12.3 release:

• ciscoEnvMonEnableShutdownNotification
• ciscoEnvMonEnableVoltageNotification
• ciscoEnvMonEnableTemperatureNotification
• ciscoEnvMonEnableFanNotification
• ciscoEnvMonEnableRedundantSupplyNotification
• ciscoEnvMonEnableStatChangeNotif

VM-MIB (1.3.6.1.2.1.236) starting from NFVIS 4.4 release:

• vmHypervisor:
• vmHvSoftware
• vmHvVersion
• vmHvUpTime
• vmTable:
• vmName
• vmUUID
• vmOperState
• vmOSType
• vmCurCpuNumber
• vmMemUnit
• vmCurMem
• vmCpuTime
• vmCpuTable:
• vmCpuCoreTime
• vmCpuAffinityTable
• vmCpuAffinity

Configuring SNMP Support

an option to add an optional passphrase for SNMP that can generate a different priv-key other than the auth-key.

Though SNMP v1 and v2c uses community-based string, the following is still required:

• Same community and user name.
• Same SNMP version for user and group.

To create SNMP community:
configure terminal
snmp community community-access

SNMP community name string supports [A-Za-z0-9_-] and maximum length of 32. NFVIS supports only readOnly access.
To create SNMP Group:
configure terminal snmp group