cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1180
Views
14
Helpful
12
Replies

OSPF to OSPF redistribution

joet8591
Level 1
Level 1

Attempting to redistribute routes from one process into another and route and database does not show it.

4503 with Sup4 running 12.1(20)EW2

Router is an ASBR with process 100 supporting Area 0 and Area 90.

Process 200 is added with networks in Area 90.

Process 200 is redistributed in process 100 but any networks added to process 200 in area 90 do not show up in the OSPF database or routing table when checking other neighbors. Tried numerous distribute options without any luck. I did not try the distance command.

Thanks

Joe

12 Replies 12

Richard Burts
Hall of Fame
Hall of Fame

Joe

If you could supply some more detail it would be easier for us to find answers to your problem. In particular it would help to see the configuration of both OSPF processes.

My first guess (without any of the detail that I just asked for) is whether you included the subnets keyword in the redistribute command.

If adding subnets onto the redistribute command does not fix it, then please post the OSPF configuration.

HTH

Rick

HTH

Rick

!

router ospf 100

redistribute ospf 200 subnets

redistribute static metric 1 metric-type 1 subnets

redistribute bgp 65502 metric 1 metric-type 1 subnets

network 10.248.18.8 0.0.0.3 area 0

network 147.191.128.1 0.0.0.0 area 90

network 147.191.128.8 0.0.0.7 area 90

network 147.191.128.16 0.0.0.7 area 90

network 147.191.128.24 0.0.0.7 area 90

router ospf 200

network 147.191.128.40 0.0.0.7 area 90

Network 147.191.128.40/29 which is an interface on the router is not getting into the routing table or ospf 100 database.

Thanks

Regards

Joe

Joe

From the config that you posted it looks like 147.191.128.40 would be a connected interface. So it will not be in the routing table as anything except a connected interface. And that helps explain why it is not redistributing. The command that you have configured: "redistribute ospf 200 subnets" indicates that any type O routes in the routing table learned via OSPF 200 should be redistributed into OSPF 100. But 147.191.128.40 is not an O route, it is a C route. That is why it is not redistributed.

HTH

Rick

HTH

Rick

Rick,

Despite the fact 147.191.128.40 is a connected network the route would still have to be redistributed into OSPF 100 as that interface is running a different OSPF process, which is being redistributed into OSPF 100.

To Joe,

Can you post the output of the following from the router doing redistribution.

show ip ospf int (int_with_ip_147.191.128.40)

show ip ospf database external 147.191.128.40

Sundar

Sundar

It seems that today is my day to respectfully disagree with some of my senior colleagues on NetPro.

If OSPF learned any routes over the 147.191.128.40 those routes will be redistributed. But 147.191.128.40 is NOT an OSPF route on that router and redistribute OSPF 200 will not redistribute 147.191.128.40. If he really wants 147.191.128.40 to appear in OSPF 100 then he probably needs to add redistribute static subnets to his config.

HTH

Rick

HTH

Rick

Rick,

There's nothing wrong in disagreeing on technical issues as long as it's not perceived in a negative way. My point was there's no need to use 'redistribute connected' under OSPF for a directly connected network if the routing protocol that's enabled on that interface is redistributed under OSPF.

I set it up in the lab and the outcome is noted below.

R1:

int e0

ip add 172.30.1.11 255.255.255.0

int e0/1

ip add 21.21.21.1 255.255.255.0

router ospf 1

log-adjacency-changes

redistribute ospf 2 subnets

network 172.30.1.11 0.0.0.0 area 0

!

router ospf 2

log-adjacency-changes

network 21.21.21.1 0.0.0.0 area 0

R2:

int e0

ip add 172.30.1.12 255.255.255.0

router ospf 1

log-adjacency-changes

network 172.30.1.12 0.0.0.0 area 0

R2#show ip ospf nei

Neighbor ID Pri State Dead Time Address Interface

172.24.2.1 1 FULL/DR 00:00:32 172.30.1.11 Ethernet0/0

R2#show ip route ospf

21.0.0.0/24 is subnetted, 1 subnets

O E2 21.21.21.0 [110/10] via 172.30.1.11, 05:04:00, Ethernet0/0

HTH

Sundar

Sundar

Very interesting - and very different from my memory of the behavior of OSPF. I have done similar things in the lab (a while back) and my memory is that the interface that matched an OSPF network statement was not redistributed but routes learned over that interface were redistributed. Your lab shows a different behavior.

Either the behavior of OSPF has changed - or my memory has played a trick on me.

HTH

Rick

HTH

Rick

Joe,

I would still expect to see the LSAs to show up in the OSPF database though OSPF would prefer the internal routes over the external routes learnt via the other process, which is the default behavior. By tweaking admin distance you might be able to achieve what you desire. However, take a look at this document I found on CCO and it may have the answer you are looking for. I haven't read it myself yet but hoping this could lead you in the right direction. I probably shall try to lab it up later and check the outcome.

http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080531fd2.shtml#topic1

HTH

Sundar

joet8591
Level 1
Level 1

Starting to wonder if we are running into a problem. Clearing the OSPF process did not help. Also attempted just using the redist connected subnets with a route-map for that network (Vlan 40: 147.191.128.40/29) under OSPF 100 and that is not working. We may try using a new test Vlan or Loopback with a 192.x.x.x and see if that gets redist.

BTW the show ip os data ext 147.191.128.40 was blank.

Thanks

Regards

Joe

That's strange. Did you try 'redistribute connected' without the route map. Can you post the output of 'show ip ospf int' when OSPF is enabled on the interface configured with the IP from 147.191.128.40 subnet.

Try configuring 'redistribute ospf 200 metric 10 subnets' under router ospf 100 and see if that makes any difference. It should work the way you have it configured and this looks like an anomaly.

HTH

Sundar

Unfortunately in this live setup we could not make too many changes. Still agree that redist connected should have worked.

To get this going we ended up using RIP 2 into OSPF which is working. (The RIP routes are actually "injected" routes from a PIX/ASA.)

Thanks

Regards

Joe

Joe,

Thanks for the update. Glad to hear you got it to work with a workaround solution :)

Your issue certainly appears like an IOS bug as the redistribution is broken somewhere. Clearing the OSPF process or reloading the router may have cleared the problem but I understand that's not possible in your case.

HTH

Sundar

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: