Missing OSPF summary / inter-area routes

[nathan.dixon]

I have an area 0 with 9 other areas connected (two of them via virtual links). Core routers participating in area 0 can see all networks. Routers in one of the others areas (non 0) can see intra area routes and area 0 but only some networks in other areas. Also, am I correct in saying these are inter-area or summary routes, is this the same thing? Cisco's fault finding flow chart says I should check for a non-contiguous area 0. If this is the only fix, whats the best way to check this, re-checking my configs...again! Thanks

[ruwhite]

If every router in area 0 can see the same routes (which means every router in area 0 have synchronized databases, including all the inter-area/summary routes from the outlying areas), and some other areas do not see all the routes that area 0 sees, (prefixes, or reachable destinations, not the same lsa's), then the most likely explaination is that these areas are stub areas in some way, or there is some sort of route summarization configured into the areas at the ABR.

I would start by looking at the area border routers first, to make certain I know what type of area each area is. For all non-stub areas, I would then look at their routing tables, to make certain they have all the routes I expect--I'd ignore the ospf database up front, until I knew what routes (destinations) were missing. Once I had a list of routes (destinations) that are missing, then I would try and figure out what type of LSA I would expect to receive that route in, and then examine the database to see if I can figure out why it's not there, or if it is there, and just not installed.

Generally, you want to work from the routing table to the ospf database, rather than sitting down staring at the ospf database first....

Russ.W

[nathan.dixon]

Russ, thanks for the response. Strange you should say route summarization, we are also running EIGRP with route summaries as we are half way through a migration to OSPF. We have not knowingly created any stub areas. The EIGRP has caused a few minor headaches when trying to establish the virtual links. The virtual links are over a transit area with more than one router, the links have not come up as yet because the two virtual link end routers don't know how to get to each other via OSPF (not in database), only EIGRP. When EIGRP was removed at both ends for a short test the virtual links came good. Not sure if this is relevant. I realise ospf has a higher cost than eigrp and we are not experiencing our missing routes on the virtual link areas only, they are missing from 'normal' areas too.

Whats the best way to check if a specific network is in the database but maybe not yet in the table. sh ip ospf database a.b.c.d ?

On an ABR with 3 interfaces, can one be in 0 and the other two be on say 100, is this leagal i.e. is 100 still contiguous? Clutching at straws I know but Im not very experienced with ospf. Thanks again.

[ruwhite]

Okay, I'm assuming we aren't talking about missing routes in the areas behind the virtual links that aren't up yet.... :-)

Unfortunately, there's no way to examine the ospf database for a specific route without knowing what type of LSA the route arrived in.... :-( If it's a point-to-point link within the same area, then you would look at show ip ospf data router. If it's a broadcast network within the same area, you'd use show ip ospf data network. If it's any sort of a link outside the area (which is what we are dealing with here), it's show ip ospf data summary (which isn't a summary of the database, it's a list of the summary lsa's).

The ability to pull regexp's on the command line can be your friend here:

show ip ospf data summ | b x.x.x

replacing the x.x.x with the first two or three octets of the network address you're looking for. (i)nclude might be easier to see rather than (b)egin, it depends on how big the database is.

If you see something in the database, and not in the routing table, check the database entry to make certain the "routing" bit is set. There's a line there someplace that says "routing bit is (not) set," whichever way it is. If it's not set, that means one of two things:

-- The ospf database entry is perfectly fine, but there is another route in the routing table with a lower administrative distance than this ospf route, so ospf didn't install it.

-- The next hop for this route isn't known via an internal OSPF route. This is only common/possible for externals with the next hop address set.

My guess, at this point, is that you are seeing the first, since you've said you are migrating from EIGRP to OSPF, and you aren't seeing the routes in the routing table. They are just not getting installed in the routing table, since EIGRP's admin distance on internal routes is better. It could be the second, if you are redistributing a good number of routes into OSPF off of broadcast networks....

As for the contiguous area question--the only area that needs to be contiguous is area 0. The other areas are just areas, when the type 3 is built at the abr, the area number isn't included.... So, it's possible to actually build an ospf network with multiple independant areas, all with the same area number (!). As long as you don't overlap your summaries, this will work.

More specifically, though, all of the interfaces in a given area within the same ospf process on the same router are considered to be in the same area, topologically. In other words, to answer your question, if you have a single router with two interfaces in area 100, and one interface in area 0, the two interfaces in area 100 will share the same link state database, and are in the same topological/physcial area....

Russ.W

[nathan.dixon]

Thanks for the tips. What we have done to test how the migration will go is to turn off EIGRP on a non critical router and run ospf only. Its on this router where we discovered ospf only knows some of the network. As you say, eigrp or other protocol with a lower cost would insert the route however we are not running any on this specific router. This router has all interfaces on area 300. Maybe i need to have a good look through the database with the | begin command and see whats missing. Im sure I did this the other day and found some networks in area 100 missing, but others in 100 were there.