Management Features and Capabilities on ACE appliance

[Sandeep Singh]

• Introduction
• ACE Management
• SNMP
• Syslog
• Role Based Access Control (RBAC)
• Configuration Management (Checkpoint/Rollback)
• NTP
• ACE Appliance Device Manager (ADM)
• Related Information

Introduction

The ACE appliances perform a critical loadbalancing function within the network. Therefore it is important to configure the necessary management features so as to ensure proper operational and performance management of devices at all times. Where ever possible the ACE appliances should be integrated into the existing NMS (Network Management Systems), using standard interfaces such as SNMP, XML and Telnet/SSH.

ACE Management

At a minimum it is recommended that the following management related features be enabled on each ACE appliance context:

a) SNMP

b) System Message Logging (Syslog)

c) Role Based Access Control (RBAC)

d) Configuration Management (Checkpoint/Rollback)

e) Network Time Protocol (NTP)

ACE Appliance also includes an embedded web-based management GUI, the Appliance Device Manager, which can be used for managing the ACE appliances.

SNMP

SNMP is an application-layer protocol that facilitates the exchange of management information between an NMS, SNMP agents, and managed devices such as the ACE. The ACE Appliance provides support for SNMP v1, v2c and v3, which allow the ACE to send traps to an NMS server, or the NMS server can be used to browse the MIB's residing in the ACE. SNMPv1 and SNMPv2c use a community string match for authentication. Community strings provide a weaker form of access control. SNMPv3 utilizes an SNMP user for authentication and provides improved access control by using strong authentication. SNMPv3 should be utilized instead of SNMPv1 and SNMPv2c wherever possible. In terms of MIB support, the ACE provides a comprehensive suite of MIB's that server to monitor both the physical device performance as well as application load balancing performance. Additionally the ACE supports the creation of SNMP traps for load balancing based events such as rserver up/down, vserver state change, feature license expirary, context creation/deletion and interface up/down. It is good to enable SNMP v2c (minimum) and configure the ACE to send traps to the NMS for the following events:

1) cesRserverStateChange (CISCO-ENHANCED-SLB-MIB) - The rserver changed to a new state as a result of something other than a user intervention. This notification is sent for situations such as ARP failure, probe failure, and so on. Note that there are no separate cesRealServerStateChange notifications sent for each of the real servers listening on this rserver.

2) ciscoSlbVServerVIPStateChange (CISCO-SLB-MIB) - The state of a Vserver changes. The change in the Vserver state could be due to a number of different reasons, such as binding to the interface, removing an active serverfarm from the policy, and associating the virtual IP address (VIP) with a class map.  The ciscoSlbVServerVIPStateChange is specified in the CISCO-SLB-MIB.

3) ciscoSlbVServerStateChange (CISCO-SLB-MIB) - This notification is sent when a virtual IP address (VIP) is removed from a class map. The ciscoSlbVServerStateChange is specified in the CISCO-SLB-MIB.

4) clmLicenseExpiryWarningNotify (CISCO-LICENSE-MGR-MIB) - The ACE sends this notification as a warning that an installed feature license is about to expire.

5) cmVirtContextAdded, cmVirtContextRemoved (CISCO-MODULE-VIRTUALIZATION-MIB) - The ACE sends one of these notifications when a virtual context is created or deleted.

6) linkUp, linkDown (SNMPv2-MIB) - A Vlan interface is up or down. A Vlan interface can be down, for example, if you specified the shut command followed by the no shut command, or the Vlan was removed from the switch configuration.

For a complete list of ACE SNMP MIBS and Traps refer to this document.

A sample configuration for enabling SNMP within the Admin context is shown below:

snmp-server community group Network-Monitor

snmp-server host traps version 2c

snmp-server trap-source vlan

snmp-server enable traps virtual-context

snmp-server enable traps license

snmp-server enable traps slb vserver

snmp-server enable traps slb real

A sample configuration for enabling SNMP within a specific user context is shown below:

snmp-server location

snmp-server community group Network-Monitor

snmp-server host traps version 2c

snmp-server trap-source vlan

snmp-server enable traps slb vserver

snmp-server enable traps slb real

snmp-server enable traps syslog

snmp-server enable traps snmp authentication

snmp-server enable traps snmp linkup

snmp-server enable traps snmp linkdown

Syslog

The ACE Appliance supports System Logging Messages i.e. Syslogs, which capture ACE related events and performance for various functions. The ACE supports the exports of these log messages to an external syslog host; furthermore the ACE supports eight unique logging severity levels which allows granular selection of specific log messages. ACE Syslogging is supported on a per user context basis and allows the configuration of an identifier for the virtual context and the virtual user responsible for executing the function in the log message.

It is recommended to send syslogs to a dedicated Syslog server, messages with severity 5 i.e. notifications should be sent to the server.

A sample ACE syslog configuration is shown below:

logging enable

logging standby   # Enable logging on Standby ACE

logging timestamp  

logging trap 5       # Level of messages sent to host

logging buffered 5   # Logging severity level 5

logging facility 16

logging device-id context-name   # Include context name in messages

logging host udp/514   # Syslog host details

Role Based Access Control (RBAC)

The ACE Appliance includes fully integrated Roles Based Access Control (RBAC), this means that it is possible to create and modify user roles with pre-defined access to certain commands or certain objects within the ACE configuration. As the ACE provides application-specific load balancing and security services, it is a common requirement that multiple I.T. departments will require access to the ACE for the purposes of administration and monitoring. Teams that require access include the network team, server team, web team and application development teams. RBAC on the ACE permits each team to access their relevant ACE objects without access to those of another team which may not be applicable or permitted. Users can make use of the pre-defined user roles included by default by the ACE. These pre-defined roles can be viewed with the "show role" exec command. Alternatively, new roles can be created and mapped to specific object domains that encompass the job function of each role within the IT departmens, i.e. Engineering have configuration access to vservers, Operations is limited to only show/debug commands for vservers, etc.

A sample ACE RBAC configuration which includes new users and new domains is shown below:

username web-admin password 5 $1$.1TZrl8k$fns/W8xvVejkbpA.IuK2Y1 expire 2007-12-31 role Server-Maintenance domain Web-Admin     # New web-admin user

!

username net-admin password 5 $1$.1TZrl8k$fns/W8xvVejkbpA.IuK2Y1 expire 2007-12-31 role Network-Maintenance domain Net-Admin    # New net-admin user

!

domain Web-Admin              

  add-object serverfarm Web-Farm1      

  add-object serverfarm Web-L7-Farm

  add-object rserver Web-Svr1

  add-object rserver Web-Svr2

  add-object rserver Web-Svr3

!

domain Net-Admin

  add-object interface Vlan 150          

  add-object interface Vlan 200

  add-object interface Vlan 201

  add-object access-list extended anyone

Configuration Management (Checkpoint/Rollback)

To assist with the management of configuration files for individual user contexts, the ACE provides support for configuration checkpoint and rollback. A configuration checkpoint is a snapshot in time of the running configuration file for a specific ACE context. The ACE stores the checkpoint for each context in a hidden directory in Flash memory. A checkpoint allows the administrator to make a copy of a known running configuration prior to making any config changes. If during the process of making a configuration change a problem is encountered the administrator can quickly roll back to the last know good configuration (checkpoint) using the rollback feature.

Sample checkpoint commands are shown below:

switch/Admin# checkpoint create ACE_Admin_Config_011008

switch/Admin# show checkpoint all

ACE_Admin_Config_011008

switch/Admin# checkpoint rollback ACE_Admin_Config_011008

NTP

The ACE Appliance is capable of synchronizing to a time server using the NTP protocol. NTP is configured in the admin context using the command "ntp server".

Sample configuration for enabling NTP is shown below:

ntp server

ACE Appliance Device Manager (ADM)

The ACE Appliance includes an embedded Web-based GUI interface, the ACE Device Manager (ADM), which can be used to configure and monitor the ACE Appliance. Access to ADM is performed via a web browser using HTTPS and pointing the URL to the ACE management address (i.e. https://). The default username and password are admin/admin, and ADM provides for a user management section to add/modify users and passwords.

ADM requires the following pre-configuration in the ACE Appliance to allow https and snmp access:

1) Management VLAN configuration in the Admin context, and IP routes for management devices

2) Management class-map and policy-map configuration, to allow snmp and https

3) Management service-policy applied to the management VLAN

4) Valid username and password (default in ACE are admin/admin)

Configuration capabilities in ADM include most aspects of the ACE Appliance, especially those related to end-to-end service provisioning. Settings that can't be configured via ADM (version 1.2, ACE Appl version A3(2.2)), and thus need to be performed using CLI, are:

a) Physical interfaces and port-channels

b) Some management services: AAA, RADIUS/TACACS servers, NTP, motd, etc.

ADM also includes the possibility of showing statistical data in a graphical form.

Related Information

Health Monitoring Best Practices for Cisco ACE

Deploying GSS and ACE in least loaded GSLB based on VIP conn number