Announcement

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

  • HQ Server can't see remote switch, switch at HQ can see remote switches

    Hi All,

    Wondering if anyone has had anything like this before. I have a HQ site with a HQ server and 1 x SG90BRI. HQ server is running connect build 21.80.7840.0. The server at HQ cannot see remote switches according to the Connectivity page, but the SG90BRI at the same site on the same LAN/subnet can see the remote switches. If I go to the Status and Maintenance-> Appliances page I can see the switch is online here and has no issues bar a few IP phones out of service which is no big deal.

    To make this a little more easy to understand I will try and give the IP addresses etc. (I haven't put the real IPs but they are the same just different ranges)

    HQ Site:
    HQ Server - 192.168.0.15
    HQ SG90BRI - 192.168.0.13
    HQ Default Gateway - 192.168.0.254 (this has a site to site VPN from the router at HQ to all other sites with no firewall on the VPN at all.)

    Remote Site 1:
    Remote SG30 - 192.168.1.10
    Default Gateway - 192.168.1.254 (again this has a VPN from the router to all other sites routers)

    Remote Site 2:
    Remote SG30 - 192.168.2.15
    Default gateway - 192.168.2.254 (again this has a VPN from the router to all other sites routers)

    Connectivity screen and LSP Ping Results:
    HQ Server - 192.168.0.15 -> HQ SG90BRI - 192.168.0.13 - SUCCESS
    HQ Server - 192.168.0.15 -> Remote SG30 - 192.168.1.10 - FAILS
    HQ Server - 192.168.0.15 -> Remote SG30 - 192.168.2.15 - FAILS

    HQ SG90BRI - 192.168.0.13 -> HQ Server - 192.168.0.15 - SUCCESS
    HQ SG90BRI - 192.168.0.13 -> Remote SG30 - 192.168.1.10 - SUCCESS (this to me suggests VPN/Network is fine, TAC are trying to tell me otherwise but not offering any real explanation more than saying it)
    HQ SG90BRI - 192.168.0.13 -> Remote SG30 - 192.168.2.15 - SUCCESS


    Remote SG30 - 192.168.1.10 -> HQ Server - 192.168.0.15 - FAILS
    Remote SG30 - 192.168.1.10 -> HQ SG90BRI - 192.168.0.13 - SUCCESS
    Remote SG30 - 192.168.1.10 -> Remote SG30 - 192.168.2.15 - SUCCESS

    Remote SG30 - 192.168.2.15 - > HQ Server - 192.168.0.15 - FAILS
    Remote SG30 - 192.168.2.15 - > HQ SG90BRI - 192.168.0.13 - SUCCESS
    Remote SG30 - 192.168.2.15 - > HQ SG90BRI - 192.168.0.13 - SUCCESS

    Any help would be greatly appreciated. I am open to suggestions of network issues but I have been to the IT guy who controls the routers/VPN to monitor for blocking/dropped packets etc. and none have shown up. The links are not too bad with consistent pings from HQ to remote site 1 of approx 40ms and HQ to remote site 2 being approx 30ms. I have only seen + or - 1-2ms on those results and no packet loss when running ping tests.

    Strangely as well when I run an LSP ping from the HQ server to a remote switch if I run a PCAP on the remote switch I do not see the pings show up at all. I see the usual UDP traffic on port 5440 you would expect but not the 1000 extra packets I see leaving the HQ server. When I do the same thing from the SG90 ar HQ I do see the 1000 LSP pings on UDP port 5440 at the remote switch. The HQ server and HQ switch use the same default gateway and also use the same network switch which is not a managed switch and has no VLANs or anything special on it like that at all. It is a brand new switch so I do not think it has any issues.

    This seems to be a new issue as I have had the work groups at the remote site working and they are now not working as they reside on the HQ server and the switch is now having these issues communicating.

  • #2
    So a huge hint here is that you see the LSP traffic leaving HQ, but not arriving at either SG30. Are you able to at least ping from HQ to the SG30s? I would try clearing the UDP sessions on the firewall at HQ, and the UDP sessions on the firewall where the SG30s are located. Your UDP traffic can't make it to the SG30s if the firewall(s) is sending them over dead UDP sessions.

    Comment


    • #3
      Had this same on a case.... issue was with their firewall... my notes on resolving:


      ran “diagnose sys session clear” on their firewall.

      Then I ask them to plug the Shortel switches back in after :30 seconds.
      I read this online it just cleared the ARP tables/cache from what I can tell.

      Comment


      • #4
        Hi All,
        Sorry for the slow response. I got this fixed. Turned out not to be a network issue but something with the ShoreTel. The resolution was to telnet into the remote switch, change its IP, then update the IP in director. It was explained to me that the TMS can get out of sync during VPN/Network outages. Which this customer did have prior to this issue coming up so it seems like when the network/VPN was re-established the ShoreTel didn't come back as expected.

        Comment


        • #5
          Thanks for the update. I still think it was a UDP issue. I see this all the time with VPN tunnels. UDP session timeouts by default are around 2 minutes (usually configurable, even on a specific level like for an IP address). Appliances continue to send UDP traffic over dead UDP sessions every 30 seconds, which doesn't allow the UDP session to expire. Doing what you did above would create all new UDP sessions, and surprise the issue went away.

          Where this is a regular issue due to environmental factors, or customers that don't want to pursue the root cause of the flapping VPN tunnel, we recommend changing the UDP session timeout for ShoreTel appliances/servers specifically to something lower than 30 seconds.

          Comment


          • #6
            I had a similar experience with a customer who had a Metro E between sites. For some reason the staff arrived at work to find that the phones in some sites could not call the other sites. We had to change the IPs of the switches and update director. The ITSP said "we didn't do anything".

            Comment

            Working...
            X