Issue with not seing multiple type 5 routes.

kpjungle

Hi All,

I am redistributing RIP into OSPF from two ASBR's. I expect to see two type 5 routes in the OSPF database, but for some reason im only seing one. I have labbed this up (this is a production network), and the same config would give me 2 external routes as expected. To test out the production network, i then created two loopback interfaces, one on each ASBR, and redistributed them into OSPF, sure enough, both routes would get installed into the OSPF database.

Anyone know some more details on this behavior?

Thanks.
Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
8.8.8.0 2.2.2.2 985 0x80000016 0x00EA75 0
10.8.0.0 2.2.2.2 728 0x80000001 0x006513 0
17.17.17.0 1.1.1.1 948 0x80000017 0x00371C 0
17.17.17.0 2.2.2.2 985 0x80000017 0x001936 0

The 8.8.8.0 and 10.8.0.0 is redistributed from RIP, and shows just one route, but the redistributed connected, shows two.

kryolla

Im not following your question you have the 2 routes in the database is it just not showing up in the routing table.

kryolla

post the output of sh ip ospf database external adv 2.2.2.2

kpjungle

kryolla wrote: »

post the output of sh ip ospf database external adv 2.2.2.2

No i dont have the 8.8.8.0 and 10.8.0.0 in the ospf database twice, as it should be.

The output is:
from one of them:

C4507R-IndVej#sh ip os database external adv 2.2.2.2

OSPF Router with ID (1.1.1.1) (Process ID 1)

Type-5 AS External Link States

Routing Bit Set on this LSA
LS age: 474
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 8.8.8.0 (External Network Number )
Advertising Router: 2.2.2.2
LS Seq Number: 8000002B
Checksum: 0xC08A
Length: 36
Network Mask: /30
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 172.16.2.79
External Route Tag: 0

Routing Bit Set on this LSA
LS age: 232
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.8.0.0 (External Network Number )
Advertising Router: 2.2.2.2
LS Seq Number: 80000016
Checksum: 0x3B28
Length: 36
Network Mask: /16
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 172.16.2.79
External Route Tag: 0

Routing Bit Set on this LSA
LS age: 476
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 17.17.17.0 (External Network Number )
Advertising Router: 2.2.2.2
LS Seq Number: 8000002C
Checksum: 0xEE4B
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0

And from the 1.1.1.1 (adv):
C4507R-IndVej#sh ip os database external adv 1.1.1.1

OSPF Router with ID (1.1.1.1) (Process ID 1)

Type-5 AS External Link States

LS age: 108
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 17.17.17.0 (External Network Number )
Advertising Router: 1.1.1.1
LS Seq Number: 8000002C
Checksum: 0xD31
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0


So you can see my frustration. The redistributed loopbacks works fine.
If i shut down the redistribute rip function on 2.2.2.2, both the 8.8.8.0 and 10.8.0.0 routes will be advertised by 1.1.1.1 without further modification....

kryolla

Does both ASBR have both these rip routes at the same time do a sh ip route rip on both ASBR and see if they both have these routes. Are you using any route-map for redistro. Also when you get 1.1.1.1 to redistro is it the same forwarding address used for 2.2.2.2 172.16.2.79.

After doing some research I think you have the same forwarding address thus you only have lsa for 2.2.2.2 higher RID. This is what I found.

(1) As per RFC2328, under section 12.4.4.1:

RTA and RTB would originate the same set of
AS-external-LSAs. These LSAs, if they specify
the same metric, would be functionally
equivalent since they would specify the same
destination and forwarding address (RTX).
This leads to a clear duplication of
effort. If only one of RTA or RTB originated
the set of AS-external-LSAs, the routing would
remain the same, and the size of the link state
database would decrease. However, it must be
unambiguously defined as to which router
originates the LSAs (otherwise neither may,
or the identity of the originator may
oscillate). The following rule is thereby
established: if two routers, both reachable
from one another, originate functionally
equivalent AS-external-LSAs (i.e., same
destination, cost and non-zero forwarding
address), then the LSA originated by the router
having the highest OSPF Router ID is used.
The router having the lower OSPF Router ID can
then flush its LSA.

tim100

When you redistribute the RIP networks on both ASBRs the problem looks like one of the ASBRs is getting the route into the routing table before the other. Once the route gets into the routing table OSPF has a lower administrative distance and the other ASBR is taking the OSPF route and adding that into it's routing table therefore disregarding the RIP route and in turn not redistributing it.

kryolla

tim100 wrote: »

When you redistribute the RIP networks on both ASBRs the problem looks like one of the ASBRs is getting the route into the routing table before the other. Once the route gets into the routing table OSPF has a lower administrative distance and the other ASBR is taking the OSPF route and adding that into it's routing table therefore disregarding the RIP route and in turn not redistributing it.

kpjungle are you doing mutual redistro or just rip to ospf

tim100

kryolla wrote: »

kpjungle are you doing mutual redistro or just rip to ospf

He is most likely doing RIP to OSPF only. Whichever ASBR gets the route into the database first will redistribute the route and the other ASBR will see this route with a lower admin distance. If he does a show ip route on one ASBR he will see the OSPF E2 route and if he does a show ip route on the other he will see the RIP route. The one with the RIP route is the one that got the route into the OSPF database first and this is the router that will be the next hop for the OSPF domain.

kryolla

tim100 wrote: »

He is most likely doing RIP to OSPF only. Whichever ASBR gets the route into the database first will redistribute the route and the other ASBR will see this route with a lower admin distance. If he does a show ip route on one ASBR he will see the OSPF E2 route and if he does a show ip route on the other he will see the RIP route. The one with the RIP route is the one that got the route into the OSPF database first and this is the router that will be the next hop for the OSPF domain.

Sorry Tim I dont quite understand it. Which ever ASBR get the route into the database first will redistro from rip to ospf and thus have E2 LSA, then the 2nd ASBR will have to make a choice from OSPF or RIP for the same prefix and will choose OSPF and will then also have an E2 route pointing to the first ASBR? Every router in the area has to have the same database and when the first ASBR redistro it will go into the ospf database first then exchange LSA with other ASBR. Thanks

tim100

kryolla wrote: »

Sorry Tim I dont quite understand it. Which ever ASBR get the into the database first will redistro from rip to ospf and thus have E2 LSA, then the 2nd ASBR will have to make a choice from OSPF or RIP for the same prefix and will choose OSPF and will then have a intra-area LSA pointing to the first ASBR? Thanks

Whichever ASBR gets the RIP route in its database first will be the adv router. Both ASBRs will show the RIP route as external in the OSPF database but with the adv ASBR's IP that got the route into the database first. If you do a show ip ospf database on both ASBRs you will see that ASBR's IP as the adv router. So if 2.2.2.2 got the route into the database first you will see 2.2.2.2 as being the adv router on ASBR 1.1.1.1

2.2.2.2 will have the RIP route in its routing table and 1.1.1.1 will have an E2 OSPF route in its routing table since it chose the OSPF E2 route over the RIP route because of admin distance. If you were to shutdown 2.2.2.2's interface connecting to the RIP domain you will then see router 1.1.1.1 as being the adv router for the OSPF domain since the RIP route has been "reinstated" and hence redistributed and so it will have the RIP route in its routing table. If you bring up the interface on 2.2.2.2 it will now see that router 1.1.1.1 as the advertising router for the RIP route in it's OSPF database and it will in turn add the E2 route into it's routing table again because of admin distance.

Both routers are not redistributing and entering the RIP routes into the OSPF database at the exact same time. When the "redistribute rip subnets" command is being entered on the routers it is not be entered at the same exact time so whichever router was configured first will have the route in the database. If you were to do a "no redistribute rip" on the ASBR 2.2.2.2 and it was advertising the route then ASBR 1.1.1.1 would take over the redistribution. Then if you re-enter the command ASBR 2.2.2.2 router it will do nothing as the OSPF E2 route from 1.1.1.1 would be in the database and would take precedence over the RIP route so ASBR 2.2.2.2 as well as any other router in the OSPF domain would see ASBR 1.1.1.1 as being the adv router for the route.

kryolla

I understand what your saying Tim but 1.1.1.1 is not showing any externals for those 2 routes.

tim100

kryolla wrote: »

I understand what your saying Tim but 1.1.1.1 is not showing any externals for those 2 routes.

His output from router id 1.1.1.1 is showing 2.2.2.2 as the adv router:

kpjungle wrote: »

No i dont have the 8.8.8.0 and 10.8.0.0 in the ospf database twice, as it should be.

The output is:
from one of them:

C4507R-IndVej#sh ip os database external adv 2.2.2.2

OSPF Router with ID (1.1.1.1) (Process ID 1)

Type-5 AS External Link States

Routing Bit Set on this LSA
LS age: 474
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 8.8.8.0 (External Network Number )
Advertising Router: 2.2.2.2
LS Seq Number: 8000002B
Checksum: 0xC08A
Length: 36
Network Mask: /30
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 172.16.2.79
External Route Tag: 0

Routing Bit Set on this LSA
LS age: 232
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.8.0.0 (External Network Number )
Advertising Router: 2.2.2.2
LS Seq Number: 80000016
Checksum: 0x3B28
Length: 36
Network Mask: /16
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 172.16.2.79
External Route Tag: 0

kryolla

Gotcha I need to pay more attention to

OSPF Router with ID (1.1.1.1) (Process ID 1)

I thought he did that command on both routers and only showed externals on 1. I learned a lot from this, a little embarrassed that I need to pay more attention to detail but its all good, I dont mind sticking my weenie out sometimes and getting it slapped. Thanks for making it more clearer and hopefully the OP understands it as well.

kpjungle

kryolla wrote: »

Gotcha I need to pay more attention to

OSPF Router with ID (1.1.1.1) (Process ID 1)

I thought he did that command on both routers and only showed externals on 1. I learned a lot from this, a little embarrassed that I need to pay more attention to detail but its all good, I dont mind sticking my weenie out sometimes and getting it slapped. Thanks for making it more clearer and hopefully the OP understands it as well.

No thats incorrect. Its not learning the route from OSPF.. i am doing a distance command on both routers to make sure that both routers learn the route (10.8.0.0 and 8.8.8.0 in this case) from RIP, so they both will redistribute them into OSPF. I am giving the route an AD of 100 to make sure they are prefered and not the route advertised by OSPF, so that cannot be to blame.

Router ID 1.1.1.1:
C4507R-IndVej#sh ip route 8.8.8.0
Routing entry for 8.8.8.0/30
Known via "rip", distance 100, metric 1
Redistributing via rip, ospf 1
Last update from 172.16.2.79 on Vlan1, 00:00:09 ago
Routing Descriptor Blocks:
* 172.16.2.79, from 172.16.2.79, 00:00:09 ago, via Vlan1
Route metric is 1, traffic share count is 1

Router ID 2.2.2.2:
C4507R-BjkVej#sh ip route 8.8.8.0
Routing entry for 8.8.8.0/30
Known via "rip", distance 100, metric 1
Redistributing via rip, ospf 1
Advertised by ospf 1 subnets route-map RIP-REDIST
Last update from 172.16.2.79 on Vlan1, 00:00:21 ago
Routing Descriptor Blocks:
* 172.16.2.79, from 172.16.2.79, 00:00:21 ago, via Vlan1
Route metric is 1, traffic share count is 1


Ie. both routers have the 10.8.0.0 and 8.8.8.0 installed in the route table as RIP routes, AD of 100. Both routers then use the exact same config to redistribute those routes into OSPF. In the lab, this produces the expected output of both routes being installed in the OSPF database.

tim100

kpjungle wrote: »

No thats incorrect. Its not learning the route from OSPF.. i am doing a distance command on both routers to make sure that both routers learn the route (10.8.0.0 and 8.8.8.0 in this case) from RIP, so they both will redistribute them into OSPF. I am giving the route an AD of 100 to make sure they are prefered and not the route advertised by OSPF, so that cannot be to blame.

Router ID 1.1.1.1:
C4507R-IndVej#sh ip route 8.8.8.0
Routing entry for 8.8.8.0/30
Known via "rip", distance 100, metric 1
Redistributing via rip, ospf 1
Last update from 172.16.2.79 on Vlan1, 00:00:09 ago
Routing Descriptor Blocks:
* 172.16.2.79, from 172.16.2.79, 00:00:09 ago, via Vlan1
Route metric is 1, traffic share count is 1

Router ID 2.2.2.2:
C4507R-BjkVej#sh ip route 8.8.8.0
Routing entry for 8.8.8.0/30
Known via "rip", distance 100, metric 1
Redistributing via rip, ospf 1
Advertised by ospf 1 subnets route-map RIP-REDIST
Last update from 172.16.2.79 on Vlan1, 00:00:21 ago
Routing Descriptor Blocks:
* 172.16.2.79, from 172.16.2.79, 00:00:21 ago, via Vlan1
Route metric is 1, traffic share count is 1


Ie. both routers have the 10.8.0.0 and 8.8.8.0 installed in the route table as RIP routes, AD of 100. Both routers then use the exact same config to redistribute those routes into OSPF. In the lab, this produces the expected output of both routes being installed in the OSPF database.

That does change everything here. In that case it should show up in the database. Did you go to both routers and remove the redistribute config and re-enter it? What's the configuration in route-map RIP-REDIST on 2.2.2.2? Also from your output on router id 1.1.1.1 - I don't see an "advertised by ospf 1 subnets" line. Did you configure "redistribute rip subnets" on router id 1.1.1.1?

kryolla

im assuming this is designed for the routers downstream to choose which ASBR to get to those external routes based on the forwarding metric to the ASBR and you lowered the AD to prevent route feed back? Have you looked at what I recommended earlier?

(1) As per RFC2328, under section 12.4.4.1:

RTA and RTB would originate the same set of
AS-external-LSAs. These LSAs, if they specify
the same metric, would be functionally
equivalent since they would specify the same
destination and forwarding address (RTX).
This leads to a clear duplication of
effort. If only one of RTA or RTB originated
the set of AS-external-LSAs, the routing would
remain the same, and the size of the link state
database would decrease. However, it must be
unambiguously defined as to which router
originates the LSAs (otherwise neither may,
or the identity of the originator may
oscillate). The following rule is thereby
established: if two routers, both reachable
from one another, originate functionally
equivalent AS-external-LSAs (i.e., same
destination, cost and non-zero forwarding
address), then the LSA originated by the router
having the highest OSPF Router ID is used.
The router having the lower OSPF Router ID can
then flush its LSA.

kpjungle

tim100 wrote: »

That does change everything here. In that case it should show up in the database. Did you go to both routers and remove the redistribute config and re-enter it? What's the configuration in route-map RIP-REDIST on 2.2.2.2? Also from your output on router id 1.1.1.1 - I don't see an "advertised by ospf 1 subnets" line. Did you configure "redistribute rip subnets" on router id 1.1.1.1?

Yeah, I know.

Route-map on R 1.1.1.1:
C4507R-IndVej#sh route-map
route-map RIP-REDIST, permit, sequence 10
Match clauses:
ip address (access-lists): 100
Set clauses:
Policy routing matches: 0 packets, 0 bytes

Access-list on R 1.1.1.1:
Extended IP access list 100
10 permit ip 8.8.8.0 0.0.0.255 any (18 matches)
20 permit ip 10.8.0.0 0.0.255.255 any (1 match)

Redistribute command on R 1.1.1.1:
redistribute rip subnets route-map RIP-REDIST

Route-map on R 2.2.2.2:
C4507R-BjkVej#sh route-map
route-map RIP-REDIST, permit, sequence 10
Match clauses:
ip address (access-lists): 100
Set clauses:
Policy routing matches: 0 packets, 0 bytes

Access-list on R 2.2.2.2:
Extended IP access list 100
10 permit ip 8.8.8.0 0.0.0.255 any (9 matches)
20 permit ip 10.8.0.0 0.0.255.255 any (1 match)

Redistribute command on R 2.2.2.2:
redistribute rip subnets route-map RIP-REDIST

So as far as I can see, they are exactly the same. Again, please note, that I recreated the same scenario in a lab, and both of them would show up as expected.