01-31-2007 10:55 AM - edited 03-05-2019 02:05 PM
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
01-31-2007 11:11 AM
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
01-31-2007 11:24 AM
!
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
01-31-2007 11:37 AM
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
01-31-2007 03:34 PM
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
01-31-2007 07:40 PM
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
01-31-2007 08:33 PM
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
01-31-2007 09:01 PM
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
01-31-2007 11:15 AM
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
02-01-2007 04:46 AM
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
02-01-2007 10:27 AM
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
02-07-2007 02:38 PM
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
02-07-2007 02:48 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide