PIX says "no route" even though there is

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?

TIA

Reply to
Tilman Schmidt
Loading thread data ...

If the packet arrives on the wrong interface. PIX 6 doesn't allow routing of a packet back to the same interface it came from, no matter what the static routes say.

Turning on reverse path verification might perhaps help track the problem.

Reply to
Walter Roberson

If the PIX is trying to route the packet to a network link that has failed it will report the error you suggest. Have you checked the interface to see if it has suffered any outages?

TP

Tilman Schmidt wrote:

Reply to
""tim"

Good point. I have turned that on now, we'll see what that'll turn up.

Thanks, Tilman

Reply to
Tilman Schmidt

dot wrote:

Looks fine IMO:

pix-bbg-bo# show route outside 0.0.0.0 0.0.0.0 .49 1 OTHER static inside 10.1.171.250 255.255.255.255 10.1.213.20 1 OTHER static inside 10.1.208.0 255.255.240.0 10.1.213.254 1 OTHER static inside 10.1.213.0 255.255.255.0 10.1.213.1 1 CONNECT static outside .48 255.255.255.248 .50 1 CONNECT static pix-bbg-bo# show interface interface ethernet0 "outside" is up, line protocol is up Hardware is i82559 ethernet, address is 0016.9ddb.069b IP address .50, subnet mask 255.255.255.248 MTU 1500 bytes, BW 10000 Kbit half duplex 13710207 packets input, 1840428945 bytes, 0 no buffer Received 304152 broadcasts, 0 runts, 0 giants 1 input errors, 1 CRC, 0 frame, 0 overrun, 1 ignored, 0 abort 12971624 packets output, 2055831726 bytes, 0 underruns 0 output errors, 216192 collisions, 0 interface resets 0 babbles, 0 late collisions, 529983 deferred 0 lost carrier, 0 no carrier input queue (curr/max blocks): hardware (128/128) software (0/14) output queue (curr/max blocks): hardware (0/26) software (0/1) interface ethernet1 "inside" is up, line protocol is up Hardware is i82559 ethernet, address is 0016.9ddb.069d IP address 10.1.213.1, subnet mask 255.255.255.0 MTU 1500 bytes, BW 100000 Kbit full duplex 12898922 packets input, 1346159876 bytes, 0 no buffer Received 74910 broadcasts, 0 runts, 0 giants 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 13355108 packets output, 1080308883 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collisions, 0 deferred 0 lost carrier, 0 no carrier input queue (curr/max blocks): hardware (128/128) software (0/26) output queue (curr/max blocks): hardware (0/14) software (0/1) pix-bbg-bo#

Also, I have been collecting "debug" level logs from all the PIXen on a syslog server and no messages about interface troubles have shown up there.

But thanks for your suggestion, any new direction of thought may help.

Reply to
Tilman Schmidt

That didn't turn up anything.

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?)

Thanks again for any insight.

Reply to
Tilman Schmidt

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.

formatting link
Good luck.

Reply to
iemonkey2

formatting link
Sorry, this is PIX OS 6.3, not ASA. But I tried with "ip verify unicast reverse-path" and it didn't log anything.

Thanks, Tilman

Reply to
Tilman Schmidt

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.