About the Authors

Roland Saville is a Technical Leader for the SDU team within Cisco, focused on developing best practice design guides for enterprise network deployments. He has 16 years of Cisco experience as a Systems Engineer, Consulting Systems Engineer, Technical Marketing Engineer, and Technical Leader. During that time, he has focused on a wide range of technology areas including the integration of voice and video onto network infrastructures, network security, wireless LAN networking, RFID, and energy management He has also spent time focusing on the retail vertical market segment. Prior to Cisco, Roland spent eight years as a Communications Analyst for the Chevron Corporation. Roland has a bachelor of science degree in Electrical Engineering from the University of Idaho and an MBA from Santa Clara University. He has co-authored the Cisco TelePresence Fundamentals book and has eight U.S. Patents.

Steve Kramling is a Software/QA engineer for Cisco's Systems Development Unit. In his 12 years at Cisco he has worked in a number of different roles. In the NSITE group, he tested various Service Provider Network Management solutions. He then worked on service provider end-to-end, customer-focused solutions using technologies such as MPLS-VPN, MP-BGP, and Multicast VRF. Next he worked on the SafeHarbor test team where he focused on enterprise-level Catalyst switching. There he focused on hardening IOS images by way of systems and regression tests using LAN networking technologies. Finally as part of the SDU team, he has been working a number of different projects including data center SANs, Flexible Netflow feature testing, and borderless network environments with a focus on energy management.

John Parello is currently a Senior Technical Leader in the Ethernet Switching and Technology Group at Cisco. He is the lead architect and co-inventor for Cisco EnergyWise, which is a key part of Cisco's Green initiatives.

He is the co-author of "IP-Enabled Energy Management: A Strategy for Administering Energy as a Service."

John joined Cisco in 1999 as an engineer in the Network Management Technology Group. He was responsible for developing network management applications focusing on fault processing and event correlation for campus and telephony management applications. He holds three patents in that area and has also focused on Network Management appliances based on Linux. John later moved to the Wireless Network Technology Group at Cisco where he worked on the Wireless Lan Service Engine and was the lead developer for the Wireless Self-Healing features.

Before joining Cisco, John was the head of engineering for Avesta Technologies, a network management startup specializing in fault and performance correlation. Prior to that he worked for Morgan Stanley specializing in high volume cash transaction processing and predictions. John began his career in New York working for the public utility, Brooklyn Union Gas Company, where he worked on large-scale Object Oriented systems and databases.

John's career in software engineering spans over 25 years. He attended New York University and received a Bachelor's degree in Computer Science. While still a student he developed the University's first production computerized registration systems. He holds a Master's Degree in Electrical Engineering and Computer Science from Steven's Institute of Technology and was an Adjunct Professor of Computer Science at Pace University.

About the Authors

About Cisco Validated Design (CVD) Program

The CVD program consists of systems and solutions designed, tested, and documented to facilitate faster, more reliable, and more predictable customer deployments. For more information visit http://www.cisco.com/go/designzone.

ALL DESIGNS, SPECIFICATIONS, STATEMENTS, INFORMATION, AND RECOMMENDATIONS (COLLECTIVELY, "DESIGNS") IN THIS MANUAL ARE PRESENTED "AS IS," WITH ALL FAULTS. CISCO AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THE DESIGNS, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

THE DESIGNS ARE SUBJECT TO CHANGE WITHOUT NOTICE. USERS ARE SOLELY RESPONSIBLE FOR THEIR APPLICATION OF THE DESIGNS. THE DESIGNS DO NOT CONSTITUTE THE TECHNICAL OR OTHER PROFESSIONAL ADVICE OF CISCO, ITS SUPPLIERS OR PARTNERS. USERS SHOULD CONSULT THEIR OWN TECHNICAL ADVISORS BEFORE IMPLEMENTING THE DESIGNS. RESULTS MAY VARY DEPENDING ON FACTORS NOT TESTED BY CISCO.

Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at http://www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

Cisco EnergyWise Design Guide

Cisco EnergyWise Overview

The Need for Energy Management

Over the past decade, rising energy costs and concerns about the environmental effects of increased energy consumption globally have led organizations to look into more sustainable and "green" business operations. In addition, government directives throughout the world have begun requiring corporations to lower their carbon footprint and reduce greenhouse gas emissions. These trends continue to have an impact in all areas of industry, from corporations, educational institutions, and federal, state, and local governmental agencies. Energy usage within facilities such as office buildings often represents a large share of the overall use of energy within organizations.

In response to these environmental and economic pressures, organizations have begun to deploy technology to monitor and control overall energy usage within their facilities. By doing so, they hope to not only comply with government regulations, but also reduce total energy usage and realize lower overall energy costs. In this manner, sustainable operations can provide not only a positive return on investment (ROI), but also a positive impact on the environment and a positive public image for the organization.

What is Cisco EnergyWise

Cisco EnergyWise is an innovative technology that provides the ability to monitor and control power across the IT infrastructure. Cisco EnergyWise is one of the services of the Cisco Borderless Network Architecture, which is the technical architecture that allows organizations to connect anyone, anywhere, anytime, and on any device—securely, reliably, and seamlessly. It is built on an infrastructure of scalable and resilient hardware and software. With Cisco EnergyWise, power management is performed through the network infrastructure as well. Cisco EnergyWise provides a framework by which the network itself can be used to open power management to all device types, including future integration with Building Management Systems (BMS). Cisco EnergyWise provides flexible and unified policy management across device and vendor type. Figure 1 shows the Cisco EnergyWise architecture.

Figure 1 Cisco EnergyWise Architecture

The Cisco EnergyWise architecture consists of three tiers—management applications, domain members, and endpoints. Each is discussed briefly in the sections below.

Management Applications

The top tier of the Cisco EnergyWise architecture consists of management applications—either Cisco- or partner-developed. Cisco provides the Cisco Prime LAN Management Solution (LMS) application, which is positioned for deployments consisting of Cisco infrastructure devices such as Catalyst switches, ISR G2 routers, PoE-enabled devices such as wireless LAN access points, and IP phones. An example of a partner provided management application is the JouleX Energy Manager (JEM) application, which is positioned for deployments which also include PC endpoints in which power is monitored and controlled.

Management applications make use of either the Cisco EnergyWise Toolkit Management API (MAPI) or Simple Network Management Protocol (SNMP) to monitor and control power on Cisco EnergyWise domain memberss, with the Cisco EnergyWise Toolkit MAPI being the more powerful and preferred application interface. Cisco EnergyWise domains are discussed in detail in Cisco EnergyWise Domain Design and Configuration. When using the Cisco EnergyWise MAPI, management applications issue Cisco EnergyWise queries to any one of the members of a domain, which then distribute the query to other domain members through the Cisco EnergyWise protocol. Results are sent back to the management application which collects and either displays or archives the results to be used for later reporting. The Cisco EnergyWise protocol was specifically developed to provide a more scalable mechanism for querying the multiple devices in a domain versus sending SNMP SET or GET commands individually to each domain member. The Cisco EnergyWise MAPI is available to Cisco Technology Partners as part of the Cisco EnergyWise Software Development Kit (SDK) through the Cisco Developer Network at the following URL: http://developer.cisco.com/web/esdk/overview.

When using SNMP, management applications issue SNMP GET or SET commands to each domain member individually using the CISCO-ENERGYWISE-MIB. Again, results are sent back to the management application which collects and either displays or archives the results to be used for later reporting. The CISCO-ENERGYWISE-MIB is available through the Cisco MIB Locator at: http://tools.cisco.com/ITDIT/MIBS/servlet/index. However, as stated earlier, the Cisco EnergyWise Toolkit Management API is the recommended application interface to use.

Network Infrastructure (Domain Members)

The second tier of the Cisco EnergyWise architecture consists of network infrastructure components such as Cisco Catalyst switches and ISR G2 routers, which are also referred to as Cisco EnergyWise domain members. Domain members issue Cisco EnergyWise queries or pass along queries initiated from management applications or other domain members using the Cisco EnergyWise protocol. Cisco EnergyWise Protocol Operation discusses the Cisco EnergyWise protocol in detail. Cisco EnergyWise is built directly into Cisco IOS technology, so deployment is relatively easy—simply enable the functionality on existing switches and routers. Building Cisco EnergyWise technology directly into Cisco IOS also provides more standard behavior across domain members and endpoints.

Endpoints

Cisco EnergyWise endpoints which support the Cisco EnergyWise SDK client respond to Cisco EnergyWise queries initiated from management applications or other domain members using the Cisco EnergyWise protocol. For endpoints which do not support the Cisco EnergyWise SDK client, such as some IP phones and access points, the attached switch port responds for the endpoint device.

Domain members form parent/child relationships with endpoint devices, which are the third tier of the Cisco EnergyWise architecture. Currently endpoints such as wireless LAN access points do not directly support Cisco EnergyWise SDK clients. Support for the Cisco EnergyWise SDK has been added to some models of Cisco IP phones as of phone load 9.2(1). Future versions of this document will include discussion around this feature. This document primarily discusses IP phones which do not support Cisco EnergyWise SDK clients. Hence no additional software is required for them to participate within a Cisco EnergyWise domain. Power monitoring and control is done through the attached PoE-enabled switch port. Cisco is actively working with partners who incorporate Cisco EnergyWise technology into endpoints, such as smart Power Distribution Units (PDUs), with Cisco EnergyWise SDK clients. The Cisco EnergyWise SDK is available to Cisco Technology Partners through the Cisco Developer Network at the following URL: http://developer.cisco.com/web/esdk/overview.

Design Guide Scope

The initial version of this design guide focuses primarily on Cisco EnergyWise technology running on network infrastructure devices (tier 2 of the Cisco EnergyWise architecture). Management application discussion (tier 1 of the Cisco EnergyWise architecture) is limited to Cisco Prime LMS in this initial version. Future versions may include partner management applications. Finally, endpoints discussed in this document are primarily Cisco IP phones. Future versions may also include discussion around wireless LAN access points as well as partner smart PDUs. The main sections are:

•Cisco EnergyWise Domain Design and Configuration focuses on what a Cisco EnergyWise domain is, how to configure domains on network infrastructure devices, and then discusses designing domains around existing power metering and sub-metering within a location to better assess the power usage which results from IT infrastructure with the overall power usage for the site.

•Monitoring Power focuses on the functionality which is provided both through Cisco EnergyWise and through existing IOS commands on network infrastructure devices to monitor power. Simply monitoring power within the network infrastructure is a typical first step in the deployment of Cisco EnergyWise technology.

•Controlling Power focuses primarily on the functionality provided through Cisco EnergyWise to control power to PoE-enabled switch ports. This section discusses both commands that can be executed directly on a single switch or throughout an entire Cisco EnergyWise domain through query commands. Recurring events, which can be used to automatically power on and off PoE-enabled switch ports, are also discussed. Finally, this section touches on some of the considerations which the network administrator must take into account when scheduling PoE-enabled switch ports to automatically power on and off.

•Cisco EnergyWise Protocol Operation focuses on the details and data flows which result from the Cisco EnergyWise protocol during the neighbor discovery process and during a Cisco EnergyWise query. This section also touches on the data flows involved with management applications.

•Cisco Prime LMS focuses on the functionality provided by this particular management application within a Cisco EnergyWise deployment.

Cisco EnergyWise Domain Design and Configuration

This section discusses the design of Cisco EnergyWise domains and the configuration of the Cisco EnergyWise protocol on network infrastructure platforms.

Cisco EnergyWise Domain Overview

A Cisco EnergyWise domain is an administrative grouping of devices for the purpose of power monitoring and control. These devices can consist of Cisco networking equipment, such as Catalyst switches and ISR G2 routers, Power over Ethernet (PoE) endpoints connected to Catalyst switches, such as IP phones and 802.11 wireless LAN access points, and endpoints which directly run a Cisco EnergyWise agent, such as Cisco partner power distribution units (PDUs). Figure 2 shows a visual example of a Cisco EnergyWise domain.

Figure 2 Example Cisco EnergyWise Domain

Cisco EnergyWise domains have no relationship with other networking infrastructure administrative groupings, such as routing protocol domains or virtual trunking protocol (VTP) domains. A device can be a member of only one Cisco EnergyWise domain at a time. In other words, a device cannot simultaneously be a member of multiple domains.

Cisco network infrastructure devices within a given Cisco EnergyWise domain are referred to as domain members, parent domain members, or parents. Domain members form peer-to-peer relationships, viewing each other as Cisco EnergyWise neighbors. Neighbor relationships are automatically formed through the use of Cisco Discovery Protocol (CDP) and/or UDP packet exchanges when Cisco EnergyWise is configured on domain members. Neighbor relationships can also be statically configured when members of a given domain are not all contiguous.

Within a given Cisco EnergyWise domain, domain members form a parent-child relationship with PoE endpoints and endpoints which directly run a Cisco EnergyWise agent. Endpoints are often referred to as child domain members or children. The difference between child domain members and full domain members (parent domain members) is that child domain members only respond to Cisco EnergyWise queries, while full domain members can both generate and respond to Cisco EnergyWise queries.

The function of a Cisco EnergyWise domain is to logically group a set of devices in order to treat them as a single administrative unit for power monitoring and/or control. Power monitoring and control is performed through management applications which support the Cisco EnergyWise Management API, such as Cisco Prime LMS 4.1 and higher, or partner management applications. Note that LMS 3.2 also supports Cisco EnergyWise power monitoring through the use of SNMP. Power monitoring and control can also be performed directly from any domain member within a given Cisco EnergyWise domain. The Cisco EnergyWise protocol is a UDP-based protocol which is used to flood Cisco EnergyWise queries received by one domain member to all domain members within a given Cisco EnergyWise domain based upon neighbor relationships. Cisco EnergyWise queries are used to either collect (monitor) power information on parent and child members or set (control) power levels on child members within a given domain. When used to collect power information, the Cisco EnergyWise protocol is also used to forward the information back to the domain member that issued the query.

Development of the Cisco EnergyWise feature has been through a sequence of phases and releases. There have been two major phases of Cisco EnergyWise technology—Phases 1 and 2. Within Phase 2 there have been enhancements focused primarily on specific platforms. For example, Cisco EnergyWise Phase 2+ was released with IOS version 12.2(33)SXJ for the Catalyst 6500 Series switches only. Likewise, software support for Cisco EnergyWise Phase 2.5 is available for Catalyst access switch platforms with IOS version 12.2(58)SE1. Cisco EnergyWise Phase 2 is not backward compatible with Cisco EnergyWise Phase 1. It is recommended to deploy Cisco EnergyWise Phase 2, 2+ or 2.5, since it replaces Phase 1 functionality.

Cisco EnergyWise releases refer to the particular version of the Cisco EnergyWise specification supported within the IOS software version running on the particular platform. The Cisco EnergyWise release can be viewed through the show energywise version administrator level CLI command. Example 1 is for a Catalyst 3560X Series switch running IOS version 12.2(58)SE1 software.

Cisco EnergyWise releases within Phases 2, 2+, and 2.5 are not all compatible with each other. The Cisco IOS Release Notes for Cisco EnergyWise, Cisco EnergyWise Phase 2.5, provides tables which show compatibility among the following releases:

•rel2

•rel2_25

•rel2_5

•rel2_6

•rel2_7

Compatibility currently exists from Cisco EnergyWise rel2_25 through rel2_7. Therefore, where possible it is recommended that the network administrator upgrade the network infrastructure components of a Cisco EnergyWise domain to an IOS version supporting Cisco EnergyWise rel2_25 or higher before implementing Cisco EnergyWise.

Note Domain members that support incompatible releases may appear within neighbor tables of other domain members. However, testing has shown that Cisco EnergyWise queries may not operate correctly across incompatible releases.

Table 1 shows various platforms, their latest IOS releases, and the corresponding current phase and release of Cisco EnergyWise supported.

Enabling Cisco EnergyWise on Cisco Platforms

This section provides a brief overview of the configuration of platforms to enable Cisco Energywise. For a thorough discussion regarding the specifics of configuring Cisco EnergyWise, refer to one of the following documents:

Note Since Cisco EnergyWise Phase 2.5 adds several enhancements, the format of several configuration-level and administrative-level CLI commands are slightly different between Phase 2.5 and Phase 2.0. Where applicable, these are specifically pointed out within this document. Where differences are not specifically pointed out, the commands are the same between the phases.

Global Configuration

To utilize the Cisco EnergyWise feature for monitoring and/or controlling power usage within the network infrastructure, it must first be enabled on each platform. Cisco EnergyWise can be enabled on supported platforms through the following global configuration command:

This mandatory parameter specifies the Cisco EnergyWise domain-name for the entity.

ntp-shared-secret | shared-secret

This mandatory parameter specifies the domain security mode to either include NTP information or not include NTP information, along with a shared secret when authenticating events between domain members. It is recommended that the network administrator ensure the network infrastructure devices within a Cisco EnergyWise domain are time synchronized by NTP before enabling the ntp-shared-secret option. This option is slightly more secure than the shared-secret option because it provides additional protection against replay attacks.

0 | 7

This parameter specifies whether an unencrypted security password 0 or encrypted security password 7 will be entered next. The default is 0, meaning that the domain-password which follows is expected to be unencrypted.

domain-password

This mandatory parameter specifies the shared secret which is used for authentication of events between members within the domain. This password must be the same for all domain members within a given Cisco EnergyWise domain. It is recommended to utilize a strong password.

udp-port-number

This optional parameter specifies the destination UDP port utilized for communication between Cisco EnergyWise domain members. If not specified, this defaults to UDP port 43440.

interfaceinterface-id | ipip-address

This optional parameter can be used to specify either a switch port interface which communicates with the Cisco EnergyWise domain or an IP address (in the case of an SVI, loopback address, or a routed interface) which communicates with the Cisco EnergyWise domain.

Where possible, it is recommended to specify either the interface or IP address within the energywise domain global configuration command. The use of a management VLAN with appropriate access-control lists for controlling traffic, including Cisco EnergyWise, is also recommended where possible. The network administrator must ensure that the IP address is reachable from all other members of the particular Cisco EnergyWise domain. If neither the IP address nor interface is specified, the router or switch automatically selects one of its IP addresses as the source for Cisco EnergyWise queries. The source address selected by the device for query packets may not always be obvious. There may be situations in which that interface may not be reachable from an IP perspective from the rest of the network infrastructure, such as when the interface belongs to a separate VRF or belongs to a dedicated subnet for network management. In such cases, Cisco EnergyWise may report that it has discovered neighbors through the CDP protocol, but Cisco EnergyWise queries, which are UDP-based, fail. In a worst case scenario, queries to set power levels or may appear to fail, but actually do succeed because the command made it to the device to set the power level, but the reply did not make it back. This can provide the network administrator with false information. Again, this is because the Cisco EnergyWise query protocol is UDP-based. It does not rely on a session to be established before executing the query. Further, Cisco EnergyWise does not necessarily even require bi-directional communications for the query to succeed if the query is sent to set power levels. The operation of the Cisco EnergyWise protocol is discussed in more detail in Cisco EnergyWise Protocol Operation.

Management Application Configuration

To enable communication between management applications which support the Cisco EnergyWise protocol and the Cisco EnergyWise domain, at least one domain member should have the following global configuration:

This parameter specifies whether an unencrypted security password 0 or encrypted security password 7 will be entered next. The default is 0, meaning that the management password which follows is expected to be unencrypted.

mgmt-password

This mandatory parameter specifies the shared secret which is used for authentication between the management workstation and the domain member. This password should be the same for all domain members within a given Cisco EnergyWise domain. It is recommended to utilize a strong password.

porttcp-port-number

This optional parameter specifies the destination TCP port utilized for communication between the management workstation and domain members. If not specified, this defaults to TCP port 43440.

Endpoint Communication Configuration

To set the security mode between Cisco EnergyWise domain members and attached endpoints which support the Cisco EnergyWise protocol, the following global configuration command must also be configured:

This parameter specifies the security mode for communication between the domain member and attached Cisco EnergyWise enabled endpoints. none means that no security is enabled. shared-secret means that communication will be secured through the use of a password.

0 | 7

This parameter only applies when the security mode of shared-secret has been chosen. It specifies whether an unencrypted security password 0 or encrypted security password 7 will be entered next. The default is 0, meaning that the endpoint-password which follows is expected to be unencrypted.

endpoint-password

This mandatory parameter specifies the shared secret which is used for authentication between the Cisco EnergyWise enabled endpoint and the domain member. It is recommended to utilize a strong password.

It should be noted that these are three completely separate passwords:

•Domain password configured for communication between domain members

•Management password configured for communication to the management workstation

The source IP address specified in the domain configuration line within the example above is the Loopback 0 interface of the switch. The Loopback 0 interface is an often recommended IP address because it remains up as long as device is up and is therefore not dependent upon any particular Ethernet or serial link of the switch or router. Alternatively, an IP address belonging to an interface on a dedicated management subnet can be used. The use of encrypted passwords is also recommended. Note that the global command service password-encryption should be enabled so that the password appears encrypted within the configuration.

Static Neighbors

Occasionally, it may be necessary to create a Cisco EnergyWise domain in which some of the domain members are not physically contiguous. Cisco EnergyWise Domain Design discusses several scenarios where this may occur. Cisco EnergyWise uses CDP and UDP broadcast packets for neighbor discovery. Therefore, in a non-contiguous domain, the domain member which is non-contiguous will not be discovered. To enable communications between domain members within such domains, a static neighbor entry must be configured within one of the domain members. Either the non-contiguous domain member has a static neighbor entry pointing at one of the domain members which is contiguous with the rest of the domain members or one of the contiguous domain members has a static neighbor entry pointing at the non-contiguous domain member.

A static neighbor can be configured with the following global-level configuration command:

energywise neighbor {host-name | ip-address} udp-port-number

Table 5 highlights the configuration parameters for the above command.

Table 5 Static Neighbor Configuration Parameters

Parameter

Purpose

host-name | ip-address

This parameter specifies either the host-name or the IP address of the static neighbor. If the host-name is used, the switch or router must have a DNS server and domain name configured to translate the host-name into an IP address. The IP address must be reachable from the domain member.

udp-port-number

This optional parameter specifies the destination UDP port utilized for communication between Cisco EnergyWise domain members. If not specified, this defaults to UDP port 43440.

Disabling Cisco EnergyWise

By default, Cisco EnergyWise is not enabled on platforms and must therefore be enabled. Once enabled, Cisco EnergyWise can be disabled again globally on a platform through the following configuration level command:

no energywise domain

This command will remove all Cisco EnergyWise configuration at both the global and interface levels of the platform.

For Catalyst switches, the no energywise interface-level command can be used to remove a specific switch port from the Cisco EnergyWise domain. All Cisco EnergyWise configurations within the particular interface of the platform will also be removed. The following is an example of the interface-level configuration command on a GigabitEthernet switch port.

interface GigabitEthernetX/X

no energywise

Note Cisco EnergyWise discovery packets and query packets will still be sent out Catalyst switch interfaces despite being configured with the no energywise interface-level command. Cisco EnergyWise discovery packets and queries are discussed further in Cisco EnergyWise Protocol Operation.

Optional Cisco EnergyWise Attributes

In addition to globally enabling Cisco EnergyWise and enabling communication to a management application, optional attributes can be configured both globally and at the Catalyst switch port or ISR G2 module level. These include Cisco EnergyWise importance, keywords, names, and roles. Cisco EnergyWise attributes function as values that set context. They provide the network administrator the ability to set common criteria for endpoints, which can then be used to provide more granular power monitoring and control capabilities. Cisco EnergyWise importance, keywords, names, and roles that are configured at the global level within a network infrastructure device apply to the global platform. Cisco EnergyWise importance, keywords, names, and roles that are configured at the switch port level within a Catalyst switch or at the module level for ISR G2 router (for those modules which support Cisco EnergyWise) apply only to the particular PoE switch port or module. Attributes set at the switch port level allow the network administrator to control PoE endpoints which do not natively support Cisco EnergyWise (in other words do not include the Cisco EnergyWise SDK or support the Cisco EnergyWise protocol). This is why the network administrator may choose to configure a switch with one particular attribute value and a switch port (which supports a PoE attached endpoint) with another attribute value.

Each of the optional Cisco EnergyWise attributes—importance, keywords, names, and roles—is discussed in the following sections.

Cisco EnergyWise Importance

Cisco EnergyWise importance is simply a value used to define a hierarchy of importance of devices within a Cisco EnergyWise domain. This value can then be used in query commands which either return power information or set power levels for devices that have an importance at or below the importance value specified. The Cisco EnergyWise importance can be specified globally for the platform. It can also be specified per Catalyst switch port and per ISR G2 module (for those modules which support Cisco EnergyWise).

The Cisco EnergyWise importance for the platform can be set with the following global configuration command:

energywise importanceimportance

The Cisco EnergyWise importance for a Catalyst switch port can be set with the following interface-level configuration commands, using a GigabitEthernet interface as an example:

interface GigabitEthernetX/X

energywise importanceimportance

Likewise, the Cisco EnergyWise importance for an ISR G2 module can be set with the following module-level configuration commands, using a PVDM module as an example:

interface PVDMX/X

energywise importanceimportance

The Cisco EnergyWise importance can range from 1 to 100, with 100 being the highest importance and 1 being the lowest importance. By default the importance is set to 1 globally for the platform, at the switch port level, and at the module level.

One scenario where Cisco EnergyWise importance may be used to provide business context is in situations where a power outage has occurred and a Catalyst switch is operating on a UPS system with limited capacity within the wiring closet. PoE-enabled devices connected to the switch which have a lower importance could be powered down to maximize the amount of available power for more critical—higher importance —devices. For instance, a handful of IP phones visibly mounted on columns within office cubicle areas may be dedicated for emergency services use. These IP phones may be given a higher importance than normal office and cubicle IP phones. Another scenario which may come up is during a demand response incident. During such times, lower importance PoE devices may be powered down to assist in shedding incremental power load for the particular site.

Cisco EnergyWise Keywords

Cisco EnergyWise keywords are basically a word or comma separated list of words which can be used as tags to characterize a device. These tags can then be used in commands which either return power information or set power levels for devices that match the keywords specified. Cisco EnergyWise keywords can be specified globally for the platform. They can also be specified per Catalyst switch port and per ISR G2 module (for those modules which support Cisco EnergyWise).

Cisco EnergyWise keywords for the platform can be set with the following global configuration command:

energywise keywordsword,word,...

Cisco EnergyWise keywords for a Catalyst switch port can be set with the following interface-level configuration commands, using a GigabitEthernet interface as an example:

interface GigabitEthernetX/X

energywise keywordsword,word,...

Likewise, the Cisco EnergyWise keywords for an ISR G2 module can be set with the following module-level configuration commands, using a PVDM module as an example:

interface PVDMX/X

energywise keywordsword,word,...

There is no default value for keywords. If no keywords are configured, then no keywords apply to the domain member.

One scenario where keywords may be used to provide business context is when the network administrator wishes to query for power information across broad classes of Cisco EnergyWise members. For example, the keyword "phone" can be used to characterize all PoE switch ports which support IP phones. A sub-class of IP phones which are used by bank tellers can also include the keyword "tellerPhone". Likewise a sub-class of IP phones which are used by agents can include the keyword "agentPhone". Therefore, if the network administrator wishes to know the power usage of just IP phones used by bank tellers across a particular domain, they can issue a Cisco Energywise query command specifying the keyword "tellerPhone" as a filter. Cisco EnergyWise queries are discussed in more detail in later sections of this design guide.

Cisco EnergyWise Name

The Cisco EnergyWise name for the platform can be set with the following global configuration command:

energywise namename

The Cisco EnergyWise name for a Catalyst switch port can be set with the following interface-level configuration commands, using a GigabitEthernet interface as an example:

interface GigabitEthernetX/X

energywise namename

Likewise, the Cisco EnergyWise name for an ISR G2 module can be set with the following module-level configuration commands, using a PVDM module as an example:

interface PVDMX/X

energywise namename

A Cisco EnergyWise name is basically a word which indicates the name of the device to Cisco EnergyWise. By default, a Catalyst switch or ISR G2 router utilizes the globally configured hostname for its Cisco EnergyWise name. Individual Catalyst switches within a switch stack utilize the globally configured hostname for the stack, along with a number appended to the end indicating the position of the switch within the stack, as its Cisco EnergyWise name.

Note For Catalyst switch stacks running IOS releases prior to 12.2(58)SE1 (prior to Cisco EnergyWise Phase 2.5), a single Cisco EnergyWise name applies to the entire switch stack. Individual switches within the stack are not identified.

For Catalyst switch ports, the Cisco EnergyWise name is dynamic and defaults to the CDP device ID of the device connected to the switch port—for devices which support CDP. The CDP device ID can be viewed through the show cdp entry * administrative-level CLI command as shown in Example 3.

Example 3 shows that the Cisco EnergyWise name of the device connected to GigabitEthernet3/4 is currently "SEP0018BA722853" (shown in bold). Note that the Cisco EnergyWise name changes if a different device is connected to the switch port, unless the network administrator has specifically configured a Cisco EnergyWise name to the switch port. If the switch port is not connected to a device which supports CDP, the Cisco EnergyWise name may default to an abbreviation of the interface itself, for instance Fa.01 for FastEthernet0/1.

For ISR G2 modules which support Cisco EnergyWise, the Cisco EnergyWise name of the module defaults to the hardware name which appears within the configuration of the router. The output in Example 4 from the show running-configuration administrative-level CLI command on an ISR G2 router shows an example of the Cisco EnergyWise name of a PVDM module.

Example 4 Output From the show running-config Command on an ISR G2 Router

me-e-miami-1#show running-config

~

!

hostname me-e-miami-1

!

~

!

energywise domain Miami security ntp-shared-secret 0 ciscoese

energywise importance 100

energywise keywords infrastructure

energywise management security shared-secret 0 ciscoese

!

energywise endpoint security shared-secret 0 ciscoese

!

~

!

hw-module pvdm 0/0

energywise importance 90

energywise role Network Module

energywise keywords PVDM,voice,DSPModule,VoIP

!

~

Example 4 shows that the Cisco EnergyWise name of the PVDM module will be "PVDM 0/0" (shown in bold) unless the network administrator has statically configured a Cisco EnergyWise name to the module.

From a design perspective, there may not be any particular reason why a network administrator would need to change the Cisco EnergyWise name of a platform. Typically a network administrator already configures a hostname for switches and routers which makes sense to management applications. This hostname is used for the Cisco EnergyWise name of the platform by default. Likewise, there may not be any particular reason why a network administrator would need to change the Cisco EnergyWise name of a Catalyst switch port or ISR G2 module. Leaving the default name allows the switch port to dynamically provide information about the attached endpoint gleaned from CDP within Cisco EnergyWise queries. Other attributes, such as Cisco EnergyWise keywords, can be used for more description if needed. Therefore, leaving the default Cisco EnergyWise name may be appropriate.

Cisco EnergyWise Role

A Cisco EnergyWise role is basically a string which indicates its use within a Cisco EnergyWise domain. By default, Cisco EnergyWise roles for platforms have the following default values:

•Modular Catalyst switch platforms use the model number of the supervisor linecard for their Cisco EnergyWise role.

•Standalone Catalyst switch platforms, Catalyst switch stacks, and ISR G2 router platforms use the model number of the chassis for their Cisco EnergyWise role.

The Cisco EnergyWise role for the platform can be set with the following global configuration command:

energywise rolerole

The Cisco EnergyWise role for a switch port can be set with the following interface-level configuration commands, using a GigabitEthernet interface as an example:

interface GigabitEthernetX/X

energywise rolerole

Likewise, the Cisco EnergyWise role for an ISR G2 module can be set with the following module-level configuration commands, using a PVDM module as an example:

interface PVDMX/X

energywise rolerole

For Catalyst switch ports, the Cisco EnergyWise role defaults to what CDP identifies as the platform of the device connected to the switch port. In Example 3, the show cdp entry * administrative-level CLI command shows that the GigabitEthernet3/4 switch port has identified a Cisco IP phone 7960 attached to it. Therefore, the Cisco EnergyWise role of interface GigabieEthernet3/4 is "IP Phone 7960". If the device connected to the switch port cannot be identified, the default role of a switch port is "interface". For ISR G2 modules which support Cisco EnergyWise, the role defaults to an asterisk (*).

Similar to Cisco EnergyWise keywords, a scenario where roles may be used to provide business context is when the network administrator wishes to query for power information across a broad class of Cisco EnergyWise devices. For example, the role "Video Phone" can be used to characterize a sub-class of IP phones which also support video capabilities. Likewise a sub-class of IP phones which only support voice can include the role "Voice Phone". Therefore if the network administrator wishes to know the power usage of just video-enabled IP phones across a particular domain, they can issue a Cisco Energywise query specifying the role "Video Phone" as a filter.

Viewing Cisco EnergyWise Attributes

The following partial configuration below shows an example of the Cisco EnergyWise configuration for the same Catalyst 4500 switch shown in Example 2. However, Cisco EnergyWise importance, keywords, names, and roles have now been added at both the global and interface level.

In the configuration in Example 5, the Cisco EnergyWise importance has been set to 60 globally for the switch itself. At the interface level, the importance of the PoE switch port has been set to 50. The Cisco EnergyWise keyword "infrastructure" has been configured globally for the switch itself. At the switch port level, the Cisco EnergyWise keywords "tellerPhone" has been configured to characterize the switch port as device which supports an IP phone used by a bank teller. Likewise, the Cisco EnergyWise role "Voice Phone" has been configured to characterize the switch port as a device which supports a voice-only IP phone.

The global Cisco EnergyWise level, importance, role, and name for a platform can be viewed through the show energywise administrative-level CLI command shown in Example 6.

Example 6 Output From the show energywise Administrative-Level CLI Command

me-westcamp-1#show energywise

Module/

Interface Role Name Usage Lvl Imp Type

--------- ---- ---- ----- --- --- ----

WS-X45-SUP6-E me-westcamp-1 490.0 (W) 10 100 parent

The Cisco EnergyWise level, importance, role, and name for a Catalyst switch port or ISR G2 module can be viewed through the show energywise children administrative-level CLI command shown in Example 7.

Example 7 Output From the show energywise children Administrative-Level CLI Command

me-e-miami-1#show energywise children

Module/

Interface Role Name Usage Lvl Imp Type

--------- ---- ---- ----- --- --- ----

CISCO2921/K9 me-e-miami-1 92.0 (W) 10 100 parent

PVDM 0/0 networkModule PVDM 0/0 6.0 (W) 10 90 module

Total Displayed: 2 Usage: 98.0

The network administrator should note that Cisco EnergyWise importance, names, and keywords can be used as filters for Cisco EnergyWise queries issued from the CLI of network infrastructure devices. The use of roles as a filter is not supported by the CLI. However, the Cisco EnergyWise MAPI can make use of roles in queries. Cisco EnergyWise queries for both controlling and monitoring power are discussed in later sections.

Cisco EnergyWise Domain Design

One of the central questions regarding Cisco EnergyWise domain design is how to determine what devices should be logically grouped into a given domain? Billing systems often determine energy usage per location based upon the deployment of power meters and sub-meters within that location. Cisco EnergyWise domains are intended to complement existing energy monitoring solutions by providing visibility into power consumed by IT infrastructure.

The following sections look at Cisco EnergyWise design from both campus and branch office perspectives. Note that the overall deployment and the benefits received through Cisco EnergyWise technology differ slightly based upon whether a site contains a single organizational entity—otherwise known as a single tenant site—or whether the site contains multiple organizational entities—otherwise known as a multi-tenant site. For the purposes of this document it is assumed that a campus location contains a single organizational entity. Branch office designs address the differences involved when multiple organizational entities lease floor space within a single building.

Campus Designs

A typical campus location consists of several buildings clustered together, all occupied by the same organization. Typical examples of a campus include:

•A cluster of office buildings within a single location owned by a single business entity such as a corporation

•A large community college, state college, or university consisting of multiple buildings

•A cluster of state, local, or federal government owned buildings within a single location

For the purposes of this document, it is assumed the organization is responsible for the energy usage across the campus, although the facilities management function may be contracted out to a third party which specializes in this area, rather than being done by the organization directly. In such cases, visibility into the energy use per building may be available due to the deployment of power meters for each building which are used by the local power utility company for billing purposes. A customer deployed Building Management System (BMS) or Building Automation System (BAS) may also collect energy usage data from power meters or sub-meters and/or directly off of high-energy usage equipment such as HVAC, lighting systems, etc. Such information may be used for energy scorecards, which analyze and compare energy usage across buildings over time to spot anomalies or determine where best to allocate resources to lower energy costs. Sub-metering may also be deployed within each building to internally allocate energy usage costs per department or business unit or to separately identify and internally allocate costs for high-energy usage areas such as labs.

In such environments, the network administrator may choose to configure Cisco EnergyWise domains to match the power metering or sub-metering within the site. In this manner, facilities management and network infrastructure personnel can assess the impact of IT infrastructure on overall energy usage within a given location. Figure 3 shows an example of this for a campus facility consisting of three buildings.

Figure 3 Example Cisco EnergyWise Domain Design within a Campus

In Figure 3, each of the three buildings is instrumented with a power meter that is used to determine overall energy usage and therefore billing for that particular building. In addition, a sub-meter is installed within Building 3 to internally determine energy use for a lab. Note that this sub-meter may or may not be visible to the power utility company. This can be used to determine the cost for energy used within Building 3, which is due to the lab. This may ultimately be charged back internally to the department which requires the lab.

Since there are three power meters and one sub-meter, four Cisco EnergyWise domains are configured. The Building 2 and Building 3 Cisco EnergyWise domains consist of network infrastructure equipment, PoE powered IP phones, PCs, and PoE powered 802.11 wireless access points which are serviced by the particular power meter. The network infrastructure equipment itself consists of distribution layer Catalyst 6500 or Catalyst 4500 Series switches connected to access layer Catalyst 4500, Catalyst 3000, or Catalyst 2000 Series switches which support Power over Ethernet (PoE) switch ports. Connectivity between the distribution layer switches and the connected access layer switches can be Layer 3 or Layer 2. However, a Layer 3 IP interface must be configured on each switch which is reachable from all other switches within a given Cisco EnergyWise domain. This is because UDP packets are used within the Cisco EnergyWise protocol itself. Note that with this design, all of the members of a given Cisco EnergyWise domain are physically contiguous. Therefore, static Cisco EnergyWise neighbor entries should not be needed. The Building 1 Cisco EnergyWise domain consists of core layer Catalyst 6500 switches and other distribution layer and access layer switching infrastructure, which are not shown in Figure 3 for simplicity. Finally the Building 3 Lab Cisco EnergyWise domain corresponds to the Building 3 sub-meter. It consist of an access layer Catalyst 3000 or Catalyst 2000 Series switch stack and smart power distribution units (PDUs) which support various lab equipment.

Due to the amount of IT equipment deployed within a campus environment, the network administrator must be aware of recommended size limitations of Cisco EnergyWise domains. Currently, it is recommended that a Cisco EnergyWise domain not exceed a total of 2,000 members (parents and/or children). Cisco EnergyWise queries are sent out across all domain members which collect the requested information (or set the desired level) and return the results to the domain member or management application which initiated the query. The amount of information which has to be collected and returned can be significant. This can exceed the time allowed for the query to complete, resulting in incomplete and/or inaccurate information. A single 48-port Catalyst access switch can support 48 PoE ports (not including uplink ports), each of which count as a child member. Each of those switch ports can also support an endpoint device which contains a Cisco EnergyWise client. These devices also count as child members. Finally, the switch itself counts as a domain member. Therefore, a single 48-port Catalyst access switch could account for 48 + 48 + 1 = 97 members. In a campus environment this means that a single Cisco EnergyWise domain could consist of 50 standalone access switches, each of which supports only 40 members. Alternatively a single Cisco EnergyWise domain could consist of 10 switch stacks or modular platforms, each of which supports 200 members. These members could be combinations of the switches themselves, the PoE-enabled switch ports, and endpoint devices which directly support Cisco EnergyWise.

If the number of Cisco EnergyWise members within a single building exceeds the recommended maximum number, the network administrator may consider splitting the Cisco EnergyWise domains based on floors or groupings of floors within the building. Figure 4 shows the first example of this.

This type of design is sometimes seen in high-rise buildings in which fiber optic cabling within the vertical risers in the building are expensive and scarce. Each floor or group of floors has a Catalyst 3000 or 2000 Series switch stack which functions not only as an access layer stack, but also as a second distribution layer for other access layer switch stacks on the same floor or group of floors. Cisco EnergyWise domains are configured to consist of the second distribution layer switch stack and its associated access layer switch stacks. Finally, the distribution layer Catalyst 6500 Series or Catalyst 4500 Series switches which connect to the core switches within the rest of the campus are configured as another Cisco EnergyWise domain. With this design, all switches within a given Cisco EnergyWise domain are still physically contiguous. Therefore, static neighbor entries should not be needed. Power information across all of the Cisco EnergyWise domains within the building needs to be aggregated either with a management application or manually to correlate the amount of overall energy use within the building, as determined through a BMS or through the building power meter, which was attributable to IT equipment.

Figure 5 shows the second example of Cisco EnergyWise domains per floor or group of floors.

This type of design follows the more traditional three-tiered campus architecture. It is often seen in high-rise buildings in which fiber optic cabling within the vertical risers in the building is plentiful. Each floor or group of floors has multiple Catalyst 3000 or 2000 Series switch stacks which function as access layer switches, directly connected to a set of distribution layer Catalyst 6500 Series or Catalyst 4500 Series switches. These in turn connect to the core switches within the rest of the campus. Cisco EnergyWise domains are configured to consist of the access layer switch stacks within each floor or group of floors. The distribution layer Catalyst 6500 Series or Catalyst 4500 Series switches are configured as another Cisco EnergyWise domain. With this design, switches within a given Cisco EnergyWise domain are not physically contiguous. Therefore, static neighbor entries connecting the different access layer switch stacks are needed. Static neighbors were discussed in Static Neighbors. Again, power information across all of the Cisco EnergyWise domains within the building needs to be aggregated either through a management application or manually to correlate the amount of overall energy use within the building, as determined through a BMS or through the building power meter, which was attributable to IT equipment.

Branch Office Designs

As mentioned previously, branch office Cisco EnergyWise domain designs are looked at from two perspectives. The first scenario is an organization which occupies the entire branch building. The second scenariois an organization which leases out only part of a larger branch building which is shared by multiple tenants. Note that in both cases, the Cisco EnergyWise domain design for the branch office may be the same. However, the ability to determine the amount of overall energy usage which is attributed to the IT infrastructure is often determined by how overall energy billing is accomplished in multi-tenant locations.

Single Tenant Branch Offices

Typical examples of single tenant branch office sites include:

•A single small office building owned by a business entity, such as a bank

•A standalone retail store

•An educational institution, such as a school

•A small state, local, or federal government owned building

For the purposes of this document, it is assumed the organization is responsible for the energy usage within the entire branch facility, although the facilities management function may be contracted out to a third party which specializes in this area, rather than being done by the organization directly. In such cases, visibility into the energy use for the building may be available due to the deployment of a power meter for the building, which is used by the local power utility company for billing purposes. A customer deployed Building Management System (BMS) or Building Automation System (BAS) may also remotely collect energy usage data from power meters or sub-meters and/or directly off of high-energy usage equipment such as HVAC, lighting systems, etc., within the branch office. Such information may be used for energy scorecards, which analyze and compare energy usage across branch offices over time to spot anomalies or to determine where best to allocate resources to lower energy costs.

In such an environment, the network administrator may choose to configure a single Cisco EnergyWise domain to match the power metering for the site. In this manner, facilities management and network infrastructure personnel can assess the impact of IT infrastructure on overall energy usage within the branch location. Figure 6 shows an example of this for a medium-sized branch facility.

This type of design is often seen when the floor space of the branch office requires the deployment of access layer switch stacks in remote wiring closets, often connected with fiber optic cabling back to the distribution layer switch stack within a central wiring closet.

The branch office Cisco EnergyWise design consists of two Cisco EnergyWise domains. The first domain consists of network infrastructure equipment, PoE powered IP phones, PCs, PoE powered 802.11 wireless LAN access points, and smart PDUs. The network infrastructure equipment consists of a distribution layer Catalyst 3000 Series or Catalyst 2000 Series switch stack connected to multiple access layer Catalyst 3000 Series or Catalyst 2000 Series switch stacks. Connectivity between the distribution layer switches and the access layer switches can be Layer 3 or Layer 2. However, a Layer 3 IP interface must be configured on each switch which is reachable from all other switches within a given Cisco EnergyWise domain. This is because UDP packets are used within the Cisco EnergyWise protocol itself. Note that with this design all the members of a given Cisco EnergyWise domain are physically contiguous. Therefore, static Cisco EnergyWise neighbor entries should not be needed. The second Cisco EnergyWise domain consists of the ISR G2 router.

Note The reason two domains are recommended is because the highest Cisco EnergyWise release supported by Cisco ISR G2 routers is rel2. Catalyst access switches currently support Cisco EnergyWise rel2_7, which is part of Cisco EnergyWise Phase 2.5, as of IOS 12.2(58)SE1. Cisco EnergyWise releases higher than rel2_25 are not backward compatible with rel2. Rather than downgrading the IOS version of the Catalyst access layer switches, it is recommended to run the Cisco ISR router as a separate Cisco EnergyWise domain.

Power information across both of the Cisco EnergyWise domains within the building needs to be aggregated either through a management application or manually to correlate the amount of overall energy use within the building, as determined through a BMS or through the building power meter, which was attributable to IT equipment. In this model, the organization's facilities management personnel working with network infrastructure personnel can again assess the impact of IT infrastructure on overall energy usage billed by the power utility company.

Due to the amount of IT equipment deployed within a branch office environment, the network administrator will probably not need to be concerned with recommended size limitations of Cisco EnergyWise domains. If the number Cisco EnergyWise members within a single branch office building exceeds the recommended maximum number, the network administrator may consider splitting the Cisco EnergyWise domains based on floors or groupings of remote wiring closets within the branch office building in a similar manner as discussed in Campus Designs.

Multi-Tenant Branch Offices

Typical examples of multi-tenant branch offices include:

•Branch offices in which the organization only leases out a single floor or part of a floor within a larger building

•Retail stores which lease space within a mall location

•Airports which lease gate and terminal space to individual airlines

In multi-tenant locations, a management company often manages the property. Allocation of costs for energy usage for the property can be done multiple ways including:

•Deployment of an individual power meter per tenant

•Deployment of internal sub-meters per tenant

•Allocation of costs per tenant equally or based on square footage of leased space

The design of the Cisco EnergyWise domain may be the same regardless of the method of allocating energy costs, however the overall benefit of Cisco EnergyWise itself may vary.

Individual Power Meter per Tenant

The property management company may have installed individual power meters for each tenant. Therefore, the power utility company directly bills each tenant for its energy usage. However, energy usage costs for common areas may be shared among all tenants. Note that centralized HVAC systems may mean that heating and cooling costs are also shared among all tenants. These costs may be averaged out as part of the overall monthly lease costs.

In such environments, the network administrator may choose to configure Cisco EnergyWise domains to match the power metering for the space leased by the organization. Figure 7 shows an example of this for a small branch office in which a single floor is leased.

Figure 7 Example Cisco EnergyWise Design within a Multi-Tenant Small Branch with Power Meters

In Figure 7, Floor 2 of a three floor building is leased by an organization. Often, the organization which leases the space installs its own network infrastructure gear consisting of a branch router and one or more switches, depending upon the size of the branch office. Similar to the standalone branch office design, Floor 2 consists of two Cisco EnergyWise domains. The first domain consists of network infrastructure equipment, PoE powered IP phones, PCs, PoE powered 802.11 wireless LAN access points, and smart PDUs. The network infrastructure equipment consists of a Catalyst 3000 Series or Catalyst 2000 Series switch stack. The second domain consists of the ISR G2 router. Both Cisco EnergyWise domains are serviced by the power meter for Floor 2.

Power information across both of the Cisco EnergyWise domains within the floor needs to be aggregated either through a management application or manually to correlate the amount of overall energy use within the floor, as determined through a BMS or through the Floor 2 power meter, which was attributable to IT equipment. In this model, the organization's facilities management personnel working with network infrastructure personnel can assess the impact of IT infrastructure on the energy usage directly billed by the power utility company. Note that since multiple tenants occupy the building and a central HVAC system may be deployed for the building, the energy bill from the power utility company may not include heating and cooling costs. However, Cisco EnergyWise does still provide visibility into the energy costs which are directly billed to the organization by the power utility company. Therefore reducing the amount of energy used by IT equipment may still directly lower the bill from the power utility company.

Sub-Meter per Tenant

The property management company may have single power meter for the overall building which is used by the power utility company for monthly billing. However, the property management company may have installed individual power sub-meters for each tenant. Therefore, the property management company bills each tenant for its energy usage as a percentage of the overall energy bill from the power utility company. Again, energy usage costs for common areas may be shared among all tenants and centralized HVAC systems may mean that heating and cooling costs are also shared among all tenants.

In such cases, Cisco EnergyWise technology can still be deployed to coincide with the power sub-meter. An example of this deployment is shown in Figure 8.

Figure 8 Example Cisco EnergyWise Design within a Multi-Tenant Small Branch with Sub-Meters

The design of the Cisco EnergyWise domain with the sub-metering model is identical to the design with individual power meters per tenant. The organization's facilities management personnel, working with network infrastructure personnel, can still indirectly assess the impact of IT infrastructure on the percentage of energy usage allocated to the organization by the property management company through the sub-meters. Therefore reducing the amount of energy used by IT equipment may still directly lower the costs billed back through the property management company with this model.

Allocation of Energy Costs Equally or by Square Footage of Leased Space

In this third model, the property management company may have a single power meter for the overall building which is used by the power utility company for monthly billing. However, the property management company has no further visibility into actual energy usage by each tenant. Therefore, the property management company may simply divide the monthly costs across all tenants based on the percentage of square footage leased by each tenant. Alternatively, the energy costs may simply be divided equally when leased floor space is relatively equal among all tenants (for example when each tenant occupies a single floor of a building). A third alternative is that the property management company may have historically averaged out energy usage over time and simply includes a charge for energy in the monthly lease costs. These charges may not correspond at all to actual energy usage for the month. An example of this deployment is shown in Figure 9.

Figure 9 Example Cisco EnergyWise Design within a Multi-Tenant Small Branch with Single Power Meter

The design of the Cisco EnergyWise domain with the single power meter model is identical to the design with individual power meters or sub-meters per tenant. However, in this case the organization's facilities management personnel working with network infrastructure personnel may not be able to assess the impact of IT infrastructure on energy usage allocated to the organization by the property management company. The organization may still choose to implement Cisco EnergyWise technology simply to monitor the power of IT equipment within the branch location or to reduce energy usage to demonstrate compliance with government mandates. However, reducing the amount of energy used by IT equipment through Cisco EnergyWise may not have any direct impact on the costs billed back through the property management company with this model.

Monitoring Power

Cisco EnergyWise Deployment Strategy

By collecting and archiving power information over the long-term through management applications such as Cisco Prime LMS, IT personnel can take the first step in an overall energy management strategy—simply monitoring power of IT equipment. This information can then be used to assess the percentage of overall energy costs for the organization which are due to IT equipment. Once the baseline has been established regarding how much of the facility's energy costs are due to IT equipment, IT personnel can then begin considering the next step in energy management-controlling the power of IT equipment to reduce overall costs. This section and the next follow this strategy by presenting information regarding how power within the network infrastructure can be monitored and subsequently how power within the network infrastructure can be controlled.

Overview of Power Monitoring Methods

This section discusses various methods by which power usage information can be obtained from network infrastructure platforms which support Cisco EnergyWise. Such information can be obtained through one of the following mechanisms:

1. Through the use of a management application such as Cisco Prime LMS

2. Through one of the administrative-level show energywise CLI commands for a single member of a given Cisco EnergyWise domain

3. Through one of the administrative-level energywise query CLI commands for all members of a given Cisco EnergyWise domain or selected domain members through the use of filters

4. Through administrative-level commands common to each Catalyst switch platform. Note that these commands also do not require Cisco EnergyWise support on the particular platform and include:

–show cdp entry

–show power inline

5. Through administrative-level commands specific to a particular Catalyst switch or router platform. Note that these commands do not require Cisco EnergyWise support on the particular platform and include:

–Catalyst 6500 Series: show power

–Catalyst 4500 Series: show power detail

–Cisco ISR G2 routers: show environment all

6. Through SNMP commands using various MIBs such as the CISCO-ENERGYWISE-MIB.

Cisco Prime LMS discusses the use of Cisco Prime LMS for both monitoring and managing power within the network infrastructure. The second, third, fourth, and fifth mechanisms are covered in this section.

Cisco EnergyWise Single Device Commands

Cisco EnergyWise commands can return power information for a Catalyst switch or ISR G2 router device (meaning the chassis, power supplies, and installed linecards), for individual PoE-enabled switch ports of a Catalyst switch, and for certain ISR G2 modules which support Cisco EnergyWise. Catalyst switch ports serve as proxies for PoE-enabled IP phones and wireless LAN access points. Future versions of these products may directly support the Cisco EnergyWise protocol. Finally, other Cisco partner products such as smart power distribution units (PDUs) may also directly support the Cisco EnergyWise protocol.

The following administrative-level show energywise CLI commands can be used to return power information when a network administrator is directly logged onto a domain member:

•show energywise

•show energywise children

•show energywise children provisioned

•show energywise usage

•show energywise usage children

The various commands yield slightly different outputs depending upon the platform and whether Cisco EnergyWise phase 2.0 or 2.5 is running on it. The examples within this section are chosen from multiple platforms to make the reader aware of these minor differences.

Output from the show energywise command varies based upon the IOS software version:

•For IOS software version 12.2(58)SE1 and higher—corresponding to Cisco EnergyWise Phase 2.5—the show energywisecommand returns individual power usage values which represent the power used by each switch within the switch stack.

•For IOS software versions below 12.2(58)SE1—corresponding to Cisco EnergyWise Phase 2.0—the show energywisecommand returns a single power usage value which represents the sum of the power usage of all the switch chassis of the switch stack.

Standalone Switches

Catalyst 3560X Series, Catalyst 3560E Series, Catalyst 3560G Series

The show energywise command returns a single power value which represents the power usage of the switch chassis itself.

The show energywise command returns a single value which represents the power usage of the router chassis along with any modules which do not support Cisco EnergyWise. Modules which support Cisco EnergyWise appear as children.

The network administrator should note that for any Catalyst switch (modular, standalone, or stackable), output from the show energywise command does not include any power used by child domain members, such as PoE switch ports. In other words this value does not necessarily represent total power usage by the switch or switch stack unless it does not currently have any PoE devices attached, or the attached PoE devices are currently not drawing power from the switch or switch stack. Likewise, for any ISR G2 router, output from the show energywise command does not include any power used by child domain members, such as modules which support Cisco EnergyWise. In other words, this value does not necessarily represent total power usage by the ISR G2 router unless it does not currently have any modules installed which support Cisco EnergyWise or the installed modules which support Cisco EnergyWise are powered down. The following document lists the ISR G2 modules which are currently supported by Cisco EnergyWise: http://www.cisco.com/en/US/partner/docs/routers/access/1900/software/configuration/guide/greenconfig_ps10538_TSD_Products_Configuration_Guide_Chapter.html.

An example of the output from the show energywise command from a Catalyst 3750X Series switch stack running Cisco EnergyWise Phase 2.0 software and consisting of two WS-C3750-X-24P switches is shown in Example 8.

Example 8 Output From the show energywise Command—Cisco EnergyWise Phase 2.0 on a Catalyst 3750X

me-e-miami-4#show energywise

Module/

Interface Role Name Usage Category Lvl Imp Type

--------- ---- ---- ----- -------- --- --- ----

WS-C3750X-24P me-e-miami-4 137.0 (W) consumer 10 1 Parent

An example of the output from the show energywise command from a Catalyst 2960S Series switch stack running Cisco EnergyWise Phase 2.5 software, consisting of one WS-C2960S-48TD-L and WS-C2960S-48TS-L switch, is shown in Example 9.

Example 9 Output From the show energywise Command—Cisco EnergyWise Phase 2.5 on a Catalyst 2960S

me-w-austin-3#show energywise

Module/

Interface Role Name Usage Category Lvl Imp Type

--------- ---- ---- ----- -------- --- --- ----

WS-C2960S-48TD-L me-w-austin-3-1 54.0 (W) consumer 10 100 module

WS-C2960S-48TS-L me-w-austin-3-2 52.0 (W) consumer 10 100 module

Total Displayed: 2 Usage: 106.0

As can be seen, information regarding the Cisco EnergyWise role, name, and importance (Imp) are included in the output. These attributes were discussed in Optional Cisco EnergyWise Attributes. Information regarding the Cisco EnergyWise level (Lvl) is also included in the output. This parameter is discussed in Manually Configuring Cisco EnergyWise Levels. As discussed previously, Cisco EnergyWise uses a hierarchical parent/child structure for power management within a domain. Catalyst switches and routers function as parent members, as seen in Example 7. PoE-enabled switch ports and ISR G2 modules which support Cisco EnergyWise function as children.

The "category" parameter indicates that this device is considered to be a consumer of power. Cisco EnergyWise Phase 2.0 defines only the "consumer" category of device. Cisco EnergyWise Phase 2.5 enhanced this to include the categories shown in Table 8.

Table 8 Cisco EnergyWise Phase 2.5 Categories

Category

Description

Consumer

A device which consumes power. All network infrastructure components, including switches and routers, have the category of consumer.

Producer

A device which generates power has the category of producer.

Meter

A device which measures the pass-through power without producing or consuming power itself. For example, a power distribution unit (PDU) outlet distributes power to connected devices.

The output from Example 7 shows power usage to be 137.0 Watts for the Catalyst 3750X Series switch stack or approximately 68.5 Watts per switch chassis. The example from Example 8 explicitly shows power usage for each Catalyst 2960S Series switch chassis to be 54.0 Watts and 52.0 Watts, respectively. Hence, one of the advantages of migrating to a higher IOS revision which supports Cisco EnergyWise Phase 2.5 is that it provides more detailed information regarding power usage when switch stacks are deployed.

show energywise children Command

An example of the output from the show energywise children administrative-level CLI command from the same Catalyst 3750X Series switch stack, running Cisco EnergyWise Phase 2.0 software, is shown in Example 10.

Example 10 Output From show energywise children Command—Cisco EnergyWise Phase 2.0 on a Catalyst 3750X

me-e-miami-4# show energywise children

Module/

Interface Role Name Usage Category Lvl Imp Type

--------- ---- ---- ----- -------- --- --- ----

WS-C3750X-24P me-e-miami-4 138.0 (W) consumer 10 100 parent

Gi1/0/11 IP Phone 9951 SEP1C17D3407EB1 5.268 (W) consumer 10 50 PoE

Total Displayed: 2 Usage: 143.3

Likewise, an example of the output from the show energywise children command from a switch stack consisting of a Catalyst 3750G and an NME module housed within an ISR router, both running Cisco EnergyWise Phase 2.5 software, is shown in Example 11.

Example 11 Output From show energywise children Command—Cisco EnergyWise Phase 2.5 on a Catalyst 3750G

me-eastny-3#show energywise children

Module/

Interface Role Name Usage Category Lvl Imp Type

--------- ---- ---- ----- -------- --- --- ----

NME-XD-24ES-1S-P me-eastny-3-1 15.0 (W) consumer 10 1 module

Fa1/0/11 IP Phone 7931 SEP001A6C7C6F78 7.0 (W) consumer 10 50 PoE

WS-C3750G-24PS me-eastny-3-2 103.0 (W) consumer 10 1 module

Gi2/0/11 IP Phone 8961 SEP68BDABA41056 9.6 (W) consumer 10 50 PoE

Total Displayed: 4 Usage: 134.6

As can be seen from Example 10and Example 11, the show energywise children command extends the show energywise command to include Cisco EnergyWise child members which are currently drawing power, such as switch ports which are currently supporting PoE devices.

show energywise children provisioned Command

An example of the output from the show energywise children provisioned administrative-level CLI command from the same Catalyst 3750X Series switch stack, running Cisco EnergyWise Phase 2.0 software, is shown in Example 12.

As can be seen from Example 12, the show energywise children provisioned command extends the show energywise children command to include Cisco EnergyWise child members which are provisioned but not necessarily currently drawing power. An example is switch ports which are not currently drawing power. In Example 12, interface GigabitEthernet2/0/23 functions as an uplink port and therefore never draws power. However the interface is still configured with Cisco EnergyWise support.

An example of the output from the show energywise children provisioned command on the Catalyst switch stack consisting of a Catalyst 3750G and an NME module running Cisco EnergyWise Phase 2.5 software is shown in Example 13.

In Example 13, interface GigabitEthernet1/0/2 functions as an uplink port and is configured for Cisco EnergyWise. However, it does not appear within the output of the show energywise children provisioned command in Example 13. This is because output from the various show energywise... commands do not include switch ports which do not support PoE. This can be verified with the show power inline command run for the interface.

Example 14 Output From the show power inline GigabitEthernet x/x/x Command

me-eastny-3#show power inline GigabitEthernet 1/0/2

Interface Gi1/0/2: inline power not supported

The network administrator should take note of this. Often fiber-optic ports are used as uplink ports in the following scenarios where distances greater than 100 meters are involved:

•Between core level switches located centrally within a campus and distribution level switches located within each building of the campus

•Between distribution level switches located centrally within a building and access level switches located in separate wiring closets on each floor of the building

•Between switches and routers when distances require it

Since fiber-optic ports do not support PoE, they do not appear within the output from any of the show energywise commands. However these uplink ports still support the sending and receiving of Cisco EnergyWise traffic for neighbor discovery and for Cisco EnergyWise queries. Hence, output from the show energywise children provisioned command is intended more for displaying ports which are provisioned for PoE devices, but are currently not drawing power.

Finally, the network administrator should note that the power value returned by the show energywise, show energywise children, and show energywise children provisioned commands do not indicate if the value is the actual power drawn by the device or an estimate. This information is obtained from the "caliber" parameter, which can be displayed with the show energywise usage and show energywise usage children commands, discussed next.

show energywise usage Command

An example of the output from the show energywise usage administrative-level CLI command from the same Catalyst 3750X Series switch stack, running Cisco EnergyWise Phase 2.0 software, is shown in Example 15.

As with other Cisco EnergyWise Phase 2.0 commands, power usage for all switches is aggregated to a single value. Cisco EnergyWise Phase 2.5 enhances the show energywise usage command to include separate power usage per switch within the switch stack. An example from the switch stack consisting of a Catalyst 3750G and an NME module is shown in Example 16.

Note that the intent of the show energywise usage command is not to include children within the output. Although children currently appear within the output of Catalyst switches running IOS version 12.2(58)SE1, future versions will not include this.

The show energywise usage command includes one additional useful piece of information, the "caliber" parameter. The "caliber" parameter is used to specify the relative precision of the power usage information returned. It can take one of the values shown in Table 9.

Table 9 Possible Values of the Caliber Parameter

Caliber Value

Description

Actual

This indicates that the data reported is not presumed or max but the real power. Actual means that there is some hardware in place on the device that can measure the power of the device. This caliber value is the most precise for monitoring power.

Trusted

This indicates that the data reported was reported from another source. For example, a PoE-enabled switch port returns the power which the attached device is expected to utilize based upon CDP negotiation between the device and the switch port. This involves the exchange of CDP power requested, CDP power available, and/or CDP power drawn TLVs between the PoE-enabled device (such as an IP phone, IPVS camera, or wireless LAN access point) and the Catalyst switch port. This caliber value is less precise than actual power, but more precise than presumed power.

Presumed

This indicates that the actual power drawn cannot be determined but can be presumed from the model. For example, a device chassis with a caliber of presumed returns the power usage it is expected to utilize based upon its configuration (number and type of linecards inserted, power supplies, etc.). A PoE-enabled switch port with a caliber of presumed returns the maximum power the attached device is expected to utilize based upon the IEEE 802.3af power class to which it belongs. For PoE-enabled switch ports, this caliber value is generally less precise than a trusted caliber value because there are only four 802.3af power classes.

Max

This indicates that the actual power cannot be determined. Instead, a presumed value that is the maximum the Cisco EnergyWise member could draw is provided. For example, a Catalyst switch, ISR G2 router, or an ISR G2 Cisco EnergyWise supported module with a caliber of max returns the maximum power drawn per engineering specifications. This is equivalent to the power usage normally shown within the datasheet of the product.

Unknown

This indicates that the power reported is unknown. For example, in some cases entities report aggregate power like what a lighting controller or aggregate controller does. In such cases it is not known whether the usage reported is actual or presumed.

From a Cisco EnergyWise design perspective, it is obviously more advantageous to deploy platforms throughout the network which support the ability to report actual power of both the chassis as well as the PoE switch ports. When monitoring power, long-term utilization reports will be more accurate, resulting in a more accurate view of power usage due to network infrastructure components. Likewise, when actively controlling power, long-term reports will provide a more accurate view of the actual energy saved by powering down PoE-enabled devices during off-hours. The monitoring of actual power requires hardware-level instrumentation to be included within switch and router platforms and not necessarily just software upgrades. Therefore, the network administrator must balance the benefits of being able to monitor actual power with the cost of upgrading to newer platforms which support the ability to return actual power both at the chassis level and the PoE switch port level. As switch and router hardware deployed throughout the network becomes obsolete and ready for upgrade, the network administrator should consider upgrading to platforms which support the ability to monitor actual power at the chassis and PoE switch port level. Table 10 shows the Cisco EnergyWise caliber values returned for both the chassis and switch ports for various access-layer switch models.

1Except WS-C2960-48PST-S and WS-C2960-48PST-L which support a caliber of actual for the switch ports.

show energywise usage children Command

For Catalyst switch platforms running Cisco EnergyWise Phases 2.0 and 2.5, the show energywise usage children administrative-level CLI command returns power information for the both the parent members and child members in which Cisco EnergyWise is enabled (provided the switch port supports PoE). As with the show energywise usage command, Cisco EnergyWise Phase 2.5 returns power information per switch chassis when a stack configuration is deployed. Cisco EnergyWise Phase 2.0 returns one power usage value for the entire switch stack. An example of the output from a Catalyst 3750X Series switch stack running Cisco EnergyWise Phase 2.0 software is shown in Example 17.

In the output from Example 17, interface GigabitEthernet2/0/23 was specifically configured as an uplink port to a router. Since the switch port does not utilize PoE, it appears with a caliber of presumed and a usage of 0.0 Watts.

Interfaces GigabitEthernet1/0/11 and 2/0/11 represent Cisco IP phones. Cisco EnergyWise shows power usage per switch port to be 5.324 Watts and 2.295 Watts, respectively from Example 17. Output from the show cdp entry commands in Example 18 reports power requested and power drawn to be 12.000 Watts and 5.000 Watts for the Cisco IP 9951 and IP 7911 phones, respectively.

This indicates that the IP phones and the Catalyst switches support the negotiation of power usage through CDP TLVs. Power usage is therefore negotiated between the Catalyst 3750X platform and these IP phone models. However, since the Catalyst 3750X Series switch platform supports actual power usage per switch port, the more precise value is reported in the output from the show energywise usage children command.

A second example of the output from the show energywise usage children command, this time with Cisco EnergyWise Phase 2.5 software running on a switch stack composed of a Catalyst 3750G (WS-C3750G-24PS) and an ISR NME module (NME-XD-24ES-1S-P), is shown in Example 19.

Example 19 Output From the show energywise usage children Command—Cisco EnergyWise Phase 2.5

me-eastny-3#show energywise usage children

Interface Name Usage Category Caliber

--------- ---- ----- -------- -------

me-eastny-3-1 15.0 (W) consumer actual

Fa1/0/11 SEP001A6C7C6F78 7.0 (W) consumer presumed

me-eastny-3-2 103.0(W) consumer actual

Gi2/0/11 SEP68BDABA41056 9.6 (W) consumer trusted

Total Displayed: 4 Usage: 134.6

In this case Cisco EnergyWise Phase 2.5 provides more detail around power usage for the NME-XD-24ES-1S-P (15.0 Watts) and the WS-C3750G-24PS switch (103.0 Watts), instead of a single power usage number which reflects the switch stack. Interfaces FastEthernett1/0/11 and GigabitEthernet2/0/11 represent Cisco IP phones. Output from the show cdp entry commands in Example 20 reports power requested and power drawn to be 7.000 Watts and 9.600 Watts for the Cisco IP 7931 and IP 8961 phones, respectively.

Again, this indicates that the IP phones and the Catalyst switch support the negotiation of power usage through CDP TLVs. However, Cisco EnergyWise shows power usage per switch port to be 7.0 Watts and 9.6 Watts, respectively, in Example 20. Since the older Catalyst 3750G Series switch platform do not support actual power usage per switch port, the less precise values are reported with the caliber values of "trusted" and "presumed" within the output from the show energywise usage children command.

The network administrator should note that in the examples shown for all of the show energywise... commands in this section, the no energywise interface-level configuration command was configured for unused switch ports which were not currently supporting PoE devices. The no energywise interface-level configuration command is discussed in Cisco EnergyWise Domain Design and Configuration.

Note As of Cisco EnergyWise Phase 2, output from Cisco EnergyWise query commands currently still includes switch ports which are configured with the no energywise command.

Monitoring Power with Cisco EnergyWise Query Commands

Cisco EnergyWise query commands are administrative level CLI commands, issued from one network infrastructure device within a particular Cisco EnergyWise domain or from a management workstation such as Cisco Prime LMS used to either collect data or set data for one or more members of a given Cisco EnergyWise domain. This section discusses the use of Cisco EnergyWise query commands for monitoring power. The following section discusses their use for controlling power.

Cisco EnergyWise queries are a highly useful administrative feature which allows the network administrator to monitor power on multiple Cisco EnergyWise domain members without having to log onto every single switch or router within a Cisco EnergyWise domain and manually run the various show energywise commands discussed earlier in this section.

For monitoring power usage, the Cisco EnergyWise query command takes the following general form, depending upon whether Cisco EnergyWise Phase 2.5 or Cisco EnergyWise Phase 2.0 is deployed on the particular platform:

•Cisco EnergyWise Phase 2.5 form of the command (IOS 12.2(58)SE1 or higher on Catalyst access switches):

Mandatory filter with a range from 1 to 100. Domain members with an importance value at or less than the value specified within the command are included. Cisco EnergyWise importance is discussed in Cisco EnergyWise Importance.

keywordsword,word...

Either the keywords or name filter is mandatory, but both may not be included together within a single Cisco EnergyWise query. When the keywords filter is used, one or more keywords must be specified and there is no default or wildcard value. Multiple keywords must be separated with a comma with no spaces between the keywords. Domain members configured with a keyword which matches one of the keywords within the list specified within the query are included. Cisco EnergyWise keywords are discussed in Cisco EnergyWise Keywords.

namename

Either the keywords or name filter is mandatory, but both may not be included together within a single Cisco EnergyWise query. When the name filter is used, only a single name must be specified. The wildcard value of asterisk "*" may be used by itself or as a trailing asterisk to specify a name that "starts with". For example, "*" and "myname*" are valid filters, but "*name" and "myn*me" are not. Domain members configured with a name which matches the name specified within the query are included. Cisco EnergyWise names are discussed in Cisco EnergyWise Name.

collect | sum

This mandatory field specifies whether the power information is returned as separate entries for each domain member which matches both the importance and either the keywords or name filters or whether the power information is returned as a summation across all domain members which match both the importance and either the keywords or name filters.

usage | delta

This mandatory field specifies whether the requested information to be returned is the actual power usage of the device or the difference between the actual power usage and the maximum power usage for each Cisco EnergyWise power level.

{all | consumer | meter | producer}

This optional parameter specifies the category of device to which the Cisco EnergyWise query applies. The default value is "consumer", which applies to domain members which are considered to be consumers of power such as routers, switches, router modules, and PoE-enabled switch ports. Note that this option only appears for devices which support Cisco EnergyWise Phase 2.5. Table 8 discusses the meaning of each of the categories.

timeouttimeout

This optional parameter can be used to specify a length of inactivity time from query replies that a sending domain member will detect to consider the query ended. The default value is six seconds. The timeout value can range from 1 to 180 seconds. For example, if the timeout value is set to 10 seconds, then if there is a 10 second timeout period of no replies from the domain, then the query will end. For larger Cisco EnergyWise domains consisting of multiple switches or switch stacks, the timeout value may need to be increased to ensure that all domain members have sufficient time to receive, execute, and reply to the Cisco EnergyWise query.

Cisco EnergyWise Query Examples

The following examples show how queries may be used to determine the power usage of members within a Cisco EnergyWise domain. The partial configurations below show both the global and the interface-level Cisco EnergyWise configurations of a Catalyst 3750X Series switch stack, me-e-miami-4, and a Catalyst 2975 Series switch stack, me-e-miami-3, used for the examples. Both switches belong to the Cisco EnergyWise domain named Miami.

Interfaces GigabitEthernet2/0/11, GigabitEthernet1/0/11, and GigabitEthernet2/0/5 have been configured with a Cisco EnergyWise importance of 50 and the keyword of "phone" indicating that the switch ports both support IP phones. The first example shows how filters can be used to return information for only PoE-enabled IP phones. The second example shows how the power usage can be aggregated for all members within the Cisco EnergyWise domain.

Example 1—Cisco EnergyWise Query Using Filters to Collect Power Use

Figure 10 shows an example in which a Cisco EnergyWise query is issued using attribute filters to collect the current power usage of all PoE-enabled IP phones within the domain.

In Figure 10, the following administration level CLI command is issued from a PC connected to one of the switches through SSH or TELNET:

energywise query importance 50 keywords phone collect usage consumer

Note that this command can be issued from either switch within the Cisco EnergyWise domain with the same results. The Cisco EnergyWise protocol distributes this command to every other member of the domain. In this case, the command is distributed to the Catalyst 2975 Series switch, me-e-miami-3, by way of the router, which is not part of the domain itself. The command instructs each domain member to match on members (switch ports in this example) which have the following attributes: an importance of 50 or below and match the keyword "phone". Once the match as been made, the switches collect and return the power usage for those entities. In this case, the switch port GigabitEthernet2/0/11 on the Catalyst 3750X Series switch and the switch ports GigabitEthernet1/0/11 and GigabitEthernet2/0/5 on the Catalyst 2975 Series switch match. The Cisco EnergyWise protocol forwards the results of the command run back to the initiating switch, which then aggregates and displays the results. In the example above the results are as follows:

EnergyWise query, timeout is 6 seconds:

Host Name Usage Level Imp

---- ---- ----- ----- ---

10.16.97.2 SEP1C17D3407EB1 5.3 (W) 10 50

10.16.150.3 SEPECC882B187B4 12.0 W) 10 50

10.16.150.3 SEP005060032D31 15.4 (W) 10 50

Queried: 3 Responded: 3 Time: 4.363 seconds

This provides an indication to the network administrator that the command was successful, that three devices matched the filters provided within the command, the current power usage of those three devices, and that the command took approximately 4.363 seconds to complete. Note that there is no indication of whether the power usage is actual or an estimate, since the Cisco EnergyWise query does not return the caliber along with the power usage value in the CLI output. The network administrator should note that the Cisco EnergyWise query and protocol do allow for more values to be returned to applications, such as Cisco Prime LMS or partner applications, thorough the management API (MAPI). The CLI only returns a subset of the information available.

This example also highlights the operation of a Cisco EnergyWise query across a domain which is not physically contiguous. In the configuration in Example 21, the Catalyst 3750X Series switch has a static Cisco EnergyWise neighbor command pointing at the Catalyst 2975 Series switch. Note that only one of the domain members requires the static neighbor definition.

Example 2—Cisco EnergyWise Query to Summarize Power Use Across the Domain

Figure 11 shows a second example in which a Cisco EnergyWise query is issued to sum the amount of power consumed across all members within the Cisco EnergyWise domain.

Figure 11 Example Cisco EnergyWise Query to Sum Power Usage Across the Domain

In Figure 11, the following administration level CLI command is issued from a PC connected to one of the switches through SSH or TELNET:

energywise query importance 100 name * sum usage all

The command instructs each domain member to match on members which have the following attributes: an importance of 100 or below and match the name "*", which represents a wildcard for any name. In other words, this command matches all members within the domain and sums their power usage. In the example above the results are as follows:

EnergyWise query, timeout is 6 seconds:

Total Usage

-----------

486.5 (W)

Queried: 148 Responded: 148 Time: 5.431 seconds

This provides an indication to the network administrator that the command was successful, that 148 members matched the filters provided within the command, the total power usage of the domain is currently 486.5 Watts, and that the command took approximately 5.431 seconds to complete. Note that the 148 responses correspond to parent and child members (every switch chassis and every switch port) within the domain.

Note Cisco EnergyWise queries currently return information for switch ports which have been configured with the no energywise interface-level configuration command. This is different from the output from show energywise commands discussed previously.

Monitoring Power with Commands Common to Catalyst Switch Platforms

The Catalyst Series of switches also provide commands which can be used to monitor the power of PoE-enabled switch ports, including:

•show cdp entry

•show power inline

As mentioned previously, the commands discussed within this section do not require Cisco EnergyWise support on the particular platform.

show cdp entry Command

The format of the show cdp entry command is:

show cdp entry { * | word }

The asterisk "*" serves as a wildcard, specifying all current CDP entries on the Catalyst switch. If the specific device entry is known, the network administrator can specify it directly. Example 22 shows the output of a Catalyst 3750X Series switch matching the specific CDP entry SEP1C17D3407EB1 corresponding to the Device ID of a Cisco 9951 IP phone connected to the switch.

From a power management perspective, the show cdp entry command provides several valuable pieces of information to the network administrator. First, it provides the platform (model number) of the device. In Example 22, the platform is a Cisco IP phone 9951. Second, it provides the switch port to which the device is connected. In this case it is connected to interface GigabitEthernet1/0/11. Next, it lists how much power can be drawn by the device along with the measurement unit (in this case Watts). This is not necessarily the amount of power which is currently being drawn by the device, but the maximum that it can draw from the switch port. This corresponds to the value sent within the CDP Power Drawn TLV, from the device to the switch. It is used by the switch in determining its power budget and allocating power for supporting PoE-enabled devices. Finally, the output lists the requested power levels. This corresponds to the value sent within the CDP Power Requested TLV, from the device to the switch. Typically the power requested and power drawn are the same. In other words, the device requests a certain amount of power through the CDP Power Requested TLV. The switch acknowledges this amount of power is available within its power budged through the CDP Power Available TLV. The device then signifies the amount of power it can draw through the CDP Power Drawn TLV.

Power negotiated through the exchange of CDP power information typically has a Cisco EnergyWise caliber of "trusted" on most Catalyst switch platforms which do not report actual power usage for PoE ports through Cisco EnergyWise. Note that some older platforms such as the NME may use the Cisco EnergyWise caliber of "presumed", even though the CDP exchange has taken place. Therefore, the network administrator may still be able to manually obtain some power usage information per PoE-enabled switch port for platforms which do not support Cisco EnergyWise with the show cdp entry command. Note, however, that it will not be as accurate as the latest switch platforms which report actual power usage per PoE-enabled switch port through Cisco EnergyWise.

show power inline Command

From a power management perspective, the show power inline command provides several useful pieces of information regarding Power over Ethernet (PoE) to the network administrator.

The initial IEEE PoE specification from 2003 (known as the IEEE 802.3af or IEEE 802.3af-2003 specification) specified up to 15.4 Watts of DC power supplied per switch port to an attached device through Category 3 or Category 5 twisted-pair cabling. Note that the standard specifies power delivered by the Power Sourcing Equipment (PSE) corresponding to the switch port and not power delivered to the Powered Device (PD) corresponding to a device such as an IP phone. Some power is lost within the twisted-pair cabling from the switch port to the device.

To support intelligent power management, the PSE may optionally classify powered devices. The IEEE 802.3af standard defined the power classifications in Table 12.

Table 12 IEEE Power Classifications

Class

Minimum Power Levels at Output of PSE

Range of Maximum Power Used by the PD

0

15.4 Watts

0.44 to 12.95 Watts

1

4.0 Watts

0.44 to 3.84 Watts

2

7.0 Watts

3.84 to 6.49 Watts

3

15.4 Watts

6.49 to 12.95 Watts

4

Treat as Class 0—Reserved for future use with 802.3af devices. 34.2 Watts for 802.3at devices

12.95 to 25.5 Watts for 802.1at devices

If the PSE cannot determine the power classification of the PD, it should default to a Class 0 device with a maximum of 15.4 Watts. Class 4 was reserved for future use within the IEEE 802.3af specification and not used. The IEEE created a second PoE specification in 2009 (known as the IEEE 802.3at or IEEE 803.2at-2009 specification) which supports up to 34.2 Watts of DC power per switch port. This is known as PoE+ and runs over Category 5e twisted-pair cabling only. Class 4 is therefore utilized for IEEE 802.3at devices only.

Depending upon the particular Catalyst switch model implemented within the network, either IEEE 802.3af or IEEE 802.3at PoE is supported. Example 23 shows the output from the administrative-level show power inline CLI command run on a Catalyst 3750X Series switch stack. Note that this switch model supports the IEEE 802.3at power specification.

Example 23 Output From the show power inline Administrative Level CLI Command

me-e-miami-4# show power inline

Module Available Used Remaining

(Watts) (Watts) (Watts)

------ --------- -------- ---------

1 495.0 12.0 483.0

2 495.0 0.0 495.0

Interface Admin Oper Power Device Class Max

(Watts)

--------- ------ ---------- ------- ------------------- ----- ----

Gi1/0/1 auto off 0.0 n/a n/a 30.0

Gi1/0/2 auto off 0.0 n/a n/a 30.0

Gi1/0/3 auto off 0.0 n/a n/a 30.0

Gi1/0/4 auto off 0.0 n/a n/a 30.0

Gi1/0/5 auto off 0.0 n/a n/a 30.0

Gi1/0/6 auto off 0.0 n/a n/a 30.0

Gi1/0/7 auto off 0.0 n/a n/a 30.0

Gi1/0/8 auto off 0.0 n/a n/a 30.0

Gi1/0/9 auto off 0.0 n/a n/a 30.0

Gi1/0/10 auto off 0.0 n/a n/a 30.0

Gi1/0/11 auto on 12.0 IP Phone 9951 4 30.0

Gi1/0/12 auto off 0.0 n/a n/a 30.0

Gi1/0/13 auto off 0.0 n/a n/a 30.0

Gi1/0/14 auto off 0.0 n/a n/a 30.0

Gi1/0/15 auto off 0.0 n/a n/a 30.0

Gi1/0/16 auto off 0.0 n/a n/a 30.0

Gi1/0/17 auto off 0.0 n/a n/a 30.0

Gi1/0/18 auto off 0.0 n/a n/a 30.0

Gi1/0/19 auto off 0.0 n/a n/a 30.0

Gi1/0/20 auto off 0.0 n/a n/a 30.0

Gi1/0/21 auto off 0.0 n/a n/a 30.0

Gi1/0/22 auto off 0.0 n/a n/a 30.0

Gi1/0/23 auto off 0.0 n/a n/a 30.0

Gi1/0/24 auto off 0.0 n/a n/a 30.0

Gi2/0/1 auto off 0.0 n/a n/a 30.0

Gi2/0/2 auto off 0.0 n/a n/a 30.0

Gi2/0/3 auto off 0.0 n/a n/a 30.0

Gi2/0/4 auto off 0.0 n/a n/a 30.0

Gi2/0/5 auto off 0.0 n/a n/a 30.0

Gi2/0/6 auto off 0.0 n/a n/a 30.0

Gi2/0/7 auto off 0.0 n/a n/a 30.0

Gi2/0/8 auto off 0.0 n/a n/a 30.0

Gi2/0/9 auto off 0.0 n/a n/a 30.0

Gi2/0/10 auto off 0.0 n/a n/a 30.0

Gi2/0/11 auto off 0.0 n/a n/a 30.0

Gi2/0/12 auto off 0.0 n/a n/a 30.0

Gi2/0/13 auto off 0.0 n/a n/a 30.0

Gi2/0/14 auto off 0.0 n/a n/a 30.0

Gi2/0/15 auto off 0.0 n/a n/a 30.0

Gi2/0/16 auto off 0.0 n/a n/a 30.0

Gi2/0/17 auto off 0.0 n/a n/a 30.0

Gi2/0/18 auto off 0.0 n/a n/a 30.0

Gi2/0/19 auto off 0.0 n/a n/a 30.0

Gi2/0/20 auto off 0.0 n/a n/a 30.0

Gi2/0/21 auto off 0.0 n/a n/a 30.0

Gi2/0/22 auto off 0.0 n/a n/a 30.0

Gi2/0/23 auto off 0.0 n/a n/a 30.0

Gi2/0/24 auto off 0.0 n/a n/a 30.0

From a power management perspective, the show power inline command provides several valuable pieces of information regarding PoE to the network administrator. First, the command provides the administrative and operational state of PoE supplied to each switch port. Note that every switch within a switch stack appears within the output. In Example 23, all of the switch ports are set to an administrative state of "auto". This means that whenever a PoE-enabled device is connected to a switch port, the switch automatically determines if it has enough power left within its power budget to power the device. If so, then power is supplied to the device. Note that the switch port always checks first to determine if the device supports PoE before supplying power. An administrative state of "auto" does not mean that power is automatically applied to the switch port. It means that if the switch has enough power within its power budget and if the device supports PoE, power is supplied. The information at the top of Example 23 shows overall how much power is available to power devices connected to switch ports, how much is currently used, and how much is available for use. In this case, both switches within the switch stack have 495 Watts of total power available for supporting PoE devices connected to their switch ports. Switch 1 is using 12.0 Watts currently and therefore has 483 Watts available. Switch 2 has the full 495 Watts of power available. Note that the operational state of switch port Gi1/0/11 is "on" and the power utilization of that switch port corresponds to the 12.0 Watts used by Switch 1.

The switch has identified the device as a Cisco IP phone 9951 and classifies it as an IEEE 802.3at Class 4 device. The maximum amount of power that can be supplied by the switch port is listed at 30.0 Watts. However, because power has been negotiated through CDP, only 12.0 Watts have been subtracted from the overall power budget of the switch. If the powered device does not support CDP, then the maximum power for the IEEE 802.3af / IEEE 802.3at class of device is subtracted from the power budget. Power use determined through the IEEE 802.3af / IEEE 802.3at class of device typically has a Cisco EnergyWise caliber of "presumed" on most Catalyst switch platforms which do not report actual power usage for PoE ports through Cisco EnergyWise. This is another example of how CDP provides more intelligent power management on top of the existing IEEE 802.3af / IEEE 802.3at specifications. Cisco EnergyWise can provide even more precise power use information per switch port for models of Catalyst switches which provide a caliber of "actual" for power usage.

Catalyst Series switches and ISR G2 router platforms also provide commands specific to each platform which can be used to monitor the power of PoE-enabled switch ports, including:

•Catalyst 6500 Series—show power

•Catalyst 4500 Series—show power detail

•Cisco ISR G2 routers—show environment all

Note that the commands discussed within this section also do not require Cisco EnergyWise support on the particular platform.

Catalyst 6500 Series show power Command

The show power command on the Catalyst 6500 Series switches has a slightly different format depending upon whether the switch is standalone or part of a VSS pair. For standalone switches, the format of the command is:

show power

For VSS pairs, the show power command only returns information for the switch which has the active supervisor. Therefore, to return power information for both switches, the following command format can be used:

show power switch all

Example 24 shows the output from the administrative-level show power CLI command run on a Catalyst 6506E standalone switch.

Example 24 Output From show power CLI Command on a Catalyst 6500 Series Switch

From Example 24, the system power used is 1,938.72 Watts. This value is the same as the power usage returned with the show energywise children command as shown in Example 25:

Example 25 Output From show energywise usage children CLI Command

me-westcore-1#show energywise usage children

Interface Name Usage Category Caliber

--------- ---- ----- -------- -------

me-westcore-1 1939.0(W) consumer presumed

The show power command can be used by the network administrator to gain a much more detailed understanding of the power usage per linecard within the Catalyst 6500 Series chassis, in addition to the aggregate power usage information obtained from Cisco EnergyWise. From the output of Example 25, it can be seen that there are five linecards installed in slots 1, 2, 3, 5, and 6 on the switch. Each linecard—including the redundant supervisor—is allocated a certain amount of power based on the engineering requirements of the linecard itself. Likewise the fan is allocated a certain amount of power. Summing the power allocation provides the following:

Slot 1

WS-X6748-GE-TX

325.50

Slot 2

7600-SIP-600

341.88

Slot 3

WS-X6708-10GE

473.76

Slot 5

WS-SUP720-BASE

328.44

Slot 6

(Redundant Sup)

328.44

Fan 1

WS-C6506-E-FAN

140.70

Total Power Allocated

1,938.72 Watts

From this example, it can be seen that the switch determines if there is enough power within its power budget based on the capacity of the power supplies that are installed and operational. If there is sufficient power, the switch allows the linecard to boot-up and subtracts the amount of power required for the linecard from its overall capacity. Hence, the power usage returned by Cisco EnergyWise—in this case with a caliber of "presumed"—is based on power allocated by the switch per linecard and for the fan. It does not represent actual power usage. However, through the show power command, the network administrator can still determine which linecards are using the majority of power within the switch itself.

Note Output from the show power switch all CLI command on a set of Catalyst 6500 Series switches configured as a VSS pair (also known as a Catalyst 1440 VSS pair) differs from output from the show energywise children CLI command with IOS version 12.2(33)SXJ.

Catalyst 4500 Series show power detail Command

Example 26 shows the output from the administrative-level show power detail CLI command run on a Catalyst 4506E switch.

Example 26 Output From show power detail CLI Command on a Catalyst 4500 Series Switch

In Example 26, the system power used is 490 Watts and the inline power used in 7 Watts. These values are approximately the same as the power usage returned with the show energywise children command as shown in Example 27.

Example 27 Output From show energywise usage children CLI Command

me-westcamp-1#show energywise usage children

Interface Name Usage Caliber

--------- ---- _____ _______

me-westcamp-1 490.0 (W) max

Gi3/4 SEP0018BA722853 7.79 (W) trusted

Gi3/5 Gi3.5 0.0 (W) presumed

Gi3/6 Gi3.6 0.0 (W) presumed

Gi3/7 Gi3.7 0.0 (W) presumed

Gi3/15 Gi3.15 0.0 (W) presumed

Gi3/25 Gi3.25 0.0 (W) presumed

Total Displayed: 7 Usage: 497.1

As with the Catalyst 6500 Series show power command, the Catalyst 4500 Series show power detail command can be used by the network administrator to gain a much more detailed understanding of the power usage per linecard within the Catalyst 4500 Series chassis. From the output of Example 27, it can be seen that there are three linecards installed in slots 1, 2, and 3 on the switch. Each linecard is allocated a certain amount of power based upon the engineering requirements of the linecard itself. Likewise the fan is allocated a certain amount of power. Summing the power allocation provides the following:

Slot 1

WS-X45-SUP6-E

260

Slot 2

WS-X4606-X2-E

50

Slot 3

WS-X4548-GB-RJ45V

60

Fan Tray

120

Total Power Allocated

490 Watts

The switch determines if there is enough power within its power budget based on the capacity of the power supplies that are installed and operational. If there is sufficient power, the switch allows the linecard to boot-up and subtracts the amount of power required for the linecard from its overall capacity. Hence, the power usage returned by Cisco EnergyWise—in this case with a caliber of "max"—is based on power allocated by the switch per linecard and for the fan. It does not represent actual power usage. However, through the show power detail command, the network administrator can again determine which linecards are using the majority of power within the switch itself.

Note Output from the show power detail CLI command on the Catalyst 4500 Series switches shows inline power for the attached IP 7960 phone to be 7 Watts. This differs slightly from the output from the show energywise children CLI command with IOS version 12.2(54)SG, which indicated 7.79 Watts.

Cisco ISR G2 Router show environment all Command

Example 28 shows the output from the show environment all CLI command run on a Cisco 2921 ISR router.

Example 28 Output From show environment all CLI Command on a Cisco 2921 ISR Router

me-e-miami-1#show environment all

SYSTEM POWER SUPPLY STATUS

==========================

Internal Power Supply Type: AC-POE

Internal Power Supply 12V Output Status: Normal

Internal Power Supply POE -48V Voltage Status: Normal

External Redundant Power Supply is absent or powered off

SYSTEM FAN STATUS

=================

Fan 1 OK, Medium speed setting

Fan 2 OK, Medium speed setting

Fan 3 OK, Medium speed setting

Fan 4 OK, Medium speed setting

SYSTEM TEMPERATURE STATUS

=========================

Intake Left temperature: 37 Celsius, Normal

Intake Right temperature: 34 Celsius, Normal

Exhaust Left temperature: 40 Celsius, Normal

Exhaust Right temperature: 36 Celsius, Normal

CPU temperature: 79 Celsius, Normal

Power Supply Unit temperature: 40 Celsius, Normal

REAL TIME CLOCK BATTERY STATUS

==============================

Battery OK (checked at power up)

SYSTEM POWER

===============

Motherboard Components Power consumption = 88.3 W

NM/SM slot 1 Power consumption = 10.1 W

Total System Power consumption is: 98.4 W

Environmental information last updated 00:00:20 ago

From Example 28, the total system power used is 98.4 Watts. This value is approximately the same as the power usage returned with the show energywise children command as shown in Example 29.

Example 29 Output From show energywise usage children CLI Command

me-e-miami-1#show energywise usage children

Interface Name Usage Caliber

--------- ---- _____ _______

me-e-miami-1 92.0 (W) actual

PVDM 0/0 PVDM 0/0 6.0 (W) presumed

Total Displayed: 2 Usage: 98.0

Note that the overall amount of power used is the same, however the information regarding the components which contribute to the power usage differs between the two outputs. The show environment all command lists power usage from the perspective of the motherboard components and the network modules. This is similar to the supervisor and linecards of a modular switch chassis, although the motherboard components contain additional systems. For example, PVDM 0/0, reported separately by the show energywise command, is actually attached to the motherboard. Therefore the 6.0 Watts of presumed power usage by the PVDM module—reported by Cisco EnergyWise—is part of the 88.3 Watts reported by contained within the motherboard components—reported by the show environment all command. The 10.1 Watts used by the NM/SM in slot 1 is actually a VPN module which is aggregated as part of the 92.0 Watts of power reported as me-e-miami-1 in the output from the show energywise usage children command. Cisco EnergyWise reports power from the perspective of the parent and child members which support Cisco EnergyWise. Since the VPN module does not support Cisco EnergyWise, it is aggregated as part of the parent member.

Controlling Power

This section discusses methods by which power usage can be actively managed on network infrastructure devices through Cisco EnergyWise. In addition, it presents two methods by which the Cisco Unified Communications Manager (CUCM) can control the power use of IP phones by putting them into different sleep modes, referred to a Power Save mode and Power Save Plus mode. Finally it presents a new feature of Catalyst 3750X, Catalyst 3560X, and Catalyst 2960S Series switches which increases energy savings by allowing the physical interface of the switch port to go into a lower power mode when the physical link is down.

Cisco EnergyWise Levels

Cisco EnergyWise uses a set of defined operational levels to control power consistently, since the devices within a Cisco EnergyWise network may be from different manufacturers. Cisco EnergyWise levels are shown in Table 13.

Table 13 Cisco EnergyWise Levels

Category

Level (Lvl)

Description

Operational

10

Full

9

High

8

Reduced

Standby

7

Medium

6

Frugal

5

Ready

4

Low

3

Standby

Nonoperational

2

Sleep

1

Hibernate

0

Shut Off

Cisco EnergyWise supports the following three methods of controlling power usage:

•Manually changing the Cisco EnergyWise level of individual domain members

•Configuring recurring events which automatically change the Cisco EnergyWise level of domain members based on scheduled times

•Simultaneously changing the Cisco EnergyWise level of members across multiple members of a given Cisco EnergyWise domain through a Cisco EnergyWise query command

It should be noted that management applications make use of one or more of these functions (typically through the Cisco EnergyWise API) to control power on Cisco EnergyWise-enabled infrastructure devices. Note also that these methods apply primarily to power on PoE-enabled Catalyst switch ports and ISR G2 modules which support Cisco EnergyWise. Each of the methods listed above is discussed below.

Manually Configuring Cisco EnergyWise Levels

For Catalyst switches and switch stacks, Cisco EnergyWise levels can be set globally for the platform and per switch port. Likewise, for ISR G2 routers, Cisco EnergyWise levels can be set globally for the platform and per module which supports Cisco EnergyWise. Note, however, that global levels currently have no effect on the switch or router platform as powering down a switch has no means to wake it back up at this time. PoE powered switch ports can be powered down/up by way of the parent PoE switch.

The Cisco EnergyWise level can be set for the platform with the following global configuration command:

energywise levellevel

The configured level has a range from 0-10, corresponding to the values in Table 13. By default, the Cisco EnergyWise level of the platforms is set for level 10, corresponding to full power. The power to a network infrastructure device itself cannot be turned off with Cisco EnergyWise commands. Therefore Cisco EnergyWise level 0 is not supported for the platform itself.

The show energywise level administrative-level CLI command can be used to display the power usage for the various levels on a Catalyst switch, switch stack, or ISR G2 router platform. The format of the output is slightly different between Cisco EnergyWise Phase 2 and Phase 2.5.

An example for a Catalyst 3750X Series switch stack consisting of two WS-C3750X-24P switches, running IOS 12.2(55)SE1, corresponding to Cisco EnergyWise Phase 2, is shown in Example 30.

As can be seen, the Phase 2.5 output individually shows power levels for each switch within the switch stack, while the Phase 2 output aggregates this information.

Changing the Cisco EnergyWise level within the global configuration does not affect power usage of a switch chassis with the current phase of Cisco EnergyWise.

PoE-enabled switch ports supply power to devices such as IP phones and wireless LAN access points. The Cisco EnergyWise level for a switch port can be set with the following interface-level configuration commands, using a GigabitEthernet interface as an example:

interface GigabitEthernet X/X

energywise levellevel

Likewise, the Cisco EnergyWise level for an ISR G2 module can be set with the following module-level configuration commands, using a PVDM module as an example:

hw-module pvdm x/x

energywise levellevel

Again, Cisco EnergyWise levels can range from 0 to 10, corresponding to the values in Table 13. By default, the Cisco EnergyWise level of PoE-enabled switch ports and ISR G2 modules which support Cisco EnergyWise is set for level 10, corresponding to full power. With the current phase of Cisco EnergyWise, a configured level of 0 removes power from the PoE-enabled switch port or ISR G2 module. Configured values from 1 through 10 supply full power to the PoE-enabled switch port or ISR G2 module.

Example 32 shows a GigabitEthernet port of a Catalyst 3750X switch in which the Cisco EnergyWise level has been manually configured for Level 0, Shut Off.

Configuring Recurring Events

Manually configuring each switch port individually to enable and disable PoE is generally not administratively feasible for anything but very small deployments. Therefore, Cisco EnergyWise supports the ability to automatically power on and off PoE-enabled Catalyst switch ports and ISR G2 modules based on a schedule.

For the purpose of this guide, the following three terms are defined as follows:

•Events—An event is a single directive to go to a particular level (like on or off). For example, go to level 10 at 8am.

Within the Building Management Systems (BMS) industry, the term "schedule", as defined above, is often utilized. Cisco Prime LMS implements "policies" which are applied to groups of devices within LMS. Finally, Catalyst switch and IOS router documentation refers to directives which control switch ports and router modules as "recurring events". The network administrator should note that LMS implements policies by modifying the configuration of Catalyst switch and IOS routers to implement schedules consisting of one or more recurring events.

This configuration-level command has two forms, either using the at configuration parameter or the time-range configuration parameter. Each method of configuring recurring events is discussed below.

Recurring Events with Cron Format

Example 34 shows the first way in which an EnergyWise recurring event can be configured to enable and disable power supplied to a device connected to a PoE-enabled switch port, the cron format.

Example 34 Catalyst Switch Recurring Event—Cron Format

~

!

interface GigabitEthernet2/0/14

description CONNECTION TO NEW YORK IP 8961 PHONE

switchport access vlan 331

srr-queue bandwidth share 1 30 35 5

priority-queue out

mls qos trust dscp

energywise level 10 recurrence importance 50 at 0 7 * * 1,2,3,4,5

energywise level 0 recurrence importance 50 at 0 0 * * 0,1,2,3,4,5,6

energywise level 0 recurrence importance 50 at 0 19 * * 1,2,3,4,5

energywise level 10 recurrence importance 50 at 0 12 * * 0,6

energywise level 0 recurrence importance 50 at 0 17 * * 0,6

energywise importance 50

energywise role endUserInterface

energywise keywords phone,videoPhone

no macro auto processing

!

In Example 34, no global time-ranges are configured. Instead, the first form of the energywise level configuration command is utilized with the at configuration parameter. This specifies a time-range directly within the command. The time-range is in Unix/Linux cron format. For example, the first energywise level command in the example above is:

energywise level 10 recurrence importance 50 at 0 7 * * 1,2,3,4,5

This configuration line specifies an EnergyWise level of 10—indicating Full power state for the switch port—specifying the time-range of 0 7 * * 1,2,3,4,5. The cron format is:

[minute] [hour] [day of month] [month of year] [day of week]

In this case, the value of 0 7 * * 1,2,3,4,5 specifies:

•0 minutes

•7 hours (7:00 AM)

•* days (meaning all days of the month)

•* months (meaning all months of the year)

•1,2,3,4,5 (meaning Monday through Friday)

Therefore, this first command line specifies that PoE to the switch port should be powered on at 07:00 AM every Monday through Friday, indefinitely. Note that with the cron format, multiple entries for a single field are separated by a comma. For instance 1,2,3,4,5 in the "day of week" position indicates days 1 through 5, which correspond to Monday through Friday. The other commands in Example 34 specify times when power to the switch port should be powered off during the week, as well as when the power to the switch port should be powered on and off during weekends.

Recurring Events with Time Ranges

Example 35 shows the second way in which a Cisco EnergyWise recurring event can be configured to enable and disable power supplied to a device connected to a PoE-enabled switch port, the use of time-ranges.

Example 35 Catalyst Switch Recurring Event—Time Ranges

!

interface GigabitEthernet2/0/14

description CONNECTION TO NEW YORK IP 8961 PHONE

switchport access vlan 331

srr-queue bandwidth share 1 30 35 5

priority-queue out

mls qos trust dscp

energywise level 10 recurrence importance 50 time-range phonesOn

energywise level 0 recurrence importance 50 time-range phonesOff

energywise importance 50

energywise role endUserInterface

energywise keywords phone,videoPhone

no macro auto processing

~

!

time-range phonesOff

absolute start 00:00 01 January 2011

periodic weekdays 0:00 to 7:00

periodic weekend 0:00 to 12:00

periodic weekdays 19:00 to 23:59

periodic weekend 17:00 to 23:59

!

time-range phonesOn

absolute start 00:00 01 January 2011

periodic weekdays 7:00 to 19:00

periodic weekend 12:00 to 17:00

!

In Example 35, the global time-ranges called phonesOn and phonesOff are configured within the Catalyst switch. On Catalyst switch platforms, time-ranges can specify absolute times and/or periodic times with configuration commands that begin with the word "absolute" or "periodic".

Absolute times are implemented slightly differently depending upon the platform and IOS software revision, as shown in Table 14.

Table 14 Absolute Time Implementation Based on Platform and Software Revision

Platform

Software Version

Absolute Time Implementation

Catalyst 6500 Series

12.2(33)SXJ (Cisco EnergyWise Phase 2.0)

Absolute times must specify a starting time and date and may contain an ending time and date, but it is not required.

Catalyst 4500 Series

12.2(54)SG (Cisco EnergyWise Phase 2.0)

Absolute times must specify a starting time and date and must also contain an ending time and date.

Catalyst Access Switches

12.2(58)SE1 (Cisco EnergyWise Phase 2.5)

Absolute times must specify a starting time and date and may contain an ending time and date, but it is not required.

Catalyst Access Switches

12.2(55)SE and below (Cisco EnergyWise Phase 2.0)

Absolute times must specify a starting time and date and must also contain an ending time and date.

Cisco ISR G2 Routers

15.1(4)M (Cisco EnergyWise Phase 2.0)

Absolute times must specify a starting time and date and may contain an ending time and date, but it is not required.

Absolute times are typically used alongside periodic times to specify a recurring event that begins at a certain time and occurs periodically. There can only be one absolute time configuration line per time-range. If an absolute time is not specified at all within the time-range, then the recurring event will occur periodically indefinitely without a starting time and date.

Note Cisco EnergyWise uses only the start time in a time range. The end time is ignored. This is why both an "on" and "off" range are needed.

Periodic times can be specified to occur using one of the following:

•Every day (daily)

•Weekdays only (Monday through Friday)

•Weekends only (Saturday and Sunday)

•A specific day or days (for example, Monday and Wednesday only)

Periodic times must specify a start time and a stop time (although the stop time is ignored) on Catalyst switch platforms using the 24-hour time format. Periodic times alone within a time-range (without absolute times) are useful for recurring schedules that have no specific start dates. There can be multiple periodic time configuration lines per time-range.

Note that the time-range does not specify an action to be performed—meaning whether PoE to the switch port is to be powered on or off. Note also that the time-range does not specify a target of the action either—meaning which switch port should be powered on or off from a PoE perspective. For a Catalyst switch this is performed within the configuration of the switch port itself with the energywise level command. In Example 35, the second form of the command is utilized. Interface GigabitEthernet2/0/14 has the following two configuration lines:

energywise level 10 recurrence importance 50 time-range phonesOn

energywise level 0 recurrence importance 50 time-range phonesOff

The first line specifies a Cisco EnergyWise level of 10—indicating a Full power state for the switch port—specifying the time-range named phonesOn. The second line specifies a Cisco EnergyWise level of 0—indicating a Shut Off power state for the switch port—specifying the time range named phonesOff.

Both forms of configuring Cisco EnergyWise recurring events have their advantages and disadvantages. The advantage of the time-range method of configuration is that a single time-range can be used for multiple switch ports or multiple router modules simply by referencing it within energywise level commands within the particular interface configurations of the Catalyst switch or module configurations of the ISR G2 router. This can reduce duplicate configuration lines for Cisco EnergyWise recurring events. Note however there are typically few modules installed per ISR G2 router, so the advantage is far less than with Catalyst switches. The time-range method also has the advantage of being able to specify a start date in the future. For example, if the network administrator wishes a recurring event to occur daily beginning in March of 2012, they can specify this using the method shown in Example 35. The disadvantage of the time-range method is that it does not allow the network administrator to specify an arbitrary range of days and months in which the recurring event is to be run. For example, it is not possible to create a recurring event that runs on the 5th, 6th, and 7th day of only the months of January, March, and June.

The advantage of the cron format method is that the network administrator can specify an arbitrary range of days and months in which the recurring event is to be run. However, one disadvantage is that the same configuration lines must be duplicated across every Catalyst switch port which supports a PoE device or router module and which runs a recurring event as well. A second disadvantage is that the recurring event cannot be set to begin in the future and run continuously.

Ability to specify an arbitrary range of days and months in which the recurring event is to be run

X

From a design perspective, if the network administrator simply needs recurring events that occur every day of the month and every month of the year, without a starting or ending date, it is recommended to use the cron format shown in Example 34. This is also the format which Cisco Prime LMS 4.1 utilizes to configure policies within supported devices.

Mixing the Two Methods for Configuring Recurring Events

The time-range and cron format methods for configuring recurring events for Catalyst switches and ISR G2 router modules may be combined—although with caution. Note that Example 36 is not a recommended configuration. It is used simply to emphasize potential issues that could arise when mixing the two methods.

As mentioned above, the results of this configuration may not be what are anticipated by the network administrator. In Example 36, global time-ranges are used to specify a start time and date in the future in which a recurring event is to begin running. However, no periodic statements appear within the time-ranges. Instead, periodic statements appear within the Cisco EnergyWise hardware module configuration, using the cron format. However, IOS executes each energywise level command independently. If the absolute start time specified within the energywise level 0 recurrence importance 30 time-range modulesOff command shown in Example 36 does not match the current time, IOS continues to the next command. Therefore, IOS will still execute the energywise level 0 recurrence importance 30 at 0 0 * * 0,1,2,3,4,5,6 command. Therefore, it is appropriate to implement recurring events using either the time-range format shown or the cron format.

Controlling Power through Cisco EnergyWise Queries

Cisco EnergyWise query commands are administrative level CLI commands issued from one network infrastructure device within a particular Cisco EnergyWise domain or from a management workstation such as Cisco Prime LMS used to either collect power information or set power levels for one or more members of a given Cisco EnergyWise domain. This section discusses the use of Cisco EnergyWise query commands for controlling power usage. The previous section discussed their use for monitoring power.

The set query is similar to the collect query. Refer to Monitoring Power with Cisco EnergyWise Query Commands for information regarding the use of queries for collecting power information. When running a query to set power levels, the following procedure is recommended:

•First, run a collect query to see what criteria passes the filters. This ensures that the proceeding set query will affect all of the desired domain members and only the desired domain members.

•Next, run the set query and monitor the results.

•Finally, run another collect query to ensure the correct levels have been set on the desired domain members.

Cisco EnergyWise set queries are a highly useful administrative feature which allow the network administrator to control power to multiple Cisco EnergyWise members without having to log onto every single switch or router within a Cisco EnergyWise domain and manually enable or disable power.

For controlling power, the Cisco EnergyWise query command takes the following general form, depending upon whether Cisco EnergyWise Phase 2.5 or Cisco EnergyWise Phase 2 is deployed on the particular platform:

•Cisco EnergyWise Phase 2.5 form of the command—IOS 12.2(58)SE1 or higher on Catalyst access switches:

Table 16 highlights the configuration parameters from the above command.

T

Table 16 Configuration Parameters For Cisco EnergyWise Query to Set Power Levels

Parameter

Purpose

importanceimportance

Mandatory filter with a range from 1 to 100. Domain members with an importance value at or less than the value specified within the command are included. Cisco EnergyWise importance is discussed in Cisco EnergyWise Importance.

keywordsword,word...

Either the keywords or name filter is mandatory, but both may not be included together within a single Cisco EnergyWise query. One or more keywords must be specified as there is no default or wildcard value. Multiple keywords must be separated with a comma with no spaces between the keywords. Domain members configured with a keyword which matches one of the keywords within the list specified within the query are included. Cisco EnergyWise keywords are discussed in Cisco EnergyWise Keywords.

namename

Either the keywords or name filter is mandatory, but both may not be included together within a single Cisco EnergyWise query. When the name filter is used, only a single name must be specified. The wildcard value "*" may be used to match any name by itself or as a trailing asterisk to specify a name that "starts with". For example, "*" and "myname*" are valid filters, but "*name" and "myn*me" are not. Domain members configured with a name which matches the name specified within the query are included. Cisco EnergyWise names are discussed in Cisco EnergyWise Name.

levellevel

This mandatory parameter specifies the Cisco EnergyWise level to be set for the members which match the filters within the query. The values of the Cisco EnergyWise level ranges from 0 through 10, as shown in Table 13.

{all | consumer | meter | producer}

This optional parameter specifies the category of device which to which the Cisco EnergyWise query applies. The default value is consumer, which applies to domain members which are considered to be consumers of power, such as routers, switches, router modules, and PoE-enabled switch ports. Note that this option only appears for devices which support Cisco EnergyWise Phase 2.5. Table 8 discusses the meaning of each of the categories.

timeouttimeout

This optional parameter can be used to specify the length of inactivity time from query replies that a sending domain member will detect to consider the query ended. The default value is six seconds. The timeout value can range from 1 to 180 seconds. For example, if the timeout value is set to 10 seconds, then if there is a 10 second timeout period of no replies from the domain, then the query will end. For larger Cisco EnergyWise domains consisting of multiple switches or switch stacks, the timeout value may need to be increased to ensure that all domain members have sufficient time to receive, execute, and reply to the Cisco EnergyWise query.

Cisco EnergyWise Query Examples

The following examples show how Cisco EnergyWise queries may be used to shut down and enable the PoE to switch ports which support IP phones within a given Cisco EnergyWise domain. Example 37 shows both the global and the interface-level Cisco EnergyWise configurations of a Catalyst 4500 Series switch (me-westcamp-1) and a Catalyst 3560 Series switch (me-westipvs-2) used in this example.

As can be seen, both switches are members of the same Cisco EnergyWise domain named WestCampus. Interfaces GigabitEthernet3/4 and FastEthernet0/48 have been configured with the Cisco EnergyWise importance of 50 and the keyword of "phone" indicating that the switch ports both support IP phones.

Shutting Down PoE to Switch Ports with Cisco EnergyWise Query

Figure 12 shows an example in which a Cisco EnergyWise query is issued using attribute filters to set power of all PoE-enabled IP phones within the domain to a shut down mode (Level 0):

The level of 0 within the command removes PoE to members which match the filters. Note that this command can be issued from either switch within the Cisco EnergyWise domain with the same result.

Figure 12 Shutting Down PoE to Switch Ports Which Support IP Phones

The Cisco EnergyWise protocol distributes this command to every other member of the domain. In this case, the command is forwarded to the Catalyst 4500 Series switch, me-westcamp-1. The command instructs each domain member to match on members (switch ports for this example) which have an importance of 50 or below and match the keyword "phone". Once the match as been made, the command instructs the switch to set the Cisco EnergyWise level to 0 for all matching members. In this case, the switch ports GigabitEthernet3/4 on the Catalyst 4500 Series switch and the FastEthernet0/48 port on the Catalyst 3560 Series switch match. PoE is therefore turned off for these ports, causing the IP phones to power down. The Cisco EnergyWise protocol forwards the results of the command back to the initiating switch, which then aggregates and displays the results. In the example above the results are:

EnergyWise query, timeout is 6 seconds:

!!

Success rate is (2/2) setting entities

Queried: 2 Responded: 2 Time: 4.97 seconds

This provides an indication to the network administrator that the command was successful, that two devices matched the filters provided within the command, and that it took approximately 4.97 seconds to complete.

To verify that power was removed from members which have an importance of 50 or below and match the keyword "phone", the network administrator can run a collect query using the same attribute filters. An example of the command for the collect query is:

Additionally, the show energywise usage children command can be run on each switch to confirm that power is no longer being supplied to the child domain members, as shown in Example 38.

Example 38 Output From the show energywise usage children Command After Setting Power Level to 0

me-westcamp-1#show energywise usage children

Interface Name Usage Caliber

--------- ---- _____ _______

...

Gi3/4 Gi3.4 0.0 (W) unknown

...

me-westipvs-2#show energywise usage children

Interface Name Usage Category Caliber

...

Fa0/48 Fa0.48 0.0 (W) consumer presumed

...

The output shown in Example 38 indicates a power usage of 0.0 Watts for the interfaces after the command has been run. Note also that since the PoE was removed from the interfaces, the IP phones are now down. CDP can therefore no longer identify the devices attached to the switch ports. Therefore, the Cisco EnergyWise names for the ports are defaulted back to the abbreviations of the interface.

A Cisco EnergyWise query which is used to remove power from a PoE-enabled switch port is a "one-time" occurrence. In other words, a switch port remains in that state until one of the following occurs:

•A new Cisco EnergyWise query is received which sets the power level to a value which supplies PoE to the attached device.

•PoE is enabled with an administrative-level Cisco EnergyWise command.

•PoE is enabled through a recurring event

Enabling PoE to Switch Ports with Cisco EnergyWise Query

Figure 13 shows an example in which a Cisco EnergyWise query is issued using attribute filters to set current power usage of all PoE-enabled IP phones within the domain to a full power mode (Level 10).

A level of 10 enables PoE to members which match the filters within the command.

Figure 13 Enabling PoE to Switch Ports Which Support IP Phones

Again, the Cisco EnergyWise protocol distributes this command to every other member of the domain. In this case, the command is forwarded to the Catalyst 4500 Series switch, me-westcamp-1. The command instructs each domain member to match on domain members which have an importance of 50 or below and match the keyword "phone". Once the match as been made, the command instructs the switch to set the Cisco EnergyWise level to 10 for all matching domain members. In this case, the switch ports GigabitEthernet3/4 on the Catalyst 4500 Series switch and the FastEthernet0/48 port on the Catalyst 3560 Series switch match. PoE is therefore enabled to full power for these ports, causing the IP phones to power up. The Cisco EnergyWise protocol forwards the results of the command back to the initiating switch, which then aggregates and displays the results. In the example above the results are:

EnergyWise query, timeout is 6 seconds:

!!

Success rate is (2/2) setting entities

Queried: 2 Responded: 2 Time: 4.424 seconds

This provides an indication to the network administrator that the command was successful, that two devices matched the filters provided within the command, and that it took approximately 4.424 seconds to complete.

Again, to verify that PoE is turned on to members which have an importance of 50 or below and match the keyword "phone", the network administrator can run a collect query using the same filters. The use of queries for collecting power information is discussed in Monitoring Power with Cisco EnergyWise Query Commands.

Additionally, the show energywise usage children command can be run on each switch to confirm that power is now being supplied to the child domain members, as shown in Example 39.

Example 39 Output From the show energywise usage children Command After Setting Power Level to 10

me-westcamp-1#show energywise usage children

Interface Name Usage Caliber

--------- ---- _____ _______

...

Gi3/4 SEP0018BA722853 7.79 (W) trusted

...

me-westipvs-2#show energywise usage children

Interface Name Usage Category Caliber

...

Fa0/48 SEPE80462EA85FD 14.38(W) consumer trusted

...

The output shown in Example 39 indicates a power usage of 7.79 Watts for interface GigabitEthernet3/4 on the Catalyst 4500 Series switch, me-westcamp-1, after the command has been run. Likewise, it shows a power usage of 14.38 Watts for interface FastEthernet0/48 on the Catalyst 3560 Series switch, me-westipvs-2. Since the IP phones are now powered up, CDP can identify the devices attached to the switch ports. Therefore, the Cisco EnergyWise names now appear in the output, corresponding to the CDP device IDs of the two IP phones.

Disabling Cisco EnergyWise Query Set Commands

When used to set power levels of PoE-enabled switch ports and ISR G2 modules, Cisco EnergyWise queries can be a powerful administrative tool to efficiently control hundreds of devices simultaneously. However, their use also presents an additional security concern. Unintentional or malicious use of Cisco EnergyWise queries to set power levels could lead to a denial-of-service of attached PoE devices, including IP phones and wireless LAN access points. Therefore, it is strongly recommended to utilize the ntp-shared-secret domain security mode when configuring any Cisco EnergyWise domain in which queries may be used to set power levels. This includes timestamp information within Cisco EnergyWise queries, which provides additional protection. This is discussed in Enabling Cisco EnergyWise on Cisco Platforms. The use of strong passwords for all Cisco EnergyWise secrets is highly recommended as well. Likewise, it is recommended to utilize a centralized authentication mechanism with multiple levels of access and an audit trail, such as the use of TACACS+, for administrative access to infrastructure devices such as switches and routers, which could then be used to issue Cisco EnergyWise queries which set power levels.

By default, network infrastructure devices allow the use of Cisco EnergyWise queries which set power levels. For implementations in which the network administrator will be using Cisco EnergyWise solely for monitoring power usage, it is recommended to disable the ability for Cisco EnergyWise queries to set power levels. This can be accomplished for each domain member with the following global configuration-level command:

no energywise allow query set

The ability to set Cisco EnergyWise power levels can also be controlled at the interface level. If the network administrator has particular switch ports which they do not want Cisco EnergyWise to ever be able to control power levels, the following command can be issued, using a GigabitEthernet switch port as an example:

interface GigabitEthernetX/X

no energywise allow query set

This may be useful if the network administrator has switch ports with attached IP phones which they want to control PoE, as well as switch ports with attached wireless LAN access points which they want PoE to always be on.

Implications of Controlling Power Usage with Cisco EnergyWise

The network administrator should note that removing power to a PoE-enabled switch port by any one of the Cisco EnergyWise methods discussed in the previous sections does not administratively disable the switch port itself. The switch port always remains administratively enabled. If power is removed from a switch port and if the device connected to the switch port requires PoE, the switch port appears to be down from both an interface and line protocol perspective. This is highlighted in bold in Example 40.

If the Cisco EnergyWise level for a Catalyst switch port or ISR G2 module has been set to Level 0, Shut Down, through a configuration-level command, that change is visible within the configuration, as shown in Example 32. However, if Cisco EnergyWise level has been set to Level 0, Shut Down, through either a recurring event or through a Cisco EnergyWise query, the configuration of the switch is not modified. However, the network administrator can issue a show power inline command on the particular interface in question to determine if PoE has been administratively disabled (see Example 41).

Example 41 Determining Power Status with the show power inline GigabitEthernetX/X Command

As can be seen from Example 41, the Admin status of inline power for interface GigabitEthernet3/4 is "off". When inline power is enabled, this would normally appear with an Admin status of "auto".

Any Cisco IP phones connected to switch ports in which PoE has been removed with Cisco EnergyWise may also appear to be down within CUCM. Existing network management applications which have no Cisco EnergyWise visibility may not be able to differentiate whether a device is experiencing an outage or whether the device was intentionally powered off through Cisco EnergyWise configuration.

Note See Appendix C—Important Notice. Cisco EnergyWise enables you to reduce energy consumption in your network by turning off the power to devices when they are not in use. If IP phones are part of your network, they can also be turned off through Cisco EnergyWise, in which case calls cannot be made or received and the phones cannot be turned on except by the network administrator or according to rules established in Cisco EnergyWise by the network administrator. Laws in the location of your network might require phones to remain available for emergencies. It is your responsibility to identify the laws which apply and to comply with them. Even in the absence of a law, we strongly recommend that you designate certain phones which will always be on and available to make and receive emergency calls. These phones should be clearly identified and all employees or others who might require emergency access to make or receive calls should be informed of the availability of these phones.

Further, if a device such as a PC is daisy-chained off of an IP phone, powering down the IP phone isolates the PC from the network. This may make it impossible to reach the PC to power it down or back up through applications such as the JouleX Energy Manager, unless the IP phone is first powered up. Should an end user need to come in during off-hours, the network administrator must make some provisions regarding how the end user overrides existing schedules and places a request to power on their IP phone and PC. Since the end user's IP phone is powered down, they cannot place a call from that phone to activate the IP phone and PC. Likewise, if the PC is isolated from the network because the IP phone is powered down, they cannot access any application through a Web page from that PC to enable their IP phone and PC.

Ultimately, the network administrator must weigh the benefits derived from power savings through actively controlling power to PoE devices, such as IP phones, against the availability requirements of end users and local regulations.

Non-Cisco EnergyWise Power Saving Features

The following section examines additional features and/or functionality which can provide additional incremental power savings within the network infrastructure. These features and/or functionality can be deployed alongside Cisco EnergyWise technology or independently of it.

CUCM Power Save Mode

The Cisco Unified Communications Manager (CUCM) functions as the call signaling control platform for Cisco IP telephony deployments. In addition to call signaling control, CUCM also provides centralized management of the configuration of IP phones deployed throughout the network infrastructure. One of the features supported through this configuration is the ability to power off the display on many IP phone models. This feature is known as Power Save mode.

Figure 14 shows an example of the configuration of Power Save mode on a Cisco IP phone.

Figure 14 Example Configuration of Power Save Mode on CUCM

As can be seen in Figure 14, the network administrator first configures the days in which the display is not active by highlighting those days in the Days Display Not Active field. For those days in which the display is active, the network administrator then configures the time (in 24 hour format) at which the display will come on and the length of time (in hours and minutes) which the display remains on. This is done through the Display on Time field and the Display On Duration field, respectively. Finally, for those days in which the display is not active, the display turns on temporarily when any key on the IP phone is touched. The Display Idle Timeout field determines how long the display remains on before turning off again.

The choice of when to implement Power Save mode is dependent upon the business requirements, regulatory requirements, and preferences of the given organization and will directly determine the amount of power savings the organization experiences. The amount of power saved when implementing the Power Save mode varies based on the IP phone model, but is generally less than 1 Watt per phone. However, multiplied across all the IP phones within a given organization, the incremental power savings may have some impact on overall power usage of IT infrastructure.

In Figure 14, the display on the IP phone has been set to be inactive every day of the week. Hence, when a person uses the IP phone for a call, they touch any button, which activates the display temporarily. Typically, the display becomes active again in under a second. When the call is done, the display goes inactive after sitting idle for 15 minutes. For those organizations whose preferences, regulatory requirements, or business needs require their IP phone displays to be active during normal business hours, the settings can be modified such that the displays are inactive on weekends, when nobody is in the office. Also, the displays can be set to come on in the morning, for instance at 7:00 AM, and stay on all day, for example for 12 hours until 7:00 PM. The organization may still realize incremental power savings from the displays of all the IP phones being powered off for half of the day during the normal business week and the full day during the weekends. The network administrator should note that the IP phone is fully active while in Power Save mode. In other words, the IP phone is active within CUCM and is able to send and receive calls. Likewise, the switch port to which the IP Phone is connected remains up from both the line protocol and administrative status.

CUCM Power Save Plus Mode

A new CUCM feature, called Power Save Plus mode, allows CUCM to place IP phones into a deeper sleep mode based on scheduled times. This feature is supported with IP phone load 9.2(1) for third-generation non-SIP IP 79xx series phones and all IP 69xx, 89xx, and 99xx series phones. In addition, IP phone 69xx, 89xx, and 99xx models support the capability for the end user to wake up their phone from the deep sleep mode without requiring a centralized mechanism for overriding the schedule. A future version of this design guide will cover this feature in detail.

Catalyst Switch Port Power Savings

Newer models of Catalyst access switches, including the Catalyst 3750X Series, Catalyst 3560X Series, and Catalyst 2960S Series support a new feature which allows the physical interface of the switch port to go into a lower power mode when the physical link is down. This is a feature of the switch hardware, separate from IEEE 802.3az. This results in lower overall power utilization of the switch chassis when not all of the switch ports are up and active. Note that this is separate from PoE supplied to the switch port.

This advantage of this feature can be realized in one of two ways today. First, organizations often have unused switch ports on access switches within wiring closets because switches typically come with fixed switch port counts, such as 24 ports or 48 ports, excluding uplink ports. Not all ports are immediately utilized when implementing a new switch within a new wiring closet, adding another switch to an existing switch stack, or upgrading from a 24-port to a 48-port switch. With newer Catalyst switch platforms, these unused switch ports result in less overall power drawn by the switch itself (regardless of whether the switch port is administratively shut down or not). Testing on a Catalyst 3560X Series switch has shown a decrease in power usage of approximately 0.5 - 0.6 Watts for each switch port which is unused (link down) on the chassis. Note that the power usage of a newer Catalyst switch platform may, in typical operation, be lower than what datasheets show to be the minimum power usage of the switch. This is often because the testing for datasheets is done with all switch ports up and active and does not take account of the ability of switch port physical hardware to go into a lower power mode in newer Catalyst switch platforms.

Second, in the future, Cisco EnergyWise technology will be able to make use of the new Power Save Plus mode of Cisco IP phones to utilize less overall power per switch port. With Power Save Plus mode, IP phones themselves will be able to go into deeper sleep mode, utilizing even less power than with Power Save mode. In addition, the switch port itself will go into a link down state during Power Save Plus mode. For the newer Catalyst 3750X Series, Catalyst 3560X Series, and the Catalyst 2960S Series switches, this will result in additional power savings per switch port, on top of the already increased power savings gained from the IP phone going into a deeper sleep mode with Power Save Plus mode.

Cisco EnergyWise Protocol Operation

This section discusses the operation of the Cisco EnergyWise protocol over an IP network infrastructure. The Cisco EnergyWise protocol supports two main functions, neighbor discovery and queries. The following sections detail how each function operates from a network perspective. Additionally, this section discusses Management API (MAPI), SNMP, and Network Time Protocol flows.

Cisco EnergyWise Neighbor Discovery Process

The Cisco EnergyWise neighbor discovery process is the mechanism by which domain members discover each other and populate their Cisco EnergyWise neighbor tables. Cisco EnergyWise queries can subsequently be distributed to all domain members using the neighbor relationships to monitor and control the power usage of devices within a domain. Cisco EnergyWise domain members automatically discover their neighbors through one of two mechanisms:

•Cisco EnergyWise UDP broadcast packet

•Cisco EnergyWise CDP packets

UDP broadcast packets are automatically sent out switch ports which support Cisco EnergyWise, regardless of whether the interfaces are configured with the no energywise interface-level command. CDP packets are sent when CDP is configured for the switch ports. Both are also referred to generically as Cisco EnergyWise discovery packets within this document. Note that Cisco EnergyWise neighbors can also be statically configured on domain members when devices within a single Cisco EnergyWise domain are not all physically contiguous. This was discussed in Static Neighbors.

Cisco EnergyWise Neighbor Discovery Using UDP Broadcast

Figure 15 shows an example network illustrating the operation of the Cisco EnergyWise protocol using UDP packets for the neighbor discovery process.

The discovery process begins when a domain member sends out a Cisco EnergyWise UDP broadcast packet. Cisco EnergyWise UDP broadcast packets are IP packets which are sent to the MAC layer broadcast address (FF:FF:FF:FF:FF:FF in the case of Ethernet) and the IP broadcast address (255.255.255.255) as opposed to a subnet broadcast address. A random high order source UDP port is chosen, along with the destination default Cisco EnergyWise UDP port of 43440. The destination UDP port can be changed from the default when enabling Cisco EnergyWise on the device. See Global Configuration.

Cisco EnergyWise UDP broadcast packets are sourced by a Switched Virtual Interface (SVI) on a switch and sent out every switch port which belongs to the same VLAN as the SVI. Cisco EnergyWise UDP broadcast packets are also sourced by Layer 3 routed interfaces on a switch (switch ports configured with an IP address). Neighboring domain members reply with a unicast UDP packet. Once a device is configured with a domain the device periodically sends out broadcast packets. Figure 15 shows only one switch sending out broadcast packets for simplicity. Cisco EnergyWise UDP broadcast packets are useful for discovering domain members that may not have a direct connection like a CDP neighbor.

Note UDP forwarding can be used to join members of a domain which are separated across core switches which are not configured for Cisco EnergyWise. This is an alternative to configuring static EnergyWise neighbors.

Cisco EnergyWise Neighbor Discovery Using CDP

In contrast to UDP broadcast packets, CDP packets are non-IP packets. In the case of Ethernet, they are sent to the MAC layer address of 01:00:0C:CC:CC:CC. When CDP is enabled on a switch, CDP packets are periodically sent out from each switch port by default. Cisco EnergyWise CDP packets are simply CDP packets which contain a specific TLV which contains Cisco EnergyWise information. The TLV can be identified in a data trace through the hex code of 0x001D. Cisco EnergyWise CDP packets are useful for discovering neighbors who are adjacent to each other over a Layer 2 connection. Figure 16 shows the same example network illustrating the operation of the Cisco EnergyWise protocol using CDP packets for the neighbor discovery process.

Cisco EnergyWise Neighbor Tables

Based on the Cisco EnergyWise discovery exchanges, each domain member builds up a table of dynamic neighbors for the Cisco EnergyWise domain to which it belongs. The table can be displayed with the show energywise neighbors administrative level CLI command (see Example 42).

The table lists the names along with IDs assigned to each neighbor, the IP address and port which can be used to reach the particular neighbor, how the neighbor was learned (through UDP or CDP), and the capabilities of the particular neighbor (switch, router, etc.).

The dynamic members of the table can be cleared with the clear energywise neighbors administrative level CLI command. This causes the domain member to immediately send out new Cisco EnergyWise discovery packets. Neighboring domain members receive the discovery packets and reply with a unicast UDP packet. In this manner, domain members rebuild their neighbor tables. The domain member which sent out the initial discovery packets continues to periodically send out additional discovery packets—backing off the time between sending out the UDP broadcasts and CDP packets which contain Cisco EnergyWise TLVs. On average a set of discovery packets is sent approximately 150 seconds after the initial set of discovery packets, 300 seconds after the second set of discovery packets, 600 seconds after the third set of discovery packets, and 1,200 seconds after the fourth set of discovery packets. Each domain member which has Cisco EnergyWise enabled on it continues to periodically send out UDP broadcast packets and CDP packets with Cisco EnergyWise TLVs approximately every 1,200 seconds when there are no neighbor changes. The overall amount of traffic generated is considered negligible since the UDP broadcast discovery and UDP unicast reply packets are typically between 200-300 bytes in length. Likewise the Cisco EnergyWise TLV information only adds approximately 200-300 bytes more length to existing CDP packets.

Cisco EnergyWise Query Process

As previously discussed in Monitoring Power and Controlling Power, Cisco EnergyWise query commands are administrative level CLI commands, issued from one member within a particular Cisco EnergyWise domain, which can be used to collect power information from all members of the Cisco EnergyWise domain. Figure 17 shows an example network which illustrates the operation of the Cisco EnergyWise protocol when an energywise query command is issued on one of the Catalyst switches within a Cisco EnergyWise domain.

In this example, an administrator is logged into one of the access-layer switches through TELNET or SSH and issues the following administrative-level CLI command:

energywise query importance 100 name * collect usage

This causes the access layer switch to send out a directed (unicast) UDP query packet, with destination UDP port of 43440 by default, to each of its neighbors within the Cisco EnergyWise domain. The query requests them to collect and return Cisco EnergyWise information for devices with any name (the * indicates a wildcard of any name) and any importance (the 100 indicates any importance from 1-100). In Figure 17, the access layer switch has the distribution layer switch as its Cisco EnergyWise neighbor. The distribution layer switch pair receives the directed UDP query. In turn, it propagates a directed UDP query to each other domain member within its list of Cisco EnergyWise neighbors. In Figure 17, the directed UDP query is propagated to the second access layer switch. In this manner, all domain members for the particular Cisco EnergyWise domain receive the query.

Each domain member then collects the Cisco EnergyWise information for its PoE ports and the device itself (chassis or multiple chassis for a switch stack) and forwards the information directly back to the domain member which originated the query. In the example above, both the second access layer switch and the distribution layer switch forward the information directly back to the originating access layer switch within one or more UDP packets with destination port 43440. The responses can be several packets long, each of which can exceed 1,300 bytes in size, depending upon the number of switch ports which support PoE and whether the switch ports are configured with Cisco EnergyWise enabled. The originating domain member must then process all received packets from all other domain members, add the energy information for all of its switch ports, its chassis, and endpoints, then finally send the output back to the command line interface.

Cisco EnergyWise Management Traffic Flows

Cisco EnergyWise management traffic flows are data flows between one or more Cisco EnergyWise domain members and a management application. Currently management applications make use of either the Cisco EnergyWise Toolkit Management API (MAPI) or SNMP to monitor or control power usage on Cisco EnergyWise domain members.

SNMP Flows

Flows generated from SNMP GET and SET commands operate over UDP port 161. SNMP is a command/response type of protocol which operates on a single device at a time. There are currently three versions of SNMP commonly deployed—SNMPv1, SNMPv2c, and SNMPv3. The security model used by SNMPv1 and SNMPv2c consists of authentication only, utilizing community strings (read only and read/write) which are sent in clear text within SNMP messages. Because of this, SNMPv1 and SNMPv2c are considered inherently insecure and read/write capability should be used with caution, even over private networks. A primary benefit of SNMPv3 is its security model, which eliminates the community strings of SNMPv1 and SNMPv2c. SNMPv3 supports message integrity, authentication, and encryption of messages. Therefore it is recommended to implement SNMPv3. Figure 18 shows an example of the operation of SNMP when used to collect Cisco EnergyWise information from various switches within a domain.

As can be seen, the management application must send individual SNMP SET or GET commands to each domain member, utilizing the CISCO-ENERGYWISE-MIB, to collect information for the entire domain. Further MIB information can be found through the Cisco MIB Locator at: http://tools.cisco.com/ITDIT/MIBS/servlet/index. Note that while the MIB is an alternative, for applications the Cisco EnergyWise Toolkit Management API is the recommended application interface.

Cisco EnergyWise Management API Flows

A domain member can have a management port activated. By default this is the Cisco EnergyWise IANA assigned TCP port 43440. Applications using the MAPI can connect to the management port configured on a domain member. Note that this is different from the Cisco EnergyWise protocol which uses UDP port 43440 by default. Cisco EnergyWise MAPI flows have their own internal security consisting of the use of encryption and authentication hashes. Cisco EnergyWise queries operate somewhat differently when a management application which supports the Cisco EnergyWise MAPI, is involved. Figure 19 shows an example of the operation of the Cisco EnergyWise MAPI when used to collect Cisco EnergyWise power usage from various switches within a domain.

The management application first establishes a TCP session (through destination port 43440) to a domain member to collect information for the entire domain. The domain member to which the management application establishes the MAPI session returns information matching the Cisco EnergyWise query for itself and its child members by way of this session. The domain member also uses the Cisco EnergyWise protocol (UDP port 43440) to distribute the query to the rest of the members of the domain. Each of the other domain members then initiates a TCP session back to the management application using a port selected at random by the session for this query. Information is then forwarded back to the management application by way of these TCP sessions.

This highlights two primary benefits of the Cisco EnergyWise protocol:

•The network itself supplies power information and control for both the infrastructure and PoE attached devices.

•When one query is sent into the domain, it is replicated throughout the domain in parallel versus sending a query to every individual device.

An example of an application which uses the Cisco EnergyWise MAPI is Cisco Prime LMS, discussed in the next section.

Note The behavior of the Cisco EnergyWise MAPI discussed in this section is based on Cisco EnergyWise Phase 2.5 code running on Catalyst switches as well as Cisco Prime LMS 4.1. If multiple members of a domain are configured with a management port, the domain member to which Cisco Prime LMS establishes a session cannot be selected by the network administrator. Cisco Prime LMS selects one of the domain members for you. Also, Cisco Prime LMS 4.1 cannot be configured to use a management port other than TCP port 43440.

Network Time Protocol Flows

The Network Time Protocol (NTP) is used for synchronizing device clocks across an IP-based computer network. NTP utilizes uses UDP port 123 for the distribution of time (typically Coordinated Universal Time or UTC) in a hierarchical tree structure. Clocks are synchronized based on their Stratum level, which indicates their precision. Stratum 0 clocks refer to devices that keep highly accurate time, such as atomic clocks or GPS clocks. Stratum 1 clocks refer to servers that receive time through directly connected stratum 0 clocks. Stratum 2 clocks refer to computers that receive time from Stratum 1 computers, and so forth.

NTP is not required for Cisco EnergyWise. If you have NTP already turned on within the network infrastructure, you can specify a stronger domain security mode of ntp-shared-secret that helps to mitigate DoS type exploits of Cisco EnergyWise. However, the domain security mode of shared-secret ensures against replay attacks.

From a Cisco EnergyWise perspective, NTP synchronization of the network infrastructure is required if the domain security of ntp-shared-secret is selected. If you use NTP and you select ntp-shared-secret in a domain, you must ensure that your clocks do not drift more than 30 seconds or the Cisco EnergyWise communication with a domain becomes unreliable. The domain security mode is set when Cisco EnergyWise is enabled on infrastructure devices as discussed in Global Configuration.

If the domain security mode is set for shared-secret only, NTP synchronization of the network infrastructure is still recommended when recurring events are configured on switch and router devices. Each device executes recurring events configured for its PoE-enabled switch ports or Cisco EnergyWise supported modules independently, based upon its internal clock. If time is not synchronized across network infrastructure devices when a policy is pushed out from a management application, such as Cisco Prime LMS, then PoE-enabled devices such as IP phones may power on and off at incorrect times of the day. This could occur, unless the network administrator has manually verified that he system clock of each network infrastructure device is set correctly. Further, unless the network infrastructure device has a built-in hardware clock, the device may not maintain the configured time when reloaded. Therefore, it is often administratively more feasible to simply enable NTP across the network infrastructure.

UDP Protocol used for Cisco EnergyWise queries. Routed across the network infrastructure between members within a Cisco EnergyWise domain.

TCP Port 43440

Protocol used for the Cisco EnergyWise management API (MAPI). Routed across the network infrastructure from one or more domain members to a Cisco EnergyWise management application such as Cisco Prime LMS.

UDP Unicast to Port 161

SNMP requests and responses. Routed across the network infrastructure from one or more Cisco EnergyWise domain members to a management application.

UDP Unicast to Port 123

NTP for time synchronization of infrastructure devices. Routed across the network infrastructure between devices which support the various Stratum level clocks.

Table 18 summarizes the routing requirements required for Cisco EnergyWise operation across various parts of the network infrastructure.

Table 18 Routing Requirements for Cisco EnergyWise

Requirement

Description

Layer 3 reachability between the IP address used for Cisco EnergyWise on all domain members.

Necessary for the distribution of Cisco EnergyWise queries to all members of the domain.

Layer 3 reachability between the IP address used for Cisco EnergyWise on all domain members and the management application such as Cisco Prime LMS 4.1.

Necessary for the operation of the Cisco EnergyWise MAPI.

Cisco Prime LMS

The top tier of the Cisco EnergyWise architecture consists of management applications. Management applications have several advantages over the CLI interface discussed in the previous sections, including:

•Ease of provisioning Cisco EnergyWise functionality throughout the network infrastructure

•Historical reporting of power usage of infrastructure and endpoints

•Policy control which extends across multiple devices and domains

Cisco currently provides the Cisco Prime LMS application. Cisco Prime LMS is positioned for control and monitoring of power for deployments consisting of Cisco infrastructure devices such as Catalyst switches and ISR G2 routers. Cisco Prime LMS version 4.1 is a new release of Cisco EnergyWise support. Not all features and configuration options in Cisco EnergyWise are available. This section goes over some of the issues and workaorunds.

Platform and IOS Software Support

Table 19 shows the platforms which have been tested for support with Cisco Prime LMS 4.1 and also with the EnergyWise Work Center within LMS 4.1 for this design guide.

Table 19 Platforms and Software Revisions Tested with LMS 4.1 and the EnergyWise Work Center

No. Catalyst 2795 Series platforms have not appeared within the EnergyWise Work Center of LMS 4.0.1 or LMS 4.1; although the platform supports Cisco EnergyWise (rel2_6)1.1.24.

Network Module (NME-XD-24ES-1S-P)

12.2(58)SE1

Yes

Yes

Cisco 2951 Series ISR

15.1(4)M

Yes

Yes

Cisco 2921 Series ISR

15.1(4)M

Yes

Yes

LMS Configuration of Cisco EnergyWise on Infrastructure Devices

The following section discusses the configuration of Cisco EnergyWise on infrastructure devices through Cisco Prime LMS. Functionality differences between the CLI method of configuration, discussed in Cisco EnergyWise Domain Design and Configuration, are noted within the discussion.

Readiness Assessment

To configure Cisco EnergyWise on an infrastructure device, it must first appear within the Readiness Assessment window of the EnergyWise Work Center within LMS. This means that the device has been discovered and added to the LMS database. Further the device must be considered an "EnergyWise capable device"—meaning it must be a hardware platform and IOS software revision supported by the EnergyWise Work Center within LMS. Under the EnergyWise Work Center, select Readiness Assessment to bring up the Readiness Assessment window. An example is shown in Figure 20.

Figure 20 Cisco EnergyWise Readiness Assessment Window within LMS

The Readiness Assessment window categorizes the infrastructure devices both graphically and in a list:

•EnergyWise Enabled—The device is capable in terms of hardware platform and software levels of supporting Cisco EnergyWise and Cisco EnergyWise has been configured (enabled) on it.

•EnergyWise Capable—The device is capable in terms of hardware platform and software levels of supporting Cisco EnergyWise, however Cisco EnergyWise has not yet been configured (enabled) on it.

•Software Incapable—The device is capable in terms of hardware platform, but does not have the correct software level to support Cisco EnergyWise. In this case, the infrastructure device needs to be upgraded to a software revision which supports Cisco EnergyWise before it appears as an EnergyWise Capable device.

Note that hardware platforms which do not support Cisco EnergyWise do not show up at all within the EnergyWise Work Center within LMS.

Enabling Cisco EnergyWise on Infrastructure Devices

Enabling Cisco EnergyWise on an infrastructure device within LMS 4.1 consists of four steps:

1. Under the EnergyWise Work Center, select Configure > Enable EnergyWise on Devices. This brings up the Enable EnergyWise on Devices window. This window provides the network administrator with a view of devices known to the EnergyWise Work Center within LMS which Cisco EnergyWise can be enabled on, but currently have no Cisco EnergyWise configuration. Select the device on which Cisco EnergyWise is to be enabled.

2. Select the domain to which the device is to be placed. Optionally create the domain to which the device is to be placed. The next section discusses the creation of domains with LMS.

3. Optionally configure Cisco EnergyWise attributes (entity name, role, keyword, and importance) which apply to the device. Note that from a CLI perspective, this configures attributes at the global-level for the switch or router. There is no option to add endpoint attributes (corresponding to attributes at the interface-level for the switch or router) when enabling Cisco EnergyWise on an infrastructure device.

4. Click Next to schedule the configuration change on the device or devices either immediately or in the future. At this point, the configuration changes which will be deployed to the device can be previewed. Note that scheduling the configuration change creates a Cisco EnergyWise job which can be monitored to ensure it was successfully run.

Changing the domain to which a device belongs or removing the Cisco EnergyWise configuration from a device follows roughly the same procedure:

1. Under the EnergyWise Work Center, select Configure > Manage Devices. This brings up the Manage Devices window. This window provides the network administrator with a view of devices known to the EnergyWise Work Center within LMS.

2. Select the device which currently has Cisco EnergyWise enabled.

3. Edit the device to either change the domain or select none for the domain.

4. Optionally modify Cisco EnergyWise attributes which apply to the device if needed.

5. Schedule the configuration change on the device or devices either immediately or in the future.

Domain Configuration

1. Under the EnergyWise Work Center, select Configure > Manage Domains. This brings up the Manage EnergyWise Domains window. This window provides the network administrator with a view of the existing domains known to the EnergyWise Work Center within LMS. Click Create.

2. This brings up the Create Domain pop-up window. An example of the window is shown in Figure 21. Fill in the necessary fields which include:

–Domain name

–Brief description of the domain

–Option to encrypt the passwords (secrets)

–Option to configure the ntp-shared-secret security level for the domain and the domain secret (called the NTP secret, when the ntp-shared-secret security level is selected)

–Management secret

–Endpoint secret

–Option to configure an NTP server on the devices added to the domain, based either on its hostname or IP address

3. Click Save. The new domain should now appear within the Manage EnergyWise Domains window. Devices can now be assigned to it.

Figure 21 Cisco EnergyWise Domain Configuration from within LMS

Unlike the CLI interface on network infrastructure devices, the EnergyWise Work Center within LMS 4.1 (and also LMS 4.0.1) can only configure Cisco EnergyWise domains without the ability to specify an IP address or interface as the source for Cisco EnergyWise packets.

Example 43 shows the output from a switch configuration when LMS is used to configure the Cisco EnergyWise domain, WestCampus2, using encrypted passwords, the ntp-shared-secret security level, a keyword of "infrastructure", and an importance of 100.

With the configuration in Example 43, when Cisco EnergyWise packets are sent by the router or switch, the device automatically chooses one IP address in its configuration as the source address for Cisco EnergyWise traffic. There are two reasons this may not be desirable. First, for security purposes, network administrators sometimes like to control access to and from a device for network management traffic. Access control is often specified through an access-control list (ACL) which allows particular IP addresses and ports. If the source address of a Cisco EnergyWise domain neighbor cannot be specified, then an ACL cannot be used to restrict traffic only from legitimate Cisco EnergyWise neighbors. Note that the Cisco EnergyWise protocol has its own internal security mechanisms to validate neighbors, which may reduce this concern somewhat. Also the use of extended ACLs may have an impact on performance on some platforms. Second, the use of VRFs and/or out-of-band management subnets may create problems for the operation of Cisco EnergyWise domains. If the router or switch interface selected as the source for Cisco EnergyWise packets is not routable across the rest of the Cisco EnergyWise domain, then the Cisco EnergyWise protocol may not function correctly within the domain. Hence, it is desirable to allow the network administrator to specify the IP address or interface to be used as the source for Cisco EnergyWise packets.

Note that one workaround for this issue is that the Cisco EnergyWise domain command can be configured manually through the CLI. In other words, the EnergyWise Work Center does not have to be used to enable Cisco EnergyWise on devices which are software capable of supporting Cisco EnergyWise. Enabling Cisco EnergyWise on Cisco Platforms discusses how to do this.

Device Attribute Configuration

Configuring device attributes within LMS 4.1 does not have to be done within the workflow used to enable Cisco EnergyWise on the device. It can be done separately and consists of three steps:

1. Under the EnergyWise Work Center, select Configure > Manage Devices. This brings up the Manage Devices window, which provides the network administrator with a view of the existing infrastructure devices (switches and routers) known to the EnergyWise Work Center within LMS. Select the device or devices on which the Cisco EnergyWise attributes are to be added, deleted, or changed.

2. Select Edit for the device. From the Configure Unique Device Attribute pop-up window, the Domain can be changed or removed. Also the Entity Name, Role, Keywords, and Importance attributes can be modified. An example is shown in Figure 22.

3. Schedule the configuration change on the device or devices either immediately or in the future. At this point, the configuration changes which will be deployed to the device can be previewed. Note that scheduling the configuration change creates a Cisco EnergyWise job which can be monitored to ensure it was successfully run.

Figure 22 Modifying Device Attributes within LMS

Endpoint Attribute Configuration

Configuring endpoint attributes can also be done within LMS 4.1 once Cisco EnergyWise has been enabled on the device and the endpoints are discovered. It consists of these steps:

1. Under the EnergyWise Work Center, select Configure > Configure EnergyWise Attributes on Endpoints. This brings up the Configure EnergyWise Attributes on Endpoints window, which provides the network administrator with a view of the existing infrastructure devices (switches and routers) known to the EnergyWise Work Center within LMS. Select the parent device or devices of the endpoint or endpoints on which the Cisco EnergyWise attributes are to be added, deleted, or changed and select Next.

2. Select the endpoint or endpoints on which the Cisco EnergyWise attributes are to be modified and select Configure to bring up the Configure EnergyWise Attributes pop-up window.

3. From the pop-up window the Entity Name, Entity Role, Entity Keywords, and Entity Importance attributes can be modified. An example is shown in Figure 23.

4. Schedule the configuration change on the device or devices either immediately or in the future. At this point, the configuration changes which will be deployed to the parent device or devices can be previewed. Note that scheduling the configuration change creates a Cisco EnergyWise job which can be monitored to ensure it was successfully run.

Figure 23 Modifying Endpoint Attributes within LMS

The network administrator should note that endpoints are only added to the Cisco EnergyWise Work Center database when the endpoint, such as an IP phone, is attached and running on the switch port. There is no capability to configure a switch port within the EnergyWise Work Center of LMS with endpoint attributes before an endpoint is connected to the switch port. Note that one workaround, if this is needed, is to configure interface-level Cisco EnergyWise attributes manually through the command line interface on switch ports which have no connected devices.

LMS Queries

The EnergyWise Work Center within LMS 4.1 has the ability to issue limited Cisco EnergyWise queries. Cisco EnergyWise queries are limited to the summarization of power usage within a domain for all devices and endpoints or selected devices and endpoints based upon attribute filters. LMS cannot issue queries to immediately return individual power for endpoints. Also, LMS cannot issue queries to set power levels of endpoints. Such queries cause power level changes to occur only once. LMS can only issue policies which result in recurring events. As with the CLI method of issuing queries, Cisco EnergyWise importance, keyword, and name filters are supported. Monitoring Power with Cisco EnergyWise Query Commands discusses the use of Cisco EnergyWise queries for monitoring power usage in detail.

Within LMS, queries can be issued from the Dashboard under the EnergyWise Work Center. Figure 24 shows an example of the Dashboard which includes the section titled EnergyWise - Current Power Consumption, which has been highlighted with a red border in Figure 24.

The query has been issued to summarize power usage for all devices within the WestCampus domain. It accomplishes this by using the wildcard name filter (*) and all devices with importance below 100. The power consumption returned is a single value corresponding to a query which summarizes power usage across all matching devices and endpoints within the domain. In this example the current power consumption is 9,342 Watts.

LMS Device Groupings

To apply policies to manage power usage for endpoints connected to domain members, the endpoints must first be placed into a device grouping. Figure 25 and Figure 26 show the creation of a device grouping for a Cisco EnergyWise domain.

Figure 25 EnergyWise Work Center Device Groupings—Miami Domain

Figure 26 Applicable Endpoints for the MiamiPhones Device Group

The example used in this section groups IP phones into a specific device group for the Miami domain. Note that the Miami domain refers to a branch office location with a Cisco EnergyWise domain in this example. The IP phone endpoints were preconfigured with Cisco EnergyWise keywords of "phone" and "videophone" and a Cisco EnergyWise importance of 50. The example identifies and groups the IP phones within the domain based upon the keyword of "phone" and importance of 50. Note that no policies are applied to the device groupings within this section. Creating device groupings consists of four steps:

1. Under the EnergyWise Work Center, select Configure > Manage Endpoint Groups. This brings up the Manage EnergyWise Endpoint Groups window, which provides the network administrator with a view of the existing endpoint groups known to the EnergyWise Work Center within LMS. Click Create to create a new endpoint group.

2. From the Create Endpoint Group pop-up window, select the domain or domains to which the endpoints belong. Note that as the domain or domains are selected, different keywords, roles, and importance values may appear in the other fields. Select the attributes which will be used to determine the endpoint devices which will be grouped. For example, in Figure 25, the Miami Domain was selected, along with the Keyword of "phone" and an Importance of 50 or below. To set up and run reports, the network administrator must first monitor power usage of the endpoint devices. This is accomplished by checking the box next to "Monitor Power Usage Every". Use the pull down menu to select the monitoring interval. The allowed values are every 30 minutes, every hour, every 2 hours, every 4 hours, or every 8 hours.

3. Click the View Applicable Endpoints button to display the endpoints which correspond to the attributes selected for the endpoint grouping. In Figure 26, the three IP phones listed match the domain of Miami, keyword of "phone", and importance of 50 or below. When done viewing the endpoints, close the Applicable Endpoints pop-up window.

4. Click Save to save the endpoint grouping. It should now appear within the Manage EnergyWise Endpoint Groups window.

Cisco EnergyWise Policies with LMS

As mentioned previously, policies are sets of schedules and schedules include one or more events. LMS policies are implemented as one or more recurring events which are then pushed out to the configuration of network infrastructure devices. However, LMS policies can be applied to multiple infrastructure domain members simultaneously. Hence policies within LMS are more holistic in terms of the network view than recurring events configured on individual domain members.

Configuring LMS Policies

Enabling policies within LMS consists of four steps:

1. Under the EnergyWise Work Center, select Configure > Manage Policies. This brings up the Manage EnergyWise Policies window, which provides the network administrator with a view of the existing policies configured within the EnergyWise Work Center within LMS. Either Create a new policy or select an existing policy (if one has previously been configured) and Edit the policy.

2. This brings up the EnergyWise Policy Configuration pop-up window. An example is shown in Figure 27. Configure a unique policy name which will make sense when applying the policy to devices and optionally configure a brief description. Specific actions within a policy are accomplished by adding events. Select the Add Event button to add an event.

3. This brings up the EnergyWise Event Configuration pop-up window. There are basically four parameters which need to be configured for an event:

a. Specify the power level to be applied to the device or switch port. Currently a power level of 0 shuts down PoE to a switch port, while power levels from 1 to 10 provide PoE to a switch port. Note that over time, additional power settings may be supported.

b. Specify the importance level at or below the level configured to which this event will apply. For example, if this event is to apply to devices at or below an importance of 50, specify a value of 50 in this field.

c. Specify the time in hours and minutes in which this event is to be executed. Keep in mind that there will usually be separate events to power on an IP phone (through the PoE-enabled switch port) and to power off an IP phone at different times of the day and different days of the week, both within the same policy.

d. Specify the days of the week in which this event is to be executed. Again, keep in mind that there will usually be separate events to power on and off IP phones during different days of the week.

4. Continue to add events until the policy is complete. Note also that specific events can be deleted by selecting the event and selecting Delete. Once all of the events have been configured for the policy, click Save to save the policy. The new policy should appear within the Manage EnergyWise Policies window.

Creating a policy does not specify what members (parent and/or children) the policy is to be applied against. That is handled under a different section of the EnergyWise Work Center within LMS. In other words, creation of a policy has no effect on endpoints or infrastructure devices, since nothing is configured on any switches or routers when a policy is created.

Figure 27 shows an example of part of a policy which controls PoE to IP phones.

Figure 27 Example of Policy Configured with LMS

In Figure 27, the first line shows a power level of 0 (shut down) is to be set for all devices with an importance of 50 or below (which has been previously configured for the switch ports which contain IP phones) beginning at midnight (0 hours 0 minutes) every day of the week. The second line shows that a power level of 10 (full power) is to be set for all devices with an importance of 50 or below beginning at 7:00 AM (7 hours 0 minutes) from Monday through Friday. The third line shows that a power level of 0 (shut down) is to be set for all devices with an importance of 50 or below beginning at 7:00 PM (19 hours 0 minutes) from Monday through Friday. These three lines specify part of an overall policy which powers on phones at 7:00 AM and powers them off at 7:00 PM every working day (Monday through Friday). Additional lines (which are not shown in Figure 27) have been added to the policy, powering on phones at 10:00 AM and off at 5:00 PM on weekends (Saturday and Sunday).

Figure 28 is an example of what the configuration looks like, for the first event within the policy above, as it is being configured.

Figure 28 Detailed Configuration of an Event within a Policy

Testing of policy configuration within LMS has shown that LMS is restricted by the fact that specific ranges of day of the month and months of the year cannot be specified within a policy. LMS creates policies which execute periodically every day of the month and every month of the year, with no absolute start or end date. In contrast, recurring events configured through the CLI interface directly on a Catalyst switch or IOS router can be configured with an absolute start date and time through the use of time-ranges. Configuration of recurring events is discussed in detail in Configuring Recurring Events Hence, LMS policies provide slightly less functionality than recurring events configured directly on individual switches and routers. However, as the next section illustrates, LMS makes up for this in terms of ease of deployment of the policy.

Applying LMS Policies

Once device groupings and policies are configured within the EnergyWise Work Center, the policies can be applied to the device groupings. Deploying policies within LMS consists of four steps:

1. From the EnergyWise Work Center, select Configure > Apply EnergyWise Policies. This brings up the EnergyWise Endpoint Groups pane within the Apply EnergyWise Policies to Endpoints window, which provides the network administrator with a view of the existing endpoint groups known to the EnergyWise Work Center within LMS. Select the endpoint group or groups to which the policy is to be applied and click Next.

2. This brings up the EnergyWise Policies pane, which provides the network administrator with a view of the existing policies configured within the EnergyWise Work Center within LMS. Select the policy to apply to the endpoint group and click Next.

3. This brings up the Apply Policies to Endpoints pane. Select the endpoint group which should appear again based on step #1. This should bring up the Assign Policy to Endpoint Group pop-up window. Select the policy which should appear again based on Step 2 and click Save to close the pop-up window.

4. Click Next to Schedule Deployment pane. Schedule the configuration change on the device or devices either immediately or in the future. Note that scheduling the configuration change creates a Cisco EnergyWise job which can be monitored to ensure it was successfully run.

Figure 29 shows an example application of the policy named IP_Phones to the endpoint group named MiamiPhones corresponding to all IP phones within the Miami Cisco EnergyWise domain.

Figure 29 Example of Assigning a Policy to an Endpoint Group

Deployment of the policy above to the endpoint group results in one or more recurring events being configured on each switch port which has an endpoint attached which is a member of the endpoint group. Note that multiple switches across multiple domains may be part of an endpoint group, although for the example above, only one domain was selected for the deployment of the policy.

LMS utilizes the Cron format for configuring recurring events on domain members (switches and routers). It is not capable of using the time-range format. Hence, any policies deployed with LMS cannot start at a future date. To create a policy which starts at a future date, the network administrator must schedule the deployment of the policy for a future date and time within the LMS work flow discussed above.

Example 44 is a configuration fragment that shows examples of the recurring event configured on multiple switches and switch ports resulting from the single policy example above deployed from LMS.

Note that the interface description, Cisco EnergyWise importance, and Cisco EnergyWise keywords were already configured on the interface before application of the recurring event. Other interface-level configuration commands have been removed from the example above for simplicity.

The advantage of implementing policies through LMS is that they provide an administratively efficient means of applying one or more recurring events across endpoints on multiple switches and routers within a single domain or across multiple switches and routers across multiple domains. The network administrator should note that deployment of the policy changes the configuration of the switches and/or routers to which the policy applies. A switch executes an event within a policy that has been applied to a particular switch port when the system clock of the switch matches the time specified within the event. In other words, LMS is only involved with the deployment of the policy, not the actual execution of the policy. Therefore, there are no scalability issues with executing an event within a policy which has been deployed across multiple switches, each with multiple switch ports. Each switch or router autonomously executes the event within the policy once the policy has been deployed.

Note The network administrator should ensure that time is accurate across the network infrastructure to guarantee that the events are executed at the correct time. This is another reason to utilize NTP to synchronize time across the network infrastructure.

LMS Policy Use Considerations

Testing has shown that LMS is currently not capable of removing events once they have been deployed to a particular Catalyst switch or ISR G2 router through a policy. When deploying a policy to a switch within LMS 4.1, the process appears to only add lines to the configuration. The following example highlights this.

This policy provides PoE to the attached phone from 7:00 AM to 7:00 PM during the weekdays and from 10:00 AM to 5:00 PM on weekends.

Replacing a Policy with A New Policy within LMS

Attempting to push a new policy which has a single event—configuring phones to be powered on at all times—simply results in what is shown in Example 46.

Example 46 Attempt to Replace the Initial Deployed Policy with a new Policy

interface GigabitEthernet1/0/11

description CONNECTION TO MIAMI 9951

energywise level 0 recurrence importance 50 at 0 0 * * 0,1,2,3,4,5,6

energywise level 10 recurrence importance 50 at 0 7 * * 1,2,3,4,5

energywise level 0 recurrence importance 50 at 0 19 * * 1,2,3,4,5

energywise level 10 recurrence importance 50 at 0 10 * * 0,6

energywise level 0 recurrence importance 50 at 0 17 * * 0,6

energywise level 10 recurrence importance 50 at 0 0 * * 0,1,2,3,4,5,6

energywise importance 50

energywise keywords phone,videoPhone

Note that LMS just added a new line to the existing configuration (highlighted above), rather than removing the existing configuration first. In other words, LMS simply added a new policy in addition to the existing policy.

Modifying an Existing Policy within LMS—Test #1

Attempting to edit an existing deployed policy by deleting events, adding new events, and pushing the policy to devices again results in what is shown in Example 47.

Example 47 First Attempt to Modify and Existing Policy

interface GigabitEthernet1/0/11

description CONNECTION TO MIAMI 9951

energywise level 0 recurrence importance 50 at 0 0 * * 0,1,2,3,4,5,6

energywise level 10 recurrence importance 50 at 0 7 * * 1,2,3,4,5

energywise level 0 recurrence importance 50 at 0 19 * * 1,2,3,4,5

energywise level 10 recurrence importance 50 at 0 10 * * 0,6

energywise level 0 recurrence importance 50 at 0 17 * * 0,6

energywise level 10 recurrence importance 50 at 0 0 * * 0,1,2,3,4,5,6

energywise level 10 recurrence importance 50 at 0 8 * * 1,2,3,4,5

energywise level 0 recurrence importance 50 at 0 18 * * 1,2,3,4,5

energywise importance 50

energywise keywords phone,videoPhone

Note that LMS simply kept the previous events which powered on the phones at 7:00 AM and powered them off at 7:00 PM during weekdays. However, LMS added new events (highlighted above) to power on the phones at 8:00 AM and power them off at 6:00 PM during weekdays.

Modifying an Existing Policy within LMS—Test #2

Attempting to explicitly change an event from powering the phone on to powering the phone off at a particular time results in what is shown in Example 48.

Example 48 Second Attempt to Modify an Existing Policy

interface GigabitEthernet1/0/11

description CONNECTION TO MIAMI 9951

energywise level 0 recurrence importance 50 at 0 0 * * 0,1,2,3,4,5,6

energywise level 10 recurrence importance 50 at 0 7 * * 1,2,3,4,5

energywise level 0 recurrence importance 50 at 0 19 * * 1,2,3,4,5

energywise level 10 recurrence importance 50 at 0 10 * * 0,6

energywise level 0 recurrence importance 50 at 0 17 * * 0,6

energywise level 10 recurrence importance 50 at 0 0 * * 0,1,2,3,4,5,6

energywise level 10 recurrence importance 50 at 0 8 * * 1,2,3,4,5

energywise level 0 recurrence importance 50 at 0 18 * * 1,2,3,4,5

energywise level 0 recurrence importance 50 at 0 7 * * 1,2,3,4,5

energywise importance 50

energywise keywords phone,videoPhone

Note that LMS simply added a new line (highlighted above) which powers the phone off at 7:00 AM on weekdays. So there is now an event which powers the phone on at 7:00 AM on weekdays, another event which powers the phone on at 8:00 AM again, and another event which powers the phone off at 7:00 AM. Note that with multiple events occurring at the same time, the last event which appears within the configuration determines the Cisco EnergyWise level.

It may be possible to modify policies with LMS to get the correct behavior. However, over time it will be complicated for the network administrator to understand deployed policies if LMS simply continues to add events to existing policies. A workaround is to manually edit recurring events using the command line of each network infrastructure device. LMS may be used to initially deploy a policy to an endpoint group. However when it is necessary to modify that policy, it may be preferable to first manually remove the energywise level commands from every Catalyst switch port and/or ISR G2 router module. Once the configuration has been cleaned up, apply a new policy with LMS. This may be an administratively arduous task in a large network. Hence, it may be more preferable to simply deploy recurring events on each switch or router using the time-range format discussed in Configuring Recurring Events.

LMS Policy Compliance

The EnergyWise Work Center within LMS 4.1 provides a visually easy means of determining whether a policy has been pushed to a particular group of endpoints and whether any of the endpoints are currently non-compliant with the policy. Under the EnergyWise Work Center, select Configure > Policy Compliance to bring up the EnergyWise Policy Compliance Status window. An example is shown in Figure 30.

Figure 30 Example Cisco EnergyWise Policy Compliance Status Window

Note that the EnergyWise Policy Compliance Status window only shows whether a policy has been applied to a particular endpoint group. It does not specifically show which policy or policies have been applied. To determine which policy or policies have been applied, the network administrator must go to Step 3 of the workflow to assign Cisco EnergyWise policies as discussed in Applying LMS Policies.

The network administrator should note that Cisco EnergyWise policy compliance checking, device collection, and endpoint collection occur at user-defined intervals through the EnergyWise Admin Settings window. Note that infrastructure device collection refers to domain members, such as switches and routers, which have been added to the network and the LMS database, but currently do not appear within the EnergyWise Work Center. Under the EnergyWise Work Center, select Settings > General to bring up the EnergyWise Admin Settings window. An example is shown in Figure 31.

Figure 31 Example EnergyWise Admin Settings Window

Each of the collection intervals is specified in relative time—every 4, 8, 12, 24, or 48 hours. The network administrator should choose the collection interval based on how dynamic their network is in terms of the addition of new infrastructure devices and endpoints. The trade-off for more frequent collection intervals is higher processing overhead on the LMS server as well as Cisco EnergyWise traffic generated on the network. If the network is relatively stable in terms of deployment of endpoints and devices, then a longer collection interval is recommended. Note that the administrator can run device, endpoint, and compliance check collection immediately through the EnergyWise Collection Summary window. An example is shown in Figure 32.

Figure 32 Example EnergyWise Collection Summary Window

Note that endpoint collections run during times when a switch port is administratively down or when PoE has been removed from the switch port by explicitly configuring the energywise level 0 command results in the attached endpoint being removed from the Cisco EnergyWise Work Center within LMS. In other words, the particular endpoint (such as an IP phone) no longer appears with any endpoint groupings to which it belongs. Note, however, that when the endpoint is powered up again and a new collection is run, the device re-appears within its endpoint grouping. Testing has shown that this behavior does not apply to devices which execute a policy which causes them to power down at specific times during the day. Endpoint collections run during times when a device is powered down due to a policy event remain within the Cisco EnergyWise Work Center.

LMS Reporting

One of the more powerful tools within Cisco Prime LMS is the ability to collect long-term power usage of endpoint groups and to make the subsequent information available through reports. Figure 33 shows a very simple example of a report showing power usage of an endpoint group consisting of several IP phones within a single Cisco EnergyWise domain.

Figure 33 Example EnergyWise Power Usage Report

As can be seen, the report provides both maximum power usage as well as average power usage for the endpoint group. Additionally, the total energy usage over the time range of the report is provided. In this simple example, the report spanned only two days. Note that the chart at the bottom of the report shows the total power usage graphed out at various points in time.

Setting up and running a report, such as the one shown in Figure 33, is relatively easy. Once an endpoint group has been created and set to monitor power usage, and sufficient time has elapsed to capture meaningful power usage information, a report can be run as follows:

1. Under the EnergyWise Work Center, select Reports > Power Usage. This brings up the EnergyWise Power Usage Report window. An example is shown in Figure 34. Check one or more existing endpoint groups, specify a report name, and specify a time range.

2. Click Create to create the report. The report status should appear at the bottom of the EnergyWise Power Usage Report window. Click the refresh arrow until the report status says "succeeded".

3. Click View to bring up the specified Cisco EnergyWise report in a separate window.

Figure 34 Example of the EnergyWise Power Usage Report Window

The combination of flexible device groups and the ability to combine those groups over varying time ranges provides the network administrator with a fairly broad range of options for reporting power usage across the IP network infrastructure.

Summary

In response to rising energy costs and concerns about rising energy consumption globally, organizations are turning to technology to monitor and control overall energy usage within their facilities. Cisco EnergyWise is an innovative Cisco technology which provides the ability to monitor and control power across the IT infrastructure by utilizing the network itself.

The Cisco EnergyWise architecture consists of three tiers—management applications, domain members, and endpoints. This document has focused primarily on the middle tier, domain members, which consist of network infrastructure components. It presented information about how power within the network infrastructure can be monitored as a first step toward an overall energy management strategy and subsequently how power within the network infrastructure can be controlled. The Cisco EnergyWise protocol and Cisco EnergyWise Management API (MAPI) were specifically developed to provide a scalable mechanism for both monitoring and controlling power across the network infrastructure. Finally, the Cisco Prime LMS application was presented as an application for the management of Cisco EnergyWise on Cisco infrastructure devices.

Future revisions of this document will continue to expand its scope to include topics such as third-party management applications and endpoints, as well as additional power monitoring and control functionality.

Appendix A—Cisco EnergyWise and IP Phone Interaction

Cisco EnergyWise might affect the operation of power over Ethernet (PoE) IP phones.

Appendix B—Cisco EnergyWise and Wireless Networks

Keep these considerations in mind when your network has lightweight access points in a wireless LAN (WLAN) and the Cisco EnergyWise domain has access points as end points.

•Understand the access-point positions and coverage levels in critical and noncritical environments to set minimal coverage in the critical environments and to disable the access points in the noncritical environments.

When you power any access points on or off, the RF domain changes. The RF group leader, a wireless LAN controller running radio resource management (RRM) software, reconfigures the group. Autonomous access points do not power off, and other access points do not start the wireless network self-healing feature.

•Do not power off the wireless LAN controllers in an RF group.

The group members elect an RF group leader. If the wireless LAN controller restarts, the group-leader metrics change and affects how the members elect a leader.

A wireless LAN controller must be powered on before you connect it to an access point. If the controller is powered off, the connected access point cannot join the controller.

•Assign the primary, secondary, and tertiary controllers to all Cisco EnergyWise-capable access points.

After the access points restart, they can rejoin the controllers to which they belonged before they restarted.

If you power on access points in groups and assign primary and secondary controllers for each group, you can power on all the access points at the same time. Some access points join the assigned primary controllers, and others join the assigned secondary controllers.

When you power on access-point groups in a sequence, make sure that the controllers have enough time to download the access-point configuration files.

•If you power off all the access points, they keep the previously assigned channel and power settings. The access points restart with working configurations.

When you first use the access-point Cisco EnergyWise profile, restart the system, and make sure that the RF group leader has enough time to reconfigure the group.

•For faster reconfiguration, adjust the transmit power control (TPC) and dynamic channel assignment (DCA) settings. After the RF leader reconfigures the group, reset the TPC and DCA settings.

You can also set the DCA interval for faster reconfiguration when you power access points on and off.

Appendix C—Important Notice

Disclaimer

Cisco EnergyWise enables you to reduce energy consumption in your network by turning off the power to devices when they are not in use. If IP phones are part of your network, they can also be turned off through Cisco EnergyWise, in which case calls cannot be made or received, and the phones cannot be turned on except by the network administrator or according to rules established in Cisco EnergyWise by the network administrator. Laws in the location of your network might require phones to remain available for emergencies. It is your responsibility to identify the laws which apply and to comply with them. Even in the absence of a law, we strongly recommend that you designate certain phones which will always be on and available to make and receive emergency calls. These phones should be clearly identified, and all employees or others who might require emergency access to make or receive calls should be informed of the availability of these phones.

Statement 361—VoIP and Emergency Calling Services do not Function if Power Fails

Warning

Voice over IP (VoIP) service and the emergency calling service do not function if power fails or is disrupted. After power is restored, you might have to reset or reconfigure equipment to regain access to VoIP and the emergency calling service. In the USA, this emergency number is 911. You need to be aware of the emergency number in your country.

Statement 1071—Warning Definition

Warning

IMPORTANT SAFETY INSTRUCTIONS

This warning symbol means danger. You are in a situation that could cause bodily injury. Before you work on any equipment, be aware of the hazards involved with electrical circuitry and be familiar with standard practices for preventing accidents. Use the statement number provided at the end of each warning to locate its translation in the translated safety warnings that accompanied this device. Statement 1071