Mitel 3300 Network issue - Cannot sync Network Elements 1

[dmax713]

Hi all,
We have 6 Mitel 3300 controllers, all at separate buildings. 5 of these buildings have our company's fiber connecting them, all layer 2 connections. These are working fine, the 3300s can sync network elements, and I can call between those buildings, and call out from all buildings. At the 6th building, I'm having a major networking issue. We are trying to connect the 3300 over a leased fiber line. This line provides 1G data service between a remote building and our datacenter, where the core of our network and the primary Mitel3300 is located. There is a Cisco router at each end of the fiber line. The connection between the buildings seems to be working properly. I can see all of my VLANs at the remote building. We have a VLAN set up for each building's VoIP traffic. However, even though I can ping, and do a tracert to the other 3300s from the remote site, I am getting a major alarm, cannot call to the other buildings, or call out. I can only call to extensions that are local on the 3300. At the remote site, the 3300 is plugged in to a Cisco 3750-X switch. That switch is directly uplinked to the leased router, which carries the traffic back to our datacenter. At the datacenter, the other endpoint leased router is directly connected to a Cisco 6509 (which is our network core). The primary Mitel 3300 is directly connected to that 6509. The uplink ports (to the leased routers) on the 6509 and 3750-X are set as trunk ports, using dot1q encapsulation. All of our other Mitel 3300s are just set on an access port, for their specific vlan. I tried setting the 3300 at the remote site on a trunk port, with a native vlan, and that allowed me to call the other buildings, and call out, but I still could not sync the network elements.

Here is a sample of the error I get from the 3300, on at the remote site:
Software 3744 Warning 2012/Aug/11 13:40:16 McSockUtil "HandleTimeoutSockMgr Secure Negotiation Timer has expired - Sock[7] - Remote IP Addr[10.41.86.1:1728], SockRecAddr[101c9fb0], sending notification to SockManager to close socket." Main SockMgrTimer.cpp;86

If anyone has thoughts, I'd appreciate it!!!
THANKS!

 

[bobcheese]

ok, few things:

When you say you can ping and tracert from the remote site to the other 3300's is this from the remote site 3300 ESM or from a PC on the remote site?
If from a PC is the gateway the same address?
Are any of the routers blocking ports? using firewall/ACL rules?
Have you confirmed you IP networking programming is correct on the 3300 in remote site?
What is the major alalrm (guessing IPC Comms)

 

[dmax713]

Thanks so much for your reply. Here are the answers:

When you say you can ping and tracert from the remote site to the other 3300's is this from the remote site 3300 ESM or from a PC on the remote site?
- I was able to do so from both the 3300 itself, and from a PC.
If from a PC is the gateway the same address?
- Yes, I did put the PC onto the same vlan and subnet as the 3300.
Are any of the routers blocking ports? using firewall/ACL rules?
- Not sure. According to our service provider, they are giving us a layer 2 connection between the two endpoints. (The remote building, and our datacenter.)
Have you confirmed you IP networking programming is correct on the 3300 in remote site?
- Yes. My partner and I were so frustrated, we actually removed the 3300 from the remote site, and transported it to our datacenter. When we connected it to the network there (into the Cisco 6509 I mentioned), using the same vlan and subnet, the 3300 was able to contact all the other ones, and it stopped alarming. Additionally - We left the 3300 connected in the DC, then when back to the building, and were able to use the phones in the building to call all other buildings and call out! I know you may be thinking, "why not leave it in the DC?" - The issue being there would be no Analog service to the building, and we are using some analog lines including faxing. But at least we proved, the voice traffic could pass over the fiber link. It's just the network element sync that constantly fails.
What is the major alalrm (guessing IPC Comms)
- Correct. The system cannot talk to the other 3300s, because it says the ipc trunk link is down, so it results in the major alarm.

 

[bobcheese]

If it works in the DC (on the same VLAN) but not at the remote site it can only be a networking issue and since you have already ruled out routing issues then it only really leaves ports being blocked.

Ask them to make sure the following ports are open from 3300 RTC & E2T addresses (if you have an E2T) to the DC:
1066 (IP Trunk unsecured)
1067 (IP Trunk Secured)
7050 (SDS)
6800 (RTC)

Also ask them to make sure the following ports are open from the whole remote Voice VLAN to the DC:

5060 (TCP/UDP for SIP)
5061 (TLS for SIP)
50000-50511 (Voice Media)

 

[dmax713]

Thank you for that information. We will be continuing to work on the issue today, I'll post the results.

 

[dmax713]

After a total of 5 days, and many hours on the phone with Windstream getting no where, they finally sent a Network Tech on-site. He looked at the configuration on their endpoint routers, and determined the issue was MTU size needed to be set to allow jumbo frames. Windstream had the MTU set as 1500, which is standard, but since we were tagging the vlan, that increased the size over the limit, thus the packet was dropped. They were also blocking spanning tree on the link, which was another part of the issue. Their tech verified that the config on our equipment was correct, so at least that made us feel better about ourselves. Too bad it took them 5 days to resolve this extremely frustrating issue! Thanks again for your response, I did use Wireshark to observe the ports you indicated would be used by Mitel. I compared the results between the unit on the remote link and one of our other units that was working. Very helpful, and appreciated! THANK YOU.