Mitel Forums - The Unofficial Source
Mitel Forums => Mitel MiVoice Business/MCD/3300 => Topic started by: chris_s on March 22, 2017, 11:41:49 AM
-
Hello,
I have two 3300 units connected across a VPN tunnel. I had the VPn go down for a few minutes this morning and now when trying to dial extensions on the remote side we get a "out of service" error on the handset
rebooting one of the 3300s brought the connection back up, but of course ::) there was another hiccup afterward and I'm back to out of service.
Is there a better way to get these things to talk again?
thanks!
-
They should just reconnect, although I have seen it take 5-10 minutes in some cases. Never seen any other condition and we take care of lots of Mitel networks.
-
what conditions is it looking for in order to reconnect? I am able to ping both devices from both sides of the network, it has been an hour and counting now
-
The 3300's will exchange "heartbeat" messages automatically, I'm not sure what the interval is but not more than a minute. Go into Maintenance Command and do a "state xnet all" and see what it says. To test connectivity between the 2, do a "rmess verify pbx [remote pbx number] lan".
-
here are my results
Next enter: ICP or PBX or TRUNK or LINK or ALL
Signalling | Link | Dest | XNET | State | Owner | ID |Status
Dvc Location |Handle|Switch| Trunk Id | | | |
-------------------------------------------------------------------------------
1 1 11 | | 1 | |Out of Service| | |
1 1 11 | | 2 | |Idle | | |
-------------------------------------------------------------------------------
and
RMESSAGE: Connected to PBX 1
RMESSAGE: Verification successful to PBX 1
RMESSAGE: Disconnected to PBX 1
-
And what does the other PBX look like? 2 can successfully talk to 1, but the link is still OOS, so I'm curious what the same commands look like on the other PBX.
-
Signalling | Link | Dest | XNET | State | Owner | ID |Status
Dvc Location |Handle|Switch| Trunk Id | | | |
-------------------------------------------------------------------------------
1 1 11 | | 1 | |Manbusy | | |
1 1 11 | | 2 | |Manbusy | | |
-------------------------------------------------------------------------------
RMESSAGE: Connected to PBX 2
RMESSAGE: Verification successful to PBX 2
RMESSAGE: Disconnected to PBX 2
-
I ran a "rts xnet all" and now get this for the state xnet all
Signalling | Link | Dest | XNET | State | Owner | ID |Status
Dvc Location |Handle|Switch| Trunk Id | | | |
-------------------------------------------------------------------------------
1 1 11 | | 1 | |Idle | | |
1 1 11 | | 2 | |Out of Service| | |
-------------------------------------------------------------------------------
-
Double check the config, in particular the IP addresses assigned in ICP/PBX Assignment. Assuming each system is looking for the correct far-end IP and the network between the 2 is up and available, there's no reason they should show as Out of Service.
-
I'll check the configuration, but the fact that the connection WORKS after I reboot one of the PBXs makes me think that that is not going to be the issue
-
I see WAN outages on the MCDs quite frequently - their logs record the IP trunk going down, and it always comes back up shortly after the actual link comes back up.
I don't recall doing anything special apart from the normal network elements and clustering config.
-
I'll check the configuration, but the fact that the connection WORKS after I reboot one of the PBXs makes me think that that is not going to be the issue
My point is you shouldn't have to reboot the PBX for the link to come back up, so *something* is wrong, we just have to figure out what. Checking the existing config is a starting point.
-
Signalling | Link | Dest | XNET | State | Owner | ID |Status
Dvc Location |Handle|Switch| Trunk Id | | | |
-------------------------------------------------------------------------------
1 1 11 | | 1 | |Manbusy | | |
1 1 11 | | 2 | |Manbusy | | |
-------------------------------------------------------------------------------
Your XNET trunks are in manbusy
try rts xnet all
-
yes the manbusy was changed to OOS after I ran rts xnet all, as above
I checked the IP addresses, that all seemed to be set properly
I am able to ping from one device to the other, in the maintenance commands section
-
Yes you can under maintenance and diagnostics
ping <ipaddress>
Also try on both controllers
busy xnet all ip
rts xnet all ip
-
ping works fine, can ping each from the other
ran the busy and the rts, still showing OOS
-
This is a long shot but go into the ICP/PBX networking on each element and change the IP address to something else then save it then change it back.
I have never had one not recover on its own before.
-
I've had an issue before similar to this and it end up being a problem with the VPN.
There was some sort of routing issue. I can't remember any further but get the VPN checked as well.
-
My first thought would be to blame the network, but his ping succeeds, so there is no layer2 or layer3 issue.
I'd be looking closely at the trunk config next....
-
I tried changing the ICP/PBX addressing, then changing it back, no luck.
tried rebooting routers on both side, no luck
I can ping both devices FROM the other device via maintenance commands. I'm no packet monkey, but IMHO connectivity is connectivity *shrug* in fact I am accessing the web console of the remote unit via the VPN (either direct via web, or by RDP'ing into a server on that side and using web there)
I'm supposed to have the local mitel service providers coming by tomorrow to fix it, I will be watching carefully and reporting back here.
-
Don't you have your network NATed?
-
In my case I'm not sure if it was the far end MCD that responded to the ping, it may have been something else that was misconfigured in the core.
-
I'm going to file this in the "long shot" category, but I've had systems that could see each other and were convinced the others were in alarm, when in fact they weren't. Our solution ended up being in SNMP Configuration. We changed "Enable SNMP Agent" to no, let it sync, then changed it back to Yes and all was good.
-
very unsatisfying resolution, ONE more reboot of each 3300 unit and they decided to start working