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.

[Nagaraja Thanthry]

Hello lokibjenson,

First of all, it is not necessarily a bug on the switch but it is more of an interoperability issue. As Tom noted, the switch works well with many other POE clients without any issues. This behavior is noted only with some of the POE clients. There was a bug filed to track this behavior and investigate through the Engineering. After further investigation, it was found that incompatibility between the POE circutary of the client and the switch is causing this. To mitigate this behavior, we can either use a CAT3 cable (lower speed) or connect one PD per each POE transformer block. Unfortunately, since it is a hardware compatibility related issue, there is not a whole lot we could do to mitigate this behavior at this point.

Hope this helps.

Regards,

Nagaraja

[lokibjensen]

I understand the position you are taking.  However, I hope that you all understand my position and why I was taken aback by being told that the "workaround" is to use CAT3.  This is not a viable workaround for any modern network and is hardly worth mentioning unless your only hope is to power the AP so as to use it as a mesh device.

[Tom Watts]

Lokibjensen, here's an excerpt

The IEEE standard for PoE requires category 5 cable or higher for high power levels, but can operate with category 3 cable if less power is required. Power is supplied in common mode over two or more of the differential pairs of wires found in the Ethernet cables and comes from a power supply within a PoE-enabled networking device such as an Ethernet switch or can be injected into a cable run with a midspan power supply.

In the most simplistic term, a POE injector. You may be able to condition the power. You may want to research this with Ruckus to ensure you don't damage components.

-Tom
Please mark answered for helpful posts

[w_smith]

Hi Tom,

Respectfully, that doesn't really answer the question.  I understand hardware incompatibility, and issues with "differential" parsing of standards, but if there's an issue with Cisco switches and other devices, some engineer needs to sit down and determine exactly which part of the standard isn't being met in which piece of equipment.

If it's Ruckus and others,then Cisco needs to publish a note that says "some vendors don't support correctly, but our switches pass (for instance)

ftp://ftp.iol.unh.edu/pub/ethernet/test_suites/CL33_PSE/PSE_test_suite_V2.8.pdf

with flying colors, and those other vendors fail tests x,y, and z of (say)

ftp://ftp.iol.unh.edu/pub/ethernet/test_suites/CL33_PD/PD_Test_Suite_v2.0.pdf

OR Cisco needs to own up to "oh, oops, we don't do properly, and we've fixed it in the next release, and we'll exchange hardware for folks who are impacted."  [Yes, that can be expensive, but so is an entire line of Cisco products that don't operate as advertised.  I'm not going to buy many more $1K switches for clients if I show up on install day and discover "oh, that doesn't work, I'll be back next week with something that will."  That makes me look like an idiot for buying Cisco equipment, and that's not good for anyone involved.]

There are lots of test labs who will be happy to check your products, but I can't imagine that Cisco doesn't have it's own.  From this thread it appears that Cisco knows what the problem is, but is reluctant to fix it.  The standard is 3 years old, the details of implementing it can't be a mystery today...

And this business of CAT3 cable not only doesn't make any sense (unless the switch can determine which cable type is connected and automatically modify itself appropriately), and it's certainly not a viable solution in this century.  Replacing the switch with another vendor's equipment is a far more palatable fix...

[Nagaraja Thanthry]

Hello w_smith,

As I stated earlier, this seems to be an interoperability issue between the Ruckus access points and the SG300-28P switch. We will not be able to comment on the design of another vendor. As noted in the datasheet, the switch follows the IEEE standards for POE delivery.

Depending upon different manufacturer's circuit design, it is possible that certain end points affect the switch functioning. As noted earlier, the Ruckus AP's do work with Cisco switch and do get power through POE. However, due to the incompatibility of the design, they may affect POE capability of the remaining ports on the same POE transformer. Using a CAT3 cable to connect the AP mitigates this incompatibility and allows both the AP and Switch to operate per POE specifications. While using CAT3 cable does have performance impact, at this point of time, that is one of the ways to mitigate this issue.

As you might already be aware of, the orignal POE standards supported CAT3 cabling where the PSE delivered power over the 2 pair wires (1,2 and 3,6). CAT3 cable just uses these 2 pairs and the other 2 pair wires are not connected. From a POE perspective, CAT3 cabling is sufficient for most devices that require upto 15.4W of power. For higher power devices, you need to have all 4 pairs.

http://www.microsemi.com/documents/powerdsine/whitepapers/Understanding_802_3at_PowerDsine.pdf

Hope this helps.

Regards,

Nagaraja

[w_smith]

Hi Nagaraja,

/*

As I stated earlier, this seems to be an interoperability issue  between the Ruckus access points and the SG300-28P switch. We will not  be able to comment on the design of another vendor. As noted in the  datasheet, the switch follows the IEEE standards for POE delivery.

*/

It's not just Ruckus, there are the MacWireless splitters I referenced above.

And I'm sure Ruckus and others will say they follow the standard as well.  Probably using the same PowerDsine chipsets you guys do.  Those of us stuck in the middle with inoperative hardware aren't really too interested in which of you is pointing the finger at the other guy.

/*

Depending  upon different manufacturer's circuit design, it is possible that  certain end points affect the switch functioning. As noted earlier, the  Ruckus AP's do work with Cisco switch and do get power through POE.  However, due to the incompatibility of the design, they may affect POE  capability of the remaining ports on the same POE transformer.

*/

You don't get to say "it works fine but it doesn't work right", we expect each and every PoE port will work up to the power limit of the port and the power limit of the entire switch, not "but you can't have more than one of a particular device on the same PoE transformer".

/*

Using a  CAT3 cable to connect the AP mitigates this incompatibility and allows  both the AP and Switch to operate per POE specifications. While using  CAT3 cable does have performance impact, at this point of time, that is  one of the ways to mitigate this issue.

As  you might already be aware of, the orignal POE standards  supported CAT3  cabling where the PSE delivered power over the 2 pair  wires (1,2 and  3,6). CAT3 cable just uses these 2 pairs and the other 2  pair wires are  not connected. From a POE perspective, CAT3 cabling is  sufficient for  most devices that require upto 15.4W of power. For  higher power devices,  you need to have all 4 pairs.

*/

I think you are confusing "2-pair versus 4-pair" with "Cat3 versus Cat5".  If 2-pair patch cables will allow the switch to work with these problematic PDs, then 2-pair CAT5 patch cables may be an acceptable answer.  Converting your building to CAT3 is never a reasonable, correct, or sensible answer.  Of course, this will allow only 100BaseT networking, which may be OK in certain circumstances.

/*

http://www.microsemi.com/documents/powerdsine/whitepapers/Understanding_802_3at_PowerDsine.pdf

*/

OK, so when my switch logs a 'signature' error when connecting to one of these problem PDs, is it Physical Layer or Data-Link-Layer signature errors?

Thanks!

[lokibjensen]

Hello again.  I have a proposal I have to send out this morning and I was hoping to receive clarification on the following.  Can somebody please tell me if this issue is found on any of the following switches:

SG300-10P (aka: SRW2008P)

SG300-10MP (aka: SRW2008MP)

SG300-28MP (aka: SG300-28MP-K9-NA)

Also, why is it that I cannot find the SG300-28MP from any of my distributors?  Was this pulled for some reason?

Thank you!

[pcscontrols]

I saw this issue on our SG300-10P when using shielded cable, as soon as I removed the shield everything worked OK

[lokibjensen]

Thanks Randy!

[DARRELL MILAM]

I think you want the mp model it is supposed to have 370 watts of power 180 watts

[nenpl2014]

I have the same issue as the original poster with my SG500-52P and Ruckus ZoneFlex 7982 APs and HP NJ2000G IntelliJacks.  I just spent about an hour on the phone with support.  After running through a bunch of tests, with the tech watching the switch activity, I was told to run CAT3 cable.   Yeah.... no....    The only other option I was given was to purchase another Cisco switch, SG300-52MP.  I was told it has completely different circuitry and software, and should not have the same issue.  Can anyone confirm that the SG300-52MP does not have this issue?

I also found these postings on the Ruckus forum:

https://support.ruckuswireless.com/answers/000001424

https://support.ruckuswireless.com/answers/000001623

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

Skipping a port between each AP (6, 8, 10, 12, 14, 16) seems to have fixed the issue, but I am still concidering the SG300-52MP or another manufacturer all together.  While I have plenty of room in my switch to spread the APs out, I have confirmed inserting other PoE devices into one of the jacks between the AP causes similar issues.  In the case of a HP NJ2000G IntelliJack, the PoE led lights up amber, indicating there isn't enough power.  This just seems like it problems waiting to happen down the road.

[Nagaraja Thanthry]

Hello Anthony,

Would it be possible for you to check the Ruckus Ethernet Pins and see if there is any short between the Pin Pairs (1,2,3,6 and 4,5,7,8)?

Thanks,

Nagaraja