Table Of Contents
Device Configuration Tasks for Modeling
Choosing a VNE Scheme (Check Technologies and Device Types)
Why Device Configuration Tasks Are Important
Cisco IOS, Cisco IOS XE, and CatOS Devices—Required Settings
Cisco IOS XR Devices—Required and Recommended Settings
Cisco StarOS Devices—Required Settings
Cisco Nexus OS Devices—Required Settings
Cisco Carrier Packet Transport Devices—Required Settings
Cisco Unified Computing System Devices—Required Settings
All Cisco Devices Added Using SSH—Required, Recommended, and Rollback Device Settings
SNMP Traps and Informs—Required Device Settings
Syslogs—Required Device Settings
IP Address Configuration for Traps, Syslogs, and VNEs
Device Configuration Tasks for Modeling
These topics describe the configuration tasks you must perform so that Prime Network can properly model and manage devices.
Note
Prime Network automatically performs a series of validation checks for Cisco IOS XR devices. See Cisco IOS XR Devices—Required and Recommended Settings.
•
Choosing a VNE Scheme (Check Technologies and Device Types)
•
Why Device Configuration Tasks Are Important
•
Cisco IOS, Cisco IOS XE, and CatOS Devices—Required Settings
•
Cisco IOS XR Devices—Required and Recommended Settings
•
Cisco StarOS Devices—Required Settings
•
Cisco Nexus OS Devices—Required Settings
•
Cisco Carrier Packet Transport Devices—Required Settings
•
Cisco Unified Computing System Devices—Required Settings
•
All Cisco Devices Added Using SSH—Required, Recommended, and Rollback Device Settings
•
SNMP Traps and Informs—Required Device Settings
•
Syslogs—Required Device Settings
•
IP Address Configuration for Traps, Syslogs, and VNEs
Choosing a VNE Scheme (Check Technologies and Device Types)
VNE schemes determine what data should be retrieved for each device, and which commands and protocols Prime Network should use to collect that data. Prime Network provides three schemes by default
Scheme
|
Use this scheme for:
|
Product
|
For devices that are not part of the network core, such as the Cisco 800 Series or 2900 Series.
|
IpCore
|
For devices that are part of the network core, such as the Cisco 3600 Series, 12000 GSR (Gigabit Switch Router) Series, or CRS (Carrier Routing System) Series.
|
EMS
|
For devices where only system information and physical inventory should be polled (that is, the minimum amount of data). It is supported on all devices but does not support any technologies.
|
Default
|
For cases where you are not sure which scheme to choose. Prime Network will use the Product scheme.
|
While all Cisco devices support either the Product or IpCore scheme, most devices support both schemes but with different levels of support.Table A-1 lists the technologies supported on each scheme. Table A-2 shows whether a specific device type supports a scheme.
Note
If none of these schemes meets your needs, you can create your own scheme and it will be added to the Administration GUI client so you can apply it to VNEs. See Create a Custom VNE Scheme.
Table A-1 Technology Support Based on Schemes
Technology
|
Scheme
|
Product
|
IpCore
|
6PE and 6VPE-based IPv6 Connectivity
|
Yes
|
Yes
|
6RD
|
Yes
|
Yes
|
ACL
|
Yes
|
Yes
|
APN
|
Yes
|
No
|
ATM
|
Yes
|
Yes
|
ATM PW
|
No
|
Yes
|
Backup Pseudowire
|
No
|
Yes
|
BFD
|
Yes
|
Yes
|
BGP
|
Yes
|
Yes
|
BNG
|
No
|
Yes
|
Carrier Supporting Carrier (CSC)
|
No
|
Yes
|
CDP
|
Yes
|
Yes
|
CEM Group
|
Yes
|
Yes
|
CFM
|
Yes
|
Yes
|
CGN
|
No
|
Yes
|
Clocking Enhancements
|
No
|
Yes
|
DSx
|
Yes
|
Yes
|
EFP
|
No
|
Yes
|
EGPTC (Evolved GPRS Tunnel Protocol Control)
|
Yes
|
No
|
Ethernet
|
Yes
|
Yes
|
Ethernet Channel
|
Yes
|
Yes
|
Ethernet IEEE 802.3 Dot1Q/VLAN
|
Yes
|
Yes
|
Ethernet LMI
|
Yes
|
Yes
|
Ethernet OAM
|
Yes
|
Yes
|
Frame Relay
|
Yes
|
Yes
|
GGSN
|
Yes
|
No
|
GRE
|
Yes
|
Yes
|
GTTP (GPRS Tunnel Protocol Prime)
|
Yes
|
No
|
HDLC
|
Yes
|
Yes
|
Hierarchical VPLS
|
No
|
Yes
|
HSRP
|
Yes
|
Yes
|
IMA
|
Yes
|
Yes
|
IP Multicast
|
No
|
Yes
|
IP Pool
|
No
|
Yes
|
IP Routing
|
Yes
|
Yes
|
IP and ARP
|
Yes
|
Yes
|
IPoDWDM
|
No
|
Yes
|
IPSec1
|
Yes
|
No
|
IPSLA Probes (Y.1731)
|
No
|
Yes
|
IPSLA Responder
|
Yes
|
No
|
IPv6
|
Yes
|
Yes
|
IRB/BVI
|
Yes
|
Yes
|
ISIS
|
No
|
Yes
|
ISIS IGPv6
|
No
|
Yes
|
L3 VPN and VRF
|
No
|
Yes
|
LAG (IEEE 802.3ad)
|
Yes
|
Yes
|
LLDP
|
Yes
|
Yes
|
Local Switching
|
Yes
|
Yes
|
MLACP
|
Yes
|
Yes
|
MLPPP
|
Yes
|
Yes
|
MP-BGP
|
No
|
Yes
|
MPLS
|
No
|
Yes
|
MPLS Multicast
|
No
|
Yes
|
MPLS P2MP TE
|
No
|
Yes
|
MPLS TE-Tunnel (including FRR)
|
No
|
Yes
|
MPLS TP
|
No
|
Yes
|
MST-AG/REP-AG
|
Yes
|
Yes
|
OSPF
|
Yes
|
Yes
|
P-GW
|
Yes
|
No
|
POS
|
Yes
|
Yes
|
PPP
|
Yes
|
Yes
|
PTP 1588
|
Yes
|
Yes
|
PWE3, L2 VPN (Martini)
|
No
|
Yes
|
PW VCCV
|
No
|
Yes
|
Q-in-Q (IEEE 802.1ad)
|
Yes
|
Yes
|
REP
|
Yes
|
Yes
|
S-GW
|
Yes
|
No
|
SAE (System Architecture Evolution) with S-GW and P-GW functionality
|
Yes
|
No
|
SBC
|
No
|
Yes
|
SL-XLAT
|
No
|
Yes
|
SONET/SDH
|
Yes
|
Yes
|
STP/MSTP/PVST
|
Yes
|
Yes
|
SVI
|
No
|
Yes
|
SynCE
|
Yes
|
Yes
|
TDM
|
Yes
|
Yes
|
TDM PW
|
No
|
Yes
|
VC Switching
|
Yes
|
Yes
|
VLAN Bridging
|
Yes
|
Yes
|
VPLS
|
No
|
Yes
|
VRRP
|
No
|
Yes
|
VTP (VLAN Trunk and Tunneling)
|
Yes
|
Yes
|
Table A-2 identifies the schemes that are supported by device type. For information on the EMS scheme, see the version of this document on Cisco.com.
Table A-2 Schemes Used by Device Type
Device Types
|
Scheme
|
Product
|
IpCore
|
Data Center
|
Cisco Unified Computing System (UCS) 61xx Series Switches
|
X
|
—
|
Cisco Unified Computing System (UCS) 62xx Series Switches
|
X
|
—
|
Optical Transport
|
Cisco Carrier Packet Transport (CPT) 50
|
X
|
—
|
Cisco Carrier Packet Transport (CPT) 200
|
X
|
—
|
Cisco Carrier Packet Transport (CPT) 500
|
X
|
—
|
Cisco Carrier Packet Transport (CPT) 600
|
X
|
—
|
Security Appliances
|
Cisco Adaptive Security Appliance 5550 Series
|
X
|
—
|
Cisco Adaptive Security Appliance 5580 Series
|
X
|
—
|
Access Servers / Gateways
|
Cisco Access Server 5800
|
X
|
—
|
Cisco Access Server 5300
|
X
|
—
|
Routers
|
Cisco 800 Series Routers
|
X
|
—
|
Cisco 1000 Series Routers
|
X
|
—
|
Cisco 1600 Series Routers
|
X
|
—
|
Cisco 1700 Series Modular Access Routers
|
X
|
—
|
Cisco 1800 Series Integrated Services Routers
|
X
|
—
|
Cisco 2500 Series Routers
|
X
|
—
|
Cisco 2600 Series Multiservice Platform Routers
|
X
|
—
|
Cisco 2800 Series Integrated Services Routers
|
X
|
—
|
Cisco 3600 Series Multiservice Platform Routers
|
X
|
X
|
Cisco 3700 Series Multiservice Access Routers
|
X
|
X
|
Cisco 3800 Series Integrated Services Routers
|
X
|
X
|
Cisco 7200 Series Routers
|
X
|
X
|
Cisco 7300 Series Routers
|
X
|
X
|
Cisco 7400 Series Routers
|
X
|
X
|
Cisco 7500 Series Routers
|
X
|
X
|
Cisco 7600 Series Routers
|
X
|
X
|
Cisco 10000 Series Routers
|
X
|
X
|
Cisco 12000 Series Routers
|
X
|
X
|
Cisco XR 12000 Series Routers
|
X1
|
X
|
Cisco CRS Carrier Routing System (CRS-1 and CRS-3)
|
—
|
X
|
Cisco ASR 9000 Series Aggregation Services Routers
|
X
|
X
|
Cisco ASR 1000 Series Aggregation Services Routers
|
X
|
X
|
Cisco MWR 2900 Series Mobile Wireless Routers
|
X
|
X
|
Cisco 1900 Series Integrated Services Routers
|
X
|
—
|
Cisco 2900 Series Integrated Services Routers
|
X
|
—
|
Cisco 3900 Series Integrated Services Routers
|
X
|
—
|
Cisco Universal Broadband Router 7200 Series
|
X
|
X
|
Cisco Universal Broadband Router 10000 Series
|
X
|
X
|
Cisco 4700 Series Routers
|
X
|
X
|
Cisco ASR 901 Aggregation Services Series Routers
|
X
|
X
|
Cisco ASR 903 Aggregation Services Series Routers
|
X
|
X
|
Cisco ASR 5000 Aggregation Services Series Routers
|
X
|
X
|
Switches
|
Cisco Catalyst 1900 Series Switches
|
X
|
—
|
Cisco Catalyst 2900 Series Switches
|
X
|
—
|
Cisco ME 3400 Series Ethernet Access Switches
|
X
|
—
|
Cisco Catalyst 3500 XL Series Switches
|
X
|
—
|
Cisco Catalyst 3550 Series Switches
|
X
|
—
|
Cisco Catalyst 3560 Series Switches
|
X
|
—
|
Cisco Catalyst 3750 Series Switches
|
X
|
—
|
Cisco Catalyst 3750 Metro Series Switches
|
—
|
X
|
Cisco Catalyst 4000 Series Switches
|
X
|
—
|
Cisco Catalyst 4500 Series Switches
|
X
|
—
|
Cisco Catalyst 4900 Series Switches
|
X
|
—
|
Cisco ME 4900 Series Ethernet Switch
|
X
|
—
|
Cisco Catalyst 5000 Series Switches
|
X
|
—
|
Cisco Catalyst 6500 Series (CatOS) Switches
|
X
|
X
|
Cisco Catalyst 6500 Series (IOS) Switches
|
X
|
X
|
Cisco ME 6500 Series Ethernet Switches (6524)
|
X
|
X
|
Cisco ME 3600X Series Ethernet Access Switches
|
X
|
X
|
Cisco ME 3800X Series Carrier Ethernet Switch Routers
|
X
|
X
|
Cisco Nexus 7000 Series Switches
|
X
|
—
|
Cisco Nexus 5000 Series Switches
|
X
|
—
|
Cisco Nexus 1000 Series Switches
|
X
|
—
|
Cisco Nexus 3000 Series Switches
|
X
|
—
|
Cisco ACE 4700 Series Access Control Engine
|
X
|
—
|
Cisco Service Control Engine
|
X
|
—
|
Generic Devices
|
Generic devices
|
X
|
—
|
Why Device Configuration Tasks Are Important
Prime Network VNEs communicate with network devices using a variety of protocols such as SNMP, Telnet, and ICMP. When a VNE is created, Prime Network connects to the device and runs a variety of registration commands to build a model of the device, based on the scheme that is chosen for the VNE. After modeling, ongoing notifications and protocol communication allows Prime Network to perform ongoing service and technology monitoring, fault processing, topological and model updates, and so forth. If the required device settings are not configured properly, Prime Network cannot retrieve the necessary information from the network element.
For example, if a new interface is added to a Cisco IOS device, but the logging enabled command is not set, Prime Network will not receive a device config change syslog from the device. As a result, Prime Network's copy of the startup device configuration file is outdated. If the device goes down, when it is restarted, the configuration change is lost.
Note
Do not change the device's default packet size (which 1500 bytes). SNMP requests are sent in bulk by default. A small packet size could result in truncated responses.
Cisco IOS, Cisco IOS XE, and CatOS Devices—Required Settings
The following settings are required for Cisco IOS, Cisco IOS XE, and Cat OS network elements:
snmp-server community public-cmty RO
snmp-server community private-cmty RW
This settings is required for Cisco IOS and Cisco OS XE devices (it is already set by default for CatOS devices):
snmp-server ifindex persist
Do not change the device's default packet size (which 1500 bytes). SNMP requests are sent in bulk by default. A small packet size could result in truncated responses.
Reduced Polling
For Cisco IOS devices using reduced polling, the following settings are required.
configure terminal
archive
log config
logging enable
If a device is generating configuration change events but Prime Network is not recognizing them, edit the VNE properties (Events tab) and add the IP address you want the VNE to listen to. See VNE Properties: Events.
Cisco IOS XR Devices—Required and Recommended Settings
Prime Network validates the configuration of Cisco IOS XR devices before creating VNEs for those devices. The validations are contained in a registration named mis-con, which validates the following:
•
The MGBL package is installed.
•
The user belongs to root-system.
•
XML is enabled on the device. See Enabling XML on a Device.
If any of these validations fail, Prime Network generates a System event. To disable this validation for all Cisco IOS XR devices, use the following command from the gateway server:
# ./runRegTool.sh -gs 127.0.0.1 set 0.0.0.0
"site/cisco-router-iox-ipcore-scheme-evne/com.sheer.metrocentral.coretech.common.dc.Manage
dElement/mis-con/enable" false
# ./runRegTool.sh -gs 127.0.0.1 set 0.0.0.0
"site/cisco-router-iox-ipcore-scheme/com.sheer.metrocentral.coretech.common.dc.ManagedElem
ent/mis-con/enable" false
# ./runRegTool.sh -gs 127.0.0.1 set 0.0.0.0
"site/cisco-router-iox-product-scheme/com.sheer.metrocentral.coretech.common.dc.ManagedEle
ment/mis-con/enable" false
# ./runRegTool.sh -gs 127.0.0.1 set 0.0.0.0
"site/cisco-router-iox-product-scheme-evne/com.sheer.metrocentral.coretech.common.dc.Manag
edElement/mis-con/enable" false
The following settings (not included in the validation check) are required for Cisco IOS XR network elements:
Note
If applicable, be sure to commit snmp-server community before snmp-server host.
domain ipv4 host gateway_name gateway_IP
telnet ipv4 server max-servers no-limit
snmp-server community community_name SystemOwner
snmp-server community community_name RO
snmp-server ifindex persist
vty-pool default 0 99
xml agent tty
To include the location of an event for an IOS XR device, execute the following command:
# logging events display-location
Enabling XML on a Device
There are three different methods for XML communication between devices and Prime Network. The device configuration required depends on the method you are using.
•
TTY XML Agent—To enable a TTY XML agent on a device, use the following commands. (In this case you do not need to enter any information in the VNE's XML tab in the Administration GUI client).
•
Dedicated XML agent—With a dedicated XML agent on the router, incoming XML sessions are handled over the dedicated TCP port 38751. In the Administration GUI client, enable XML on the VNE using the Telnet protocol. Enter the following commands on the device:
aaa authorization exec default local
•
SSL XML agent—With a dedicated SSL agent on the router, incoming XML sessions are handled over the dedicated TCP port 38752. In the Administration GUI client, enable XML on the VNE using the SSL protocol. Enter the following commands on the device:
aaa authorization exec default local
Reduced Polling
For Cisco IOS XR devices using reduced polling, the archive must be enabled (it is enabled by default).
If a device is generating configuration change events but Prime Network is not recognizing them, edit the VNE properties (Events tab) and add the IP address you want the VNE to listen to. See VNE Properties: Events.
Other Guidelines for Cisco IOS XR Devices
Do not change the device's default packet size (which 1500 MB). SNMP requests are sent in bulk by default. A small packet size could result in truncated responses.
In addition to the required settings, you must follow these guidelines:
•
Install the Cisco IOS XR Manageability Package (MGBL) on top of the Cisco IOS XR version. You can get information on this package from the release notes for your Cisco IOS XR version. (Prime Network automatically performs a validation check to ensure the MGBL package is installed.)
•
Prime Network should use the device login user that is a member of group root-system and cisco-support. (Prime Network automatically performs a validation check to ensure this is properly configured.)
•
To correctly model logical routers, the Prime Network user should use the admin user unique Telnet login user@admin (and also be a member of groups root-system and cisco-support).
•
The devices must have one of the following SNMP community privileges: SDROwner, SystemOwner, or the default (which means no specific level was specified). You may configure this as needed, using the following guidelines.
snmp-server community [clear | encrypted] community-string [view view-name] [RO | RW] [SDROwner | SystemOwner] [access-list-name]
The snmp-server command takes the following arguments.
Argument
|
Description
|
[clear | encrypted] community-string
|
Specifies the community-string command format and how it should be displayed in the show running command output.
• clear—community-string is clear text and should be encrypted when displayed by show running.
• encrypted—community-string is encrypted text and should be encrypted when displayed by show running.
|
[view view-name]
|
Specifies the previously-defined view view-name, which defines the objects available to the community.
|
[SDROwner | SystemOwner]
|
Controls what Prime Network users can see in Prime Network Vision.
• SDROwner—Limits access to the Service Domain Router (SDR) owner. In other words, the Prime Network user will be able to view SDR owner modules and ports and SDR child modules. But the Prime Network user will not be able to see the contents under SDR child modules and utility cards, such as fans, power supplies, and so forth.
Note For CRS devices running Cisco IOS XR 3.5.x and earlier, use LROwner instead of SDROwner.
• SystemOwner—Does not limit access; Prime Network users will be able to see the entire physical inventory (including utility cards) in the GUI clients. Use this for CRS devices.
|
[access-list-name]
|
The list that contains IP addresses that are allowed to use community-string to access the SNMP agent.
|
Cisco StarOS Devices—Required Settings
The following SNMP community settings are required.
[local]asr5000# configure
[local]asr5000(config)# snmp community name community-string read-only
[local]asr5000(config)# end
To verify the SNMP settings:
[local]asr5000# show snmp communities
Community Name Access Level
-------------- ------------
Starting from StarOS 14.0, following MIBs have been disabled by default in the device.
•
ENTITY-MIB
•
F-MIB
•
ENTITY-STATE-MIB
•
CISCO-ENTITY-FRU-CONTROL-MIB
Physical inventory will not get modeled if these mibs are disabled. Enable the MIBs using the following:
snmp mib ENTITY-STATE-MIB
snmp mib CISCO-ENTITY-FRU-CONTROL-MIB
To verify if above MIBs are are enabled:
Reduced Polling
Setting the configuration-monitor is required for reduced polling.
[local]asr5000# configure
[local]asr5000(config)# cli configuration-monitor
[local]asr5000(config)# end
To verify that the configuration-monitor is enabled:
[local]asr5000# show cli configuration-monitor
config monitor enabled? : yes
monitoring config changes? : yes
monitoring enabled/disabled : Wed May 23 01:41:37 2012 cli config monitor instance : 0
cli config monitor status : running - idle
# config change traps sent : 0
seconds until next monitor : 713
longest checksum time (sec) : 0
time of last object change : (not set) last config object changed : (no changes)
If a device is generating configuration change events but Prime Network is not recognizing them, edit the VNE properties (Events tab) and add the IP address you want the VNE to listen to. See VNE Properties: Events.
Cisco Nexus OS Devices—Required Settings
General Requirements
The complete hostname, such as hostname#, must be added when entering the credentials.
VDC Configuration
Each Virtual Context Device (VDC) in a Nexus device must be configured using the procedures below. so that Prime Network can process device events and monitor the devices using the reduced polling mechanism.
1.
In the default VDC for the Nexus device, the vdc combined-hostname command must be configured.
2.
To configure the VDC, enter the following commands. These commands create the VDC and enter configuration mode, display the interface membership for the VDC, allocate one interface to the VDC (ethernet 2/1 in this example), exit configuration mode, display VDC status information, and update the startup configuration file.
switch(config)# vdc vdcname
switch(config-vdc)# show vdc membership
switch(config-vdc)# allocate interface ethernet 2/1
switch(config)# copy running-config startup-config
3.
Associate the management IP address of all VDCs with the default VDC's management-VRF (that is, the VRF which is associated with the management IP address of the Nexus switch).
a.
Configure each VDC with a management IP address:
ip address ip-address/mask
All events generated from the VDC will use the source IP ip-address.
b.
Add each VDC's management IP address to the Event-Generating IP field in the VNE properties (Events tab) so that the VNE will also listen to those addresses. See VNE Properties: Events.
c.
Enable logging:
switch(config) logging server gateway-IP 5 use-vrf management-VRF
4.
Ensure the system administrator account on the device is set up.
5.
Verify that the VDC configuration is complete and confirm that you can switch between VDCs by entering the switchto vdc command as follows (vdcname is the name of the VDC you created, and vdcname2 is the name of a different VDC).
switch# switchto vdc vdcname
Do you want to enforce secure password standard (yes/no) [y]: no
Enter the password for "admin":
Confirm the password for "admin":
---- Basic System Configuration Dialog VDC: 4 ----
Would you like to enter the basic configuration dialog (yes/no): no
switch-cisco3# switchback
switch# switchto vdc vdcname2
switch-cisco3#
Cisco Carrier Packet Transport Devices—Required Settings
The following settings are required for Prime Network to properly model Cisco Carrier Packet Transport devices. Configure these settings using the Packet Transport System View GUI.
•
The SNMP host settings must set in the Provisioning tab (in the SNMP area).
•
The Syslogs destinations must be set in the Maintenance tab (in the Syslog area).
When creating the Prime Network CPT VNE, the VNE's Telnet prompt must be configured correctly, as shown in the following procedure.
Step 1
Check the Enable check box and select Telnet from the Protocol drop-down list (use the default port, which is 23).
Note
To verify a device's Telnet sequence, open a Telnet session to the device and copy the information. The following is an example.
Step 2
Enter the expected device prompts and responses:
a.
Enter Login: in the Prompt field.
b.
Enter your user ID in the Run field.
c.
Click Add.
d.
Enter Password: in the Prompt field.
e.
Enter the password associated with the user ID in the Run field.
f.
Click Add.
g.
Enter # (a hash mark) in the Prompt field.
h.
Click Add.
For information on how to configure CPT devices using the Packet Transport System View, see the Cisco Carrier Packet Transport documentation.
These settings should also be configured:
•
For Cisco IOS devices, set the following command so that Prime Network can determine the mode used by the CPT device:
•
Configure the following snmp community setting on the NGXP card:
snmp-server community cellbus RO
If a device is running in CTC mode, the following is not supported:
•
Reduced (event-based) polling
•
Sylogs and trap event notifications that are disabled by default
Reduced Polling
If a device is generating configuration change events but Prime Network is not recognizing them, edit the VNE properties (Events tab) and add the IP address you want the VNE to listen to. See VNE Properties: Events.
As stated earlier, reduced polling is not supported when a device is running in CTC mode.
Cisco Unified Computing System Devices—Required Settings
Along with the required settings for the UCS device, this topic describes the process of creating a UCS VNE because it is somewhat different from the normal VNE creation process.
On the UCS device, SNMP, Telnet, and HTML must be configured so that Prime Network can access the device. The recommended method for configuring this is for a user with Administrator privileges to use the UCS Manager to confirm the proper settings. (These settings are normally found under the Admin tab by expanding All > Communication Management > Communication Services.)
•
In the Telnet/HTTP and HTTPS sections:
–
Ensure that Enable is selected.
–
Do not change the ports (use the defaults).
•
In the SNMP section, ensure that Enable is selected and:
–
The Community/Username section contains the correct community string.
–
The SNMP Trap destination section contains the Prime Network gateway IP address and port, and the SNMP version. (This assumes the Event Collector is running on the gateway, which is the default Prime Network configuration. If the Event Collector is running on a unit, enter the IP address and port of the unit.)
In Prime Network, the UCS VNE creation process is in several steps during which you start and then restart the VNE.
1.
Create the UCS VNE and correctly configure the VNE's Telnet, SNMP, and HTTP settings:
–
In the Telnet/SSH tab, add the Telnet/SSH credentials of the UCS device.
–
In the SNMP tab, add the snmp community string.
–
In the HTTP tab, enable HTTP/HTTPS (use the default ports) and provide the management path (normally nuova) with credentials.
2.
Start the VNE.
3.
When the VNE is up, open the VNE properties and go to the vCenter tab. Enable HTTP/HTTPS (use the default ports), and enter the vCenter server address and credentials.
4.
Restart the VNE to complete the UCS model with virtualization support.
All Cisco Devices Added Using SSH—Required, Recommended, and Rollback Device Settings
This SSH information applies to all device types and operating systems. (For information on how to set up a device to run SSH, see your device documentation.) The following is an example of how to enable SSH on Cisco devices when they need to be added to Prime Network using SSH:
(config) ip domain-name DOMAIN
(config) crypto key generate rsa
Note
When you are requested to enter the modulus length, leave the default value. Although a longer modulus length may be more secure, it takes longer to be generated and used.
Configure vty to accept local password checking:
The following are recommended SSH configuration settings:
ip ssh time-out 120
ip ssh authentication-retries 2
ip ssh version 1(2)
To roll back to the original device configuration, use the following settings:
no ip ssh {timeout | authentication-retries}
crypto key zeroize rsa
SNMP Traps and Informs—Required Device Settings
The required settings for SNMP traps and informs are listed below. Note the additional information for Cisco IOS XR devices.
•
Required SNMP Settings by Device Operating System
•
Recommended and Optional SNMP Settings for Cisco IOS XR Devices
Required SNMP Settings by Device Operating System
The following table lists the settings you must configure in order to properly receive SNMP traps and informs.
SNMP Type
|
Required Setting
|
All
|
snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart
snmp-server enable traps chassis
snmp-server enable traps module
snmp-server enable traps bgp
snmp-server enable traps ospf state-change
snmp-server enable traps ospf errors
snmp-server enable traps ospf retransmit
snmp-server enable traps ospf lsa
snmp-server enable traps ospf cisco-specific state-change
snmp-server enable traps ospf cisco-specific errors
snmp-server enable traps ospf cisco-specific retransmit
snmp-server enable traps ospf cisco-specific lsa
snmp-server enable traps ipmulticast
snmp-server enable traps entity
snmp-server enable traps flash insertion removal
snmp-server enable traps envmon fan shutdown supply temperature status
snmp-server enable traps rtr
snmp-server enable traps mpls ldp
snmp-server enable traps ipsec tunnel start
snmp-server enable traps ipsec tunnel stop
snmp-server trap-source interface_name
Note interface_name is the active management IP address. This setting is required if the device has a management IP address.
Required for Nexus devices:
snmp-server enable traps
snmp-server host event_collector_IP use-vrf management-VRF
Required for StarOS devices (such as an ASR 5000; you can verify the settings using the show snmp transports command):
snmp target target-name target-IP security-name community-string version 2c traps
snmp trap enable all target target-name
Required for ASR 1000:
snmp-server enable traps ipsec tunnel start
snmp-server enable traps ipsec tunnel stop
Note management-VRF is the VRF which is associated with the management IP address of the Nexus switch.
Optional for all devices:
Caution  Be careful when applying the following settings. Depending on your configuration, they may result in a trap flood.
snmp-server enable traps config
snmp-server enable traps syslog
|
SNMPv1
|
snmp-ser ver host event_collector_IP version 1 community
|
SNMPv2
|
snmp-server hos t event_collector_IP {traps | informs} version 2 c community
|
SNMPv3 With Authentication
|
Note MyUsr, MyGrp, MyPswd, and MyView must match the information you enter when you create the VNEs in Prime Network.
• For all devices:
snmp-server group MyGrp v3 priv write MyView
snmp-server view MyView internet included
snmp-server view MyView 1.2.840.10006.300 included
snmp-server group MyGrp v3 auth [notify MyView]
• For Cisco IOS, Cisco IOS XE, and CatOS devices:
snmp-server user MyUsr MyGrp v3 auth {md5|sha} MyPswd
• For Cisco IOS XR devices:
snmp-server user MyUsr MyGrp v3 auth {md5|sha} {WORD,CLEAR,encrypted} MyPswd SystemOwner
• For all devices, after configuring SNMPv3 on the device, configure the following setting:
snmp-server host event_collector_IP traps version 3 auth MyUsr
|
SNMPv3 With Privacy and Authentication
|
Note MyUsr, MyGrp, MyAuthPswd, MyPrivPswd, and MyView must match the information you enter when you create the VNEs in Prime Network.
• For all devices:
snmp-server group MyGrp v3 priv write MyView
snmp-server view MyView internet included
snmp-server view MyView 1.2.840.10006.300 included
snmp-server group MyGrp v3 priv [notify MyView]
• For Cisco IOS, Cisco IOS XE, and CatOS devices:
snmp-server user MyUsr MyGrp v3 auth {md5|sha} MyAuthPswd priv {des|aes 128|aes 192|aes
256} MyPrivPswd
• For Cisco IOS XR devices:
snmp-server user MyUsr MyGrp v3 auth {md5|sha} {WORD,CLEAR,encrypted} MyAuthPswd priv
{des|aes 128|aes 192|aes 256} {WORD,CLEAR,encrypted} MyPrivPswd SystemOwner
• For all devices, after configuring SNMPv3 on the device, configure the following setting:
snmp-server host event_collector_IP traps version 3 priv MyUsr
|
SNMPv3 No Authentication
|
Note MyNoAuthUsr and MyNoAuthGrp must match the information you enter when you create the VNEs in Prime Network.
• For Cisco IOS, Cisco IOS XE, and CatOS devices:
snmp-server group MyNoAuthGrp v3 noauth
snmp-server user MyNoAuthUsr MyNoAuthGrp v3
• For Cisco IOS XR devices:
snmp-server user MyNoAuthUsr MyNoAuthGrp v3 SystemOwner
• For all devices, after configuring SNMPv3 on the device, configure the following setting:
snmp-server host event_collector_IP traps version 3 noauth MyNoAuthUsr
|
SNMP Informs
|
SNMP Informs can be configured for all SNMPv3 modes. The following is an example for configuring SNMPv3 Informs for the mode SNMPv3 With Privacy and Authentication. The configuration is similar for the other modes (refer to the required settings for each mode for guidelines).
Note For Informs, MyUsr corresponds to Prime Network's local user (not the device-configured user that is used for polling and receiving traps).
• For Cisco IOS, Cisco IOS XE, and CatOS devices:
snmp-server user MyUsr MyGrp remote event_collector_IP v3 auth {md5|sha} MyAuthPswd priv
{des|aes 128|aes 192|aes 256} MyPrivPswd
• For Cisco IOS XR devices:
snmp-server user MyUsr MyGrp remote event_collector_IP v3 auth {md5|sha}
{WORD,CLEAR,encrypted} MyAuthPswd priv {des|aes 128|aes 192|aes 256}
{WORD,CLEAR,encrypted} MyPrivPswd SystemOwner
• For all devices, after configuring SNMPv3 on the device, configure the following setting:
snmp-server host event_collector_IP informs version 3 priv MyUser
|
Recommended and Optional SNMP Settings for Cisco IOS XR Devices
In large-scale environments that contain more than 100 EFPs or PWs associated with the same interface/subinterface, an interface outage may generate a large number syslogs and traps. In such scenarios we recommended that you increase the default snmp server queue length buffer size using the following command. This applies to Cisco IOS XR 4.0 and later. The value of new-buffer-size should at least equal the number of EFP or PW objects. (This increase is also advisable if traps are being used as a transport mechanism for syslogs by way of the CISCO-SYSLOG-MIB.)
snmp-server queue-length new-buffer-size
If a Cisco IOS XR device has a configured virtual IP address and the VNE was added using that address, the device can receive the traps and syslogs through the virtual IP address. You do not need to configure the source for the SNMP traps and syslogs in the Prime Network Administration GUI client, as described in VNE Properties: Events. The following are examples of commands for configuring a virtual IP address:
ipv4 virtual address 10.49.224.120 255.255.255.128
ipv4 virtual address use-as-src-addr
To enable all traps to be sent from a Cisco IOS XR device:
snmp-server traps
<CR>
Alternatively, choose from the following list to enable forwarding of specific traps from Cisco IOS XR devices:
snmp-server trap link ietf
snmp-server traps ethernet cfm
snmp-server traps ethernet oam events
snmp-server traps copy-complete
snmp-server traps snmp linkup
snmp-server traps snmp linkdown
snmp-server traps snmp coldstart
snmp-server traps snmp warmstart
snmp-server traps snmp authentication
snmp-server traps flash removal
snmp-server traps flash insertion
snmp-server traps ospf lsa lsa-maxage
snmp-server traps ospf lsa lsa-originate
snmp-server traps ospf errors bad-packet
snmp-server traps ospf errors authentication-failure
snmp-server traps ospf errors config-error
snmp-server traps ospf errors virt-bad-packet
snmp-server traps ospf errors virt-authentication-failure
snmp-server traps ospf errors virt-config-error
snmp-server traps ospf retransmit packets
snmp-server traps ospf retransmit virt-packets
snmp-server traps ospf state-change if-state-change
snmp-server traps ospf state-change neighbor-state-change
snmp-server traps ospf state-change virtif-state-change
snmp-server traps ospf state-change virtneighbor-state-change
snmp-server traps bridgemib
snmp-server traps isis all
snmp-server traps frame-relay pvc interval 30
snmp-server traps atm pvc interval 30
snmp-server traps vrrp events
snmp-server traps vpls all
snmp-server traps vpls status
snmp-server traps vpls full-clear
snmp-server traps vpls full-raise
snmp-server traps l2vpn all
snmp-server traps l2vpn vc-up
snmp-server traps l2vpn vc-down
snmp-server traps mpls traffic-eng up
snmp-server traps mpls traffic-eng down
snmp-server traps mpls traffic-eng reroute
snmp-server traps mpls traffic-eng reoptimize
snmp-server enable traps mpls frr all
snmp-server enable traps mpls frr protected
snmp-server enable traps mpls frr unprotected
snmp-server traps mpls ldp up
snmp-server traps mpls ldp down
snmp-server traps mpls ldp threshold
snmp-server traps mpls traffic-eng p2mp up
snmp-server traps mpls traffic-eng p2mp down
snmp-server traps rsvp all
snmp-server traps rsvp new-flow
snmp-server traps rsvp lost-flow
snmp-server enable traps mpls l3vpn all
snmp-server enable traps mpls l3vpn vrf-up
snmp-server enable traps mpls l3vpn vrf-down
snmp-server enable traps mpls l3vpn max-threshold-cleared
snmp-server enable traps mpls l3vpn max-threshold-exceeded
snmp-server enable traps mpls l3vpn mid-threshold-exceeded
snmp-server enable traps mpls l3vpn max-threshold-reissue-notif-time 1
snmp-server traps fabric plane
snmp-server traps fabric bundle link
snmp-server traps fabric bundle state
snmp-server traps fru-ctrl
Syslogs—Required Device Settings
The following table lists the settings you must configure for syslogs.
Note
If you are using reduced polling, be sure the follow the requirements in this section. These settings increase the depth of syslogs that will be logged, and ensures that all syslogs are handled. If the device is using Cisco IOS XR, verify the syntax of the settings against the Cisco IOS XR documentation in case there have been changes across OS releases.
If a device is generating configuration change events but Prime Network is not recognizing them, edit the VNE properties (Events tab) and add the IP address you want the VNE to listen to. See VNE Properties: Events.
Required Settings
|
All
|
Required if the device has a management IP address (interface_name is the active management IP address):
logging source-interface interface_name
|
Cisco CatOS, Cisco IOS, and Cisco IOS XE
|
logging on
logging buffered 64000 informational
logging trap informational
logging event link-status default
Required for ASR 1000 IPSec Syslogs:
Required for MPLS TP-related changes:
[no] logging config-change
|
Cisco IOS XR
|
logging events level informational
logging alarm level informational
logging buffered <307200-125000000>
Note The range indicates the minimum of 307200 and maximum of 125000000 log messages that can be stored on the device
logging trap informational
logging events link-status software-interfaces
If you will be using Path Tracer or event correlation to mimic flows that involve bridge tables, configure the following:
l2vpn resynchronize forwarding mac-address-table location node-id
Note If devices are running an older version of Cisco IOS XR, enable the following commands to make sure Prime Network is properly notified of link status changes:
logging events link-status logical
logging events link-status physical
|
Nexus OS
|
If you are using reduced polling, specify the following for each VDC that is configured in the Nexus device.
logging server gateway-IP 5 use-vrf management-VRF
If you are not using reduced polling, specify one of the following (for each VDC):
logging server gateway-IP use-vrf management-VRF
logging server gateway-IP facility use-vrf management-VRF
Note management-VRF is the VRF which is associated with the management IP address of the Nexus device.
|
IP Address Configuration for Traps, Syslogs, and VNEs
Traps and syslogs maybe dropped if any of the VNEs managed by Prime Network are configured in such a way that the following addresses are different:
•
The traps and syslogs source IP address
•
The VNE IP address (entered when the VNE was created and displayed in the VNE properties)
To avoid missing any traps or syslogs, do one of the following:
•
Change the device configuration so that traps and syslogs are sent using the VNE's IP address. In addition, make sure that the source IP address matches the startup-config.
•
Configure the VNE to receive traps and syslogs using a different IP address by changing the VNE Properties: Events. Do this if a device is generating configuration change events but Prime Network is not recognizing them.
Note
If your deployment has virtual entities that generate events, such as applications running on virtual machines, add the entity's IP address in the VNE Events tab. Refer VNE Properties: Events for more details.