A simple Energywise setup (without management software).

One of the things I found to be useful at Cisco Live is EnergyWise. What’s EnergyWise? Simply put, it’s a protocol that allows you to see how much power everything attached to the network is consuming, as well as influence that power consumption. In this article I’ll describe how to do some simple checks and modifications using EnergyWise. Note that this is without any management software and thus only half the solution: together with (mostly third-party) management software, a lot of automation is possible, such as scheduled standby of devices, detailed graphs about power usage, and real-time queries.

First thing about EnergyWise configuration: it lets switches act as an EnergyWise cluster, with one master switch that gathers all data. This is a good thing really: while you can read out EnergyWise data on switches with SNMP, it’s a lengthy process, and querying one master switch makes it a lot more responsive. EnergyWise is activated by configuring cluster parameters:

energywise domain domain security shared-secret secret protocol udp port 43440 interface interface

The domain name obviously needs to be the same for all switches in one domain, just as the shared secret. Protocol currently only supports UDP but it was added to allow for future expansion if needed. Default port number is 43440, and interface is the interface on which the switches will communicate as a cluster (most likely management interface). Yes, even if you just have one switch, this is mandatory.

EnergyWise defines 10 levels of device operation, where zero is powered off and 10 is full power. If the device is EnergyWise aware, it can use those energy levels advertised by the network to adjust its power consumption. Theoretically, a printer can go to standby, full power, turn itself off, and so on. But back to reality: without any EnergyWise aware software and devices, it’s limited to basics. But that’s enough, as you can influence PoE consumption on a port. Energy levels 1 to 10 mean PoE is allowed on a port, energy level 0 mean no PoE. So configuring a port with EnergyWise level 0 will disable PoE on that port.

Okay, interesting, but what makes this better than ‘power inline never’? Well: EnergyWise can be combined with time ranges. And that’s where it gets fun. Say I want to have all IP Phones in an office only powered up during business hours, being 8 am to 6 pm. First, make time ranges in the IOS:

time-range TIR-Work
periodic weekdays 7:55 to 17:59

time-range TIR-Free
periodic weekend 0:00 to 23:59
periodic weekdays 0:00 to 7:54

Because the IP Phones need some time to boot, start time for activity (business hours) is set to 7:55 am. Next, on the interfaces where IP Phones are attached, the following two commands do the magic:

energywise level 0 recurrence importance 100 time-range TIR-Free
energywise level 10 recurrence importance 100 time-range TIR-Work

Now, automatically every day, the IP Phones boot up, and after business hours, they power down, saving energy. You need both time ranges, as EnergyWise will stay in the state it was changed last to otherwise. This is a very simple setup, and more fine tuning is possible, including the ability to only power down if there is no more activity on the IP Phone.

While this is not something widely deployed yet, I hope people will see the potential.

The new 3850 switch, UPOE and compact switches: interesting design options.

Initially, I told myself I wasn’t going to spend an entire blog post to the new 3850 switch. Presented on Cisco Live London, it was just a new series of Catalyst switches with all existing functionality plus some new things like the integrated WLC. Not really interested in anything else, I got bored and Googled around to see if my WS-C3560-8PC fanless desktop switch had a gigabit equivalent. Turns out it does, with quite a few models. All fanless, PoE capabilities and some layer 3 models. But then I noticed something: some of these models had both PoE powering and PoE powered ports. So how does that work? Well, these switches have two PoE powered ports. Some power is used for the switch itself and the remainder is used in the PoE budget towards the switches. The switches can give standard 802.3af PoE at 15.4W per port, but can receive 802.3af (15.4W), 802.3at PoE+ (25,5W) or UPoE. UPoE isn’t an official standard yet, but Cisco is pushing for it and their new 3850 series supports it. It allows up to 60 Watts per port.

And then it hit me. 3850’s, compact switches, and other PoE devices like Access Points and IP Phones allow for a lot of interesting designs.

For example, using the 3850 in a stack as a core switch in an office, it’s possible to give power to fanless (silent) compact switches near the desks. The C2960CPD-8PT (what a name!) has two powered PoE uplinks so a 2 Gbps port-channel towards the 3850 stack is possible. That gives redundancy when spread over two switches, and the stack can also use StackPower. It’s max power budget is 30W, which is enough for two PoE devices, or more when using 802.3af classes or CDP PoE negotiation, e.g. many IP Phones only use 7 Watt, allowing for four on one switch. Result: it’s possible to power an entire office network directly from the core: less wall sockets needed, less cable runs. And finally, the integrated WLC on the 3850 allows all AP tunnels to terminate in the office itself, instead of going back towards a remote controller in a HQ/Data Center. This allows faster and easier access to local resources (printers, on-site servers).

The combination 3850/Compact switches allows for long cable runs without any need for a power supply anywhere in between. In the most extreme case you can bridge 500 meters with it: 3850, 100m copper  UPoE, 2960CPD, 100m PoE, 2960C, and a 100m cable run towards a mirrored setup.

So yes, when thinking about it, these new switches with new technology do allow more flexibility when deploying a network!

Cisco Live 2013: a great experience.

Last week a colleague and I went to Cisco Live London 2013! Overall experience: great. I gained an impressive amount of knowledge in a short time, and writing all that down would generate enough blog posts for a year. We went to many different seminars that really went into the details. Too much to name, but a quick review of the impressive stuff I saw:

• The launch of the Catalyst 3850 switch. I’m not going to read the data sheet, but quick overview: all 3750X functionality (StackWise, StackPower, hardware IPv6, QoS, redundant power and fans), 802.3at PoE+, 32k CAM table possible, integrated Wireless LAN Controller, up to 40 Gbps WLC throughput, and besides the 24 or 48 Gigabit ports up to 4x 10GE is possible in a SFP+ module. Very promising, although most functionality is expected for a next-generation switch, and I have yet to test it all in a production environment.
• A seminar about the Nexus 6000 switch. Designed towards ultra low-latency implementations. While I did think initially that it would be of little use cost/benefits-wise outside of the trading and high computing markets, an article by Greg Ferro made me think about this again. Apparently he was there too in London. Worth the read.
• The Nexus 7000 architecture seminar. This was a bit of a disappointment. Cisco’s flagship data center switch sounds like an elephant: huge, strong and loudly announcing it’s there, but too many features that aren’t ready yet, so watch out what you want to do with it. I noticed plenty of limitations on the current generation that will probably go unnoticed if you’re not using the Nexus to its full potential, but no one buys a Nexus 7000 just for basic switching.
• Energywise fundamentals and deployment by John Parello. An unexpectedly useful technology, that I have working now (more about that in a later blog post). I find that this requires more attention and research.
• FCoE practical lab: a complete overview of the technology, much more in-dept than my own brief review. Again an interesting technology that will prove useful when mastered. For practical implementation it requires a lot of planning and design in advance though.
• Ultra Low Latency Data Center design: I already mentioned some details on latency in my article about fibers. Though not that important for me in practice, I learned some key points about latency.
• Multicast troubleshooting: Luc De Ghein did a great explanation there, giving me insight into multicast inner workings.
• Meet The Engineer meeting with Lars, an engineer sharing the same native language as I did who is a Catalyst 6500 switch expert. He provided me good insights with hardware and software ACLs and Control Plane Policing.
• CCIE Troubleshooting lab: me and my colleague actually managed to solve part of it… But the 45 minutes time was just too short. A nice taste of things that may come for me one day.

For a network engineer this was a really great event, much to see, to learn, to experience. Probably a once-in-a-lifetime chance for me, and I don’t regret it.

Testing an Aruba IAP.

Once again, I was presented the opportunity to test out a device my work borrowed me. This time: an Aruba IAP 105.

It’s an Instant Access Point, which comes with a built-in virtual controller. Aruba usually makes Lightweight Access Points (LAPs) which need a central WLC or Wireless LAN Controller to function. Since this one contains the controller function inside the device, I can go experimenting. Yes, it’s like a consumer-grade access point now, with a web GUI to configure it, but compared to the average consumer-grade AP, this one comes with more functionality.

First the standards: it supports 802.11a/b/g/n, with n in both 2.4 Ghz and 5 Ghz frequencies. It also supports 802.3af PoE, or an external power supply, and has support for 802.1q trunking. So as far as compatibility goes, this device supports it all.

After applying PoE to it, it boots up. Since it’s an IEEE compliant power device, and I have a Cisco ILP powered IP Phone on the same switch, this gives a nice comparison:

This shows the IAP as a Class 3 power device, and the IP Phone as Cisco proprietary. The IP Phone gets a slight advantage here as it can tell by CDP how much it needs, thus drawing less power budget. I did not detect any CDP or LLDP support for the Aruba IAP by the way.

Back to the IAP: after booting up and receiving an IP through DHCP, it sends out a default network. After connecting to it, I’m automatically redirected to the login page (Windows 7 even shows an event message ‘Please open your browser’). After entering the default login and password I’m asked in which country I am, likely to comply with local radio regulations.

The main page in the web GUI show some graphs, indicating signal strength, throughput, and number of users connected. Clicking around, I discover noise levels, transmission errors, even individual reports for each client device, as well as a mobility trail, to check the roaming patterns between multiple access points. As I only have one, there’s no useful information there.

The noise levels do indicate a problem:

Reason: there are several other access points nearby, one of which is on the same channel 6 as the Aruba. After setting the channel static to 11 (it was automatically searching first), the problem did go away.

Apart from that, there’s also an IDS tab that showed more details about other access points in the area: how far away they are, channel, 802.11 mode, connected clients,… Strangely enough, my own AP is the only one marked as ‘rogue’. Since it’s also the only AP to be in the physically same network as the Aruba, I assume it has some mechanism of finding out unauthorized APs. Maybe it has found the AP’s MAC address in the same VLAN?

As far as configuring SSIDs goes, it have plenty of options too: multiple VLANs are supported, each with it’s own security features. There’s support for WPA, WPA2, WPA2 through RADIUS, MAC filtering, also optionally through RADIUS, 802.1x WEP, and open network. There’s also the option to do a redirect to a login webpage, either hosted on the IAP itself or on an external web server. Network access can be done either through NAT on the IAP, direct access to the uplink (access port) or VLAN tagged to a trunk link. The last one is very useful and what it’s usually all about: by mapping different SSIDs to different VLANs, and connecting the Aruba IAP with a trunk link, one can give access to different subnets through one AP. The authentication (usually by RADIUS) then checks whether access to a certain VLAN is allowed or not. On top of that, it’s possible to set up a per-SSID access list to deny access to certain resources or networks from the IAP.

I did ran into a few unexpected problems. First was that my 802.11n capable laptop could not pick up any 5 Ghz signal, only 802.11n on 2.4 Ghz worked. Second was setting up the trunk link, which didn’t work at first until I realized I was acting too quickly and ‘spanning-tree portfast’ is not the same as ‘spanning-tree portfast trunk’, making the trunk link go through STP states.

And in case you were wondering: yes, the signal strenght of the device is great. I had no stability issues, connecting went fast and reliable.

Last things I’ve learned for this year.

My last blog post for 2011! Past days I’ve been playing games mostly, and reading some CCDA stuff. No labs for the weeks to come, I have to redesign my home lab first and integrate the access server.

I did still learn some small things this week:

• A Cisco device without ‘ip routing’ enabled (like an unconfigured layer 3 switch) needs the command ‘ip default-gateway’ to be reachable from another subnet. But once ‘ip routing’ is enabled, this command no longer works, and it needs a default route for similar behavior.
• Cisco PoE endspan devices (PoE capable switches) use PoE mode A, while midspan devices (PoE injectors) use PoE mode B.
• I learned what SSL offloading is, and that it can be used together with an IDS/IPS for improved security.
• 10 Gigabit Ethernet requires Cat6A UTP, and runs up to 100m. For 40 and 100 Gigabit there’s no cabling standard as far as I know.

Well, that’s it. Happy holidays to everybody!

Introduction to Power over Ethernet.

I’ve been researching Power over Ethernet (PoE) lately, as I have two PoE switches at home. It wasn’t a requirement I had in mind when I bought them, but I’m happy I did now because it allows me to play around with it. I also strongly recommend to look into PoE for you lab if you’re going for Voice. I have some IP Phones I use as end devices in labs: they can be pinged, have a build-in webserver on port 80, are cheaper than a seperate computer and consume less power, especially on PoE.

To the point: it is remarkably hard to find simple information about the mechanics of PoE without having to go through many (sometimes contradicting) resources. There are three methods of PoE I’m going to discuss: Cisco’s Inline Power (ILP), the 802.3af standard and the 802.3at standard. Besides that, there are many vendor-specific implementations.

ILP was, like most vendor-specific PoE solutions, developed before the standards. It uses a 340kHz tone of AC current which it continuously sends through one of the data pairs. A Cisco IP Phone will loop back the tone (only that tone, using a filter, no actual data frames) to the PoE switch, which will detect it and grant power to the line. Once the IP Phone becomes active, in low-power mode (6.3W), it will send a CDP message stating the correct power requirements. The switch will adjust it’s power to that, so the IP Phone can work properly. Documentation is vague about the maximum supported output, but it seems to be 15.4W, like 802.3af.

802.3af detects a powered device by sending a low DC current through the transmit and receive pairs. If a resistance of 25,000 Ohm is measured, caused by a PoE supported device attached to the port, power will be granted. After the device powers up, it will be classified into a category. The device will create a load, the switch will recognise the load and determine the class. If this is not done, the default class 0 is used. Classes are:

0 – 15.4W (default, the maximum supported)
1 – 4.0W
2 – 7.0W
3 – 15.4W
4 – More, 802.3at

There are two power modes: mode A and mode B. In mode A, pairs 1,2 and 3,6 are used for power. These are also the data wires in 10Mbit and 100Mbit connections, a ‘phantom technique’ is used to put both streams on the wires. In mode B, pairs 4,5 and 7,8 are used, which are spare pairs in 10/100Mbit networks. In gigabit networks all pairs are used for communication. Note that a device requiring 10W for example, must use class 0 or 3, so the 5.4W that is allocated too much to that device can’t be used for another device on the same switch. Cisco’s ILP does not have this problem.

And last: 802.3at, commonly named PoE+. It supports up to 25,5W officially, but since both modes (Mode A: pins 1,2 and 3,6; mode B: pins 4,5 and 7,8) can be used at the same time, devices exist that can draw 51W of power using this standard.

So those are the standards, but what devices can provide that power, and use that power? Providing is done by either an end-span device (a switch or switch chassis blade) or a mid-span device (a power injector). Record holder for the most output seems to be the Mega PoE by Phihong for the moment, at 95W per port. No idea whether this has any real use, and whether the cables will heat significantly during usage.

As far as devices that can use PoE goes, while it originally started with IP Phones, many other devices support it now too, e.g.:

• Wireless Access Points, for places where no power cables are, like ceilings.
• IP Cameras, for the same reason as above.
• Switches, like the WS-C2960PD-8TT-L.
• Complete thin clients and computers, like the ones by SkinnyBytes, supporting 802.3at.
• Print servers
• Electric guitars (yes, I’ve found multiple articles, just not in English but my native language).

For an even more in-dept read, this was some of my best source material. The only thing I’m unable to find out so far is which modes are used by the switches used in my lab. The IP Phones power up completely without CDP, indicating that 802.3af is present and working, but if I turn on CDP, which method is used? Still 802.3af, or Cisco’s ILP? There are no commands to toggle these modes, just a general ‘power inline auto’ and ‘power inline never’. If anybody knows, please let me know (in the comments).