OSPF Down/Up transit links, aka the presumptious DR

gonzo1948

I have a question about OSPF transit links and the LSA exchange when a transit link goes down and then back up. Consider the following: Several routers each with a single FastEthernet interface to a common switch. One is the DR and OSPF has converged.

When one of the non-DR interfaces goes down, the DR notices this (from the lack of Hellos from the downed interface) and sends out a Network-LSA telling all other routers of the downed interface. After some time, all of the other interfaces are sending Hellos with one less neighbor. So far everything seems OK.

After some time, the downed interface comes back up. The DR notices this by the Hello from the previously downed interface. Now here is my question.

I would expect the DR to FIRST send out a new Network-LSA listing the new neighbor because that is all it really knows at this point in time. But it does not. Instead, I see that the DR sends out a Router-LSA of the previously downed router. To further add to my confusion, this Router-LSA lists a stub link. Then later, the DR sends out the expected Network-LSA, and then the previously downed router finally sends out its expected Router-LSA listing its transit link.

So, why does the DR send this Router-LSA (from the previously downed router) before it sends out the Network-LSA? And why does the DR CHANGE its own copy of that previously downed router's Router-LSA by adding the stub link and removing the original transit link? By doing so, It seems like the DR is telling everyone else, that a router it used to know about, now has a new stub link, BEFORE it knows what that router actually has (because that router has not yet sent out its own Router-LSA telling everyone what links it actually has). Seems that the DR is very presumptious to tell everyone what that router has before that router officially declares what it has with its own Router-LSA.

Thanks,

-Andres

networker050184

Ok, maybe what is confusing you is that the DR is not sending a Router-LSA (type 1 LSA) for the neighboring router, every router generates its own type 1 LSA. The DR does not generate any type 1 LSAs for other routers. So I believe what you are seeing is the non-DR router updating/generating its own type 1 LSA for that network. It will not be a stub network, but maybe you are catching this type 1 LSA before neighbors are formed and the router is aware that this is a transit network. Finally once neighbors are formed the DR updates the Network-LSA (type 2) and re-floods to ensure all other routers know that another router has come online on this shared segment.

Hope his helps with the understanding.

gonzo1948

Thanks for your response.

But it appears that the DR *is* sending the other router's Router-LSA.

I get a LSUpdate pkt, sent from the DR, and it contains a non-self-originating Router-LSA that has the Advertising Router field set to the Router ID of downed router.

Also, I get the Router-LSA generated by the non-DR router later--the LSUpdate pkt from the DR comes in first.

networker050184

Well, type 1 LSAs are flooded throughout the area as mandated by the OSPF standard. I'd assume you are just seeing the DR flood this updated LSA, but under no circumstances does any router generate a type 1 LSA for another router.

gonzo1948

networker050184 wrote: »

Well, type 1 LSAs are flooded throughout the area as mandated by the OSPF standard. I'd assume you are just seeing the DR flood this updated LSA, but under no circumstances does any router generate a type 1 LSA for another router.

I agree, that is why this is so confusing to me. The DR appears to be flooding the type 1 LSA but with a different link list. But that LSUpdate pkt from the DR, containing the non-DR router's type 1 LSA, is sent a full second before the DR router sends its own Network-LSA, and 4 seconds before the non-DR router sends it type 1 LSA,

networker050184

The DR can only flood/withdraw another routers type 1 LSA. So I think this is what you are seeing with a few assumptions on your topology.

1. Link goes down/neighbor lost.
2. Non-DR router updates its type 1 for this and its flooded onto the segment by the DR (or if the non-DR router goes off the map completely the type 1 LSA is withdrawn).
3. Link comes back up and non-DR router updates it's type 1 LSA with stub status because no neighbors are formed yet.
4. Neighbors are formed and DR router updates the type 2 LSA and now the non-DR router must update it's type 1 as a transit link which is again flooded.

What you are describing sounds like normal OSPF behavior to me.

gonzo1948

networker050184 wrote: »

1. Link goes down/neighbor lost.
2. Non-DR router updates its type 1 for this and its flooded onto the segment by the DR (or if the non-DR router goes off the map completely the type 1 LSA is withdrawn).
3. Link comes back up and non-DR router updates it's type 1 LSA with stub status because no neighbors are formed yet.
4. Neighbors are formed and DR router updates the type 2 LSA and now the non-DR router must update it's type 1 as a transit link which is again flooded.

2. my topology is all single interfaces so when the interface goes down, the non-DR is totally off the map so it cannot flood any updated type 1 LSAs.
3. I agree. non-DR router updates its type 1 LSA with stub status but I never see this LSA.

Time t = 0: the DR floods the non-DR router's type 1 LSA with stub status. Note that this happens BEFORE I see ANY type 1 LSA from the non-DR router, pre-adjacency nor post-adjacency LSAs.

Time t = 1: now the DR floods its type 2 LSA showing the non-DR router

Time t = 4: now the non-DR sends out its type 1 LSA with the transit link indicating the adjacency has formed. Note that we never got the non-DR router type 1 LSA with the stub status indicating it has not yet formed the adjacency.

I know this all appears to be totally wrong but that is what I am seeing on the wire.

The thought crossed my mind that the switch that is connecting all of these single interface routers, must not be transmitting out frames in the order received. That would explain the screwed up order that I see the LSAs, but it would not explain the absence of the pre-adjacency type 1 LSA from the non-DR. BTW, my monitor access point is this switch. It appears that this switch is faulty.

networker050184

I'm going off the top of my head right now so some research may be in order.

Are you sure what you are seeing is not the withdrawal of the type 1 LSA? The marking of stub could be some part of the purge.

gonzo1948

when the transit link goes down, I get the type 2 LSA from the DR indicating the link is gone. I saw several Hellos for all of the other routers on this network with their neighbor lists showing that the downed neighbor was long gone. So it seems like the network was fully stable. Then it is over 40 seconds later that I physically reconnected the link to bring it back online. So it seems like any effects from the "withdrawal of the type 1 LSA" would be well past (If I am interpreting correctly what you mean when you say "withdrawal of the type 1 LSA")