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

Unanswered Question
Aug 11th, 2012

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.

I have this problem too.
2 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (2 ratings)
Tom Watts Sat, 08/11/2012 - 15:50

Hi John,

Thanks for the interesting post. Can you post a few output commands?

show power inline

show interfaces advertise gigabitethernet xx (for what ports are of interest)

show power inline gigabitethernet xx (for each device plugged in)

show spanning-tree active

A few also things to try and test about to see if there is a way to narrow the process;

  • Set the port manual speed 1000 full duplex, 100 full duplex
  • If the products support CDP, try to disable it, see if it's a CDP min/max issue
  • Set the power inline priority (critical) for the active POE ports
  • Remove the POE from the ports which do not require it
  • Disable the EEE globally and per port
  • Verify there is not any port flapping, such as bpdu being received on the ports, etc

After fiddeling with those few settings, see if you can power your products in adjacent ports, etc. Make notes of what works, what doesn't work (if anything at all!)

-Tom

Cinemaffect Sat, 08/11/2012 - 18:30

Thomas:

Forgive me. My networking skills are not the greatest.  [If it weren't for the GUI of the SG300's, I probably would be completely lost.]  How do i find these output commands you'd like me to post?

I did try several of the other recommendations you posted in the past.  Tried them again, but didn't seem to change anything.  I attempted turning off POE off all unused ports.  Problem remained - no adjacent port placements of the POE devices.  I also turned off CDP on a port-basis inside the SG300-28P.  And I set the power inline priority to critical for all POE devices.  No such luck.  Next, I disabled the EEE globally and per port.  No change in actions.

I'm not sure how to check for port flapping [don't know what that is]; however, I can confirm that BPDU guard is disabled/off.

What's really strange is that the default settings of the SG300-10P work just fine, while the default settings of the SG300-28P do not.

Any help with the output commands would be much appreciated.

Tom Watts Sat, 08/11/2012 - 18:44

Hi John, enable telnet under security -> TCP / udp services then telnet the switch. Then you may run those commands.

-Tom

jamiehhlireland Mon, 04/22/2013 - 11:21

I have a simular issue with a 802.3af compliant POE Adaptor ( http://www.ubnt.com/8023af )

Invalid Signature Counter rises in the properties section but I never get a POE device to power on at all.

I have updated to the latest software, 1.3 but still no luck.

bhackbarth Sun, 08/12/2012 - 00:21

It's definitely not just a straight firmware problem; I've run every version of firmware since 1.0.0.27 on my 28P's and my phones and access points have always worked, power on all 24 ports.  The output of those commands Thomas asked for should reveal the usage and class of those PoE devices, among other useful details. I'm curious about this one.

Cinemaffect Mon, 08/13/2012 - 05:39

show power inline

Port based power-limit mode

Unit  Power  Nominal Power   Consumed Power   Usage Threshold   Traps  

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

1     On      180 Watts     13 Watts (7%)          95         Disable 

  Port      Powered Device         State          Status    Priority   Class  

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

  gi1                               Auto            On      critical  class0  

  gi2                              Never           Off        low     class0  

  gi3                               Auto        Searching   critical  class0  

  gi4                              Never           Off        low     class0  

  gi5                               Auto            On      critical  class0  

  gi6                              Never           Off        low     class0  

  gi7                               Auto            On      critical  class2  

  gi8                               Auto        Searching     low     class0  

  gi9                               Auto        Searching     low     class0  

  gi10                              Auto        Searching     low     class0  

  gi11                              Auto        Searching     low     class0  

  gi12                             Never           Off        low     class0  

  gi13                             Never           Off        low     class0  

  gi14                             Never           Off        low     class0  

  gi15                             Never           Off        low     class0  

  gi16                             Never           Off        low     class0  

  gi17                             Never           Off        low     class0  

  gi18                             Never           Off        low     class0  

  gi19                             Never           Off        low     class0  

  gi20                              Auto        Searching     low     class0  

  gi21                             Never           Off        low     class0  

  gi22                              Auto        Searching     low     class0  

[0mMore: ,  Quit: q or CTRL+Z, One line:                                                          gi23                              Auto        Searching     low     class0  

  gi24                              Auto        Searching     low     class0  

show power inline gigabitethernet xx (for each device plugged in)

  Port      Powered Device         State          Status    Priority   Class  

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

  gi1                               Auto            On      critical  class0  

Power limit (for port power-limit mode): 15.400W

Port Status:               Port is on - valid resistor detected

Overload Counter:          0

Short Counter:             0

Denied Counter:            0

Absent Counter:            3

Invalid Signature Counter: 17583

  Port      Powered Device         State          Status    Priority   Class  

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

  gi2                              Never           Off        low     class0  

Power limit (for port power-limit mode): 15.400W

Port Status:               Port is off - user setting

Overload Counter:          0

Short Counter:             0

Denied Counter:            0

Absent Counter:            0

Invalid Signature Counter: 0

  Port      Powered Device         State          Status    Priority   Class  

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

  gi3                               Auto        Searching   critical  class0  

Power limit (for port power-limit mode): 15.400W

Port Status:               Port is off - detection is in process

Overload Counter:          0

Short Counter:             0

Denied Counter:            0

Absent Counter:            2

Invalid Signature Counter: 1

Port      Powered Device         State          Status    Priority   Class  

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

  gi4                              Never           Off        low     class0  

Power limit (for port power-limit mode): 15.400W

Port Status:               Port is off - user setting

Overload Counter:          0

Short Counter:             0

Denied Counter:            0

Absent Counter:            0

Invalid Signature Counter: 0

Port      Powered Device         State          Status    Priority   Class  

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

  gi5                               Auto            On      critical  class0  

Power limit (for port power-limit mode): 15.400W

Port Status:               Port is on - valid resistor detected

Overload Counter:          0

Short Counter:             0

Denied Counter:            0

Absent Counter:            0

Invalid Signature Counter: 0

  Port      Powered Device         State          Status    Priority   Class  

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

  gi7                               Auto            On      critical  class2  

Power limit (for port power-limit mode): 15.400W

Port Status:               Port is on - valid resistor detected

Overload Counter:          0

Short Counter:             0

Denied Counter:            0

Absent Counter:            0

Invalid Signature Counter: 0

  Port      Powered Device         State          Status    Priority   Class  

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

  gi13                             Never           Off        low     class0  

Power limit (for port power-limit mode): 15.400W

Port Status:               Port is off - user setting

Overload Counter:          0

Short Counter:             0

Denied Counter:            0

Absent Counter:            1

Invalid Signature Counter: 0

  Port      Powered Device         State          Status    Priority   Class  

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

  gi14                             Never           Off        low     class0  

Power limit (for port power-limit mode): 15.400W

Port Status:               Port is off - user setting

Overload Counter:          0

Short Counter:             0

Denied Counter:            0

Absent Counter:            0

Invalid Signature Counter: 0

show interfaces advertise gigabitethernet xx (for what ports are of interest)

Port: gi9      

Type: 1G-Copper

Link state: Down

Auto negotiation: Enabled

                                  1000f  1000h  100f  100h  10f  10h

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

Admin Local link Advertisement    yes    no     yes   yes   yes  yes 

Oper Local link Advertisement     -      -      -     -     -    - 

Oper Remote link Advertisement    -      -      -     -     -    - 

Priority Resolution               -      -      -     -     -    - 

Port: gi10     

Type: 1G-Copper

Link state: Down

Auto negotiation: Enabled

                                  1000f  1000h  100f  100h  10f  10h

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

Admin Local link Advertisement    yes    no     yes   yes   yes  yes 

Oper Local link Advertisement     -      -      -     -     -    - 

Oper Remote link Advertisement    -      -      -     -     -    - 

Priority Resolution               -      -      -     -     -    -

Port: gi11     

Type: 1G-Copper

Link state: Down

Auto negotiation: Enabled

                                  1000f  1000h  100f  100h  10f  10h

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

Admin Local link Advertisement    yes    no     yes   yes   yes  yes 

Oper Local link Advertisement     -      -      -     -     -    - 

Oper Remote link Advertisement    -      -      -     -     -    - 

Priority Resolution               -      -      -     -     -    -

Port: gi21     

Type: 1G-Copper

Link state: Down

Auto negotiation: Enabled

                                  1000f  1000h  100f  100h  10f  10h

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

Admin Local link Advertisement    yes    no     yes   yes   yes  yes 

Oper Local link Advertisement     -      -      -     -     -    - 

Oper Remote link Advertisement    -      -      -     -     -    - 

Priority Resolution               -      -      -     -     -    -

Port: gi22     

Type: 1G-Copper

Link state: Down

Auto negotiation: Enabled

                                  1000f  1000h  100f  100h  10f  10h

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

Admin Local link Advertisement    yes    no     yes   yes   yes  yes 

Oper Local link Advertisement     -      -      -     -     -    - 

Oper Remote link Advertisement    -      -      -     -     -    - 

Priority Resolution               -      -      -     -     -    - 

Port: gi23     

Type: 1G-Copper

Link state: Down

Auto negotiation: Enabled

                                  1000f  1000h  100f  100h  10f  10h

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

Admin Local link Advertisement    yes    no     yes   yes   yes  yes 

Oper Local link Advertisement     -      -      -     -     -    - 

Oper Remote link Advertisement    -      -      -     -     -    - 

Priority Resolution               -      -      -     -     -    - 

Cinemaffect Mon, 08/13/2012 - 05:56

I have 6 VLANS configured on our office network.  Ideally, I'd like to arrange them in easy clusters [e.g VLAN1 on ports 1,2,3, 13, 14, and 15, etc.]  However, I could not get my Ruckus Wireless access points to all come up when doing such.  Only by staggering the inputs.  Therefore, you'll notice the staggered layout [e.g port 1, 3, and 5] for any device requiring POE.

Ports 9 [vlan4], 10 [vlan1], 11 [vlan1], 22 [vlan1], and 23 [vlan1] are all currently set up to support POE.  However, I could not get 3 access points to power up when plugged into any combination of 3 of those ports.  Only 2 max.

Port 1 currently has an active access point plugged into it.  The other 2 are currently disconnected [although sitting on our lab table as we continue to test these things out].  Again, what's interesting is that if we take the very same POE devices and plug them into the SG300-10P that was temporarily loaded into our equipment rack, we don't have to worry about skipping any ports.  All 3 access points can power up just fine [e.g ports 1,2,and 3].  In fact, our entire inventory of POE devices can be plugged into the SG300-10P simultaneously without any problems.  Same test gear, different switch.  And all those tests were run with the switches in default factory mode and after loading it with a config file.  We got the same behavior in either case.

And having both SG300-28P's loaded in our equipment rack, as well, made it real easy to test them with different firmware versions.  Both were factory-defaulted.  One with 1.1.2.   The other with 1.1.1.8.  We could easily move the patch cables around as needed.  And definitely got a different behavior of how the two handled some of our POE devices. 

I found another thread listed here in the Cisco support community: here.  Could they be related?  However, the Ruckus Wireless 7982 access points are definitely not pre-standard POE devices, as suggested in this other thread.  I couldn't quite tell from this thread if there could be an issue, in general, with how power is supplied to 4-port clusters within the 28-port switch.  Maybe, I misread the thread. Anyhows, looking forward to your thoughts.

Tom Watts Mon, 08/13/2012 - 09:27

Hi John, email or pm me your tele number. I'd like to give you a call around 4pm EST today.

-Tom

harrysummers Wed, 10/31/2012 - 06:48

Hi, was this problem ever resolved? I have the exact same issue with a new SG300-28P using firmware version 1.2.7.76.

Thanks.

Tom Watts Wed, 10/31/2012 - 08:01

Hello Harry, can you provide some details?

-Tom
Please rate helpful posts

harrysummers Wed, 10/31/2012 - 08:44

Hi Tom,

I am experiencing very similar issues to what John reported, I am using 8 x Ruckus 7982 access points.

Using factory settings and only applying a management IP address to VLAN1, I find that when plugging each access point in some ports will come on and some simply won't. At first it appeared to be every other port, similar to what John was stating but I have found by playing around that this is not always the case and is very random.

Currently I have access points plugged in and working on ports 1, 2, 4, 5, 7, 9, 11 and 12. If I try to move an access point to a free port none of them work. If I remove all the cables and plug one access point in at a time then some of the ports that were working stop working and I have to plug into each port until one works.

I have checked the power consumption and that is showing 33W with 147W available.

As I only require the 8 access points to be POE and they are all working this is not a huge problem in this scenario but if I wanted to add more it would be. Interestingly if I pull the power out and allow the switch to reboot all the ports that were working continue to work.

Any help or suggestions will be appreciated.

Tom Watts Wed, 10/31/2012 - 08:55

Harry, if you'd like, I can give you a phone call today in the later evening, would around 8pm EST be okay?. I'd like to have a session with you to collect data.

-Tom
Please rate helpful posts

harrysummers Wed, 10/31/2012 - 09:23

Sorry Tom I am from the UK and four hours in front of you. I am available any day during the week 8am - 1pm your time. Don't know if this helps, let me know the best way to get my contact details to you.

Tom Watts Wed, 10/31/2012 - 09:25

Please send me an email. I will write out a process for you if you're comfortable with that.

-Tom
Please rate helpful posts

Tom Watts Wed, 10/31/2012 - 13:29

If anyone else has the problem with Ruckus 7982 connecting to the SX300 switch, I will share the process which should be completed to help things along-

As an example:

AP#1 to port 1 <-Works

AP#2 to port 2<-Works

AP#3 to port 13<-Fails

A working example would be

AP#1 to port 1

AP#2 to port 3

AP#3 to port 5

-Network topology (What router, switch, AP, #users, #devices)

-How many SX300 switches are affected

-Configuration file of all switches in question

-Ensure you're using the 1.2.7.76 firmware

In addition to this information I'd like the following tests       performed

-Factory default the unit (leave the switch at 100% default       status)

1.) Set up a console (or CLI) connection and log all output to a       text file

2.) Once logged on to the CLI, connect Ruckus AP#1 to port #1 then       perform the following

-show spanning-tree active

-show power inline  gi1

-show power inline

-show power inline consumption

-show interface status gi1

3.) Connect Ruckus AP#2 to port#2 then performing the following

-show spanning-tree active

-show power inline gi2

-show power inline

-show power inline consumption

-show interface status gi2

4.) Connect Rucks AP#3 to port #13 then perform the following

-show spanning-tree active

-show power inline gi13

-show power inline

-show power inline consumption

-show interface status gi13

5.) At this point, port 13 should fail. At this time, disconnect AP #3 from port #13 and AP#2 from Port#2

6.) Connect a computer that has wireshark installed to port #10

7.) Set up a SPAN (port monitor), with the destination port #10, source port#2 (remember, if the computer connects to a monitor port, it has zero network connectivity)

config t

interface gi10

port monitor gi2

8.) Connect AP#2 to port#2, wait 30 seconds then discontinue the  wireshark, save the file (please mark the file clearly what ports used)

9.) Remove the port monitor from gi2 and change it to gi13

config t

int gi10

no port monitor gi2

port monitor gi13

10.) Connect the AP#3 to port#13

11.) Wait 30 seconds then discontinue the wireshark, save the file (please mark the file clearly what ports used)

12.) Collect the log file from the session

show log

show log file

13.) Collect tech data

show tech

14.) Please put all files, clearly named in to a folder and make a ZIP file

-Tom
Please rate helpful posts

Cinemaffect Wed, 10/31/2012 - 15:03

Hi Tom,

Just wanted to say that the issue I was having was not resolved yet.  So, I'm interested as well about this continuing issue.  On a side note, guys, I'm getting in a group of Ruckus 7363 AP's to try with the SG300-28P switch.  I'll let you guys know if I have the same performance issue with that model of AP in order to help narrow down some issues.  Feel free to contact me if you guys have any questions.  Thanks.

Tom Watts Tue, 11/13/2012 - 14:16

Hi John, I had a customer using 7363 x5, on his switch all AP worked on port 1,2,13,14.  They were pulling about 3-4 watt per port, class 3 poe around 50 MA.

They should work for you.

-Tom
Please rate helpful posts

Cinemaffect Tue, 11/13/2012 - 15:58

Thanks for the info, Tom:

Funny timing you have.  We're actually in our offices configuring the 7363/SG300-28P combo as I type this.  I'll let you know what I discover later on this evening.  Thanks.

w_smith@compusm... Thu, 11/15/2012 - 06:08

Are you getting anywhere with this?  I've got a bunch of PoE adapters from MacWireless (POE-TGS-25125DN) that don't really work on an SG500-28P.  I can plug in one and it works, but more than a couple and some or all of them don't power up and flicker and throw some signature(?) errors in the logs.

Of course MacWireless says they work just fine, so they won't take them back, nor have they any interest in buying an SG500 just to test them.

I threw them in the junk box and went with Trendnet TPE-114GS boxes which work fine.

John (or any other Cisco engineer), if you think you can debug the problem with them I'm happy to ship them to you, but I have neither the time nor the spare SG500 to play with debugging them from here.

Not _positive_ if this is related to the SG300 PoE issues, but it might be worth checking out.

Tom Watts Mon, 01/28/2013 - 13:54

This is still an open issue. There is no ETA. The good thing is, it is a well documented problem and Cisco engineering is VERY aware of this.

If you guys need a solution right now use the 8/10 port or the MP versions.

-Tom
Please mark answered for helpful posts

w_smith@compusm... Mon, 01/28/2013 - 14:04

/*

If you guys need a solution right now use the 8/10 port or the MP versions.

*/

I've got SG500-28P and SG300-28P boxes, is there an easy solution for me?

Thanks!

Tom Watts Mon, 01/28/2013 - 17:22

Hi w_smith the only current solution I'm aware of, aside from using a SX300-10p switch would be to intersperse the AP through the switch ports.

So if you connect AP #1 to port 1, 2, 13 or 14. Connect AP #2 to port 3,4,15, or 16, etc. Connect AP #3 to port 5,6,17, or 18.

The switch is built in fours of transformer blocks. So visual each "square" of 4 ports as 1 transformer. 1 AP per transformer should perform without problems.

-Tom
Please mark answered for helpful posts

w_smith@compusm... Tue, 01/29/2013 - 05:12

/*

This is still an open issue. There is no ETA. The good thing is, it is a  well documented problem and Cisco engineering is VERY aware of this.

*/

Is this a hardware issue or a software/firmware issue?  Will I ever be able to use more than 6 of these PoE splitters on my existing SG500-28P switches?

Thanks!

Tom Watts Tue, 01/29/2013 - 07:50

I honestly don't know if it is software or hardware issue. The reason I say that is because the 8/10 port models have no problems and they use the same firmware.

-Tom
Please mark answered for helpful posts

pcscontrols Fri, 02/01/2013 - 11:30

I encountered similar problems with both a -28P and a -10P but i FOUND the problem in my installtion.  Are any of you with this problem using SHEILDED CATx cable?  If you are then that is the problem. I ended up removing the shield jacket that is wrapped around the rj45 plug from my cables and ALL the issues went away.

CISCO support acknowledges that there is an issue using shielded cable but haven't fixed anything yet.

I hope this help someone out!

w_smith@compusm... Fri, 02/01/2013 - 13:28

Nope, not only doesn't require any shielding to fail, but I can make them fail by connecting them to the switch with 6" CAT5 patch cables.

It seems to have something to do with signature detection, as it throws those kinds of errors in the logs.

fturner124@gmail.com Wed, 02/27/2013 - 16:46

I've been having the same problem with SG300-28P and several ZF7982 APs for a while now.  May have it figured out, but would like someone else to confirm. 

Try setting "Administrative Power Allocation (mW)" on unused ports to 0.  The AP that wouldn't boot up, immediately came online after changing this setting.

I had also already changed the priority to critical on active ports, and disabled POE on all inactive ports.  These changes didn't resolve the issue, but may have been part of the solution.

dmilam@clhnt.com Wed, 03/13/2013 - 05:45

I also have been having this issue but with Cisco 1142 access points....changing the Administrative power allocation DID NOT fix my problem.  Does anyone have any other suggestions.  I have also updated the controller and switch firmware. Set ports to critical, disabled Poe on all unused ports. Moved all connections to every other connection meaning I'm only using less than 12 connections per switch even though the switch shows it has plenty of poer left.  I have also noticed the sometimes the power is on the access point but it will not connect to the wireless controller,  but the big issue is the switch stops powering the ap.  rebooting the switch will sometimes bring them back on but then drop power to another port and so me time it makes no difference in the port that is powered off. To get it up you can sometimes enable the Poe on a different port then move the connection and it will come back on. After you get all the ports operating a few hours later and sometimes days it will drop another.  I can not see a pattern or anything in the switch log or controller that corresponds.  Any suggestions other than replacing

pcscontrols Wed, 03/13/2013 - 06:25

My problem sounded exactly like what you are seeing and it went COMPLETELY away when I switched to UNSHEILDED cables.  Inspect the RJ45 connector jack at the cable end you are plugging into the Cisco, if it has a metal jacket on/around it my problem was fixed when I removed the metal shield/jacket.

Nagaraja Thanthry Fri, 03/22/2013 - 13:29

Hello Darrell,

Can you please reach out to SBSC and open a Serivce Request in this regard? Please ask the SBSC Engineer to escalate the case to the next level so one of our Escalation Engineers can take a look at the problem.

Thanks,

Nagaraja

uschhs-cisco Wed, 03/20/2013 - 09:15

Getting on this thread to validate that this problem persists. We are experiencing the same symptoms. I've would up running power supplies and extension cords from wall outlets to power our Ruckus 7982 access points as the PoE, even when distributed across transformers has proven unreliable occassionally causing the access point to restart.

Not good for continuity. Worked with Ruckus for several weeks trying to update their firmware to be less sensistive to the fluctuating power to no avail.Love to hear from Cisco on a firmware update to address this obvious, and long standing issue.

Nagaraja Thanthry Fri, 03/22/2013 - 16:59

Hello Andrew,

When you say that the connection is not reliable, are you seeing any port flaps? Do you have EEE turned on on the switch? If yes, can you turn off EEE and see if that helps? If you are seeing issues even after turning off EEE, please reach out to SBSC and open a Service Request. One of our Engineers will be happy to take a look at the settings and see if we can find the root cause.

Thanks,

Nagaraja

lokibjensen Fri, 03/22/2013 - 10:19

I too am jumping on this thread to confirm the same issue with the 28P's and Ruckus 7982's. My case number is: 625315271

I will ask the tech if he's using shielded cables and I will try setting the Administrative power on unused ports to 0. Anyone know off-hand what the command for that is?

lokibjensen Fri, 03/22/2013 - 10:28

Quick update, the command to set adminitrative power to 0 is "power inline limit 0".

I applied this to most ports, except for one's with AP's and this did not work for me.

lokibjensen Fri, 03/22/2013 - 12:07

Another update related to a tip above, we are not using shielded cable and still experiencing the issue. Then there's also this response from support. Is this some sort of joke????? CAT3???

"The issue you are facing is a know bug with the SG300-28P switch. I have reached out to the developers regarding your issue and awaiting their response for what should be out next step. The workaround recommended for this issue is to use Cat3 cable on site.

I will keep you posted as soon as I hear back from the developers."

If Cisco knows this is an issue then why is it being sold? It is supposed to be a PoE switch with 24 PoE ports. Obviously there is a limit to how much power per port but we are not even coming close to what the limits are supposed to be. At this point Cisco should honor the sale and send an SG300-28MP as replacement if that will fix the issue. There is NO WAY I'm putting CAT3 in and besides the building is already pre-wired.

Is anybody monitoring these posts?

Tom Watts Fri, 03/22/2013 - 12:43

Hi lokibjensen.

Another update related to a tip  above, we are not using shielded cable and still experiencing the issue.  Then there's also this response from support. Is this some sort of  joke????? CAT3???

"The issue you are facing is a know bug with the  SG300-28P switch. I have reached out to the developers regarding your  issue and awaiting their response for what should be out next step. The  workaround recommended for this issue is to use Cat3 cable on site.

I will keep you posted as soon as I hear back from the developers."

No, it is not some sort of joke. The reason Cat3 should resolve the problem is because it was the relevant wire-type for legacy POE. Cat3 has less twists in the wire pairs. Additionally Cat3 uses 2 wire pairs while Cat5 uses 4 wire pairs.

The technical matter of Cat3 is it can handle 16mhz while Cat5 is like 100mhz. Although it is not a favorable solution due to speed concerns (10mbit vs 100+ mbit).

Most of the problem comes from the concept of integrating support for legacy POE.

If  Cisco knows this is an issue then why is it being sold? It is supposed  to be a PoE switch with 24 PoE ports. Obviously there is a limit to how  much power per port but we are not even coming close to what the limits  are supposed to be. At this point Cisco should honor the sale and send  an SG300-28MP as replacement if that will fix the issue. There is NO WAY  I'm putting CAT3 in and besides the building is already pre-wired.

You have an invalid arugment that if there is an issue why is it sold. You may be frustrated which is agreeable and understandable but if your contention if no vendor has a bug or defect, you're in the wrong business.  This device is advertised for every port POE capable and it is thoroughly documented since it's inception of how much it supports per port. Quite frankly it does work. This is an isolated instance with a very specific symptom. The issue seems to be there is not a valid signature detected. It is very questionable if this has to do with the cross-implementation of 802.3at support with the AP. As you may notice most/any devices that are not 802.3at compatible do not have a problem. Since 802.3at is not standardized (or barely standardized, i'd have to double check) the implementations still are likely sloppy and incomplete.

Is anybody monitoring these posts?

Yes. The best thing to do is open a ticket with the support center and add more leverage to the cause. The support forums are provided as a courtesy and are complimentary. This is not the official channel of communication or documentation.

-Tom
Please mark answered for helpful posts

lokibjensen Fri, 03/22/2013 - 13:00

Sorry if I offended you.  However, asking somebody to use CAT3 as a workaround for a device on a Gigabit switch, in 2013, is quite frankly unreasonable.  I understand why CAT3 will work but that doesn't mean it should ever be used in any modern deployment unless it is satisfactory to the client to have an outdated network when they paid for a new one.  I know my clients would fire me in a second if I even approached them with such a solution.

As for the switch working or not, it apparently cannot handle what it is advertised to do in this instance and the instances mentioned above in this thread.  I believe it's advertised as being able to handle up to just over 15W per port and not to exceed something near 180W (off the top of my head I can't remember the exact numbers).  As the switch obviously cannot do that in the instances on this thread (or even come close), and the issue has been known for about a year now, I find it alarming that Cisco would still sell the switch as advertised.

      

The reason I posted the "workaround" here was to provide the courtesy to the fellow members of this community so that they would know where we stand on this issue, especially as I had not seen a reply to anybody's comments or requests since January 29th, about two months ago.

Thank you.

Tom Watts Fri, 03/22/2013 - 13:26

Hi Lokibjensen, it's really understandable the confusion and frustration. I was the original TAC engineer that sent this problem to the tier 2 team. From the best of my recollection there wasn't really anything to see. There was a header 0 for the POE and then the signature counter incremented.

I do not know what Cisco/Tier 2/Development has learned since the initial reports of this. My suspicion is it has something to do with how the Ruckus 7982 may set up the parameter for the POE negotiation. Since it increments an invalid signature I believe it is sending too much juice on the line and the switch doesn't like it. Hence the Cat3 wire can't support the juice therefore it works.

I do not feel it is a POE leak. I do feel it is a flawed implementation of POE. It's just a matter of by whom and why. Since all of the SB switches work very well with every other 802.3af compliant devices, I believe it has something to do with Ruckus' integration of 802.3at and interop with 802.3af when the AP realized the 802.3at is not present.I also think Ruckus may have a limitation to using a "phantom power" only. Another concept is mid-span. Gigabit switch uses all 4 pairs. Midspan will short the 4-5, 7-8 pairs.So if you're using mid-spans stick with 10/100 (How would your client respond to that?)

Ruckus does have some issues with product such as Adtran Netvanta 1234 switch where it does not power correctly. Another switch is the HP procurve 2520 has some issues with the Ruckus AP's.

-Tom
Please mark answered for helpful posts

lokibjensen Fri, 03/22/2013 - 19:02

Please forgive my ignorance....what do you mean by, "Another concept is mid-span. Gigabit switch uses all 4 pairs. Midspan will short the 4-5, 7-8 pairs.So if you're using mid-spans stick with 10/100 (How would your client respond to that?)"

Nagaraja Thanthry Fri, 03/22/2013 - 17:26

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 Fri, 03/22/2013 - 19:01

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 Fri, 03/22/2013 - 19:43

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@compusm... Sat, 03/23/2013 - 07:23

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 Sat, 03/23/2013 - 12:01

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@compusm... Sat, 03/23/2013 - 14:07

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 Wed, 04/10/2013 - 06:11

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!

Actions

Login or Register to take actions

This Discussion

Posted August 11, 2012 at 2:45 PM
Stats:
Replies:80 Avg. Rating:
Views:14183 Votes:2
Shares:0

Related Content

Discussions Leaderboard