Solved: ASA RIP routes received but not installed into database

Dave Lewis · ‎07-09-2013

Hello,

I have a strange issue at a site which uses OSPF internally and RIPv2 to communicate with a vendor managed router. These RIP routes are then redistributed into OSPF.

The problem I'm seeing is that 25 routes are being received via RIP from the vendor router but only one is being installed into the RIP database (and thus into the route table). There is no filtering or distribute lists affecting things.

Communication with the vendor router is fine (ICMP ping etc.) and the debug output shows the correct routes being received.

Here is the relevant redacted config from the ASA which is a member of an active/active failover cluster...

#sh ver

Cisco Adaptive Security Appliance Software Version 8.4(3)

Device Manager Version 6.4(7)

This platform has an ASA 5520 VPN Plus license.

#sh run int gi0/1

!

interface GigabitEthernet0/1

description INSIDE

nameif INSIDE

security-level 100

ip address 10.1.9.254 255.255.255.0 standby 10.1.9.253

sh run int gi0/3.204

!

interface GigabitEthernet0/3.204

vlan 204

nameif Vendor

security-level 10

ip address 10.1.98.201 255.255.255.0 standby 10.1.98.202

#sh run router rip

router rip

network 10.0.0.0

passive-interface default

version 2

no auto-summary

!

# sh rip data

10.0.0.0 255.0.0.0 auto-summary

10.1.9.0 255.255.255.0 directly connected, GigabitEthernet0/1

10.1.98.0 255.255.255.0 directly connected, GigabitEthernet0/3.204

199.x.y.0 255.255.255.0 auto-summary

199.x.y.192 255.255.255.192

[1] via 10.1.98.3, 0:00:12, GigabitEthernet0/3.204

Note that only one route has been installed in the RIP database. Here is part of the debug output from 'debug rip'...

RIP: received v2 update from 10.1.98.3 on Vendor

a.b.14.240255.255.255.240 via 0.0.0.0 in 3 hops

a.b.14.224255.255.255.240 via 0.0.0.0 in 1 hops

a.b.91.192255.255.255.224 via 0.0.0.0 in 1 hops

c.d.103.0255.255.255.224 via 0.0.0.0 in 3 hops

g.h.161.0255.255.255.192 via 0.0.0.0 in 1 hops

i.j.181.192255.255.255.192 via 0.0.0.0 in 1 hops

RIP-DB: network_update with i.j.181.192 255.255.255.192 succeeds

RIP-DB: adding i.j.181.192 255.255.255.192 (metric 1) via 10.1.98.3 on GigabitEthernet0/3.204 to RIP database

a.b.14.64255.255.255.224 via 0.0.0.0 in 1 hops

c.d.0.0255.255.255.192 via 0.0.0.0 in 1 hops

a.b.24.96255.255.255.248 via 0.0.0.0 in 1 hops

g.h.161.64255.255.255.192 via 0.0.0.0 in 1 hops

a.b.13.176255.255.255.240 via 0.0.0.0 in 3 hops

e.f.246.192255.255.255.192 via 0.0.0.0 in 3 hops

a.b.13.208255.255.255.240 via 0.0.0.0 in 3 hops

a.b.24.0255.255.255.224 via 0.0.0.0 in 1 hops

c.d.54.128255.255.255.192 via 0.0.0.0 in 3 hops

c.d.64.0255.255.255.192 via 0.0.0.0 in 3 hops

i.j.181.224255.255.255.224 via 0.0.0.0 in 3 hops

a.b.24.120255.255.255.248 via 0.0.0.0 in 3 hops

a.b.24.104255.255.255.248 via 0.0.0.0 in 3 hops

a.b.14.160255.255.255.224 via 0.0.0.0 in 3 hops

a.b.15.64255.255.255.224 via 0.0.0.0 in 1 hops

a.b.13.80255.255.255.240 via 0.0.0.0 in 1 hops

a.b.14.0255.255.255.224 via 0.0.0.0 in 1 hops

a.b.13.64255.255.255.240 via 0.0.0.0 in 1 hops

a.b.13.128255.255.255.224 via 0.0.0.0 in 3 hops

RIP: Update contains 25 routes

RIP: received v2 update from 10.1.98.3 on Vendor

a.b.92.88255.255.255.248 via 0.0.0.0 in 3 hops

a.b.95.208255.255.255.240 via 0.0.0.0 in 3 hops

a.b.92.16255.255.255.240 via 0.0.0.0 in 3 hops

a.b.166.81255.255.255.255 via 0.0.0.0 in 3 hops

a.b.94.154255.255.255.255 via 0.0.0.0 in 3 hops

a.b.17.192255.255.255.224 via 0.0.0.0 in 3 hops

a.b.16.240255.255.255.240 via 0.0.0.0 in 3 hops

a.b.17.176255.255.255.240 via 0.0.0.0 in 3 hops

a.b.16.32255.255.255.224 via 0.0.0.0 in 3 hops

a.b.16.96255.255.255.224 via 0.0.0.0 in 3 hops

a.b.17.48255.255.255.240 via 0.0.0.0 in 3 hops

a.b.17.240255.255.255.240 via 0.0.0.0 in 3 hops

a.b.17.144255.255.255.240 via 0.0.0.0 in 3 hops

a.b.16.160255.255.255.224 via 0.0.0.0 in 3 hops

g.h.161.192255.255.255.192 via 0.0.0.0 in 3 hops

c.d.1.0255.255.255.192 via 0.0.0.0 in 3 hops

g.h.161.128255.255.255.192 via 0.0.0.0 in 3 hops

c.d.36.0255.255.255.192 via 0.0.0.0 in 1 hops

i.j.181.0255.255.255.192 via 0.0.0.0 in 1 hops

e.f.246.0255.255.255.192 via 0.0.0.0 in 1 hops

c.d.36.64255.255.255.192 via 0.0.0.0 in 1 hops

a.b.13.160255.255.255.240 via 0.0.0.0 in 3 hops

a.b.14.32255.255.255.224 via 0.0.0.0 in 3 hops

a.b.24.112255.255.255.248 via 0.0.0.0 in 1 hops

a.b.14.96255.255.255.224 via 0.0.0.0 in 3 hops

RIP: Update contains 25 routes

RIP: received v2 update from 10.1.98.3 on Vendor

i.j.181.64255.255.255.192 via 0.0.0.0 in 3 hops

a.b.99.64255.255.255.224 via 0.0.0.0 in 1 hops

a.b.99.160255.255.255.224 via 0.0.0.0 in 3 hops

c.d.234.0255.255.255.224 via 0.0.0.0 in 3 hops

a.b.99.240255.255.255.240 via 0.0.0.0 in 3 hops

a.b.99.128255.255.255.224 via 0.0.0.0 in 1 hops

a.b.99.224255.255.255.240 via 0.0.0.0 in 1 hops

c.d.230.0255.255.255.224 via 0.0.0.0 in 1 hops

a.b.99.96255.255.255.224 via 0.0.0.0 in 3 hops

a.b.15.160255.255.255.240 via 0.0.0.0 in 3 hops

a.b.93.0255.255.255.192 via 0.0.0.0 in 3 hops

a.b.166.32255.255.255.224 via 0.0.0.0 in 3 hops

a.b.95.24255.255.255.248 via 0.0.0.0 in 3 hops

a.b.95.160255.255.255.248 via 0.0.0.0 in 3 hops

a.b.95.192255.255.255.240 via 0.0.0.0 in 3 hops

a.b.98.32255.255.255.224 via 0.0.0.0 in 3 hops

a.b.97.128255.255.255.224 via 0.0.0.0 in 3 hops

a.b.92.112255.255.255.240 via 0.0.0.0 in 3 hops

a.b.166.0255.255.255.224 via 0.0.0.0 in 3 hops

a.b.95.64255.255.255.224 via 0.0.0.0 in 3 hops

a.b.92.176255.255.255.240 via 0.0.0.0 in 3 hops

a.b.92.208255.255.255.240 via 0.0.0.0 in 3 hops

a.b.95.120255.255.255.248 via 0.0.0.0 in 3 hops

a.b.166.160255.255.255.224 via 0.0.0.0 in 3 hops

a.b.166.64255.255.255.224 via 0.0.0.0 in 3 hops

RIP: Update contains 25 routes

RIP: received v2 update from 10.1.98.3 on Vendor

i.j.181.192255.255.255.224 via 0.0.0.0 in 1 hops

c.d.50.0255.255.255.192 via 0.0.0.0 in 1 hops

c.d.40.128255.255.255.192 via 0.0.0.0 in 1 hops

i.j.179.128255.255.255.224 via 0.0.0.0 in 1 hops

e.f.246.128255.255.255.192 via 0.0.0.0 in 1 hops

c.d.40.0255.255.255.192 via 0.0.0.0 in 1 hops

c.d.40.64255.255.255.192 via 0.0.0.0 in 1 hops

c.d.52.0255.255.255.192 via 0.0.0.0 in 1 hops

a.b.166.72255.255.255.255 via 0.0.0.0 in 3 hops

a.b.94.153255.255.255.255 via 0.0.0.0 in 1 hops

c.d.245.32255.255.255.224 via 0.0.0.0 in 1 hops

c.d.245.0255.255.255.240 via 0.0.0.0 in 1 hops

c.d.244.0255.255.255.224 via 0.0.0.0 in 1 hops

a.b.94.158255.255.255.255 via 0.0.0.0 in 3 hops

a.b.17.0255.255.255.224 via 0.0.0.0 in 1 hops

c.d.245.96255.255.255.240 via 0.0.0.0 in 1 hops

c.d.244.32255.255.255.224 via 0.0.0.0 in 1 hops

c.d.245.64255.255.255.224 via 0.0.0.0 in 1 hops

a.b.16.192255.255.255.224 via 0.0.0.0 in 1 hops

a.b.17.160255.255.255.240 via 0.0.0.0 in 1 hops

a.b.16.0255.255.255.224 via 0.0.0.0 in 1 hops

a.b.16.224255.255.255.240 via 0.0.0.0 in 1 hops

c.d.37.64255.255.255.192 via 0.0.0.0 in 3 hops

e.f.246.64255.255.255.192 via 0.0.0.0 in 3 hops

c.d.37.0255.255.255.192 via 0.0.0.0 in 3 hops

Any ideas why only one of the routes is being inserted into the RIP database? I have another site with almost identical config that is working fine and installing all the routes.

Thanks,

Dave

Peter Paluch · ‎07-09-2013

Hi Dave,

I would have thought it would still add them to the RIP database which  would then be redistributed into OSPF and thus chosen as the preferred  route in the routing table but it looks like that's not what it does.

This is a common misconception about redistributing routes between routing protocols. Route redistribution is done via the routing table, i.e. a route must first be present in the routing table, only then it can be redistributed into the destination routing protocol. Because the OSPF-learned routes are more trustworthy (AD=110), they are inserted into the routing table and will not be replaced by RIP-learned routes with AD=120. And at this point, because there are practically no RIP routes in your routing table (save one route), no RIP-learned routes can be redistributed into OSPF. Redistribution is not done between routing protocols' databases, only via the routing table.

 I'm wondering if tweaking the admin distances so RIP is preferred over OSPF (for this particular device) would do the trick.

Yes, it definitely would allow RIP routes to be more preferred than OSPF.

Best regards,

Peter

View solution in original post

Dave Lewis · ‎07-09-2013

Update: I believe the problem might be that all the routes except 1 are already known to the ASA via OSPF from the other site. I would have thought it would still add them to the RIP database which would then be redistributed into OSPF and thus chosen as the preferred route in the routing table but it looks like that's not what it does.

So, as the ASA doesn't have any distribute-list command within it's OSPF process I'm wondering if tweaking the admin distances so RIP is preferred over OSPF (for this particular device) would do the trick.

Any thoughts?

Peter Paluch · ‎07-09-2013

Hi Dave,

I would have thought it would still add them to the RIP database which  would then be redistributed into OSPF and thus chosen as the preferred  route in the routing table but it looks like that's not what it does.

This is a common misconception about redistributing routes between routing protocols. Route redistribution is done via the routing table, i.e. a route must first be present in the routing table, only then it can be redistributed into the destination routing protocol. Because the OSPF-learned routes are more trustworthy (AD=110), they are inserted into the routing table and will not be replaced by RIP-learned routes with AD=120. And at this point, because there are practically no RIP routes in your routing table (save one route), no RIP-learned routes can be redistributed into OSPF. Redistribution is not done between routing protocols' databases, only via the routing table.

 I'm wondering if tweaking the admin distances so RIP is preferred over OSPF (for this particular device) would do the trick.

Yes, it definitely would allow RIP routes to be more preferred than OSPF.

Best regards,

Peter

Dave Lewis · ‎07-09-2013

Hi Peter,

Thanks for the reply, completely understand the redistribution happening from the routing table, just not sure why the routes aren't even kept in the rip database ready to populate the routing table if the OSPF routes failed? But I think we've nailed the problem.

It looks like I can't change the RIP admin distance on an ASA (?) so I'll change the admin distance of the OSPF intra-area routes to 121 during the next change window with "distance ospf intra-area 121", do you concur?

Kind regards,

Dave

Peter Paluch · ‎07-09-2013

Hello Dave,

It's a good question why the RIP-learned routes are not kept at least in the RIP database even though they can not currently be placed into the routing table. I would speculate that this is by design. Both RIP and EIGRP on Cisco devices advertise only those networks that actually get installed into the routing table after being learned. In other words, if a RIP-learned route does not make it into the routing table, it will not even be further advertised by RIP. Most probably, this is accomplished by simply not having that route in the RIP database at all.

It looks like I can't change the RIP admin distance on an ASA (?) so  I'll change the admin distance of the OSPF intra-area routes to 121  during the next change window

I have very limited hands-on experience with ASA boxes but at least in theory, this should do the trick. On routers, that would be one of the ways of solving it.

Best regards,

Peter

Dave Lewis · ‎07-11-2013

Hello Peter,

Just to let you know that this worked a treat, ended up adding the following commands...

router ospf 1

distance ospf external 121

redistribute rip subnets

Thanks for your assistance.

Dave