Announcement

Collapse
No announcement yet.
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • TMS errors

    Last week we installed a new MPLS circuit between our 2 locations. Ever since doing this our headquarters voice mail server keeps giving TMS errors concerning the remote office switch.

    Computer: AVTEL-ROCH
    Version: 13.23.4801.0
    Type: Warning
    Date: 10/5/2009 3:39:44 PM
    Source: ShoreWare
    Category: (2) TMS
    Event ID: 233
    TMS has disconnected from switch "Tampa SG50" (192.168.20.40). This may be as a result of a network outage, administrative action, or unexpected switch behavior.

    Also the switch connectivity screen shows the remote DVM is unable to communicate with TMS.

    Before this we were using just a Cisco router VPN through the internet between offices.
    When installing the MPLS we changed the IP on the existing router at the remote office and installed a new router using the old routers IP, which was the default gateway for the remote network. The new MPLS router forwards local traffic and internet traffic to the old router.

    Today we pulled the cable on the MPLS and the old routers are set to fail-over to the old VPN. Even with this the switch connectivity did not restore for all devices at the remote office.

    Everything has been rebooted several times.

  • #2
    I've been battling the same issue for some time. This error is thrown every time your remote switch sends a TCP Keep-Alive to your HQ switch and it is not returned (its constantly sending them from port 1026 to an incremented port #). I can't figure out, for the life of me, why my remote sites are doing it. It doesn't seem to be affecting much for us, but I still don't like seeing those errors. I keep leaning towards our MPLS carrier, but they claim everything is fine after like 3 open cases. Who is your MPLS provider?

    Comment


    • #3
      AT&T is our carrier for MPLS.

      Comment


      • #4
        Can you do a successful LSP ping to Director from the switch. I think this would be a good starting point.

        400Degreez...it's my time to shine!

        Comment


        • #5
          Since you have MPLS and VPN at your locations, are you using seperate devices for each of the connections (i.e. router for MPLS and seperate firewall/security router for VPN)?

          If so, are you using multiple VLANS at the offices? Is the voice vlan on a seperate broadcast domain than where the router/fw sits or are they on the same subnet (i.e. 10.1.1.X/24 for all devices)?

          Comment


          • #6
            Good Morning--Have you gotten the issue fixed yet, if not, i would do a LSP Ping and ENSURE you have a successful LSP ping. I would also pull up the routes on your switch and make sure they are going out the MPLS Gateway. Anywayz.....if they are not....clear the routes. Holla back and let me know how it goes. ICMP Redirects could be the culprit

            Comment


            • #7
              Has anyone nailed down what is causing these errors yet?
              I too am seeing these errors.

              I've installed a new SG50 in a new location and immediately starting seeing these errors. I have been trying to troubleshhot the issue for a few weeks. Last week another location that has been installed for several months starting throwing up these errors also. No changed were made in the network that I am aware of.

              I am working with my vendor. We have done LSP Pings and can say for certain that we are losing packets.

              Although we can pin point the issue residing in the network, I cannot say for certain where the issue resides.

              I am leaning towards QOS, however, that doesn't explain why a location would starting losing connections to TMS when there have been no changed on the network.

              Also- ICMP redirects would not be an issue as the voice vlan and WAN vlan are on different subnets.

              Comment


              • #8
                I've seen rather hard to find things like mis-matched MTU values at opposite ends of the network cause issues like this. Probably worth a double check of the routing table on all your ShoreTel switches as well as getting a trace from each end of the packets that do go through and doing a pretty detailed examination of them side by side in Wireshark.

                Simultaneously I'd be looking to the MPLS vendor to do some work here. If your devices are delivering packet to their border router then it must be the network dropping them...

                Comment


                • #9
                  ShoreTel increased MTU to 1472 effective release 8.x. Figure 1500 with overhead. If that's not changed on network, packets fragment.

                  Comment


                  • #10
                    Is this still an issue? If not was MTU the solution? I am experiencing the same thing at my remote site. Worked for about half a day after changing MPLS providers and now the switch just throws errors.

                    Comment

                    Working...
                    X