Announcement

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

  • Explanation of Events in Application log on Shoretel Server

    Hi,

    I am seeing these events in my application log on the Shoretel server. Does anyone have any insight?


    EventID: 119 - Switch xxxxx: Excessive number of packets lost from Raleigh xxxxxxx (44 out of 1406(this number varies))

    EventID: 233 - TMS has disconnected from switch xxxxxx. This may be a result of a network outage, administrative action, or unexpected switch behavior.

    EventID 233 is always followed immediately by this event:

    EventID: 234 - TMS has connected to switch xxxxxx.

  • #2
    The TMS ones are you the phone switches disconnecting from your network. Why? could be many reasons. If this is a remote office it is most likely you P2P connection.

    Comment


    • #3
      From what understand and have experienced all the switches and phones send notifications to the server every few seconds that they are still connected. The 233 events are simply a missed notifications to the server and usually due to network issues. They will come back on the next check (234) but I would keep an eye on them if they occur frequently. You can even setup the event filters under maintenance to send an email so you can see how often it happens ( I would also add 116 event).

      Some things to check:

      - Disable any teaming on the NIC of the server and avoid any HP hardware if possible.
      - Check for any network congestion
      - If you see a 116 event following the 233 event then check your spanning tree settings on the network.

      We experienced the 116 event which is a complete disconnect from the network. In our case this was due to spanning tree incorrectly set. ShoreTel has a best practices article on how to set spanning tree.

      At that time we were on 6.0 and I was told by our partner that the 119 event was a bug and can be ignored. We are now on 7.0 build 12.5.9303.0 and I still see this every once in a while.

      Comment


      • #4
        thanks for the responses!

        tyajckson, I am in contact with some of our Shoretel partner support guys and am asking for some tech articles regarding switch settings. What config is your STP in for the shoretel gear? What is interesting is that once I enable Fast Link (PortFast) on the RTSP settings for the LAGs that interconnect our switches, those 233 events and most of the 199 events are non-exisitent.

        we are still on 6.0 right now as well - not sure when we will be going to 7, but it should be this quarter.

        thanks again!

        Comment


        • #5
          Originally posted by jterribili
          thanks for the responses!

          tyajckson, I am in contact with some of our Shoretel partner support guys and am asking for some tech articles regarding switch settings. What config is your STP in for the shoretel gear? What is interesting is that once I enable Fast Link (PortFast) on the RTSP settings for the LAGs that interconnect our switches, those 233 events and most of the 199 events are non-exisitent.

          we are still on 6.0 right now as well - not sure when we will be going to 7, but it should be this quarter.

          thanks again!

          STP (or more appropriately RSTP or MSTP) should be disabled on the ports that ShoreGear switches are plugged in to... it freaks them out. I have also seen 3com's freak out phones when they have STP turned on.

          What switch infastructure are you using?

          Comment


          • #6
            We are running RSTP and with HP Procurve. The term portfast in Cisco is the same as edge-port for HP. So enabling portfast (edge-port) is what we enabled for the ShoreGear connections to the HP switch. This skips the first three RSTP steps and puts the port into an immediate forwarding state.

            Comment


            • #7
              I thought I would add an update to this:
              1-30264462
              Switch error "State=DYING" in TMSMAIN log which gets into a state where they disconnect and then reconnect.

              This defect was fixed in ST 7.5 12.15.8700.
              This error appears to trigger 233 and 234 errors.

              Comment

              Working...
              X