ports dead after reboot

[teching123]

I have a 406 running 3.2.53, that after a reboot, a couple digital ports will go dead. This is not happening on the same module, which leads me to believe that it isn't a bad module. Has anyone had this happen? My only fix was to move the phones to different ports on the system to make the phones go live again.

 

[janni78]

Are these DS16 or DS30 modules?

 

[pstnguy]

Yes, I also have had the same problem. I am almost positive is because I was performing 'reboot when free' instead of timed (after hours).

I have 15 systems in the field and the only time I have ever had this issue is when I have had to reboot in the middle of the day. Now, I change the extension numbers for the ports and tell the users that the new numbers will be available the next morning. I have had to replace 3 digital modules because of bad ports.

Thanks, Bob

 

[teching123]

They are digital 30 modules...

However, when this was rebooted, it was timed, not a "when free".

 

[1043]

Are you using the new power supply for the DS30's?

 

[teching123]

No, I believe they are the original power supplies. I wasn't aware there was a new power supply.... When did these get released?

 

[jml2665]

http://support.avaya.com/elmodocs2/ip_office/tech/Global_IP_Office_Technical_Tip_143.pdf

 

[teching123]

Oh... thank you. I will try that out.

 

[aarenot]

i assume that you unplugged, and replugged the ext port, and checked it after. sometimes if the ext is attempted to be used during the reboot, it will lock up.

also, when you pull the cfg that is a snap shot of the cfg. when sending the cfg you revert to the snap shot plus your changes. negating any other changes to the cfg that occurred between your pulling the cfg, and the cfg being sent. this includes if you use the immediate, when free, times etc. options. it can revert passwords, and other items as well to the status of when you pulled the cfg. rememeber this when waiting any time between pulling, editing, and sending cfg's. i try to only use immediate, and no longer than 15 minutes between pulling, and sending cfg's.
if anyone else has access to manager, make sure they do not use it in between your pulling, and the actual sending. including if there is another instance of manager elsewhere on the network. a good practice is changing the password so it can not be done, before you pull the cfg you are going to change.

your cfg can change the pw back when it goes through.

 

[flashover]

catalyst telcom sent me a batch to load into manager and that fixed the issue