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

  • Out of Service (Operational)

    I have users in home offices that connect to Corporate via site to site VPN. They are using ShoreTel 530 and 230 phones that connect to phone switches in the Corporate office. Every 8 hours the VPN renegotiates the VPN connection and when it does the phones stop working. They either say "No Service" or "Requesting Service". ShoreWare Director lists the phone as Out of Service (Operational). Normal IP traffic in both directions works just fine after the VPN renegotiation. I can even ping the remote phone from the Corporate office. I have found several work arounds that get the phones back in service but only until the next VPN renegotiation.

    • In ShoreWare Director move the phone to an alternate phone switch.

    • Change the IP address of the remote phone.

    • In ShoreWare Director delete the phone and then reboot the phone and assign the user's extension.

    We are a Cisco shop with an ASA 5510 in Corporate and ASA 5505s in the home offices. We are running ShoreTel 7.

    Any thoughts?

  • #2

    What's the round-trip delay between the phone and switch?


    • #3
      If you can ping the phone, you are passing TCP packets, but the phones communicate with the switches over UDP.

      UDP: 2427 IP phones listen on this port (IP phone is listening for its TMS ping)
      UDP: 2727 Switches listen on this port (Switch is listening for the Phones reply)

      Thus, when the phone or switch does not receive the proper TMS reply, the Director will return the phone as Out of Service (Operational).

      Normally, I suggest the remote VPN device be set to an aggressive mode in that the VPN will normally go dormant with no TCP traffic and aggressive mode keeps the link up for UDP traffic.

      I have seen IP phones go down periodically on VPN connections, but not at regular intervals.


      • #4
        You can normally set keep-alive packets on VPN devices as well. This will keep the tunnel active (it doesn't do anything to address the tunnel reneg. the keys though).


        • #5
          The remote office with the longest delay has an average of 85ms. Most of the other offices are around 60ms.


          • #6
            We have the ASAs set for 60 second keep-alive packets. Phase 1 and 2 reneg is set for 8 hours. We also setup a continuous ping to ensure that the VPN was always receiving "interesting" traffic and would therefore keep the VPN active.


            • #7
              We are moving our remote offices to static public IPs. Right now they are dynamic and connect very much like a regular VPN client. For testing purposes we changed one office to aggressive mode and left another office in standard mode. I'll post the results as soon as I have some. Thanks for all you help.