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 strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

MCD 6.0 SP2/SP3 networking issues

Status
Not open for further replies.

MitelJam

IS-IT--Management
Nov 25, 2009
14
JM
I have two systems MCD 6.0 SP2 and MCD 6.0 SP3 networked but not clustered. Networking is being done via VPN and were working. One system was rebooted Friday morning and the customer discovered that the two were not talking to each other, but we do not know if this happened after we rebooted, or if they stopped communicating before. No changes were done on either system and the customer said no changes were done to the network. Windows applications continue without any discussions. RME responds with TIMEOUT on both sides. Ping and Tracrt work from both sides. I rechecked programming on both systems and that's ok.

Any help would be appreciated.

 
Windows applications continue to work without any disruptions.
 
if programming is ok then it sounds like perhaps ports are being blocked ?

are you running pings from RTC-> other site via maintenance command ?



If I never did anything I'd never done before , I'd never do anything.....

and due to an endless stream of MiCollab , MiCC issues
Life would be simpler If only they tested products properly before releasing them .....
 
Pings are going through via command line. What port nos. should I allow to go through?
 
command line on what ? , if you are not doing them from the maintenance command then perhaps pings arent working as you think?

1066 TCP is XNet 1067 TCP is Ip networking SSL

there may be more required for the speech portion , We normally use clustered systems so i dont have a list off hand



If I never did anything I'd never done before , I'd never do anything.....

and due to an endless stream of MiCollab , MiCC issues
Life would be simpler If only they tested products properly before releasing them .....
 
if you want to know when the IP trunks dropped check the maintenance logs it will show when the heartbeat dropped.
 
Also, when you say 'the two systems are not talking to each other' do you mean the IP trunks are down? IE you have an IPCOMMS alarm?
 
Billz66- pings from the ESM on either of the 3300's to the other RTC. Are you saying if they were clustered there might not be these problems?

Bob cheese- yes icp comms error. I will check logs for the heartbeat error.

I left the network guy yesterday and will check back with him if had any progress.
HTTPS to the far side was not tested because the guy said VPN would not open up on that type of traffic, so he gave me access via Remote Desktop over the VPN
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top