Newer SSG firmware 6.0.0r4 << clearing had no effect Older NS device firmware 5.3.0r3 << clearing had no effect The link between the sites is over a private circuit which remained up throughout (of course the switch itself was replaced) - there are several Juniper/Netscreen routers in the traffic path all of which had active sessions for port 5440:Įarly SSG device firmware 5.0.1p1.6_ssg <<<<< had to clear the sessions here OK I take it back - now we've seen this issue as well had to RMA out a SG50 switch at the HQ site, installed the replacement but then none of the remote site switches would connect back to it (ie bad vibes from the Minesweeper screen). So I've shown you mine, now show me yours. The problem is that the problem occurs in the first place, and that I have not found a solution to. This will fix the problem without disconnecting any user important traffic. This clears all sessions for any traffic associated with the shoretel lsp keepalive port, which is udp 5440. (clear session src-ip x.x.x.x, clear session dst-ip y.y.y.y) Then we learned about clearing only sessions based on the source and destination IP addresses of the shoretel switches. We then learned we can clear sessions, but that can be intrusive to users. As you may have discovered, the initial fix discovered was rebooting the firewall.
I find it astounding nobody else has these problems. We've worked with Juniper TAC on it a large number of times over the last 2 years, and they have never gotten anywhere towards fixing it. But it may or may not have an OSPF tie in. But in all cases we see it, the customer is using OSPF on their network. I am not sure if this has any relation with routing protocols or not.
I am 99% sure the trigger for this is when a tunnel goes down. The firewall may or may not be trying to create a new session, but the end result is the same: the old session is stuck and no traffic can pass. So switch A might have a session to switch B and C and D, when the tunnel goes down, that session somehow gets stuck and never times out. So what happens, is when a tunnel goes down and comes back up, the session gets hanged in the firewall. I'm almost loath to share what I know, since I've spent 2 years working on it, and I hate to share my hard won knowledge with the world without any guarantee of getting any benefit for myself. This is a problem I've been working on for a long time. If anyone has had similar experiences please advise. We are using route-based vpn's between sites. We have had some issues, but we have always been able to work through them and get it working. We are a Juniper reseller, so we have implemented this at other client sites and have been successful in the past. We initially thought that their may have been large amounts of data passing through the vpn's, but we have had lost connectivity after hours when nothing is going on. There is traffic shaping in place to give the Voice precedence over the Data. We can clear the sessions on the SSG's, to reestablish the connectivity, but at just random times the switches will lose connectivity. Network connectivity is there among the switches (we can ping), but we can't complete lsp_pings so the sites show up as red on the Switch Connectivity. We have an ongoing issue with the switches losing connectivity on the Switch Connectivity screen (We call it the mine sweeper screen).
The vpn's are terminated with Juniper SSG firewalls. We have a client that has 5 sites and they are all connected via vpn.
0 kommentar(er)
