Solved: Issue with CP79xx phones being randomly put in deceased state

finalconnect · ‎04-29-2010

Again, since we can't get help from the SBCS team because "all lines are busy", I'm posting this for help.

UC560 with (2) ESW520-24P switches. 40 CP7962, CP-7945 and CP7965 phones. 40 user licenses on UC560-registered and verified. After a system reboot or phone reboot, a random phone located on the first ESW switch will automatically go into a DECEASED state (sho ephone stat). The phone changes every time so there is no port or phone pattern to work with. On the actual phone, it will state "Configuring IP". It never gets an IP address. One note, the PC connected to the phone can work without issue and receives an IP address from DHCP on UC560. Shutting the switch port does not clear up the issue. The only way to clear up the issue is to command line (yes I know you all hate us doing command line, but what we have to fix the customer's problem). Basically, "no ephone ##" the "DECEASED" ephone then wait 5 seconds and add it right back in. Once added back in, the phone gets an IP and all it's configuration back.

This has happened on every system reload or phone restart. This installation has been installed less than 1 week.

Running current available UC soft pack of 8.0.2.

David Trad · ‎06-24-2010

Hi Michael,

Dear old friend. We have been going at it on these boards for what feels like years, and I have always appreciated your input.

Unfortunately, I think you are mis-reading this post and my position, and defending Cisco too quickly.

WOW we have been at it for a while haven't we

Look Michael I actually did not write that up correctly, one of my biggest problems is that I think something in my head and then in a bad attempt try and put that down on paper (Or a thread), and it often does not quite come out so right.

I do agree i misread your post, and i realise that now so i must apologies for that.

I do not view it as defending Cisco at all, in fact I am probably one of their most harshest critics and have no issues with speaking my mind to them, normally though where it is not in a public forum, but my defense was more towards Cisco support not Cisco in general.

This post clears up what you meant, I didn't get the drift of the conversation, I'm loosing my reading mojo

I do stand by my statements as I believe them to be correct, but I probably should have pointed out in it that it was not directed at you (Minus the first part), the remainder of my post was quite a general topic/discussion statement/point, again lacking the right direction I guess.

Anyway i look forward to more of your posts your issues and resolution are brilliant to watch and also provide a great insight into problem i face from time to time.

Cheers,

David.

(PS) It has been a busy day watching out Prime Minister getting rolled by his own party, and his party putting in this countries first Female Prime Minister, it truly has been an odd day.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

View solution in original post

finalconnect · ‎04-30-2010

Anybody at Cisco want to follow the case at the SBCS support-

Case #614251053 - SBCS support. Of course no one has updated me on the case from the SBCS team since they are just too busy to honor a 24x7x4 SBCS contract, but maybe one day........

jcarter · ‎06-23-2010

What was the fix for this? This just started happening in our office today.

finalconnect · ‎06-23-2010

We RMA'd one of the ESW520 switches and that fixed the issue. Once we replaced the bad ESW520,

that issue went away.

If you are using the ESW520, immediately request an RMA on that switch.

David Trad · ‎06-23-2010

Hi Michael,

If you are using the ESW520, immediately request an RMA on that switch.

I am curious with this statement, I don't mind it when a broad general statement is used most times, but this could cause a panic with many of people who have them out in the field.

I am aware of many ESW520 in active deployment and none have issues, they are a solid and robust switch much better then the CE520's which i considered to be dud and problematic. I also point out it is not fair on Cisco that you RMA a switch that may not actually be faulty, it ties up resources and I would encourage everyone to follow standard procedures with getting TAC involved and having the Switch looked out, it could be a user error and might save a person some embarrassment.

I am sad for you that you got a bad one, but i dont think it is appropriate to brush all ESW20's with the tar, each and everyone of them will be different.

Cheers,

David.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

finalconnect · ‎06-23-2010

David,

Dear old friend. We have been going at it on these boards for what feels like years, and I have always appreciated your input.

Unfortunately, I think you are mis-reading this post and my position, and defending Cisco too quickly.

This post is not about the ESW switches, BUT about CP-79xx phones randomly going into a deceased state when combined with the ESW switch line. When this issue first appeared, the Cisco SBCS support team had me trying all kinds of crazy timeout/keepalive configuration tweaks that I have never had to do before. They tried to blame the UC as well as inside wiring. The wild goose chase got me no where- except to further frustate the client. Oh yes, and FYI, the issue did not occur on install, but several days post installation.

This was NOT a demo environment. This was a real customer environment that the deceased state was occurring. When you are in a post-deployment situation, customers just cannot accept 4 business days looking for a fix. Luckily, I finally screamed enough and was able to narrow the problem to phones on a single ESW switch within a 2 ESW switch environment. I was also able to find an engineer willing to RMA a switch even though he did NOT believe the switch was the problem. Once the RMA'd switch was installed, all was good.

My point on this post is that if the person is experiencing the deceased state post instalaltion (as described in the post I was replying) and using a ESW switch, the switch IS the problem. I have done a good amount of these installs with and without ESW switches, but never experienced a deceased state phone issue. All knowledge base on the issue points to inside wiring or station cabling, but a simple cat 5 tester proves that inside wiring is not the issue.

Therefore, my position stands in this post. Dear fellow Cisco users/partners, don't be afraid to ask for an RMA if you feel it is the equipment. Yes, as David states, don't go for the RMA first, but use your best judgement and make that call if necessary.

I have two specific examples where, had Cisco actually done an RMA before a situation got out of hand, it would have saved Cisco, me the partner and the customer a significant amount of resources.

As for the ESW line, I think we have a 10% issue rate with those switches. This is not our only RMA on that switch line. I like the switch and it is priced right to sell a bunch of units.

David Trad · ‎06-24-2010

Hi Michael,

Dear old friend. We have been going at it on these boards for what feels like years, and I have always appreciated your input.

Unfortunately, I think you are mis-reading this post and my position, and defending Cisco too quickly.

WOW we have been at it for a while haven't we

Look Michael I actually did not write that up correctly, one of my biggest problems is that I think something in my head and then in a bad attempt try and put that down on paper (Or a thread), and it often does not quite come out so right.

I do agree i misread your post, and i realise that now so i must apologies for that.

I do not view it as defending Cisco at all, in fact I am probably one of their most harshest critics and have no issues with speaking my mind to them, normally though where it is not in a public forum, but my defense was more towards Cisco support not Cisco in general.

This post clears up what you meant, I didn't get the drift of the conversation, I'm loosing my reading mojo

I do stand by my statements as I believe them to be correct, but I probably should have pointed out in it that it was not directed at you (Minus the first part), the remainder of my post was quite a general topic/discussion statement/point, again lacking the right direction I guess.

Anyway i look forward to more of your posts your issues and resolution are brilliant to watch and also provide a great insight into problem i face from time to time.

Cheers,

David.

(PS) It has been a busy day watching out Prime Minister getting rolled by his own party, and his party putting in this countries first Female Prime Minister, it truly has been an odd day.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

jcarter · ‎06-24-2010

I appreciate the feedback. Unfortunately for me, the phones are plugged directly into the UC540. We have a mix of SPA5xx and 7975 phones. I tried removing and added back in the ephones. It did not work. I looked at the network configuration on the phone. It was getting an IP from VLAN 1. I statically assigned an IP from VLAN 100 and the phones work again. Obviously it is a workaround but it is all I have right now.

finalconnect · ‎06-24-2010

Do you have a PoE problem? We always put AC bricks on 7975 phones when connected directly to

UC540s. The power draw on the 7975 series can be the full 15. The max PoE on the UC540 is less than full port utilization. We have seen the phones drop to VLAN 1 typically when there is not enough power or the switch ports are misconfigured (missing the phone vlan setting).

Just something else to check.

finalconnect · ‎06-24-2010

No worries about any of it. I don't take any of this personal. But I will typically address almost anything.