Paul,
Only way to make the tunnels reestablish in a L2L is to send traffic destined for the tunnel. No way to have the devices automatically reestablish automatically. Could run a continous ping from a server. If what your also saying is that the tunnels cannot reestablish period, from the pix side, even when sending traffic and can only establish the tunnel if pinging from the 3000 side its usually because policies aren't matching up. Specifically one side is more restrictive than the other. In this case it would be the 3000 thats has a more restrictive policy than the pix. For ie, tunnel traffic defined on the 3000 is to allow traffic from 10.10.10.0/24 to 192.168.1.0/24. Traffic defined on the pix says to allow traffic from 192.168.1.0/24 to 10.0.0.0/8. So when establishing the tunnel from the pix to the 3000, pix says it wants to connect to a class A network but the 3000 is only allowing class C, tunnel is rejected. Send traffic from the 3000 to the pix, 3000 wants to connect to class C and pix is ok with that because its actually allowing the entire class A, tunnel established.
Another note, some versions of 3000 code have a "feature" where it doesn't realize that the peer went down and so when peer tries to reestablish it says the tunnel is still up, so it rejects the new request. But when pinging from the 3000 to the peer, the peer tells the 3000 that there is no tunnel, so it tears down its old tunnel and creates a new one. This feature should have been removed in 3.6.3.
Debugs would tell you which problem you are actually running into though, could be something else but these 2 are the most typical. Hope this helps.
Kurtis Durrett
