Sounds like you are hitting some CEF issue.
I would try setting a /32 route for the Checkpoint to the interface.
(your /25 are overriding the connected reachability info and somehow
you lost the way to the checkpoint).
i.e. ip route 192.168.249.1 255.255.255.255 GigabitEthernet0/0
-Carlos
Nico Van Niekerk @ 1/12/2010 4:34 -0300 dixit:
> I just had a very weird issue.
>
> The way that I understand recursive lookup is that the router will always go back to the routing table until it has an outbound interface for the next-hop.
>
> We have 2845 outside a Checkpoint cluster.
>
> On the 2845:
> Gi0/0 = 192.168.249.250/24
> S0/0/0 = 172.16.1.81/30
>
> The Checkpoint cluster:
> Virtual = 192.168.249.1
> 1st Checkpoint = 192.168.249.2/24
> 2nd Checkpoint = 192.168.249.3/24
>
> We are NATting our internal ranges on the Checkpoint to 192.168.249.x addresses.
>
> On the 2845 I had these routes:
> C 172.16.1.80/30 is directly connected, Serial0/0/0
> S 192.168.101.0/24 [1/0] via 172.16.1.82
> C 192.168.249.0/24 is directly connected, GigabitEthernet0/0
> S* 0.0.0.0/0 [1/0] via 192.168.249.1
>
> Now, if the 2845 needs to send anything to 192.168.249.x addresses, it will send an ARP request out of Gi0/0.
> The Checkpoint FW doesn't reply to the ARP, so we needed to route 192.168.249.x addresses to the FW (192.168.249.1)
>
> Adding host routes to all the NAT addresses worked fine, but why have a load of /32 routes when you can break it up into 2x /25 routes?
>
> So now the routing table is:
> C 172.16.1.80/30 is directly connected, Serial0/0/0
> S 192.168.101.0/24 [1/0] via 172.16.1.82
> C 192.168.249.0/24 is directly connected, GigabitEthernet0/0
> S 192.168.249.0/25 [1/0] via 192.168.249.1
> S 192.168.249.128/25 [1/0] via 192.168.249.1
> S* 0.0.0.0/0 [1/0] via 192.168.249.1
>
> All of a sudden my default route breaks because of this route (S 192.168.249.0/25 [1/0] via 192.168.249.1)
> From the 2845 I cannot ping internal address 10.1.5.4
> I can still ping 192.168.249.250 from 10.1.5.4, but not ssh... WEIRD? From the 2845 I cannot ping 10.1.5.4
>
> "debug ip packet" showed that the source interface was 172.16.1.81 when I tried to ping 10.1.5.4???
> So I tried a "ping 10.1.5.4 source 192.168.249.250" and it worked.
>
> Seems like recursive lookup was broken because of the /25
> I removed the culprint (S 192.168.249.0/25 [1/0] via 192.168.249.1) and replaced it with more specific routes that excluded 192.168.249.1 and problem solved!
>
> So does a Static route that is more specific than your Connected route, break next-hop reachability for the default route which have a next-hop to an addres on the Static route? Seems like recursive lookup breaks in this case. What I don't understand is that I couldn't ssh to my router anymore, but I could still ping it from the same source (10.1.5.4)!?! No NAT on the FW for 10.1.5.4 and I could also see the packets hitting the 2845 as 10.1.5.4 for icmp as well as ssh. No funny source-routing on the 2845 either.
>
> Anybody seen this before?
>
>
>
>
>
>
>
>
>
>
>
> **********************************************************************
> This email and all content are subject to the following disclaimer:
> http://content.momentum.co.za/content/legal/disclaimer_email.htm
> **********************************************************************
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
-- Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina Blogs and organic groups at http://www.ccie.netReceived on Wed Dec 01 2010 - 04:58:11 ART
This archive was generated by hypermail 2.2.0 : Sat Jan 01 2011 - 09:37:49 ART