SG300-28P - POE not correctly supported on all ports - possible firmware or hardware issue

[Cinemaffect]

So, I spent some time this weekend troubleshooting the issues I've had  with the new SG300-28P switch and POE to many of my devices in the  office.  As a recap, I cannot utilize all of the 24 POE ports on the switch  for POE purposes.  Really only every other port [with a few odd  combinations thrown in between]. In addition, the SG300-28P switch, on occasion, is sending POE to non-POE devices [e.g. my Ruckus Zone Director 1106].

Here are my POE devices [all 802.3 af-compliant]:

• 3 Ruckus 7982 access points
• 1 Pakedge access point
• 2 home-automation controllers
• 2 Polycom voip phones

I called Cisco support several times in regards to this problem, and they figured it was a hardware issue - a faulty switch.  So, Cisco sent me a replacement SG300-28P, which I  hooked up today.  The exact problem still occurs.  Default configuration  [fresh out of the box].  No way I can land, for example, the 3 Ruckus  7982 AP's on ports 1, 2, and 3 [or ports 1,13, and 2].  I have to put  them on ports 1, 3, and 5 in order for them to power up.  In addition, I  can't plug any other POE devices on the ports either between or below  them.   I had to skip another port bay.  This is very odd behavior!!   Two Cisco SG300-28P's in a row with the same problem.

However, I also had one of the new Cisco SG300-10P switches in my  possession for a recent project of ours.  I decided to hook up the same  POE devices to this switch.  ALL POE devices were recognized and  worked!  No need to skip a port.  And it didn't matter what device was  plugged in first or not.  I am now convinced that it is either a  hardware issue [bad power supply/transformer?] inside all of the  SG300-28P switches, or a firmware issue. 

Both of the SG300-28P switches were running firmware 1.1.2 [the  latest on Cisco's website].  So, I decided to install an older firmware  version on the SG300-28P switch that I'm returning [installed 1.1.1.8].   Here's what I found out.  I could then plug 2 POE devices [e.g. two  Ruckus AP's] in adjacent horizontal ports, but not three in a row.  In  addition, not all adjacent ports.  It's funky. For example, I could plug  an access point in ports 20 and 21, but not in 21 and 22.  No rhyme or  reason in how it worked.  And I still couldn't plug an access point in  adjacent vertical ports [e.g. ports 1 and 13].  BUT...

It's interesting that the same exact switch that would not initially  allow 2 horizontally-adjacent POE ports to be utilized WOULD allow 2  horizontally-adjacent POE ports to be utilized when running a different  firmware version.   It's also interesting to note that when plugged into  a "non-working" POE  port, the SG300-28P would actually make a small whining noise.  Very  subtle noise; I could hear it when approx. 1ft away from the switch.   The noise was not noticeable when ports were skipped [and POE actually  worked].  Therefore, I believe that Cisco has some SG300-28P firmware  bugs [at least in the last two versions of firmware] that is not truly  allowing all 24 ports to utilize POE correctly.  This problem does not  exist with the SG300-10P switch.

I'm really interested to hear what Cisco's reply and findings on this  matter would be.  And would welcome a reply from one of their senior  support team members/managers who could actually experiment with this,  too.   In addition, I'd like to know when they think a solution could be  created if it's firmware-related.  If hardware-related, I don't think  I'll be recommending any 28P switches in our projects.  Perhaps just the  regular SG300-28 with a separate SG300-10P.  It's a shame because the  SG300-28P is more of a bargain when compared to the two separate  components.

[lokibjensen]

Maybe not.  I can confirm that it works with Ruckus Zoneflex 7982's, Ruckus Zoneflex 7372's and Ruckus Zoneflex 7782's.  We do this every day.  That's good enough for me.  Just trying to help.  Have a good evening.

[Cinemaffect]

It's been a while for me to post in this thread.  However, I just wanted to say that similar to lokibjensen, I have continued to use the SG300 switches with various Ruckus AP's.  Just be aware of some of the limitations and work-arounds with the non-MP versions [excluding the sg300-10P].  The pricepoint of the SG300 line is just so appealing.

If you have the budget in a project, then go MP and give yourself a little extra piece of mind.  Otherwise, keep in mind the power layout of the 28/52 port standard-power switches when using the bigger Ruckus AP's.  I use them successfully all the time.

My suggestion is play with a few of the switches in-house for a bit when dealing with the 7982's.  You'll know what works and what doesn't.  I dont find issues with the 7363 and 7372's.

[Cinemaffect]

Also wanted to add that I do primarily resi install of Cisco/Ruckus, so most of my AP head-counts are under 6 in order to cover the home.  Most of the time, I try to dedicate a small MP switch for the wireless stuff, if possible.  The 7363/72 APs, however, make up the majority of our Ruckus AP installs for homes.  For jobs where I forsee the use of 7982's, I try to spec in MP models across the board, or at least a small one dedicated for AP use, if everything's centrally wired.

Sure, there are some work-arounds with the SG300 line and Ruckus (which I hope one day will get resolved by one or both manufacturers), but it's tough to beat the price of the SG300's for a decent managed switch.

[fturner124]

This is a Ruckus AP issue.  Below is the response I received from Ruckus Support.

"...I just want to update you that hardware rework has gone into the 7982/7372/7352 platforms to eliminate the earlier PoE issues we'd encountered, and all product should be compatible/immune at this time. If you do still have any APs that appear to reboot frequently, Not powering up, we will do RMAs on those few individual units."

[lokibjensen]

From what I have been told it is NOT a Ruckus AP issue but rather an 802.3at compatibility issue with the Cisco switches as ANY 802.3at compatible device has issues with these switches, not just Ruckus.  Ruckus was going out of their way to make changes to their own devices so that they would work with these Cisco switches because they were getting too many support calls about it.  It was only the 300 series and 500 series switches that had this issue and all other Cisco switches did not.

[Lannar Dean]

Ruckus has a knowledgebase article about this issue (need a ruckus support login to view): https://support.ruckuswireless.com/answers/000001424

Summary
Ruckus Wireless is aware that when multiple ZoneFlex 7982 AP’s are connected to certain PoE switches, some AP’s fail to power up. Ruckus has investigated the issue in depth and believes this not to be a ZoneFlex7982 product problem, but rather a common design flaw found among several models of PoE switch.
Version
n/a
Workaround
The recommended work-around for this interoperability issue is to connect ZoneFlex 7982 AP’s on non- adjacent ports of the PoE switch, assuming the PoE switch exhibits the common design flaw. Using non- adjacent ports avoids illegal circuit paths forming between AP’s and is found to be an effective solution.
Root Cause
A common design practice in multiport PoE switches is to use components which group some of the Ethernet circuitry for multiple ports together – e.g. 1 component serves 2 or 4 adjacent ports. If these components are not configured properly, they can introduce “illegal” circuit paths (DC current paths) from one port to another, which can be problematic if there is an AP on both ports since it interferes with APs’ PoE circuits. Ruckus has found this to be a common cause of ZoneFlex 7982 failures on several different PoE switches.
Resolution







ZoneFlex 7982 / PoE Switch Interoperability Notice
Revision: February 11th 2013
Issue: 7982’s fail to power up when plugged in to adjacent ports on some PoE switch models
Description
When ZoneFlex 7982 AP’s are plugged in to adjacent ports on certain PoE switch models, some AP’s fail to power up. Ruckus has investigated the issue in depth and believes this not to be a ZoneFlex7982 product problem, but rather a common design flaw found among several models of PoE switch.
A common design practice in multiport PoE switches is to use components which group some of the Ethernet circuitry for multiple ports together – e.g. 1 component serves 2 or 4 adjacent ports. If these components are not configured properly, they can introduce “illegal” circuit paths (DC current paths) from one port to another, which can be problematic if there is an AP on both ports since it interferes with APs’ PoE circuits. Ruckus has found this to be a common cause of ZoneFlex 7982 failures on several different PoE switches.
Some devices are more sensitive than others to this switch design. Ruckus has reproduced the problem with switches known to have this design issue with Ruckus and non-Ruckus APs. The problem has also been reproduced on both 802.3af and 802.3at switches which exhibit the issue. The problem does not exist with switches which are properly DC-isolated.

[lokibjensen]

I wish it were as simple as not plugging into adjacent ports.  Unfortunately it's not.

[devils_advocate]

Was there ever a resolution to this?

Do any of the latest Ruckus AP's work with the Small business switches?

[Aleksandra Dargiel]

Hi Devils,

They should work with SG300-28PP-K9 where PoE implementation should be more compatible with 3rd party devices.

Just to let you know SG300-28P was announce End of life: http://www.cisco.com/c/en/us/products/collateral/switches/small-business-stackable-managed-switches/eos-eol-notice-c51-733213.html?emailclick=CNSemail

Regards,

Alesandra

[Helmeczi Zoltan]

Hi All!

I have the same issue. In my implemantation ther is 1 SG300-28P, 1 SG300-10P, and 7 1600 series AP.

4 AP use the 28P model on ports 21-24, but the 24. port dont grant PoE.

(or just somethimes for a short time. After reboot, but not always) 

3 AP use the 10P model on ports 1-3, but the 1. port dont link up with the AP.

(only PoE is good on port 1, the AP booting up, but no link with the switch. I dont know how it is possible.

Tried 3pcs of 1600 series AP connected with a 2m Cat5e patch cable to the switch, but same problem/result occurs.)

So these APs not 3rd party devices, but the problem is still consists.

And i understand, there are newer switches, like Aleksandra sad (SG300-28PP-K9), but

what do You think? a customer want to throw out his newly acquired 300 series switches and should buy new devices (because unfortunatelly SG300 not able to do what is in the datasheet)?

Or Cisco will replace the SG300-28P for free with an SG300-28PP?

Or what do you think, when will the customer buy any other cisco product, when i have to say

during installation, that "sorry only this and this ports supports PoE correctly" or when i have to start my install with an RMA process because the out of box devices (2 of 2 switch!) are faulty...

[Aleksandra Dargiel]

Hi Zoltan,

I understand your concern but neither way please open ticket with Small Business Support team:

http://www.cisco.com/c/en/us/support/web/tsd-cisco-small-business-support-center-contacts.html

Regards,

Aleksandra

[Chris Butler]

Had the exact issue and found our problem - and fixed it!

Our neighboring switch to the SG300-28P was a SG500-52P.  We had 2 cat6 copper uplinks going to it.  These ports had PoE enabled.  We discovered by unplugging the power supply on the SG300-28P that the switch was still powered on by these PoE uplinks.  The switch would stay powered on but not have enough power to send to the APs.

"Power inline never" on copper uplinks from neighboring switches, restore power supply to SG300-28P and Access Points powered up.  Hope this helps someone else :)

[Adrien LERAYER]

I know this is an old post, but I had the same problem and here is how I solved it :

I just changed the Power Management Mode from Class to Dynamic with the following command in config mode :

(config)# power inline management dynamic

From this, all IP telephones with PoE that were not working started to boot up.

And the Test-Fail disappeared from the "show power inline" command.

I hope this will help :)

[jgould0011]

I found this thread and HAVE to reply because I know see my problems are definitely related to this. I have a few SG500-52P. I've replaced the one about two years ago, same thing happened again about a year after that, and today I find that it happened AGAIN.

See my thread HERE from 2 yrs ago when I posted about it. Only now did I realize that the ports that stop working show "invalid signature counter" and "denied counter" increasing. Everything will work fine for about a year and then randomly this starts happening.

This happens with Polycom and Yealink PoE VOIP phones plugged in. Doesn't matter if I run them directly off the switch with CAT5E patch cables or into my patch panels (also CAT5E cabling). Doesn't matter if I skip ports either. Doesn't matter if I try to power other devices (grandstream phones, ubiquiti UAP's, etc).

The phones themselves are fine and can be power up using different switch ports.

Also, it's always a whole 6 port "cassette' that starts acting this way.

We are not even close to budget (54W total).

So here I am again with a drop of ports on my switch that don't supply PoE to devices. And no, I won't run CAT3 cable, that isn't a solution. Certainly not when you daisychain a PC off a PoE phone. Certainly not going to spend 20k on CAT3 wiring.

[jgould0011]

I was able to get the switch working again, BUT this really seems like an issue with the switch firmware. I've had the same problem across 3 different firmware over the years (I've been running the latest for this last incident).

I tried to power cycle just the switch giving me the issue. It is 1 of 4 in a stack. When the switch came back online the problem persisted.

So instead I unplugged all 4 switches in the stack and then proceeded to bring them back up 1 by 1. The issue I was having now went away and everything worked again.

I suspect that a reboot of the switch stack (via the GUI or CLI) will resolve the issue as well and will be trying this tonight on ANOTHER stack of switches I'm having this issues with at a remote facility.

Having to shutdown the entire stack of switches makes this even more of an issue for me.