Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

Another OSPF database "issue"

In my OSPF lab, all routers have a Loopback 0 interface with the address 222.1.x.1; where x equals the number of the router's letter (RouterA=1, B=2, etc).

I have a backbone area of Routers E, F, G, and H; all connected via tokenring and all on subnet 10.4.4.0/24.

Router E is the ABR to Area 1; via a serial link (201.0.0.0/30; A=.1 E=.2).

Within Area 1, Router A has an Ethernet link to Router B; 10.3.3.0/24.

I have full connectivity everywhere; the routing tables all look like I think they should.

The thing that's confusing me is that the 201.0.0.0 link isn't showing up in the "sh ip ospf database" output anywhere in Area 1.

All of the backbone routers list a Link ID of 201.0.0.0 under "Summary Net Link States (Area 0)" with 222.1.5.1 as the adv router. That's all well and good but how come the routers in Area 1 don't list it under "Net Link States (Area 1)?"

Shouldn't they?

If so, why ain't they...

If not, why's that?

1 ACCEPTED SOLUTION

Accepted Solutions

Re: Another OSPF database "issue"

Hi Seth,

The reason behind this is tied to the function on each LSA as to what it advertises.

For example:

- A Router LSA's function is to advertise a network node and its connected links. How do we identify a node on the SPF-tree? By its router-id.

This is why the Router LSA's link-id is the router-id.

- A Network LSA's function is to advertise a multiaccess network and its DR. So practically the best choice to identify this LSA is with the IP address of the DR on this multiaccess network.

- A Summary LSA's function is to advertise subnets in other areas. So the best choice to identify this LSA with the subnet address that it advertises.

And so on.

In case of Summary and External LSA's there is no sense to advertise network nodes and DR's of OTHER areas, because the OSPF routers in THIS area do not need that topology information. THIS area's OSPF routers calculate the SPF-tree for THIS area only.

OSPF routers use the topology information of only ares that they are members of.

I hope I explained understandably.

Cheers:

Istvan

8 REPLIES

Re: Another OSPF database "issue"

...

Re: Another OSPF database "issue"

Hi Seth,

201.0.0.0/30 should be a Router LSA in area 1. The link state ID should be the router-id of the advertising router.

You should look for it using the "show ip ospf database router" command.

A Net link state is advertised by a DR on a network where a DR is elected. On point-to-point serial lines DRs are not required.

Cheers:

Istvan

Hall of Fame Super Silver

Re: Another OSPF database "issue"

Hello Stuey,

Istavan is right: a serial link doesn't need the creation of a network LSA to represent it in area 1 section of OSPF database.

For the same reason in the output of sh ip ospf neigh you see

FULL/- instead of FULL/DR or FULL/BDR or twoway/DRother meaning that a DR/BDR election didn't occur on the link.

sh ip ospf interface serx/y will show you OSPF network type as point-to-point.

You would need to change ospf network type with

int serx/y

ip ospf network broadcast

on both routers and see the difference: with this change the network LSA should be generated as a result of a DR/BDR election.

Hope to help

Giuseppe

Re: Another OSPF database "issue"

Hmmm, well thanks Istvan and Giuseppe.

I guess the thing that's most confusing me is, in the OSPF database, why are some "Link ID's" the router-ID's, while other "Link ID's" are the network addresses?

Re: Another OSPF database "issue"

Hi Seth,

The reason behind this is tied to the function on each LSA as to what it advertises.

For example:

- A Router LSA's function is to advertise a network node and its connected links. How do we identify a node on the SPF-tree? By its router-id.

This is why the Router LSA's link-id is the router-id.

- A Network LSA's function is to advertise a multiaccess network and its DR. So practically the best choice to identify this LSA is with the IP address of the DR on this multiaccess network.

- A Summary LSA's function is to advertise subnets in other areas. So the best choice to identify this LSA with the subnet address that it advertises.

And so on.

In case of Summary and External LSA's there is no sense to advertise network nodes and DR's of OTHER areas, because the OSPF routers in THIS area do not need that topology information. THIS area's OSPF routers calculate the SPF-tree for THIS area only.

OSPF routers use the topology information of only ares that they are members of.

I hope I explained understandably.

Cheers:

Istvan

Re: Another OSPF database "issue"

Well I guess that makes a bit more sense then. Surely I would have designed things a little differently if I had been the inventor of OSPF. (For instance, if router-id is such a great choice to announce a network node; then with a Network LSA, why not use the router-id of the DR; instead of the DR's IP address...)

Frankly I still think it's a little unfair that the the routers in Area 1 don't get to see the network address of a real, live, point-to-point network, located in their own area, in their ospf databases. But I guess the routing table is where it really matters.

I tellya, it's really something. I thought I had a really good understanding of interarea OSPF; and I was doing really well on all the self-tests at the end of my textbooks' chapters. Then I see it in action in the real world, and it's practically like I'm back at square one again.

Re: Another OSPF database "issue"

Hi,

The OSPF (Net Link state) Type 2 LSA generated by every DR on a segment.

Looking at your example, the Type LSA wont be visible on all AREA 1, but rather would be seen on the 201.0.0/30 segment with the forwarding address being the DR on this segment IF there is DR & BDR election. (Broadcast Multi access Network).

HTH

Mohamed

Re: Another OSPF database "issue"

Hi,

I just wanted to know/interrested why you have given me a rate of 3 ? Doesn't it a helpful answer or I just missed some point here.

HTH

Mohamed

151
Views
11
Helpful
8
Replies
CreatePlease to create content