Re: Static Routes and Recursive Lookup

Why would ARP fail for the main checkpoint address ? If that were the
case, no traffic would happen ever ?

Joseph L. Brunner @ 1/12/2010 11:25 -0300 dixit:
> Carlos,
>
> That would cause probably another recursion lookup problem when ARP fails on the broadcast Ethernet medium.
>
> I would do
>
> ip route 192.168.249.1 255.255.255.255 GigabitEthernet0/0 192.168.249.1
>
> But,
>
> I don't believe that is the solution you need.
>
> Try a static arp for the checkpoint virtual ip on the cisco
>
> arp 192.168.249.1 01e1.0010.001a arpa
>
> (remember this guys from the days of Microsoft terminal server load balancing ;)
>
> -Joe
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of Carlos G Mendioroz
> Sent: Wednesday, December 01, 2010 2:58 AM
> To: Nico Van Niekerk
> Cc: 'Cisco certification'
> Subject: Re: Static Routes and Recursive Lookup
>
> 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.net