Switch communication over WAN/IPsec VPN

[robsuh]

Hello,

Does anyone know of a best practices guide in regards to Shoretel over the Internet via a VPN/IPSec? I know it is actively advised to avoid sending calls over the Internet, but alas we are stuck trying to make it work.

We have two facilities VPN'd together via two Cisco 2811 (IPSec tunnel.) For the most part, the connection is stable. The facilities are around 170ms apart (across the planet.)

The problem we are seeing is occasional switch disconnected and reconnected messages. They symptoms manifest itself in PCM/Contact Center agent software dropping connection and quickly reestablishing connection. The "micro outage" lasts around 3-8 seconds. Any voice calls that are established during the micro outages are okay and don't drop.

Anyways, I was wondering if there was any suggestions to make the agent software more resilient to occasional and small outages. Is there any timeouts to extend, especially on the switch to switch communications?

Any insight or recommendations would be appretiated.

Thanks,
Rob

[Jlorenz]

If your a Partner or Enterprise customer you can grab the WAN LAN best practices. The problem with your connection is it is asymmetrical and you will never get a SLA from an ISP. No matter what VPN tunnel or hardware provider, you are at the mercy of the "PUBLIC INTERNET"

It is IMHO very bad practice to deploy Sites across public network, With a 180 PLus MS turn around that is just so far out there it is a wonder the SG's are connecting at all.

I am not sure I can offer any advice but to get a better Network connection

Hello,

Does anyone know of a best practices guide in regards to Shoretel over the Internet via a VPN/IPSec? I know it is actively advised to avoid sending calls over the Internet, but alas we are stuck trying to make it work.

We have two facilities VPN'd together via two Cisco 2811 (IPSec tunnel.) For the most part, the connection is stable. The facilities are around 170ms apart (across the planet.)

The problem we are seeing is occasional switch disconnected and reconnected messages. They symptoms manifest itself in PCM/Contact Center agent software dropping connection and quickly reestablishing connection. The "micro outage" lasts around 3-8 seconds. Any voice calls that are established during the micro outages are okay and don't drop.

Anyways, I was wondering if there was any suggestions to make the agent software more resilient to occasional and small outages. Is there any timeouts to extend, especially on the switch to switch communications?

Any insight or recommendations would be appretiated.

Thanks,
Rob

[robsuh]

Hi Jlorenz,

Thanks for the reply. Yes, we are an Enterprise customer and I will be searching for their WAN LAN best practices guide.

I do agree that trying to make it work over the Internet isn't advised but I'm unfortunately stuck with trying to make it work better.

Thanks again and I hope the WAN LAN best practices guide can at least give me some knobs to turn.

Rob

[eazeaz]

Locations

Where are the two locations? Just curious.

While I agree that 170ms is not going to cut it but........

have you looked at the tunnel config?

Many times there are timeouts that will drop the tunnel if no traffic is seen, or re-negotiation times......

we had a similar problem with a tunnel once. Its key life was set to like 5 minutes. Every time it re-negotiated there was about a 3-5 second drop/halt in traffic.

Most traffic will simply re-try and pass and you will never know it happened. Any UDP traffic would not.... it would just die.

Just a thought.

[robsuh]

Hi eazeaz,

The locations are in Seattle and Ireland.

Thanks for the insight into the tunnel. I did go down the route of ipsec tunnel issues and I did clear up some of the errors we were getting.

I will investigate that angle further though.

Rob

[eazeaz]

Tunnel

If you do a continuous ping, do you lose replies at the same time the switches go offline? May take a while to catch it, but it would tell you that the connection itself is going down, and elimate issues with the shoretel switches themselves.

[robsuh]

Hi eazeaz,

Yup, we are definitely losing packets (I'm using mtr on linux and pathping on Windows on both sides of the link to measure.) The packet loss at worse is something like 43 / 1500. Which is still bad, but I guess we're just trying to make it work around such things.

I have just configured a new monitoring session, where every 5 minutes mtr sends 100 packets to each "hop" on the link to determine packet loss.

I'll check that to see if the tunnel is dropping.

Thanks,
Rob

[eazeaz]

Qos

Do you have QOS setup on the routers? If not, you could easily be filling the queue and the router would just drop the extra packets.... maybe its not your tunnel at all?

A vpn over the internet from Seattle to Ireland would be very dependant on QOS being setup properly for sure.

[Jlorenz]

One other Item on the suggestions, its important to understand the Hardware your using is UDP aware as well. This is how ShoreTel sends its keep alive, if you are expecting TCP as a keep alive ST wont do that

[cburgy]

VPN devices will renegoitiate the keys (and therefore the tunnel) after a certain amount of time or a certain amount of traffic. With Shoretel riding over the tunnel, I'd have it renegoitiate based on time.

[Jlorenz]

VPN devices will renegoitiate the keys (and therefore the tunnel) after a certain amount of time or a certain amount of traffic. With Shoretel riding over the tunnel, I'd have it renegoitiate based on time.

Chris
There in lies the problem, ShoreTel needs the ability to keep the UDP keep alive going between SG's and Servers. In many Tunnels its time is TCP based ignoring UDP traffic. If no TCP is seen and or is time based say 5 minutes, this can cause issues with ShoreTel connectivity.

The recomendation is to aquire hardware that is UDP aware in these time slots, so any activity is seen and the time factor is not a given.

I hope that makes sense