Shoretel Connectivity Issue

[ASG]

Good day all.
We've recently upgraded to Build 14.40.9006.0 of shoretel with call manager 9.2 and we're having an issue with our remote site. We have a remote site connected with a dual T1 P2P connection between 2 cisco routers. This remote site has it's own DVM/DHCP server and when we attempt to dial them from our HQ 3/5 times the call rings once and goes straight to their VM extension. If the phones in the remote site are on their own switches, they can call anyone in the remote site, but calling HQ results in the same issue. If they're on the HQ switches, they can't reliably call any extension, and their VM won't work 3/5 times.

Shoretel thought that it was an MTU issue between the two sites and asked us to raise the MTU from 1500 to 1550, thinking that the shoretel system was sending out larger packets that were getting dropped. We did this and it didn't solve the issue.

This issue has been happening only since the upgrade to the new version (7.5 previously). Does anyone have any ideas of what could be happening? If you need more info, I can provide what is needed.

Thank you.

[ASG]

We have been seeing EventID 119: Switch <switch_name: Excessive number of packets lost from IP (14 out of 858). This started the morning after the upgrade.

[eazeaz]

Upgrade

Sure gives the "appearance" of a network issue doesnt it?

i assume you have tried to reboot both servers already?

Also,


when upgrading from 7.5 all your codecs change. If you dont change them back, you could be using much more bandwidth than you were before, trashing your QOS, or even hitting your admission control bandwidth

what is your admission control set to on both sites?

what codec were you using BEFORE the upgrade?

If you were suddenly using more bandwidth, your qos could be dropping packets,etc

sounds reasonable to me

[ASG]

Sure gives the "appearance" of a network issue doesnt it?

i assume you have tried to reboot both servers already?

Also,


when upgrading from 7.5 all your codecs change. If you dont change them back, you could be using much more bandwidth than you were before, trashing your QOS, or even hitting your admission control bandwidth

what is your admission control set to on both sites?

what codec were you using BEFORE the upgrade?

If you were suddenly using more bandwidth, your qos could be dropping packets,etc

sounds reasonable to me

It seems like it's definitely coming down to a codec issue. We have several new ones since the upgrade and are probably going to revert back to the orginals. For some reason, this change appears to be greyed out.

[ASG]

We're changing now by creating a new group. Our previous codecs were PCMU/8000 and PCMA/8000.

[eazeaz]

Group

What is your admissional control bandwidth set to at each site?

It is a commonly misconfigured item.

[ASG]

What is your admissional control bandwidth set to at each site?

It is a commonly misconfigured item.

The ACL's are open for the P2P and we have no QoS in place on either router.

[eazeaz]

admission control

The admission control bandwidth is set in director for each site. Once you hit that limit, all traffic is dropped.

Very commonly misconfigured. Many admins dont even know its there.

[ASG]

The admission control bandwidth is set in director for each site. Once you hit that limit, all traffic is dropped.

Very commonly misconfigured. Many admins dont even know its there.

They were set to HQ 1500, remote site 1536. Set both to 1550. Tested and still the same.

[ASG]

Things we've tried so far:
Switching to low bandwidth codecs
Setting MTU on P2P routers to 1550
Setting admission control on Shoretel for both sites to 1550
Moving remote phones to HQ switches

[400degreez]

Have you run a trace on your network yet, if not, I suggest you do.

[ASG]

Have you run a trace on your network yet, if not, I suggest you do.

Other than a header checksum error issued from wireshark, we're not seeing any other issues. So delving into that one.

[sean]

It would be nice if you actually got a successful call; that way if you noticed the quality being bad then you could check the shoretel system for call settings like eazeaz was suggesting.

As for the 119 issue i have seen that from our remote sites and it relates back to they didn't have enough bandwidth so sometimes they would get a few dropped packets. Is your remote site WAN connection saturated? Might want to check bandwidth reports for that site.

Let us know what you find out; this is interesting.

[ASG]

It would be nice if you actually got a successful call; that way if you noticed the quality being bad then you could check the shoretel system for call settings like eazeaz was suggesting.

As for the 119 issue i have seen that from our remote sites and it relates back to they didn't have enough bandwidth so sometimes they would get a few dropped packets. Is your remote site WAN connection saturated? Might want to check bandwidth reports for that site.

Let us know what you find out; this is interesting.

We've tested the bandwidth between the two sites and we're usually right around 2746kpbs for the test. That's pretty solid for a dual T1 line. We only have about 35 machines on the other end and not all of them utilize the P2P in a hefty way.

[cburgy]

Still haven't gotten it resolved?