cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2952
Views
5
Helpful
3
Replies

3650 Poe issue - interface down/down but Poe still granted

clausonna
Level 3
Level 3

I have a multiple 3560G-48PS switches supporting IP phones (non-Cisco.) About once a week I get a call from a user who's phone dies (no power), and the fix is to go into the port and do a shut/no-shut. Once I bounce the port the phone draws power again and everything goes back to normal.

If I do a 'show int' the port is down/down, but if I do a 'show power inline' it shows that the port is drawing power.

I have 30 remote offices and have had the issue in most of them. They're all running 12.2.25-SEE or SEE2 IP base. Theres plenty of power remaining on the switch (via 'show power inline')so I know its not that.

I'm fairly sure that its not the user mucking around with the wall jack; I've had reports that the phone just dies in the middle of a conversation, and also when its just sitting there. There's no rhyme or reason to it.

Unplugging from the walljack has no effect, switching phones has no effect, etc. There's nothing in the logs, either.

Any suggestions?

3 Replies 3

Danilo Dy
VIP Alumni
VIP Alumni

I have same experience for wireless (not IP Phone though) that makes the port down/down once a month. Forcing the port to FD/100 for both Cisco Switch and other Vendor device help fixed it for good.

tim.heidemann
Level 1
Level 1

Hello clausonna,

we have the same problem as you. Did you find a solution ???

About a month ago we rolled out 12.2.40SE out to all of our 3560's and haven't had a single 'hung' port since. I believe the bug was identified and fixed in a previous release (12.2.35?) but .40 made the most sense for us.

The upgrade went very smoothly and didn't introduce any new issues or problems on the switches or on the Wireless LAN controllers or AP's.

Now all we get is users that 'double-plug' the phones and the port goes error-disabled due to BPDU guard. *sigh* Right now we manually shut/no-shut the port to fix that, but I'm looking at using err-disable timers to restore the port after 60 seconds or so. I'm -sure- the users will discover yet another way to take the port down, though!

Good luck!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco