Cannot log into GUI Constant reboots

[pakman]

Hello,

I've got an issue where I can ping my controller but cannot log into the GUI and the box seems to keep rebooting. If I manually reboot the PBX 1-2 times I can usually get in for a certain period of time before it falls off. I've had Mitel and partner look at the logs several times. They couldn't find anything. We replaced the hardware at the recommendation of partner. That didn't work. We know replaced the hard drives so its essentially a new box besides a few cards. I'm still having the problem.  Has anyone had this issue before? There was nothing in the logs that pointed to a hardware of hard drive issue. One of the techs thinks that SDS errors are jamming it up and it couldn't wright to the old hard drives. I do have 1k sds logs on my VMCD and they mostly all reference this box on the fritz.  I've moved the PBX from a UPS that was not experiencing any issues to a straight wall jack but that didn't seem to matter. 

thanks for any suggestions

[acejavelin]

I would fix the SDS errors as soon as possible, a complete resync and then check the logs and manually correct any failures. But that isn't the cause of your problem... If you have replaced the hardware and done a full backup and restore (you said you replaced the HDD) and the system is still becoming inaccessible the problem could be in the network and not the PBX hardware.

The next time the PBX seems to become unavailable and "reboots" take a laptop and set a static IP address directly on the laptop and disconnect the LAN and connect the laptop directly to the PBX so only those two devices are talking to each other and see if you can connect to the system. If it is a network issue, withing about 300 seconds the MAC address tables should clear and you should be able to access the system.

I actually find it quite odd the logs would give no indication of the issue at all.

[pakman]

I would fix the SDS errors as soon as possible, a complete resync and then check the logs and manually correct any failures. But that isn't the cause of your problem... If you have replaced the hardware and done a full backup and restore (you said you replaced the HDD) and the system is still becoming inaccessible the problem could be in the network and not the PBX hardware.

The next time the PBX seems to become unavailable and "reboots" take a laptop and set a static IP address directly on the laptop and disconnect the LAN and connect the laptop directly to the PBX so only those two devices are talking to each other and see if you can connect to the system. If it is a network issue, withing about 300 seconds the MAC address tables should clear and you should be able to access the system.

I actually find it quite odd the logs would give no indication of the issue at all.

Thanks I will give that a try.

[pakman]

I was finally able to get onsite and test with my laptop directly plugged into the PBX. I experienced the same packet loss immediately. Unless our vendor used the same nic from the previous box I'm not sure how this could be. Any suggestions?

[acejavelin]

I still think this goes back to a network issue, and not a Mitel issue, the Mitel becoming unresponsive is a symptom and not the underlying problem... Something is happening in the network and it's locking up the embedded switch in the controller somehow.

Look at the commonalities here... You have replaced all the Mitel components except the database, but you have done a backup and restore which would eliminate any corrupt information, so the cause is likely something common to all phones that is NOT the Mitel controller, thus the network infrastructure. If you also control the network infrastructure, start looking at switch logs and making sure your STP/RSTP settings are consistent throughout the network and there are no loops anywhere. If you don't control the network, your in a tough spot as no one likes to have the finger pointed at them...

I am not saying any of these things are your issue, but if you have eliminated everything you can it might be time to call in tech support, too bad it's 10 times harder now than it used to be since we have to go through multiple layers to get to real support (I had Mitel for that).

[pakman]

I still think this goes back to a network issue, and not a Mitel issue, the Mitel becoming unresponsive is a symptom and not the underlying problem... Something is happening in the network and it's locking up the embedded switch in the controller somehow.

Look at the commonalities here... You have replaced all the Mitel components except the database, but you have done a backup and restore which would eliminate any corrupt information, so the cause is likely something common to all phones that is NOT the Mitel controller, thus the network infrastructure. If you also control the network infrastructure, start looking at switch logs and making sure your STP/RSTP settings are consistent throughout the network and there are no loops anywhere. If you don't control the network, your in a tough spot as no one likes to have the finger pointed at them...

I am not saying any of these things are your issue, but if you have eliminated everything you can it might be time to call in tech support, too bad it's 10 times harder now than it used to be since we have to go through multiple layers to get to real support (I had Mitel for that).

I do have control over the network and no logs or errors on that switchport or switch. I removed the network entirely from the equation and still experienced packet loss. Our Mitel partner wants to remove all the cards and run the ping test again as those cards are not brand new. 

[VinceWhirlwind]

The 3300 is programmed to auto-reboot when the CPU reaches threshold.
If somebody set this threshold too low, or if the CPU is going nuts for some reason, that might explain why it reboots.
 
We've had this with the root cause being faulty memory. The faulty memory was creating database corruption and the database corruption was causing high CPU.
 
I'd be worried that Mitel are suggesting "ping tests". Sounds like they have a long way to go before they reach the meat of the issue.
Depending on how many users are on the box, a few tens of thousands of SDS errors would cause this.

[pakman]

The issue was a bad E2T card supposedly. They replaced this after replacing everything else and it's working now. They tell me there was no logs indicating this before we replaced what we did. I find that hard to believe.