Power controller reports power tstart error detected

Troubleshoot PoE Imax Errors on Catalyst 3650/3850 Switches

Available Languages

Download Options

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Contents

Introduction

This document describes how to troubleshoot PoE (Power over Ethernet) Imax errors on Catalyst 3650/3850 switches. PoE is used by Catalyst 3650/3850 switches in order to provide power to external devices such as Wireless Access Points (APs), IP phones, and so on via the Ethernet cable that attches them to the switch.

What are Imax errors?

An Imax error occurs when a PoE capable port on the switch draws more power than it negotiated. When an IEEE Powered Device (PD) comes up it gets classified into a class. Dependent upon what class a device is in, it is allocated a certain amount of Watts by the switch that acts as the Power Source Equipment (PSE). This can be renegotiated later by the device that uses Cisco Discovery Protocol (CDP) or Link Layer Discovery Protocol (LLDP) to request more or less power. This is to allow budgeting of power.

The PD ensures it does not draw more power than it is allocated. The switch controls this by setting an Icutoff value. This is the value that gets set on the controller as the high mark. When a device exceeds the Icutoff value the switch stops supplying power and logs an Imax error which indicates the attached device exceeded the negotiated wattage.

Comparison to Older Devices

The Catalyst 3650/3850 utilizes a more enhanced PoE controller. Where older devices like the Catalyst 3750 do not support much granularity with regards to setting Icutoff values, the Catalyst 3650 and 3850 do. This often leads to a perception that the Catalyst 3650/3850 experiences issues that the older devices do not. In almost all cases, however, this is just a perception. The older devices have less granularity in policing of the power and allow a PD to draw more power than negotiated. The Catalyst 3650/3850 does police the drawn power more strictly, and as such, Imax errors might occur on Catalyst 3650/3850 where a connection of the same device to an older switch would not show any problem.

Troubleshoot Imax Errors

A determination of how much power a PD really draws in the field is not very easy. When the power controller on the switch detects there is more power being drawn on a port, it shuts the port down and notifies Cisco IOS ® of the fact that the PD has exceeded the maximum allocated power. In Cisco IOS you can see the currently drawn power usage per port with the show power inline detail command.

The measured value shown at the port in this output is measured by the controller. This information is gathered every few seconds and gives some indication about the drawn power. The value shown with Maximum Power drawn appears useful to troubleshoot Imax errors, but unfortunately that is just a historical display of what the Maximum power drawn by the device has been. If an Imax error occurs, the Power drawn at that time is not reported back to Cisco IOS and will not be displayed there.

As can be seen in the example, the value allocated to the port is 15W. This is the cutoff value that gets programmed onto the interface. Prior to Cisco bug ID CSCuy7423, the Icutoff value is programmed regularly on a port. Every time a CDP packet is received the value will be reprogrammed. After Cisco bug ID CSCuy74231 (fixed in Cisco IOS-XE 3.6.5E and 3.7.5 or later) this programming has been optimized. This reduces the possibility of a «failure» in reprogramming the Icutoff value which leads to an Imax error.

Programming of Icutoff value can be shown via two commands. Either via the trace where the log can be gathered historically or a debug can be enabled to log a debug message when it occurs. The commands to get this are:

The show trace command can only be executed if the active switch in the stack is PoE capable. Otherwise, this command is needed in order to first connect to the PoE member switch in the stack to execute it:

As mentioned earlier, it is a complex process to diagnose Imax errors. There is not much information logged at the time an Imax error occurs. The controller shuts the port down and the PD would have typically lost all logs in regards to what it was doing at the time it drew more power than allocated. Measurement of the drawn power by a port in the field is not easy, but with static allocated power a determination could be made. By statically allocating more power than would be requested dynamically, it is possible to determine how much more power the PD would draw that would trigger the Icutoff threshold to be exceeded. A static maximum power consumption can be configured on a switch port with the command power inline static max .

Power Negotiation

Various IEEE classes have defined levels of power usage. Further negotiation of power is done between the PD and the PSE with either CDP or LLDP. Power negotiation plays an important part when you look at Imax errors. A PD requests how much power should be allocated to it, but it also should ensure that it will not exceed the requested value.

Class PSE PD

Class 0/Default 15.4W 12.95W

Class 1 4.0W 3.84W

Class 2 7.0W 6.49W

Class 3 15.4W 12.95W

Class 4 30.0W 25.50W

As per this table, dependent on what class is being detected, the Switch (PSE) allows a certain maximum power to be drawn. It is important to note that the standard also defines the power the PD should be able to consume. The standard allocates for a budget of power to be used by the cabling between the PSE and the PD. This also highlights how important it is to know what type of cables are used when you investigate Imax errors and to determine in what circumstances they might occur more than in others.

On top of the classification, negotiation of power is completed with the CDP or the LLDP protocol. This allows the switch to allocate more or less power than what the class has set as maximum.

As can be seen in the next example, a PD (Access Point in this case) comes up. Before power negotation has taken place, it was allocated the default 15.4W that is set for the class.

Now as soon as power negotiation happened the switch allocates less power. To note, in the output of the show cdp neig detail command are the various power levels that are requested. While some devices might just have one requirement, there are devices that would request multiple power levels. APs, for example, have the ability to power up or down radios if they would not be granted full power. In this example, the PD requests either 15000 or 14500 mW.

The use of LLDP instead of CDP shows the same results. As the PD gets powered, the device receives full 15.4W as per the class.

Once it boots up, allocation gets lowered.

Output from the show power inline detail command shows more information in regards to the negotiation that is being done than what is shown by CDP. There is also another major difference between CDP and LLDP in regards to power negotiation. CDP negotiates the amount of power provided at the port (15W). With LLDP however, you see that the PD does not negotiate the power the port should supply. It requests the amount of power the PD wishes to have. In this case it is 12.7W. The switch (PSE) has to compensate for the loss in the cabling and allocates 15W to the port. As power negotation does take place it is also key to determine what the requested power was at the time of failure. Knowledge of how long the device was up and what events might have taken place at the time of the error can provide more detail around the root cause. For example, an IP phone that comes out of sleep and turns its screen on fully might momentarily draw more power.

Summary

For Imax errors, it is hard to determine the exact cause. In almost all cases these are found to be an issue with the PD drawing more power and the PD vendor needs to be engaged in order to investigate why it exceeds the power it has negotiated with the switch.

It is also crucial to investigate the type and length of the cabling as this does change the electrical characteristics and influences the amount of power drawn on the port. It is important as well is to investigate the power negotation and confirm that the power requested by a device is also the amount of power that gets allocated. In the case of LLDP, additional budget for cabling between PD and PSE is needed. In some cases, with use of statically allocated power, it is possible to work around Imax errors and/or to determine the amount of power the device overdraws on a port. A confirmation that the PD overdraws the amount of power it gets allocated can be achieved only with power measuring and testing devices.

In Cisco IOS-XE releases 3.6.5 and 3.7.5 and later, a few improvements have been made around Imax errors:

• The amount of reprogramming of the Icutoff value to the port has been reduced.
• The allowance on the port for overdrawing power has been increased, this in some cases might be enough to prevent an Imax error.
• Some corner case scenarios were resolved where an Imax error might have occurred as a false alarm.

Источник

Power controller reports power imax error detected

На объекте, система ЛВС реализована посредством коммутаторов CISCO 2960, коммутаторы с функции PoE+, имеется около 120+ видеокамер SIEMENS, и 50+ видеокамер Hikvision, большая часть видеокамер питается по PoE от коммутаторов.
Не давно получили новые видеокамеры DS-2CD2512F-IS, вчера две штуки подключили, полет нормальный.
Сегодня утром взяли еще две, подключили к другому коммутатору, порт поднялся, питание пошло, видеокамеры включилась и появилось изображение на УРМ. И. через 5 минут камеры сдохли, в прямом смысле слова!
Сняли видеокамеры, на столе попробовали запитать от АКБ 12В — не включаются, подключили к неуправляемому коммутатору тренднет с функции PoE — не включается.
Внешних повреждений на камере — нет, запаха гари — нет.

В логах циски имеется следующее:
009756: Jun 25 12:19:46: %ILPOWER-5-POWER_GRANTED: Interface Gi1/0/26: Power granted
009757: Jun 25 12:19:50: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/26, changed state to up
009758: Jun 25 12:19:51: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/26, changed state to up
009759: Jun 25 12:19:52: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/26, changed state to down
009760: Jun 25 12:19:53: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/26, changed state to down
009761: Jun 25 12:19:56: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/26, changed state to up
009762: Jun 25 12:19:57: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/26, changed state to up
009763: Jun 25 12:20:01: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/26, changed state to down
009764: Jun 25 12:20:03: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/26, changed state to up
009765: Jun 25 12:26:43: %ILPOWER-3-CONTROLLER_PORT_ERR: Controller port error, Interface Gi1/0/26: Power Controller reports power Imax error detected
009766: Jun 25 12:26:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/26, changed state to down
009767: Jun 25 12:26:45: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/26, changed state to down

Туточки мы видим, что порт коммутатора отключился через 5 минут работы по причине «срабатывания защиты по максимальному порогу тока потребления».

Так же стоит сказать, что именно на этом злополучном коммутаторе без каких либо проблем уже в течении года работает видеокамера SIEMENS.

Стандарты питания PoE у камер и коммутатора совподают, а именно 802.3af.

Источник

PoE Part 2 – Admin states explained exhaustively, with a lot of real world on the job info you might run into!

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

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

SW1(config-if)#power inline auto max ?
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 ?
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.

SW1(config-if)#power inline consumption ?
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)
———- ———– ——————-

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 ?

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

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 ?

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

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 detected

Conditions:
Seen with some of the 3750,3750G,3750-E,3560-E, 3750-X, 3560-X, 3560-C, 2960S,
2960,2960C,2960X switches

Longer cable (>50ft) seems to fix the issue in most cases.

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 shut

The 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

SW1(config-if)#power inline static max ?
milli-watts

So it can be just left at “static” as there is the 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!

Источник

I acquired a 3750 48-PS-S with PoE.  It replaced a 24-port SG300-28P (I ran out of ports).  Devices that are receiving power from the switch are:

 
2 x Cisco SPA525G2
3 x Cisco SPA501G
2 x Cisco VC240 IP Cameras
1 x iQInvision 32M IP Camera (Mounted in warehouse high in the rafters)
1 x WAP200
1 x WAP200E (Mounted in warehouse high in the rafters)

 
When I plug the WAP200E into the 3750, I was getting the error:

 
«Controller port error, Interface Fa1/0/XX: Power Controller reports power Tstart error detected»

 
I would only get the error on the WAP200E.  All other devices (except the iQInvision camera, more on that later)  power on and function just fine.  WAP200E specs state that it should only draw 8.5 watts.  When I ‘sh power inline’, the WAP200E was only using like 7.5 watts and the other devices on the entire switch are only using 74 of the 370 watts available.  I have tried other ports on the switch with the same results.  I don’t have the rackspace to put the SG300 back in service and trunk to it just for a WAP200E but tested it again connected to the SG300 and it powers and functions just fine on the SG300.

 
There is also something else in the message about the «lmax/tstart» error.  After doing some research on the web, supposedly IOS 12.2.55 SE3 or 12.2.58 SE1 will get rid of the error.  The switch is currently running 12.2.55 SE5.  I have not found these versions to download, only 12.2.55 SE1 or SE6.  I have tried 12.2.55 SE6 IP Services and now the problem has gotten worse.  When I plug the WAP200E into the 3750, the port light flashes just ever so briefly and then the Oper of the port shows Faulty when i issue a ‘sh power inline’.  

has-switch#sh power inline fa1/0/40
Interface Admin  Oper       Power   Device              Class Max
                            (Watts)
——— —— ———- ——- ——————- —— —-
Fa1/0/40  auto   faulty     0.0     n/a                 n/a   15.4

Interface  AdminPowerMax   AdminConsumption
             (Watts)           (Watts)
———- ————— ———————

Fa1/0/40              15.4                 15.4

I had already upgraded the firmware on the WAP200E to WAP200E-FW-2.0.5.0.rmt when it was still connected to the SG300-28P.

 
I see if I had a 3750X Series, I could issue the interface command ‘power inline 2x’ and that was supposed to get rid of the error but I am only on a 3750 Series.

I read another thread on here about a WAP200/3560 with a similar issue and BPDU packets, tried disabling that with the ‘no spanning-tree bpduguard’ and still the same.  The config for the port looks like:

has-switch#sh run int fa1/0/40
Building configuration…

Current configuration : 181 bytes
!
interface FastEthernet1/0/40
 description WAP200E
 switchport access vlan 172
 switchport mode access
end

I have a WAP200 and it is working fine.  I had to setup the VLAN/SSID mapping to replace the 200E but had to enable DHCP on my ASA5505 firewall VLAN since the WAP200 is in the DMZ for customers.  The WAP200E is on my DATA VLAN behind the ASA5505.  It is located in the rafters of my warehouse and covers the entire building.  The WAP200 is in the office and has very limited coverage and really don’t like using DHCP on my firewall.

The only other thing I can think of is that the warehouse is out-of-spec for temperature right now.  Since changing over to the 3750, it has only been about 10 degrees F but the WAP200E specs show -4 to 140 F.  I only am concerned with this since the IQInvision camera is not functioning either but it powers on, stays powered on but will not show up on the network.  If I ping its address, it will show in the arp cache for a while but its MAC shows INCOMPLETE.  I was told by someone to put them where there is enough heat to test but that defeats the purpose of the 200E compared to the 200 and I cannot access either without the help of someone else to drive a forklift.

It is supposed to be 40 degrees on Sunday so maybe both will start to function.  If not, is there anything anyone can add here?

I have tried some of the different ‘power inline’ commands but still the same.

Any help/ideas would be appreciated.

 
Thanks.