SG300 PoE-short counters

[Helmeczi Zoltan]

Hi All,

We have ip cameras on a SG300-28PP switch, and one camera sometimes stop to working for a random amount of time (1/2day-2day).

After, something happens and this camera starts and working fine for a while. On the corresponding switch port i see short counters in PoE statistics.

SW3#sh power inline gi3

  Port      Powered Device         State          Status    Priority   Class

-------- -------------------- ---------------- ------------ -------- ---------

  gi3                               Auto            On      critical  class3

Time range:

Power limit: 30.0  W

Inrush Test: Enable

Port Status:               Port is on - valid capacitor/resistor detected

Overload Counter:          0

Short Counter:             52 

Denied Counter:            0

Absent Counter:            0

Invalid Signature Counter: 0

SW3#

Can you give me detailed explanation about short counters?

e.g.: What can cause this counter incrementation? or it is a switch related problem or can cause the cabling or the connected device?

Thanks,

Zoltan

[Dan Lukes]

Short Counter — Number of times there has been a power shortage.

Taken from Configuration of Power over Ethernet (PoE) Settings on Cisco 200/300 Series Managed Switches

See also: SG300-28P: POE power drops every several minutes

[Helmeczi Zoltan]

Thanks Dan!

I read and understand this line from the config guide.

This counter is increment if power shortage occurs.

But i'm not sure about the causes what can increment this counter.

Or what factors/phenomenons can cause power shortages.

I wants to sure about what is the main problem, because this occurs 3-4 times yet and we always change the faulty camera to a new one, but it is not the way of troubleshooting.

So it would be great if i could prove if it is a switch problem or it is due to cameras error.

Thanks, Zoltan.

[Dan Lukes]

I wish someone else will respond you as I'm no expert on SG300.

I found no detailed description of counter in question, despite similar error counter is available on many PoE servers including those from non-Cisco vendors. I'm just guessing it's incremented when power is removed from device because device with higher priority is asking for power and there's no budget to satisfy both devices.

Output of show power inline and show power inline detail may help. If debug ilpower ... command is supported on SG300 then it may reveal details as well (you need to wait for event).

Just for completeness (it's not for SMB segment, but may be partially helpful): Troubleshooting Power over Ethernet (PoE)

[Helmeczi Zoltan]

Thanks Dan, for the link!

It's a good documentation!

Unfortunatelly in SG300-28PP cli there isnt so much option to show more detailed information (no show power inline detail or debug ilpower command).

I saw the 'debug-mode' command which will maybe good, but im not sure how to use this exec mode, because no documentation about it. And the CLI reference guide doesnt contains this command.

Somebody have any documantation or information about this 'debug-mode' ?

Thanks, Zoltan.

[Glenn Martin]

Thanks Dan, and sorry for the late reply..

Short counters monitors the number of power shortages encountered on the powered ports. Setting Priority Power Levels on ports will help minimize the number or shortages and should resolve your camera issues.

[Helmeczi Zoltan]

Hi Glenn!

The ports are already configured to "critical" priority where cameras were placed.

Yesterday we have problem again with camera on gi3 port, and something why it get class0 instead of calss3 as before.(power class parameters are not configurable) 

Somebody have any documantation or information about this 'debug-mode' ?

Thanks, Zoltan

[Dan Lukes]

"Class 0" mean "unknown". I assume the device has failed to claim their class properly at power-up, thus default PoE class has been assigned to port.

It should not harm so much, as both class 0 as well as class 3 devices have same upper limit of power supplied.

Well, what's now ...

SG300-28PP can deliver up to 180W of PoE power (see data sheet, Power over Ethernet (PoE) table on bottom). Based on output of sh power inline gi3 you provided above, there are 30W allocated to camera port. So the switch can power up to 6 cameras if no other PD is connected. How many PoE consumers you have connected ? Can you provide output of sh power inline for all other ports as well ?

Also, can you provide sh power inline gi3 output when camera is misdetected as class 0 device ?

In the meantime, you may consider different test as well. You have more cameras, if I understood correctly. Swap other camera from GiN to Gi3 and vice versa. Wait a while. If the short counter become incremented on GiN port instead of Gi3, it's matter of the camera/their firmware/wiring. If it will be incremented on Gi3 regardless of swap, it's matter of SG's power management. Such test will not solve the issue, but it may verify we are not on dead path.

[Helmeczi Zoltan]

Thanks Dan!

First i will do an firmware upgrade, because i found that the actual image is not the latest.

And fortunately i can go to this customer with a new camera on next week, and i will do these tests. I will post here the results.

Another interesting thing is when the camera is even then faulty it doesnt matters if i do a port 'shutdown' and then 'no shut' the camera doesnt starts.

But some time later it suddenly start (when it wants? :) ).

So until then, thanks for your helpful replies!

[Dan Lukes]

The true PoE is not just dumb power plug. There's rather complex power on sequence that needs to be followed or PSE may decide there's no PoE device connected at all (thus it give no power to them).

Some PDs are known not to follow specification. For example they draw so much power during power-on sequence (e.g. before the power budget has been granted to them). It may caused undervoltage condition as well as uncountable list of issues.

Thus not only SG's firmware but also PD's firmware may affect the results. E.g. check firmware version on camera as well. Latest firmware may not the best all the times, but it should be tried.

[Helmeczi Zoltan]

Yes!

And here would help the debug function, but no documentation about it.

or how to use this debug-mode, because it is not the traditional Cisco debug.

I tried to look at some command in debug-mode's help, but couldt find any poe related. So if anybody has information about this, please let me know...

[Helmeczi Zoltan]

Dan,

There are cameras on all 24 ports. But the overall pover consumption was 70% at night,

when IR leds are active and the cameras use the max power.

I attached the datasheets of these devices and the outputs the 'sh pow in' commands.

Thanks, Zoltan.

[Dan Lukes]

Well, I'm no expert on PoE management implementation in SG300, but using just mathematics, it seems you have up to 7.5W per port max (180W/24ports).

But camera specification claim it can draw up to 8.04W per camera, e.g. 192W in total. It's not available on SG300-28PP switch. In advance, PoE management is not based on true current that the device is drawing. The device needs to claim their demand and SG will allocate power budget to it (if available). So we are not interested so much to know true power consumption (as shown by 'sh pow in'). So we need to know rather demand claimed by camera to SG than true consumption.

To make it more clear - if a camera is claiming it will draw 15.4W and SG will approve such drawing, then the SG needs to be ready to supply it anytime. So the sum of granted power must not exceed 180W of available power.

Well, there's something unclear to me. According the output you provided, the camera is asking for class 3, e.g. 15.4W.

I really don't understand how the SG can grant class 3 power on all 24 ports with only 180W PoE power supply available.

Well, some non-standard devices are known to claim self to be class 3 devices, but then use LLVM protocol to clarify their demand (according specification the LLVM capable devices should claim class 4 instead). It's the only explanation of the behavior observed I know.  In such case we need do see per port LLVM data (it's no problem on 'classic' switches, but I don't know it's possible on SG300).

OK. I feel it may sound so complex. Let's simple variant - SG may be overloaded (in the term of power, not the data bandwidth).

Complete the test I proposed in my previous comment. If the issue will manifest to be tied to particular camera, then forgot all those paragraph above, it's camera or wiring issue. If it show the issue is camera-independent, then it may be matter of overloading. In such case try to disconnect one camera. If it will work reliably with 23 cameras but not with 24 cameras, we can consider it confirmed.

KAM-SW3#sh pow in gi3

  Port      Powered Device         State          Status    Priority   Class
-------- -------------------- ---------------- ------------ -------- ---------
  gi3                               Auto            On      critical  class0

...
Invalid Signature Counter: 1

I assume the class 0 assignment is related to incremented "Invalid signature counter". It seems the device has been identified as type 1 PD, but classification of PD has been unsuccessful  thus Class 0 has been assumed (see last paragraph of 33.2.6 of 802.3at for details if you wish).

For those curious: IEEE 802.3at (namely paragraph 33)

[Helmeczi Zoltan]

Sorry Dan,

My last information was incorrect, because on this switch we have

only 6 pcs of 73048 cameras with max 8,04W power consumption,

and 18 pcs of 93024 cameras with 4,44W max power consumption,

so it is 129W total.

But if the switch allocate the class 3, e.g. 15.4W per port it may be not good too.

And it is not clear to me too why the 93024 camera get class3, if it need max 4,44W.

What dou you think, it is good idea to use the below config parameter to 

set the port power limit?

KAM-SW3#conf t
KAM-SW3(config)#int gi3
KAM-SW3(config-if)#pow in
  limit                              The port limit of the interface from the point of view of inline power management.
  never                           Turns off the device discovery protocol
  powered-device        powered device
  priority                         The priority of the interface from the point of view
                                        of inline power management
  auto                             Turns on the device discovery protocol
KAM-SW3(config-if)#pow in limit
  <0-30000>            Specify the port limit in milliwatt
KAM-SW3(config-if)#pow in limit

[Dan Lukes]

According the 'sh pow in' all devices connected claimed self to be class 3 (15.4W).

Yes, 4.44W device should call for class 2 instead.

It's so common the vendors doesn't care and ask class 3. Even Cisco's own IP phone has claimed class 3 for long time. Then, after a firmware upgrade, it claim class 2 if standalone, or class 3 it equipped with extension console. So we don't know for sure what class the 93024 is requesting.

Well, it may be firmware bug so 'sh pow in' show improper data (other that PoE management is using). No way to verify unless we can connect a "we are sure it's class 1 PoE class device".

it is good idea to use the below config parameter to set the port power limit

Definitely yes, at least for the purpose of test. Please don't miss the "from the point of view of inline power management" phrase. Because power is dissipating from the wire, the SG needs to supply more than drawn by device. For example 15.4W of class 3 is from taken from suppliers side. On device's side there's only about 13W available.

Thus you should set limit about 10000mW for 73048 and about 5500mW for 93024. It still fit the overall 180W limit.

Just a warning - I'm not sure it turn of just power limit negotiation, or it will force PoE turned on all the times. In the second case, you should not plug a non-PoE device to port with PoE forced on. It may harm the non-PoE device.

On the other side, don't hesitate about PoE devices so much. If you will plug 93024 camera to port configured for 73048 it will not harm at all. If you will plug 73048 camera to port configured for 93024 it will not harm, but it may not work (as it will try to overdraw according the limit configured; the Overload Counter should be incremented).