Testing IP trunking connections remotely

[kwbMitel]

I have a customer that previously had no issues with their 2 clustered systems. The 2 systems are in separate cities and connected via the customers VPN.

I can ping and tracert between the contollers without issue

The customer claims there are no port restrictions between the sites.

The IP trunking fails the RMess verify

SDS Fails with a simple update (comment field in Cluster Element)

I cannot use reach thru from 1 controller to the other (either direction.

I can connect to both systems via ESM and telnet

Systems are 3300 MXe's with MCD 5.0 SW

The issues started when the customer had issues with their ISP connection at the remote site and has not worked since the ISP "repaired" their issue.

Other than suggesting to the customer that the network is now blocking ports that were not blocked before, does anyone have any other suggestions for troubleshooting/isolating the issue?

**********************************************
What's most important is that you realise ... There is no spoon.

 

[dryaquaman]

Try putting a phone in teleworker phone and point it to the controller on the opposite controller.

If you can point it to your local controller and it works and it doesn't work across the network then you have a network problem.

Dry Aquaman

http://www.university-music-on-hold.com

 

[LoopyLou]

What would wireshark report on an issue like this I wonder? Can't really think of anything helpful.

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[bribob]

I recently used NMAP to confirm that the appropriate ports were accessible between subnets.

Here are the ports that were open:

21 tcp open ftp syn-ack
23 tcp open telnet syn-ack
25 tcp open smtp syn-ack Mitel 3300 PBX smtpd Access denied
80 tcp open http syn-ack Apache Tomcat/Coyote JSP engine 1.1
443 tcp open http syn-ack Apache Tomcat/Coyote JSP engine 1.1
1066 tcp open fpo-fns syn-ack
1067 tcp open instl_boots syn-ack
1606 tcp open unknown syn-ack
1750 tcp open sslp syn-ack
1751 tcp open syn-ack
1752 tcp open lofr-lm syn-ack
1753 tcp open unknown syn-ack
1754 tcp open syn-ack
2001 tcp open telnet syn-ack SMC SMC2870W Wireless Ethernet Bridge
2002 tcp open telnet syn-ack SMC SMC2870W Wireless Ethernet Bridge
2004 tcp open mailbox syn-ack
2005 tcp open deslogin syn-ack
2006 tcp open invokator syn-ack
3999 tcp open remoteanything syn-ack
4001 tcp open newoak syn-ack
5000 tcp open tcpwrapped syn-ack
5001 tcp open tcpwrapped syn-ack
5002 tcp open tcpwrapped syn-ack
5003 tcp open tcpwrapped syn-ack
5004 tcp open tcpwrapped syn-ack
5060 tcp open sip syn-ack SIP end point; Status: 200 OK
5061 tcp open sip syn-ack SIP end point; Status: 400 Bad Request
5190 tcp filtered aol no-response
6800 tcp open syn-ack
6802 tcp open syn-ack
6803 tcp open syn-ack
6830 tcp open syn-ack
7011 tcp open syn-ack
7050 tcp open unknown syn-ack
8000 tcp open http-alt syn-ack
8001 tcp open vcom-tunnel syn-ack
8080 tcp open http syn-ack GoAhead-Webs httpd
8443 tcp open http syn-ack GoAhead-Webs httpd
10990 tcp open unknown syn-ack
15372 tcp open unknown syn-ack
15373 tcp open unknown syn-ack
15374 tcp open unknown syn-ack
49500 tcp open unknown syn-ack
49501 tcp open tcpwrapped syn-ack

But you say that routing between the two subnets is working? I'd want to know exactly what the ISP did to 'resolve' the issue.

 

[kwbMitel]

That's some good info bribob.

I take it that list was obtained from a working system?

Will u be in town soon? Lunch?

**********************************************
What's most important is that you realise ... There is no spoon.

 

[dryaquaman]

If you're buying lunch.....

<g>
Dry Aquaman

http://www.university-music-on-hold.com

 

[kwbMitel]

Lunch, no problem, anyone anytime they find themselves in Edmonton, Alberta, Canada

Travel and Accommodations are up to you

**********************************************
What's most important is that you realise ... There is no spoon.

 

[bribob]

Yes, that list of ports are from a working system (3300 CX2 in the US of A). The NMAP (v)host was located in the same subnet as the vMCD.

Wouldn't you know it, the issue that lead to the NMAP scan was the result of the wrong IP address in the Network Element form...

And yes, I'll be up next week.