PIX says "no route" even though there is

Discussion in 'Cisco' started by Tilman Schmidt, Jul 4, 2007.

  1. 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
     
    Tilman Schmidt, Jul 4, 2007
    #1
    1. Advertisements

  2. 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.
     
    Walter Roberson, Jul 4, 2007
    #2
    1. Advertisements

  3. Tilman Schmidt

    Guest

    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
     
    , Jul 4, 2007
    #3
  4. Good point. I have turned that on now, we'll see what that'll turn up.

    Thanks,
    Tilman
     
    Tilman Schmidt, Jul 4, 2007
    #4
  5. Looks fine IMO:

    pix-bbg-bo# show route
    outside 0.0.0.0 0.0.0.0 <publicnet>.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 <publicnet>.48 255.255.255.248 <publicnet>.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 <publicnet>.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.
     
    Tilman Schmidt, Jul 4, 2007
    #5
  6. 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.
     
    Tilman Schmidt, Jul 13, 2007
    #6
  7. Tilman Schmidt

    iemonkey2 Guest

    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.

    http://www.cisco.com/en/US/docs/security/asa/asa72/command/reference/s1_72.html#wp1289167

    Good luck.
     
    iemonkey2, Jul 25, 2007
    #7
  8. Am 25.07.2007 02:25 schrieb :
    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
     
    Tilman Schmidt, Aug 18, 2007
    #8
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.