In a fully meshed VPN of several PIXen, I see log messages like this:
%PIX-6-110001: No route to 10.1.212.254 from 10.1.213.251
with a disquieting frequency, but of course always when I'm not in the office. The network uses static routing exclusively, and by the time I log in to the PIX in question "show route" invariably shows the route is there as it should. Nor do I see any correlation with other log messages such as the occasional bursts of "%PIX-7-702205: ISAKMP Phase
2 retransmission" probably caused by line problems.
What might lead a PIX to temporarily deny the existence of a static route, and how can I diagnose that?
But I notice that all the messages are for addresses that aren't directly connected to the nearest PIX, but behind another router. Is it possible that the PIX generates such a message when the problem is really with the next hop router? eg.
- next hop router isn't reachable at all (no ARP reply)
- next hop router replies "ICMP unreachable" because it doesn't have a usable route to the destination
- next hop sends the packet back to the PIX for lack of a better route (but shouldn't it show up in a "reverse path check" log message then?)
I don't know if this applies to this situation, but if the traffic is coming in an interface and needs to return out the same interface you can have similar issues. Hairpinning sometimes is required in a situation like this. You can test by enabling the same-security command.