Power Over Ethernet in action on a phone so old it should have a rotary!
One real world tip to start this off for finding a port # for a device like a phone, when things are mislabeled, and no one in the office knows what a switch even is and your troubleshooting remotely.
If you unplug and re-plug the device into the port a few times so it loses power, it will show in the logs, and tell you right where that device is:
SW1#sh log
(A LOT of output redacted)
*Mar 1 00:55:53.589: %ILPOWER-7-DETECT: Interface Fa1/0/24: Power Device detected: Cisco PD
*Mar 1 00:55:53.933: %ILPOWER-5-POWER_GRANTED: Interface Fa1/0/24: Power granted
*Mar 1 00:55:58.110: %LINK-3-UPDOWN: Interface FastEthernet1/0/24, changed state to up
*Mar 1 00:55:59.117: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/24, changed state to up
*Mar 1 00:56:39.265: %ILPOWER-5-IEEE_DISCONNECT: Interface Fa1/0/24: PD removed
*Mar 1 00:56:39.323: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/24, changed state to down
*Mar 1 00:56:40.322: %LINK-3-UPDOWN: Interface FastEthernet1/0/24, changed state to down
*Mar 1 00:56:50.631: %ILPOWER-7-DETECT: Interface Fa1/0/24: Power Device detected: Cisco PD
*Mar 1 00:56:51.311: %ILPOWER-5-POWER_GRANTED: Interface Fa1/0/24: Power granted
*Mar 1 00:56:55.111: %LINK-3-UPDOWN: Interface FastEthernet1/0/24, changed state to up
*Mar 1 00:56:56.117: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/24, changed state to up
SW1#
So for the sake of clarity I highlighted the PoE messages of the device because flapping just a computer on a port will likely not have those messages, however you can do this on any device, and you’ll see the port “flap” in the logs, so just a good to know method of determining where things are without being there in person.
Now that we got that out of the way, back to the CCNP stuff!
I’ve actually found a 5th usable option / modifier on my switch so I assume it is a newer model than in the video series I am watching, a finger wag to Chris for making me research this Switching stuff:
SW1(config)#int fa1/0/24
SW1(config-if)#power inline ?
auto Automatically detect and power inline devices
consumption Configure the inline device consumption
never Never apply inline power
port Configure Port Power Level
static High priority inline power interface
SW1(config-if)#power inline
Going down the line, Auto allows the switch to deliver up to 30 watts, which can actually be changed if you follow the modifiers with a ? after each word starting with “auto”:
SW1(config-if)#power inline auto ?
max Maximum power allowed on this interface
<cr>
SW1(config-if)#power inline auto max ?
<4000-15400> milli-watts
SW1(config-if)#power inline auto max
A couple of gotchas on this part, this is where you would actually set a “minimum” as well, there is no minimum command so be sure to watch that on exam day. Also this is measured in milliwatts , not Watts, so 15,400 = 15.4 Watts.
*To note – When a switch negotiates with a device via CDP to determine power consumption, the max consumption or power needed by the device is determined and only that amount is sent, and the switch will retain any extra wattage to dedicate to other peripheral devices*
Which brings up the important question, what if CDP isn’t running?
This is where the “power inline consumption” comes into play, as instead of configuring the maximum consumption for a device off that particular port, the power is negotiated and the switchport is telling the device plugged in “this is what I’ll give you” and dedicating that amount of power to that switchport.
I ran the following commands on the interface with the IP Phone and would like to review the output:
SW1(config-if)#power inline consumption ?
<4000-15400> milli-watts
SW1(config-if)#power inline consumption 6400
%CAUTION: Interface Fa1/0/24: Misconfiguring the ‘power inline
consumption/allocation’ command may cause damage to the switch and void
your warranty. Take precaution not to oversubscribe the power supply.
It is recommended to enable power policing if the switch supports it.
Refer to documentation.
Firstly:
SW1(config-if)#power inline consumption ?
<4000-15400> milli-watts
SW1(config-if)#power inline consumption 6400
%CAUTION: Interface Fa1/0/24: Misconfiguring the ‘power inline
consumption/allocation’ command may cause damage to the switch and void
your warranty. Take precaution not to oversubscribe the power supply.
It is recommended to enable power policing if the switch supports it.
Refer to documentation.
This is again in mW instead of W, and I knew the phone was drawing 6.3W from “sh power inline” last night, so I set it to 6400 which caused the big ugly warning in red.
The big ugly red warning is saying if you over-subscribe the power consumption and kill the switch, your warranty is out the window, though I am not sure how possible that is to over subscribe it – lets do the math.
24 x 15.4 = 369.6 which falls .4 shy of the 370 Watts the switch shows it can provide, I assume Power is about the same as CPU, you don’t want your switch running at 99% CPU all the time so you wouldn’t want to configure each port at its max consumption.
It also bounces the port any time you change a PoE configuration on the port, as I found when I configured that, just an fyi. To remove it, simply type no in front of it, and you will still get that big ugly warning about frying your switch which CCNP’s don’t do!
Also a couple of verification commands to finish this segment off, lets take a look:
SW1#sh power inline consumption
Interface Consumption Admin
Configured Consumption (Watts)
———- ———– ——————-
Fa1/0/1 NO 0.0
Fa1/0/2 NO 0.0
Fa1/0/3 NO 0.0
Fa1/0/4 NO 0.0
I spared the output of the other 20 ports, but as you can see it will show if power consumption is even turned on for an interface, and the power it is drawing on each port.
To look at a specific interface, you would just put the interface number format at the end of the command like “fa1/0/24”, it gives you the exact same info above just for a single port rather than all of them.
Let’s take a look at “power inline never”
So this one is pretty self explanatory by the title, but lets check it out on here, I used it on port 24 where the phone is plugged in which is now dark:
SW1(config-if)#power inline never ?
<cr>
SW1(config-if)#power inline never
SW1(config-if)#
*Mar 1 01:39:07.078: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/24, changed state to down
*Mar 1 01:39:09.091: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/24, changed state to up
Note there was no power removed or any type of power message at all, and in fact changed state to Down then back to Up even though the phone is not plugged in.
So lets check CDP neighbors to see whats up here:
SW1#sh cdp nei
Capability Codes: R – Router, T – Trans Bridge, B – Source Route Bridge
S – Switch, H – Host, I – IGMP, r – Repeater, P – Phone,
D – Remote, C – CVTA, M – Two-port Mac Relay
Device ID Local Intrfce Holdtme Capability Platform Port ID
SW2 Fas 1/0/1 164 S I WS-C3750V Fas 1/0/1
SW3 Fas 1/0/7 137 S I WS-C3560- Fas 0/7
R1 Fas 1/0/11 153 R S I 1841 Fas 0/1
SW1#
So that no longer recognizes the phone as a neighbor because it isn’t powered on, but what about the sh power inline:
SW1#sh power inline
Module Available Used Remaining
(Watts) (Watts) (Watts)
—— ——— ——– ———
1 370.0 0.0 370.0
Interface Admin Oper Power Device Class Max
(Watts)
——— —— ———- ——- ——————- —– —-
Fa1/0/1 auto off 0.0 n/a n/a 15.4
Fa1/0/2 auto off 0.0 n/a n/a 15.4
Fa1/0/3 auto off 0.0 n/a n/a 15.4
Fa1/0/4 auto off 0.0 n/a n/a 15.4
Fa1/0/5 auto off 0.0 n/a n/a 15.4
Fa1/0/6 auto off 0.0 n/a n/a 15.4
Fa1/0/7 auto off 0.0 n/a n/a 15.4
Fa1/0/8 auto off 0.0 n/a n/a 15.4
Fa1/0/9 auto off 0.0 n/a n/a 15.4
Fa1/0/10 auto off 0.0 n/a n/a 15.4
Fa1/0/11 auto off 0.0 n/a n/a 15.4
Fa1/0/12 auto off 0.0 n/a n/a 15.4
Fa1/0/13 auto off 0.0 n/a n/a 15.4
Fa1/0/14 auto off 0.0 n/a n/a 15.4
Fa1/0/15 auto off 0.0 n/a n/a 15.4
Interface Admin Oper Power Device Class Max
(Watts)
——— —— ———- ——- ——————- —– —-
Fa1/0/16 auto off 0.0 n/a n/a 15.4
Fa1/0/17 auto off 0.0 n/a n/a 15.4
Fa1/0/18 auto off 0.0 n/a n/a 15.4
Fa1/0/19 auto off 0.0 n/a n/a 15.4
Fa1/0/20 auto off 0.0 n/a n/a 15.4
Fa1/0/21 auto off 0.0 n/a n/a 15.4
Fa1/0/22 auto off 0.0 n/a n/a 15.4
Fa1/0/23 auto off 0.0 n/a n/a 15.4
Fa1/0/24 off off 0.0 n/a n/a 15.4
SW1#
So as an Admin state, is shows this port in the table as “Off” and shows no power draw whereas it was 6.3, and at the top it shows 370 out of 370 watts available.
The mode not covered in my series, that might overload the switch, “port” mode
So I did some research on this, and a lot of it is people troubleshooting AP’s and things that require more Power than your average phone, and it seems that in some cases using this command resolved the issue:
SW1(config-if)#power inline port ?
2x-mode Apply 2X power level to the port
SW1(config-if)#power inline port 2x-mode ?
<cr>
SW1(config-if)#power inline port 2x-mode
SW1(config-if)#do sh power inline | i 1/0/24
Fa1/0/24 auto on 6.3 IP Phone 7940 n/a 15.4
SW1(config-if)#
So it still shows auto, only drawing 6.3, still Max 15.4 Watts power on “sh power inline | i fa1/0/24” output so I am not exactly sure where you can verify other than sh run:
!
interface FastEthernet1/0/24
power inline port 2x-mode
!
interface GigabitEthernet1/0/1
Also note, it did not bounce the port when the config on the interface was changed to 2x-mode.
So the best documentation I found was actually a bug this command addresses, which since you need a Cisco website login to view, I’ll post it here for your knowledge:
Power Imax / Tstart errors may be reported with some third party PDs
CSCsw18530
Description
Symptom:
Power Imax / Tstart errors may be reported with some third party PDs%ILPOWER-3-CONTROLLER_PORT_ERR: Controller port error,
Interface Power Controller reports power Imax
error detected%ILPOWER-3-CONTROLLER_PORT_ERR: Controller port error, Interface Gi1/0/35:
Power Controller reports power Tstart error detectedConditions:
Seen with some of the 3750,3750G,3750-E,3560-E, 3750-X, 3560-X, 3560-C, 2960S,
2960,2960C,2960X switchesWorkaround:
Longer cable (>50ft) seems to fix the issue in most cases.
Solution
This issue is fixed in 12,2(55)SE3 , 12.2(58)SE1 and later releases. The
following interface configuration commands have to be applied to resolve the
issue,Switch(config)# int x/y
Switch(config-if)# power inline port 2x-mode
Switch(config-if)# shut
Switch(config-if)# no shutThe fix is present in the following platforms :
3750-E,3560-E, 3750-X, 3560-X, 3560-C, 2960S, 2960,2960C,2960X
The other platforms do not support 2X power mode and the workaround would be to
use a longer cable.
Note this is only on certain switch platforms, so its unlikely to show up on your test, however ^ that bug workaround and information is very good to note.
The main take away from this is this was implemented on some switch models because the PD devices that spike the current being drawn, but does not knock it out of the IEEE 802.3af standard – As devices need to meet the IEEE 802.3af/at standard to even work with PoE at all. That is a good solid point to keep in mind as well.
Ventilation for the switches server room is just as important as planning the power!
Before getting into that last state, I wanted to again in terms of real world, always be sure to check your current power usage / available power before turning on or plugging in more devices if you aren’t sure as it may be power 20 high power Cisco Video end points / WAP’s and that one last power draw is the straw that breaks the llama’s back.
Also, in home labs this is rarely an issue and you wouldn’t even think about heat, until you step into a Data Center and feel the heat coming off of the switch / server racks. If its a smaller business that uses one or two switches, they probably just throw it in their back room with the modem / phone system / server and let the room get super hot.
However said Data Center supplying PoE across an entire building was pretty awesome to see, the floors and ceiling had tiles with holes in them, that vacuumed the hot air out of the room and recycled it into cold air so it was efficient. It was pretty neat.
So the point there, if asked on the test and for the real world, when expanding the use of network devices and PoE on them, remember its not just the power but also the heat that needs to be considered so the switch does not fry itself.
The “power inline static” command, and how it makes a port high priority for PoE
This basically guarantees power will be provided to a particular port with this configured, which sounds all fine and great, but you want to use this sparingly and only when needed as it is easy to forget about that power threshold and not think about frying the switch.
The command and modifiers look like this:
SW1(config-if)#power inline static ?
max Maximum power allowed on this interface
<cr>
SW1(config-if)#power inline static max ?
<4000-15400> milli-watts
So it can be just left at “static” as there is the <cr> there, however you can also set a max power guaranteed from that port. That is about all there is for that, just remember static = PoE priority on an interface and you are good for exam day on that topic!
One last set of commands, to turn off PoE from being supplied to switch interfaces!
This can also be done per interface, however do note this command does need to be issued on the interface(s) to take effect, below I turn off the PoE for all interfaces:
SW1(config)#int range fa1/0/1 – 24
SW1(config-if-range)#power inline never
SW1(config-if-range)#
*Mar 1 01:17:40.198: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/1, changed state to down
*Mar 1 01:17:40.265: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/7, changed state to down
*Mar 1 01:17:40.332: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/11, changed state to down
*Mar 1 01:17:40.433: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/24, changed state to down
*Mar 1 01:17:42.203: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/1, changed state to up
*Mar 1 01:17:42.270: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/7, changed state to up
*Mar 1 01:17:42.346: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/11, changed state to up
*Mar 1 01:17:44.133: %ETHCNTR-3-LOOP_BACK_DETECTED: Loop-back detected on FastEthernet1/0/24.
*Mar 1 01:17:44.133: %PM-4-ERR_DISABLE: loopback error detected on Fa1/0/24, putting Fa1/0/24 in err-disable state
*Mar 1 01:17:46.146: %LINK-3-UPDOWN: Interface FastEthernet1/0/24, changed state to down
- int range fa1/0/1 – 24 (or whatever your range you need to yank PoE for)
- power inline never
It did bounce all ports that were Up and connected, but it also put the port with the PoE phone into err-disabled mode, which requires a shut / no shut on the interface and it came back up fine but is now not providing PoE to the phone obviously 🙂
If you have made it this far without falling asleep, congratulations, cause that is all I’ve got for PoE related matters unless I run into some things down the course that involves PoE! Happy almost Monday morning!
The DEVNET GRIND! 