Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Avaya IP 500v2 daily reboots

Status
Not open for further replies.

Ed.Sabano

IS-IT--Management
Jun 1, 2017
21
US
I started getting these daily random reboots. We have avaya ip 500 v2 on 9.1.5.0 and about two weeks ago, the system just reboots randomly daily. I tried to catch the reboot log but am not able to see anything. I dont think it logged the reboot. I have two logs here but it only tells me that system was not shutdown properly as far as i can read these. We had two PRI lines with one was being used as backup and recently got rid of the back up line.

Service Alarms:

The follwoing licenses are all in use.
Licesne Type: Power User



8KHz clock source was changed
Previous source was internal


Trunks:

Alarms for Line : 1 (in Red Text)

Loss of signal
Trunk Out of Serivce

Alarms for Line 2: (In yellow text)

Yellow Alarm
Trunk Out of Service


All occurred during the reboot. The second PRI line we had was for backup and its no longer in service. Could it be that its rebooting because of the license? Any feedback would be helpful. Also attached the log.
 
 http://files.engineering.com/getfile.aspx?folder=2441c231-a47e-4258-82a8-d44c94e6aa0e&file=avaya500v2_reboot_20170907_134100_(6).txt
lots of things could cause this, faulty power, a bad power power supply, a defective UPS, A defective IP 500 controller
 
Those alarms are normal following a reboot, you need to capture a trace just before the reboot, not after :)
 
joe2938 (Programmer)7 Sep 17 19:13
lots of things could cause this, faulty power, a bad power power supply, a defective UPS, A defective IP 500 controller

So no way to troubleshoot this except just start eliminating one by one. Or just put in a new controller.
 
amriddle01 (Programmer)7 Sep 17 19:26
Those alarms are normal following a reboot, you need to capture a trace just before the reboot, not after smile


I have it. The reboot was at 13:14.
 
 http://files.engineering.com/getfile.aspx?folder=ad58b402-504e-4e05-aaeb-79c6a6b3cbdd&file=avaya500v2_reboot_20170907_131403_(5).txt
one more thing.
Alarms in red writing are still active while Alarms in black writing are historical.
That usually helps finding nasty stuff that is still buggering up the system

Joe W.

FHandw, ACSS (SME)


"This is the end of the world, make sure to buy your T-shirt before it is too late"
Original expression of my daughter
 
i am just going to replace the unit, that should take care of it.
 
Yes and no. It's a rich tapestry this problem solving lark. If it's firmware or config related, you've gone and pissed 500+ dollarydoos up the wall by replacing the control unit unnecessarily.
These two events occurred in the last two seconds of the up time.

13:11:59 61253566mS PRN: SyncSystemTime: sync gap=18(sec)

13:12:44 61297978mS PRN: UDP: CHECKSUM FAILED 81f0 against 932f (src ac1b145a dest ac1b14ff)

Therefore,
Check your time setting config source and time settings of any associated servers, such as a vmpro server.
Confirm only 1x ISDN line is set to clock and all others are set to fallback or unsuitable
Upgrade the IP Office to the latest release of 9.1.X after consulting the TB for that release to confirm the release is right for you.

Also, you don't appear to be running the very important 'Error" filter in Sys Mon.

Good day to you.


holdmusic34 1
German Tourist 0
 
holdmusic34 (Vendor)8 Sep 17 11:53

Yes and no. It's a rich tapestry this problem solving lark. If it's firmware or config related, you've gone and pissed 500+ dollarydoos up the wall by replacing the control unit unnecessarily.
These two events occurred in the last two seconds of the up time.

13:11:59 61253566mS PRN: SyncSystemTime: sync gap=18(sec)

13:12:44 61297978mS PRN: UDP: CHECKSUM FAILED 81f0 against 932f (src ac1b145a dest ac1b14ff)

Therefore,
Check your time setting config source and time settings of any associated servers, such as a vmpro server.
Confirm only 1x ISDN line is set to clock and all others are set to fallback or unsuitable
Upgrade the IP Office to the latest release of 9.1.X after consulting the TB for that release to confirm the release is right for you.

Also, you don't appear to be running the very important 'Error" filter in Sys Mon.

Good day to you.


The time settings are correct.

Two ISDN lines are configured but one is no longer in service (which was for failover). In the system status, it shows that line "1" is out of service which is set to Network and line "2" is set to fallback. Should i need to switch the line 2 to clock (network) then?

Also, the error filter under system tab is checked.
 
yes. the primary, preferred, sexiest, main Isdn trunk should be s3t to network.
that's probably the reason for your exciting trips through reboot land.

holdmusic34 1
German Tourist 0
 
why does it reboot if the main line is set under fallback? It didn't do that at the beginning, started after couple of months.

 
i changed the clock, and it went without a reboot for a few days and started rebooting again.

The sysmonitor is completely throwing me off with log configuration.

Save screen Log as : this is the current screen you see in real time

Log Preference: this is to save the actual log to file.

When i do this, i dont see any logs in the monitor folder. The start/stop logging to file button is checked.

Under trace options what is save file,load file, load partial file, and select file for? And for god sake what is rollover log, can anybody explain this to me please? I want to trace the reeboot again because it has to show some kind of error.
 
check your isdn filters. it prob says something like falc slip store.
system status isdn errors would also be riddled with red alarms.
If so, check with your carrier.

You need to read the monitor manual available on the knowledgebase.

holdmusic34 1
German Tourist 0
 
why dont you upgrade to latest SP to rule out the software first, and then test the hardware piece by piece
 
You can still upgrade to the latest 9.1 release, which would be 9.1 SP12 although I haven't tried that.
Highest I have currently is 9.1 SP11 which seems to be stable, anything below 9.1.6 is pretty crappy though.

"Trying is the first step to failure..." - Homer
 
like the time i purchased discounted rollerblades.

cheapskates.

I hate jokes about German sausages.

They're the wurst.
 
its complicated. i dont have access to avaya support. :( I dont have the sold to number.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top