IESC V3 pg 226 - RIP problem on ASA

From: Farrukh Haroon (farrukhharoon@gmail.com)
Date: Thu Nov 15 2007 - 18:28:41 ART


Dear All

I am facing an issue with a task on the Internetwork Expert Security
Workbook V3. The scenario is like this:

                             DMZ
                              ||
Loopback0 >> R1 ----(inside)--------- ASA ----(outside)--------- R2 >>
Loopback0

R1 Loopback0: 150.1.1.1 /24
R1 FE 0/0: 136.1.121.1 /24
ASA Ethernet1 (inside) 136.1.121.12 /24
ASA Ethernet0 (outside) 136.1.122.12 /24
R2 E 0/0: 136.1.122.2 /24
R2 Loopback0: 160.1.1.1 /24 (I changed this to troubleshoot from the
orignal 150.1.2.0/24)

The task is actually VPN related, but I'm having issues with the RIP
(routing) part.

All interfaces on all devices are participating in RIP (including the
loopbacks on both R1 and R2). All devices are configured with RIP Version 2
and 'no auto-summary'

ASA: Version 7.2(3)
R1 IOS: 12.4(7) ADV-ENT (same problem with 12.3(7) ADV ENT)

The problem is that R2's loopback subnet is not being installed in R1.
Whereas the loopback for R1 is properly installed on R2.

I checked with a packet sniffer on both ASA interfaces (inside and outside),
the ASA, when sending RIP updates to R2 on the outside interface (which
would include its directly connected interfaces,and the loopback on R1),
sets the next-hop to 0.0.0.0 in the RIP updates as seen below, which seems
the normal way to go :

! DEBUG ON ROUTER R2

**Nov 16 07:06:48.859: 150.1.1.0/24 via 0.0.0.0 in 2 hops
***Nov 16** 07:06:48.859: RIP-DB: network_update with 150.1.1.0/24 succeeds
***Nov 16** 07:06:48.859: RIP-DB: adding 150.1.1.0/24 (metric 2) via
136.1.122.12 on
Ethernet0/0 to RIP database*

But the ASA, when sending RIP updates to R1 on its inside interfaces (which
would include its directly connected interfaces,and the loopback on R2) sets
the next-hop of the RIP update to the IP address of R2's ethernet interface
(136.1.122.2). Is this normal behavior or a bug in the ASA code? As a result
the update for R2's Loopback0 simply vanishes on R1. Below output shows ASA
is sending everything to R1 as seen below ( also verified this with
WireShark):

! DEBUG ON THE ASA

RIP: sending v2 update to 224.0.0.9 via inside (136.1.121.12)
RIP: build update entries
        10.0.0.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0 (ASA DMZ)
  * 136.1.122.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0 (ASA
OUTSIDE)
        160.1.2.0 255.255.255.0 via 136.1.122.2, metric 2, tag 0 (R2
LOOPBACK0)*
*RIP: Update contains 3 routes*

But the output on R1 reads:

! DEBUG ON R1
 RIP: received v2 update from 136.1.121.12 on FastEthernet0/0
      10.0.0.0/24 via 0.0.0.0 in 1 hops
     136.1.122.0/24 via 0.0.0.0 in 1 hops
*RIP: Update contains 2 routes (Two?)*

So it seems R1 simply ignores the 160.1.2.0/24 transmission from the ASA
(even the its receiving it as verified by the packet capture)..Is this
because of the strange next-hop set by the ASA..can someone help me with
this please?*

*Surprisingly if I do 'auto-summary' on the ASA rip process, the route for
R2's Loopback starts showing on R1. It seems this happens because now the
ASA starts sending 0.0.0.0 as the next-hop in its RIP updates (for R2s
Loopback).

Thanks for the help in advance :).

Regards

Farrukh



This archive was generated by hypermail 2.1.4 : Sat Dec 01 2007 - 06:37:30 ART