cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2732
Views
15
Helpful
9
Replies

Cisco WLAN AP3800 PoE Problem on Cisco SG350 switches

Gehrig_W
Level 1
Level 1

Hello Cisco WLAN experts,

 

we are suffering obviously from a CDP/PoE-mismatch problem between Cisco WLAN 3800 APs

and small Cisco SG350-office-switches. The result ist that the WLAN AP is drawing 15,4 Watt only

and all antennas are no longer working.

 

The following info can be provided.

The problems appears, in case the switch port is cycled twice through Link Down/Up.

This can be reproduced by resetting the WLAN AP from WLC CLi.

 

(WLC-5520-1) >config ap reset KEM-AP04

 

E7-1OG-507#09-Feb-2022 10:27:56 %LINK-W-Down:  gi1

 

09-Feb-2022 10:27:57 %NT_poe-I-PowerNegStatus: Port gi1 power negotiation moved to expire

state, power protocol and allocation will remain at 25W (CDP) until port down/up cycle

09-Feb-2022 10:28:25 %LINK-I-Up:  gi1

09-Feb-2022 10:29:09 %LINK-W-Down:  gi1

09-Feb-2022 10:29:17 %LINK-I-Up:  gi1

 

As soon as the port is cycled a second time through Down/Up during this procedure the problem starts.

 

During the reboot the WLAN AP is complaining about CDP PoE negotiation:

 

Feb  9 10:15:19 brain: CDP PoE - waiting for CDP from PSE, timeout 22

Feb  9 10:15:20 brain: CDP PoE - waiting for CDP from PSE, timeout 21

Feb  9 10:15:21 brain: CDP PoE negotiation START

Feb  9 10:16:22 brain: CDP PoE negotiation FAILED !!

Feb  9 10:16:22 brain: LLDP PoE negotiation START

Feb  9 10:16:54 brain: LLDP PoE negotiation FAILED !!

Feb  9 10:16:54 brain: Power mode: Degraded/Reduced Power, power_detection: DC_adapter(FALSE), 802.3AF_POE(FALSE)

Feb  9 10:16:54 SYS-COND: SYS-COND: AP is in critical condition

 

and the PoE negotiation  end up in lower Power drawn shown in CDP neigbor details

 

Power drawn: 15400 milliwatts

 

We work around the problem by cycling the Inline Power on the Cisco SG350:

 

E7-1OG-507#conf term

E7-1OG-507(config)#int gi6

E7-1OG-507(config-if)#power inline never

E7-1OG-507(config-if)#09-Feb-2022 09:25:57 %LINK-W-Down:  gi6

E7-1OG-507(config-if)#power inline auto

E7-1OG-507(config-if)#end

 

After another round of two Link Dwon/Ups, the Poe-negotiation is correct again:

 

E7-1OG-507#09-Feb-2022 11:47:00 %LINK-I-Up: gi1

09-Feb-2022 11:47:44 %LINK-W-Down: gi1
09-Feb-2022 11:47:52 %LINK-I-Up: gi1
09-Feb-2022 11:48:35 %NT_poe-I-PowerNegStatus: Port gi1 power negotiation completed,

CDP resolved power is 25 watts

 

And the AP and its antennas are up again using 25 Watts according to CDP Neigbor details:

Power drawn: 25800 milliwatts

 

The switch-log-statement

 

power negotiation moved to expire state, power protocol and allocation will remain at 25W (CDP)

until port down/up cycle

 

is always valid.  As soon as I produce the next port down/up cycle by reloading the WLAN AP, the

error situation is appearing again.

 

Interesting in this case is also the switch inline power details information regarding this port:

 

E7-1OG-507#show power inline gi1

Interface Admin Oper Power (W) Class Device Priority
---------- ---------- ----------- ----------------- ----- -------------- --------
gi1 Auto On 12.0 (25.800) 4 low


Port Status: Port is on. Valid resistor detected
Port standard: 802.3AT
Admin power limit (for port power-limit mode): 30.000 watts
Time range:
Link partner standard: 802.3AT
Max Power Allocation: 30.000 watts
Spare pair: Disabled
Negotiated power: 25.800 watts (CDP(expired))
Current (mA): 229
Voltage(V): 53.100

 

It shows 25,8 Watts but CDP expired.

 

While the CDP  details show clearly that the AP is only using 15,4 Watt:

E7-1OG-507#show cdp nei detail
---------------------------------------------
Device-ID: KEM-AP04
Advertisement version: 2
Platform: cisco AIR-AP3802I-E-K9
Capabilities: Router TransBridge
Interface: gi1, Port ID (outgoing port): GigabitEthernet0
Holdtime: 164
Version: Cisco AP Software, ap3g3-k9w8 Version: 8.10.162.0
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 2014-2015 by Cisco Systems, Inc.
Duplex: full
Power drawn: 15400 milliwatts

 

Any ideas how we can solve this ?

 

Thank You

Wini

 

 

 

 

 

 

 

 

 

 

 

 

 

9 Replies 9

Leo Laohoo
Hall of Fame
Hall of Fame

@Gehrig_W wrote:

Feb  9 10:15:21 brain: CDP PoE negotiation START

Feb  9 10:16:22 brain: CDP PoE negotiation FAILED !!

Feb  9 10:16:22 brain: LLDP PoE negotiation START

Feb  9 10:16:54 brain: LLDP PoE negotiation FAILED !!

Feb  9 10:16:54 brain: Power mode: Degraded/Reduced Power, p


Upgrade the firmware of the AP or the WLC.  
This is a well-known issue.  

Hello Leo,

 

we are running on 8.8.10.162.0 software.

Do You have more information about this "well known issue" regarding 2800/3800 APs ?

Which bug are we hitting and which SW-version are You recommending to solve the problem ?

 

Kind regards

Wini

We ran into the CDP/LLDP negotiation bug with COS when our controllers were running 8.8.X.X and the APs were connected to IOS-XE switches. 
This issue is never present with classic IOS switches. 

If the WLC are already in 8.10MR6, you might want to try disabling LLDP manually. 

For IOS-XE, Cisco TAC does not recommend CDP and LLDP to be enabled on the same switch.  Aside from CSCvv54912, there are many CDP & LLDP more and some can cause the switch to crash.  

For classic IOS, there is no adverse impact if CDP and LLDP is enabled.  

balaji.bandi
Hall of Fame
Hall of Fame

check power requirement for 3800

 

https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9100-access-points/215467-cisco-access-point-power-requirements-qu.html

 

PoE+ need more power to AP to work.

 

 

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

Rich R
VIP
VIP

We can see from CDP output that AP is on latest code version 8.10.162.0 so I think that rules out the known issues in older code versions.

Are you aware of any issues in 8.10.162.0 @Leo Laohoo ?

My suspicion would be the SG350 switch.  Never worked with them myself.

Is that on latest code version 2.5.8.15?  If not then upgrade that for a start.

One other thing to try - disable LLDP on the switch port (CSCux89585 is supposed to be fixed but nevertheless worth a try)

If it's updated already and still seeing problems then open a TAC case.

Scott Fella
Hall of Fame
Hall of Fame

Here is a few things I know.  We ran into AP's disassociating and re-associating once in a while, that was due to having CDP and LLDP enabled.  Now I have AP's connected to a Meraki switch and they are drawing 13W-14W but advertised at 30W.  I have no issue with these AP's at all and all there radios are powered up.  The power draw will fluctuate, but will never stay at 30W.  Now with AP's connected to a 9300 switch, I see the max advertised being used.  So you see there is a difference on my equipment on what I will see for port PoE used, but at the end, I will see the advertised.  I don't know that switch much, we tested them, but not for access points.

What do you see from the ap or controller as far as power?  Is your ap's joined and then drops off?

-Scott
*** Please rate helpful posts ***

Hello Guys,

 

in the meantime there is Bug description CSCvz05686 available from Cisco in SW-Release 8.10.171.

Cisco Aironet 2802 or 3802 AP fail to bring up radios while connected to Cisco SG350 switches.

 

Kind regards

Wini

UKW-NK-Cisco
Level 1
Level 1

Hello Cisco WLAN experts,

the problem is appearing on our new 9800-WLC running 17.9.3-code again.

Cisco Aironet 2802 or 3802 AP fail to bring up radios while connected to Cisco SG350 switches.

Problem shows up as CDP expired on Cisco SG350 Switch:

UKWNKCisco_0-1695206723112.png

Eventhough 29,9 Watt seems to be negotiated, the Port is operating on 12 Watt only.

Workaround: Power cycle Switch port

UKWNKCisco_1-1695206826626.png

UKWNKCisco_2-1695207081684.png

Any idea when Cisco Bug CSCvz05686 will be solved on 9800-WLC also ?

Kind regards

Wini

 

 

Rich R
VIP
VIP

As far as Cisco are concerned CSCvz05686 should have been fixed in 17.6.1 and later releases but it might have somehow missed the later releases or the regression was re-introduced in later releases.  We've seen that type of rookie developer error in Cisco code a number of times before!  According to the bug notes: "This is a regression that first appeared in 17.3.4 and 8.10.162.0. It does not affect 17.5.1 and is fixed in 17.6.1"

The only way to resolve that is to open a TAC case and they will either re-open CSCvz05686 or open a new bug to get it fixed in later releases.

Review Cisco Networking for a $25 gift card