Cisco power controller reports power imax error detected

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 <interface> detail command.

3850_4#sh power inline Te 3/0/44 detail
 Interface: Te3/0/44
 Inline Power Mode: auto
 Operational status: on
 Device Detected: yes
 Device Type: Ieee PD
 IEEE Class: 3
 Discovery mechanism used/configured: Ieee and Cisco
 Police: off
 Power Allocated 
 Admin Value: 60.0
 Power drawn from the source: 15.0
 Power available to the device: 15.0
Actual consumption
 Measured at the port: 6.1
 Maximum Power drawn by the device since powered on: 6.2
 Absent Counter: 0
 Over Current Counter: 0
 Short Current Counter: 0
 Invalid Signature Counter: 0
 Power Denied Counter: 0
 Power Negotiation Used: IEEE 802.3at LLDP
 LLDP Power Negotiation --Sent to PD--      --Rcvd from PD--
   Power Type:          Type 2 PSE           Type 1 PD
   Power Source:        Primary              PSE
   Power Priority:      low                  high
  Requested Power(W):  12.7                 12.7
   Allocated Power(W):  12.7                 12.7
Four-Pair PoE Supported: Yes
Spare Pair Power Enabled: No
Four-Pair PD Architecture: Shared

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:

show mgmt-infra trace message platform-mgr-poe  <switch x>
debug platform poe

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:

session switch <x>
*May 20 00:34:04.445:CDP-PA: Packet received from AP2 on interface TenGigabitEthernet3/0/44
**Entry  found in cache**
*May 20 00:34:04.445: %IOSXE-7-PLATFORM: MEMBER: 3 process platform_mgr: PoE Info: Dequeued POE SPI msg ver 1 if_id 73003723793629284
 num_ports 1 req_id 650 msg_type 20
*May 20 00:34:04.452: %IOSXE-7-PLATFORM: MEMBER: 3 process platform_mgr: PoE Info: E_ILP_SET_CUTOFF if_id 73003723793629284
*May 20 00:34:04.452: %IOSXE-7-PLATFORM: MEMBER: 3 process platform_mgr: PoE Info:port 44 icutoff power 15000
*May 20 00:34:04.452: %IOSXE-7-PLATFORM: MEMBER: 3 process platform_mgr: PoE Info: re_poe_set_icutoff_current port 44 power 15000
*May 20 00:34:04.452: %IOSXE-7-PLATFORM: MEMBER: 3 process platform_mgr: PoE Info: scale factor 22 for power 15000
*May 20 00:34:04.452: %IOSXE-7-PLATFORM: MEMBER: 3 process platform_mgr: PoE Info: POE_SET_CUTOFF_CURRENT_SCALE_FACTOR sent
 for port 44 (e:11)

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 <value>.

3850_4#sh run int te 3/0/44
interface TenGigabitEthernet3/0/44
  power inline static max 20000
end
3850_4#sh power inline te 3/0/44 detail
Interface: Te3/0/44  
Inline Power Mode: static  
Operational status: on  
Device Detected: yes  
Device Type: Ieee PD
IEEE Class: 3  
Discovery mechanism used/configured: Ieee and Cisco  
Police: off
Power Allocated  Admin Value: 20.0  
Power drawn from the source: 20.0
Power available to the device: 20.0

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.

3850_4#sh cdp neigh te 3/0/44 detail
-------------------------
Device ID: AP2
Entry address(es): 
  IPv6 address: FE80::CEEF:48FF:FEC2:1B9B  (link-local)
Platform: cisco AIR-CAP3501I-E-K9,  Capabilities: Router Trans-Bridge Source-Route-Bridge IGMP 
Interface: TenGigabitEthernet3/0/44,  Port ID (outgoing port): GigabitEthernet0
Holdtime : 163 sec
Version :
Cisco IOS Software, C3500 Software (AP3G1-K9W8-M), Version 15.3(3)JNB3, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2016 by Cisco Systems, Inc.
Compiled Tue 05-Jan-16 00:44 by prod_rel_team
advertisement version: 2
Duplex: full
Total cdp entries displayed : 1
3850_4#sh power inline te 3/0/44  
Interface Admin  Oper       
Power   Device              Class Max
                            (Watts)
--------- ------ ---------- ------- ------------------- ----- ----
Te3/0/44  auto   on         15.4    AIR-CAP3501I-E-K9   3     60.0 

Now as soon as power negotiation happened the switch allocates less power. To note, in the output of the show cdp neig <if> 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.

3850_4#sh cdp neigh te 3/0/44 detail
-------------------------
Device ID: AP2
Entry address(es): 
  IP address: 10.1.200.2
  IPv6 address: FE80::CEEF:48FF:FEC2:1B9B  (link-local)
Platform: cisco AIR-CAP3501I-E-K9,  Capabilities: Trans-Bridge Source-Route-Bridge IGMP 
Interface: TenGigabitEthernet3/0/44,  Port ID (outgoing port): GigabitEthernet0
Holdtime : 172 sec
Version :
Cisco IOS Software, C3500 Software (AP3G1-K9W8-M), Version 15.3(3)JNB3, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2016 by Cisco Systems, Inc.
Compiled Tue 05-Jan-16 00:44 by prod_rel_team
advertisement version: 2
Duplex: full
Power drawn: 15.000 Watts
Power request id: 15079, Power management id: 2
Power request levels are: 15000 14500 0 0 0 
Management address(es): 
  IP address: 10.1.200.2
3850_4#sh power inline te 3/0/44 detail
 Interface: Te3/0/44
 Inline Power Mode: auto
 Operational status: on
 Device Detected: yes
 Device Type: cisco AIR-CAP3501I-
 IEEE Class: 3
 Discovery mechanism used/configured: Ieee and Cisco
 Police: off
 Power Allocated 
 Admin Value: 60.0
Power drawn from the source: 15.0
 Power available to the device: 15.0
 Actual consumption
 Measured at the port: 6.1
 Maximum Power drawn by the device since powered on: 6.2
 Absent Counter: 0
 Over Current Counter: 0
 Short Current Counter: 0
 Invalid Signature Counter: 0
 Power Denied Counter: 0
 Power Negotiation Used: CDP
 LLDP Power Negotiation --Sent to PD--      --Rcvd from PD--
   Power Type:          -                    -
   Power Source:        -                    -
   Power Priority:      -                    -
   Requested Power(W):  -                    -
   Allocated Power(W):  -                    -
Four-Pair PoE Supported: Yes
Spare Pair Power Enabled: No
Four-Pair PD Architecture: Shared

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. 

3850_4#sh lldp neighbors te 3/0/44 detail
------------------------------------------------
Local Intf: Te3/0/44
Chassis id: 2c3f.387e.91d0
Port id: Gi0
Port Description: GigabitEthernet0
System Name: AP2.cisco.com
System Description: 
Cisco IOS Software, C3500 Software (AP3G1-K9W8-M), Version 15.3(3)JNB3, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2016 by Cisco Systems, Inc.
Compiled Tue 05-Jan-16 00:44 by prod_rel_team
Time remaining: 64 seconds
System Capabilities: B
Enabled Capabilities: B
Management Addresses:
    IP: 10.1.200.2
Auto Negotiation - supported, enabled
Physical media capabilities:
    1000baseT(FD)
    1000baseT(HD)
    100base-TX(FD)
    100base-TX(HD)
    10base-T(FD)
    10base-T(HD)
Media Attachment Unit type: 30
Vlan ID: - not advertised 
Total entries displayed: 1 
3850_4#sh power inline te 3/0/44 detail 
 Interface: Te3/0/44
 Inline Power Mode: auto
 Operational status: on
 Device Detected: yes
 Device Type: Ieee PD
 IEEE Class: 3
 Discovery mechanism used/configured: Ieee and Cisco
 Police: off
 Power Allocated 
 Admin Value: 60.0
Power drawn from the source: 15.4
 Power available to the device: 15.4
 Actual consumption
 Measured at the port: 5.2
 Maximum Power drawn by the device since powered on: 5.3
 Absent Counter: 0
 Over Current Counter: 0
 Short Current Counter: 0
 Invalid Signature Counter: 0
 Power Denied Counter: 0
 Power Negotiation Used: None
 LLDP Power Negotiation --Sent to PD--      --Rcvd from PD--
   Power Type:          -                    -
   Power Source:        -                    -
   Power Priority:      -                    -
   Requested Power(W):  -                    -
   Allocated Power(W):  -                    -
Four-Pair PoE Supported: Yes
Spare Pair Power Enabled: No
Four-Pair PD Architecture: N/A

Once it boots up, allocation gets lowered.

3850_4#sh lldp neighbors te 3/0/44 detail
------------------------------------------------
Local Intf: Te3/0/44
Chassis id: 2c3f.387e.91d0
Port id: Gi0
Port Description: GigabitEthernet0
System Name: AP2.cisco.com 
System Description:
Cisco IOS Software, C3500 Software (AP3G1-K9W8-M), Version 15.3(3)JNB3, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2016 by Cisco Systems, Inc.
Compiled Tue 05-Jan-16 00:44 by prod_rel_team
Time remaining: 108 seconds
System Capabilities: B
Enabled Capabilities: B
Management Addresses:
    IP: 10.1.200.2
Auto Negotiation - supported, enabled
Physical media capabilities:
    1000baseT(FD)
    1000baseT(HD)
    100base-TX(FD)
    100base-TX(HD)
    10base-T(FD)
    10base-T(HD)
Media Attachment Unit type: 30
Vlan ID: - not advertised
PoE+ Power-via-MDI TLV:
 Power Pair: Signal
Power Class: Class 3
 Power Device Type: Type 1 PD
 Power Source: PSE
 Power Priority: high
 Power Requested: 12700 mW
 Power Allocated: 12700 mW
Total entries displayed: 1
3850_4#sh power inline te 3/0/44 detail
 Interface: Te3/0/44
 Inline Power Mode: auto
 Operational status: on
 Device Detected: yes
 Device Type: Ieee PD
 IEEE Class: 3
 Discovery mechanism used/configured: Ieee and Cisco
 Police: off
 Power Allocated 
 Admin Value: 60.0
 Power drawn from the source: 15.0
 Power available to the device: 15.0
 Actual consumption
 Measured at the port: 6.1
 Maximum Power drawn by the device since powered on: 6.2
 Absent Counter: 0
 Over Current Counter: 0
 Short Current Counter: 0
 Invalid Signature Counter: 0
 Power Denied Counter: 0
 Power Negotiation Used: IEEE 802.3at LLDP
 LLDP Power Negotiation --Sent to PD--      --Rcvd from PD--
   Power Type:          Type 2 PSE           Type 1 PD
   Power Source:        Primary              PSE
   Power Priority:      low                  high
  Requested Power(W):  12.7                 12.7
   Allocated Power(W):  12.7                 12.7
Four-Pair PoE Supported: Yes
Spare Pair Power Enabled: No
Four-Pair PD Architecture: Share

Output from the show power inline <interface> 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.

Sep 22, 2020
• 1 min read

One of my IP cameras stopped working. It is PoE camera, so I restarted its port on my Cisco Catalyst 3750X switch, but that did not help. Looking at logs shown repeted error:

May  1 23:35:37.769: %ILPOWER-7-DETECT: Interface Gi1/0/6: Power Device detected: IEEE PD
May  1 23:35:38.775: %ILPOWER-5-POWER_GRANTED: Interface Gi1/0/6: Power granted
May  1 23:35:39.010: %ILPOWER-3-CONTROLLER_PORT_ERR: Controller port error, Interface Gi1/0/6: Power Controller reports power Imax error detected

May  1 23:35:49.756: %ILPOWER-7-DETECT: Interface Gi1/0/6: Power Device detected: IEEE PD
May  1 23:35:50.763: %ILPOWER-5-POWER_GRANTED: Interface Gi1/0/6: Power granted
May  1 23:36:18.764: %ILPOWER-3-CONTROLLER_PORT_ERR: Controller port error, Interface Gi1/0/6: Power Controller reports power Imax error detected

Solution to this by Cisco is to use… longer cable. Of course longer cable is not an option if you have all cables sealed in walls. One other option for extending cable is to add longer patchcord from patchpanel to switch if it is possible.

Seconf option is if you have most recent IOS to use command on problematic port:

power inline port 2x-mode

Complete configuration:

(config)#interface Gi1/0/6
(config-if)#power inline port 2x-mode
(config-if)#shutdown
(config-if)#no shutdown

After couple of seconds port came to life without any problem and camera started broadcasting.

May  1 23:51:06.908: %ILPOWER-7-DETECT: Interface Gi1/0/6: Power Device detected: IEEE PD
May  1 23:51:07.847: %ILPOWER-5-POWER_GRANTED: Interface Gi1/0/6: Power granted
May  1 23:51:08.275: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/6, changed state to down
May  1 23:51:11.303: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/6, changed state to up

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!

Источник

We are about to deploy the Aruba IAP-105s firm wide to the tune of about 200 APs.  I have been having issues with my pilot group where the IAP-105 suddenly fail.  Fail in the sense that they no longer are able to pull Power from the switch.  The switch reports 

ILPOWER-3-CONTROLLER_PORT_ERR: Controller port error, Interface Gi1/0/15: Power Controller reports power Imax error detected

which basically means the switch sees the device trying to pull more power than it can support.  Now I have 10 other APs connected the same type of switch running the same IOS.  The failures have no pattern.  Today I had a 4th one fail in this manner.  Once they fail they will work only if they are powered externally.  

I had a second one fail today as well.  This was the one that I used to replace the failed one.  I did plug it back into the same port and it failed about an hour later.  I have had APs fail on other ports so it isn’t isolated to a single port or switch. However,  the second one to fail today will work if it is connected to a Cisco 3750-x which supports up to 30mw of power per port.

I have changed switches, cables, IOS on the switch and the IAP.

Anyone having similar issues or know of anyone that is.

I recently encountered some issue, no PoE given to the ip phone and saw below lines in the switch log:

%ILPOWER-3-CONTROLLER_PORT_ERR: Controller port error, Interface Gi0/16: Power given, but Power Controller does not report Power Good

SWITCH#sh power inline
Available:370.0(w) Used:0.0(w) Remaining:370.0(w)

Interface Admin Oper Power Device Class Max
(Watts)
--------- ------ ---------- ------- ------------------- ----- ----
Gi0/1 auto off 0.0 n/a n/a 15.4
Gi0/2 auto off 0.0 n/a n/a 15.4
Gi0/3 auto off 0.0 n/a n/a 15.4
Gi0/4 auto off 0.0 n/a n/a 15.4
Gi0/5 auto off 0.0 n/a n/a 15.4
Gi0/6 auto off 0.0 n/a n/a 15.4
Gi0/7 auto off 0.0 n/a n/a 15.4
Gi0/8 auto off 0.0 n/a n/a 15.4
Gi0/9 auto off 0.0 n/a n/a 15.4
Gi0/10 auto off 0.0 n/a n/a 15.4
Gi0/11 auto off 0.0 n/a n/a 15.4
Gi0/12 auto off 0.0 n/a n/a 15.4
Gi0/13 auto off 0.0 n/a n/a 15.4
Gi0/14 auto off 0.0 n/a n/a 15.4
Gi0/15 auto off 0.0 n/a n/a 15.4
Gi0/16 auto faulty 0.0 n/a n/a 15.4

Sometimes it can be an IOS bugs, some workaround is to reboot the switch. But before doing that it’s better if we use Time-Domain Reflectometer (TDR) features to diagnose the physical cabling.

What is Time-Domain Reflectometer (TDR)?
“A time-domain reflectometer (TDR) is an electronic instrument used to characterize and locate faults in metallic cables (for example, twisted wire pairs, coaxial cables)

How can TDR help me?
TDR, in its simplest form, can help you determine IF you have a cable problem, WHICH pair(s) is/are faulty and HOW FAR away the fault is.

Typically, when you have a Layer 1 issue there are a lot of factors to consider:
Local-end Side (LeS) patch cable;
Local-end Side (LeS) patch panel (including punch block);
Horizontal cable;
Remote-end (Red) patch panel (including punch block);
Remote-end (Red) patch cable; and
Remote-end (Red) device NIC

So you see, TDR minimize the guess-work.

To start diagnostic:

SWITCH#test cable-diagnostics tdr interface gigabitEthernet 0/16

wait for the test to start, after 4-7 seconds, run below command

SWITCH#sh cable-diagnostics tdr interface g0/16

TDR test last run on: October 09 10:46:53

Interface	Speed	Local pair	Pair length	Remote pair	Pair status
Gi0/16	auto	Pair A	49+/- 4 meters	Pair A	Normal
		Pair B	48 +/- 4 meters	Pair B	Normal
		Pair C	49+/- 4 meters	Pair C	Normal
		Pair D	49+/- 4 meters	Pair D	Normal

Based on above result, we know the cable having an issue. So what does this result above tell us?

Port tested is on GigabitEthernet 0/16;
Port has negotiated to auto;
Cable use is a straight-through cable (look and compare the values of “Local pair” and “remote pair”);
Cable length is approximately 49 metres long and an error (length-wise) of 4 metre; and
All four pairs are working fine (Pair status)

Under “Pair status” you can get the following results:

Result	Explanation
Normal	If testing FastEthernet, you want Pair A and B as “Normal”. If testing GigabitEthernet, you want ALL as “Normal”.
Open	Open circuit. This means that one (or more) pair has “no pin contact”.
Short	Short circuit.
Impedance Mismatched	Bad cable. For more explanation, go here

Cable Pairs explained?

Pairs	Functions
A	This pair controls whether or not the port should go up or down.
B	Protocol-level and controls FastEthernet.
C	Power over Ethernet (PoE)
D	GigabitEthernet

Caveats:
Any Gotchas I need to be aware of?
Switches need to run IOS version 12.2 or later. TDR is supported in IOS version 15.0. IOS version 12.0 and 12.1 do NOT support TDR.

If you are running IOS version 12.2(46)SE or earlier, TDR test is DISRUPTIVE. During the test, the interface will go down and up. For obvious reasons, anything connected will lose network connectivity.

If the remote-end device is a power-over-ethernet (PoE) device, the test will cause the device to lose power. If you have, for example, a Voice over IP (VoIP) phone and a PC client is connected to the phone, both the phone and client will lose network connectivity because the phone does not have a bypass functionality. This will affect ALL IOS versions.

Particularly when you are running old IOS versions, the test can take between five (5) to seven (7) seconds.

TDR works on 10/100/1000BaseTx. Fibre optic ports (any flavours) is not covered/discussed here. TenGigabitEthernet copper port DOES NOT (YET) support TDR.

Cisco GLC-T/GLC-TX SFP module does NOT support TDR.

The next two Gotcha items are for those who plan to use the TDR feature on Cisco Catalyst 2960 and 2960G (2960S not included):

1. The 2960 will support TDR in both the FastEthernet and dual-personality GigiabitEthernet port, however, when used on a FastEthernet port, TDR will only test the first two pairs, namely Pairs A & B. For obvious reasons, Pairs C and D will not be tested when used on non-GigabitEthernet ports. Pairs C and D will report a result of “Not Supported”.

2. Except the WS-C2960-48PDL, when using the copper GigabitEthernet (Gig 0/1 and Gig 0/2) ports of the Catalyst 2960, one must manually set the interface to copper using the command “media rj” before the test can be conducted.

Source: https://supportforums.cisco.com/docs/DOC-18983

Incoming search terms:

• Power given but Power Controller does not report Power Good
• %ILPOWER-3-CONTROLLER_PORT_ERR: : Power Controller reports Short detected
• cisco ip phone state machine power good
• Power Controller reports power Imax error detected
• power given but controller does not report
• Controller port error Interface Fa0/11: Power given but link is not up
• Controller port error Interface Gi2/0/23: Power given but State Machine Power Good wait timer timed out
• evidencev3n
• face67u
• fifthqli
• not supported TDR test on two pairs
• power given but state machine power good
• Power given but State Machine Power Good wait timer timed out
• tdr test was never run on

IOS Message — ‘Imax Error detected’ ? IOS Message — ‘Imax Error detected’ ? (OP) 15 Jul 11 04:46 Can anyone give me a clue as to what this message means? «Controller Port error. Interface …. Imax Error Detected» Its on a 3750 POE switch so I presume its related to an Avaya phone on one of the ports. Googling doesn’t throw up many results Red Flag Submitted Thank you for helping keep Tek-Tips Forums free from inappropriate posts. The Tek-Tips staff will check this out and take appropriate action.

Join Tek-Tips^® Today!

Join your peers on the Internet’s largest technical computer professional community.
It’s easy to join and it’s free.

Here’s Why Members Love Tek-Tips Forums:

• Talk To Other Members
• Notification Of Responses To Questions
• Favorite Forums One Click Access
• Keyword Search Of All Posts, And More…

Register now while it’s still free!

Already a member? Close this window and log in.

Join Us             Close