This paper describes the deployment considerations related to rolling out the Phase I of the EnergyWise features. The Cisco® EnergyWise solution helps companies use their network infrastructure to manage and control the power usage of network devices. The intended audience for this paper is network engineers and managers of enterprises that are eager to take advantage of this feature.
Cisco EnergyWise is a logical evolution of services that can be offered using the network as a platform. Switching devices initially provided only Layer 2 network connectivity to end devices. With the introduction of Power over Ethernet (PoE) the switch became a source of power for end devices such as wireless LAN access points, IP phones, IP cameras, and so on. With the EnergyWise framework, switches can now help to measure and control the power usage of power-enabled network-attached devices. Phase I of EnergyWise allows you to control the energy usage of PoE devices. EnergyWise Phase II extends control to non-PoE devices such as desktop PC and laptops. The aim of EnergyWise Phase III is to have the network control the traditionally non-IT energy usage such as the lighting and cooling within the building.
Figure 1 depicts the different phases of the EnergyWise framework.
Figure 1. EnergyWise phases
This paper discusses the deployment considerations for EnergyWise Phase I, which is essentially the control of PoE-based network devices. For more information on EnergyWise, visit http://www.cisco.com/go/energywise.
What Customers Have
Most enterprise customers have a three-tier network architecture consisting of core, distribution, and access-layer switches in their network. (See Figure 2.) The access layer provides connectivity to end devices. The access-layer switches have PoE capabilities to power attached IP phones, wireless LAN access points, and IP cameras.
Figure 2. Three tier LAN architecture
EnergyWise Phase I would typically be rolled out on the access layer for PoE-enabled switches. Figure 3 shows a typical access-layer PoE switch with end PoE devices connected.
Figure 3. Power over Ethernet Enabled switches and end devices
What Customers Need to Run EnergyWise Phase I
As of today, the customer should have the following hardware and software in place to run EnergyWise:
• PoE-capable access-layer switches
• PoE-capable devices (cameras, access points, and IP phones)
• Cisco IOS® Software that supports EnergyWise feature
The current networking platforms that support Cisco EnergyWise include the Cisco Catalyst® 2960, 3560, 3560-E, 3750, and 3750-E Series fixed switches, as well as the Cisco Catalyst 4500 Series modular switch and the Cisco EtherSwitch modules for Cisco integrated services routers.
For fixed series switches and Cisco EtherSwitch modules, customers must upgrade to Cisco IOS Software Release 12.2(50)SE or later with either the IP Base or IP Services feature set. For Cisco Catalyst 4500 Series Switches, customers must upgrade to Cisco IOS Software Release 12.2(52)SG or later.
End Device Considerations for Phase I
EnergyWise enabled switches can set up to 10 power levels for end devices. Table 1 summarizes the different levels.
Table 1. EnergyWise power levels
Cisco EnergyWise can support any PoE device currently. However, because most existing devices at present do not recognize EnergyWise signaling, the support is limited to simple on/off decisions. As more devices, for example, both Cisco and third-party IP phones and access points as well as building control systems, become Cisco EnergyWise enabled, more sophisticated sleep modes will be possible.
EnergyWise has its own terminology. It helps to become familiar with the terminology before deploying this feature.
An EnergyWise domain consists of a number of EnergyWise entities. Entities are physical or logical devices that participate in EnergyWise (for example, PoE switch, PoE end devices, and so on). Entities can either have peer relationship (neighbor-neighbor) with each other or have hierarchical relationships (parent-child). A parent supplies and controls power to its connected child. A switch would typically be a parent, and any PoE device connected to it would be classified as its child. A switch entity communicates with the child as well as it neighbors (other switches within the same domain). A domain is a single manageable community or unit of energy entities. Managers are applications and devices that measure, monitor, and manage the power consumption of a domain or sometimes multiple domains. Figure 4 graphically depicts the EnergyWise terminology.
Figure 4. EnergyWise Network
EnergyWise deployment consists of the following steps:
1. Identify the switches (entities) that will run EnergyWise.
2. Define an EnergyWise domain on these switches.
Once the EnergyWise domain is defined, the switches begin to exchange EnergyWise messages with each other and perform a neighbor discovery.
This communication between the entities can be authenticated using a shared password. The entities become neighbors only when they have matching passwords configured. The neighbor discovery uses two protocols: Cisco Discovery Protocol and also User Datagram Protocol (UDP) using port 43440 (default). Neighbors can also be discovered using static method if required. Figure 5 depicts the use of Cisco Discovery Protocol or UDP to exchange neighbor information.
After configuration changes, the neighbor table can be cleared and automatically refreshed:
Switch# clear energywise neighbors
Cleared all non static energywise neighbors
Non-PoE ports do not participate in EnergyWise. Once a domain is defined and neighbors discovered, all PoE ports start participating with EnergyWise. EnergyWise can be disabled on a per-port basis if required.
All interfaces are added by default when activating EnergyWise. EnergyWise can be turned off on one or more ports without affecting other ports.
Switch(config)# int range gi0/45-48
Switch(config-if-range)# no energywise
Switch# show run int gi0/45
switchport mode access
For the ports that participate in EnergyWise, it helps to define names and roles. Naming helps in providing specific context such as 2nd_fl_A_wing_cube_22. The role helps in providing a general business context such as "user_phone," "Reception_phone," "Executive_Phone," and so on. These names and roles can be used in queries for searching. The ports can also be labeled with a specific importance. The importance helps to differentiate between the end devices in the domain. For example, a lobby phone will have lower importance as compared to a reception phone. Again, importance levels can be used to either query or manage the power usage of the devices.
Here is an example of how an interface can be configured for an EnergyWise name and importance level:
Queries can be used to measure the power usage of the entire domain. Queries help to get consolidated as well as individual power usage views of the domain. It can also be used to set the appropriate power levels for devices across the domain. Figure 6 shows the flow of the queries and the responses in the EnergyWise domain.
Figure 6. EnergyWise Queries and Responses
For example, the following query command collects present power used by all devices in the domain that have the name "phone." (The wildcard "*" is permitted and finds "phone.1," "phone.lobby," and so on). Alternatively, keywords can be used instead of names.
Switch# energywise query importance 100 name phone* collect usage
EnergyWise query, timeout is 3 seconds:
Host Name Usage
---- ---- -----
188.8.131.52 phone 15.4 (W)
184.108.40.206 phone 15.4 (W)
Queried: 9 Responded: 9 Time: 0.26 seconds
All devices and interfaces in the domain can be selected by using the * wildcard.
Switch2# energywise query importance 100 name * sum usage
EnergyWise query, timeout is 3 seconds:
Queried: 147 Responded: 147 Time: 0.121 seconds
A query command can be used to set power levels in the domain. In this example, the power level is set to 10 (on full) for all devices with any name that has an importance of 50 or lower. Individual devices with specific names or keywords can also be specified, including wildcards for part of the name or keyword.
Switch# energywise query importance 50 name * set level 10
EnergyWise query, timeout is 3 seconds:
Success rate is (47/47) setting entities
Queried: 47 Enacted: 47 Time: 0.16 seconds
If importance 100 is specified and name *, all devices with any name will be set to power level 10.
Note the number of devices queried and responded to verify that it is consistent with anticipated results.
It is useful to consider the following while deploying EnergyWise:
• The extent of the domain: If the domain has too many entities, a query can take considerable resources and time to complete. Even though there is no hard-limit, lab tests have indicated that using more than 50 entities in a domain could affect the performance of the switches.
• Disjointed domains: Typical communication between neighbors happens at Layer 2 (Cisco Discovery Protocol) or using broadcast (Layer 3 UDP). If there are neighbors that are on the other side of a WAN connection, then automatic discovery will not happen. In this case, static neighbor configuration is recommended. Alternatively, the WAN router can be configured for "ip helper address" and "ip forward-protocol udp" commands to allow the communication to happen over the WAN.
• Port blocking: Care should be taken to allow UDP port 43440 (default) through the firewall if the neighbor happens to be in the DMZ.
• Bandwidth consideration: Neighbor discovery can have an effect on the bandwidth usage Neighbors exchange information that are about 200 KB every 30 seconds by default. For a campus LAN this is negligible bandwidth, but for neighbors spread across a WAN with low-bandwidth links, then this needs to be factored. Queries are logical broadcast in the sense that it is sent as unicast to each of the neighbors, and each neighbor in turn forwards it to its list of neighbors. Query responses are unicast back to sender.
• Effects of availability of PoE devices: Phase I has only on/off capabilities for end devices. Due consideration must be taken while configuring the power states of the port connecting to the IP phone. Powering off a security camera during off hours could be a huge security risk. Similarly, shutting down all IP phones after work could result in business effects (if customers are calling) or inability to dial for help during an emergency.
• Cascading PCs to IP phones: Many offices today have PoE IP phones connecting to the switch, and the PC connects to the data port on the IP phone. Due consideration should be made for PC connectivity when an IP phone is switched off using EnergyWise. This leads to no wired connectivity for the PC or laptop as the data-port of the IP phone does not function when there is no power to the IP phone. Similarly, switching off WLAN access points that power through PoE would result in no coverage for the client machines using wireless.
NMS for EnergyWise
Phase I of EnergyWise can be managed using two NMS applications. Cisco EnergyWise for LMS 3.2 is a drop-in available free of charge from the software center on Cisco.com. CiscoWorks LMS is available for ordering through regular Cisco sales and distribution channels worldwide. Solarwinds has an excellent interface to manage EnergyWise as an alternative option.
With the Cisco EnergyWise drop-in for LMS 3.2, the RME page has two new components:
EnergyWise Capability Summary portlet shows a pie chart that contains a summary of EnergyWise-capable devices in the following categories:
• EnergyWise-enabled devices
• EnergyWise-disabled devices
• EnergyWise software-incapable devices
Figure 7 is a sample of the pie chart from LMS 3.2.
Figure 7. EnergyWise capability summary in LMS
The Technology Links portlet has the EnergyWise quick links for configuring EnergyWise, as shown in the snapshot in Figure 8.
Figure 8. Technology Portlet screen in LMS
Two new templates have been added to support EnergyWise in HUM 1.2.1:
• Energy Wise Port Power Usage to monitor individual power usage at port level.
• Energy Wise Device Power Usage to monitor individual power usage at device level. This includes an aggregated power usage of all the ports and the device itself.
Figure 9 shows a screen shot of the above two options in HUM
EnergyWise Phase I offers the ability to manage only PoE devices. The control is not granular, and currently it is restricted only to switching the PoE end devices on or off. EnergyWise rollout should be done considering all the factors mentioned in this paper. As further developments happen both on the network entities and on the PoE devices, this feature could be become a valuable way to manage the power usage of the entire building.