Screen OS

SSG550 routing problem "re-born".  A tunnel is established between a SSG550(local) and SSG20(remote).  For days everything works fine, then some addresses on the remote network behind the SSG20 are not reachable.  They can be pinged from the SSG20 but not from the SSG550 or the local network.  A trace route to the remote unreachable address will bounce between the trusted interface on the SSG550 and the local router.  A trace route to another device on the same remote network will work correctly.  A trace route to an ip address that is not used on the remote network will time out correctly.  One time the problem cleared up on its own the most recent event was corrected by resetting the SSG550.  I thought I had fixed the problem by removing routes to the remote network in trust and untrust VR.  Route in untrust-vr had a preference of 20.  Not sure how or why they were added to the untrust-vr but removing them fixed the problem for a day.
Using policy based VPN.  4 remote sites are configured off this SSG550.  Only one has this promblem.  Remote site supports less than 20 devices(server, workstations and printers).  Other remote sites off the same SSG550 have not had this problem.  No session limit problem.  Another SSG550 configured the same but supporting additional remote sites has not had this problem.

Tom

symptoms sound similar to an issue with the route-cache introduced in 6.3.

If running 6.3., you can disable this feature by "unset flow route-cache".

You can view the route cache and cross reference the get route/mac address output and verify if this is causing the issue.

get flow route-cache
get flow route-cache | inc <ip address>
get route

Regards,

Sam

Sam,

  Thanks for the info.  The ssg550 is at 6.3.  Right now everything is working.  I tried the "get flow route-cache |inc xxx.xxx.xxx.xxx comand and it reset the device.  Not good   Is this a known bug with 6.3?  I'll look around and see if we can upgrade.

Thanks,

Tom

Shoot.  Sorry about that.

There was a known issue in earlier version of 6.3.x  I forgot about that.  The latest 6.3.x does not have this issue. 

Again. I'm real sorry running the command resulted in a reboot.

Regards,

Sam

Sam,

  No problem... Resets happen!  Route-cache looks like the problem.  The config has been updated and scheduling to upgrade to r13.

Thanks again,

Tom