I am migrating a network from EIGRP to OSPF. I have configured OSPF with an area 0 and non-zero areas hanging from it. Two via virtual links. Each area has 6 routers, two of them are the ABR's to area 0 (A and B chain). I have turned off EIGRP on a non-ABR router for a test. I have noticed this router can see some but not all inter-area networks. Some networks that are missing are within the same area as ones that can be seen! It is also missing two entire area's networks. No stub areas are configured. Database has been checked for the routes, not just the routing table, still with no luck. Area 0 should be contigious. The other 3 non ABR's also have the routes missing from the database. All ABR's can see everything. Every non-0 area can see all area 0 networks OK. If I go to a network which can't be seen and I check for routes back to the faulty area I see that it does know it by OSPF.
OSPF configs have been double checked, inverse masks etc. OSPF has been removed and re-applied.
Seems inter-area routes are working in one direction to my faulty area, but not back again.
Can EIGRP be causing any problems with OSPF?
Had a problem where the virtual links (over multiple router transit area) are not up, they come up only when I temporarly remove EIGRP on these routers. Not sure if this is relevent.
EIGRP internal routes (by default) has a better (90) admin distance so it would be preferred over OSPF (110) but EIGRP itself should not cause any problems with OSPF.. redistribution brings in another set of issues all togther..
Virtual links not being up is a problem. Virtual links being up also should have nothing to do with EIGRP's presence. Can you share more information about your topology? Virtual links can cause considerable problems and complexity to an OSPF network. They are not recommended to use unless absolutely needed. Why are you using them?
Hope this helps,
Thanks for the response. We are not re-distributing between EIGRP and OSPF. We have a core network of 12 routers in a ring where 2 of these routers are at the same site and are ABR's. Therefore 6 key sites. At these 6 sites we then have 4 other routers for access to the network. We have a special site which is not on the core ring but is connected to two of the areas at different locations so as to provide redundancy, area 200 and 300. The remote site cant be a part of either of these areas as which one would you chose and what would happen in a fault situation? So we have made the special site an area 900. The only way to link this area 900 to 0 is via virtual link. The A path goes via 300 and B path via 200. The special site conencts via the access routers. The virtual link config points from the ABR to the area 900 routers and back again. There is then a hop over the access router. Can virtual links span accross a router in the transit area. All examples I have seen only show virtual links to a directly connected router not over a hop. Thanks
It shouldn't matter how many routers are in between the remote site router and the ABRs where the virtual links terminate. But, you can only bring the virtual link up if the route is actually learned through OSPF, so... I'd guess that's why the virtual link isn't up at this point.
You could choose to put the remote site in either area 200 or 300, either one would work fine. As far as a fault situation--you could always set up a virtual link over one of the areas, rather than both, to connect the entire area back to area 0. For instance, you could put the remote site in 200, and then put a virtual link through 300 back into area 0 from this part of 200. You could also configure it half way, and just bring it up when you need it, if you'd rather not have the virtual link up all the time.
As for the missing routes in the routing table and the ospf database, we'll probably need more information. For instance, are these routes present as intra area routes in any of the routers in the area where they originate? If not, what does the databse on the router that should be originating them look like?
If they are in some routers, and not in others, are you certain the area is contiguous? Interareas should be treated the same way:
-- Start by checking the area the routes should be originating in, to make certain they are correctly originated and flooded as intra area routes in that area.
-- Next, check the ABR, which should have two of that route, one in it's area 0 database as a type 3, and the other in it's area
-- Next, look around around 0, and see which routers have this route as a type 3, and which don't. Try to figure out what the pattern is with those that don't--do they have some other route overriding this one, or are they isolated from area 0, or.... (?).
Thanks for your help.
I have had a dig around on the 'missing' area's routers and found that only some of the networks are being advertised. These don't appear as intra-area routes on adjacent or even the originating router! However the ABR's do see the networks, strange! I have removed the virtual links config from the ABR's in this area only and re-set the ospf process. Hopefuly this is of some help. Regards.
Make certain you're looking in the right area of the database for the right routes.... Remember that intra area these will be either show ip ospf database router or show ip ospf database network, while for inter areas, they will be in show ip ospf data summ. If you have a set of databases and configs you'd like looked at, either post them here, or send them to me directly.
Thanks Russ, I will post some stuff to you tomorrow. If you remember I said some intra area networks were visible but not all. I removed all of virtual link references and these networks have now all gone! The v links seem to have some sort of influence on this. I have been looking at the database using "sh ip os da | inc 10.216.104." so as to find any of my intra area router loopback addreses anywhere! (Loopbacks have 32bit masks). Should I be using ...router or ...network. I presumed not specifying these key words would show the entire database. Thanks.
Hi Russ, can you let me know exactly what you want me to send you. The configs and database (sh ip os da) from the missing areas or the area that can't see some areas. Would you like the ABR's, non-ABR's etc. They are big as the the networks has >200 routers!
Well, let's back up some.... do the missing database entries exist on the routers the networks are connected to? If not, then we need to see the config for the router, and show ip ospf router from that router, with just the locally originated LSA in the output.
This may be more complicated than something you want to handle here in the forum--you could open a case, then you could have the tac engineer look at the routers directly (?).... In any case, we should take one situation at a time, since solving one specific case might solve all of the cases.