Unnecessary DR election

CriscoSystems · ‎02-20-2009

Hi everyone

I already posted this in the "Training" forum, figuring it was a question from someone who could stand a little more "Training" on this subject, but that forum doesn't seem too active. Here it is:

Four routers are connected via token-ring in Area 0. RID 222.1.8.1 is DR, 222.1.7.1 is BDR. DRothers are 222.1.6.1 and 222.1.5.1.

I powered 222.1.5.1 down. Switched it right the hell off. Felt no guilt; would do it again.

I was logged on, console-like, to Router G (222.1.7.1) with OSPF Adjacency debugging activated, and here's part of what I saw:

01:08:28: OSPF: 222.1.5.1 address 10.4.4.5 on TokenRing0 is dead

01:08:28: OSPF: 222.1.5.1 address 10.4.4.5 on TokenRing0 is dead, state DOWN

01:08:28: %OSPF-5-ADJCHG: Process 100, Nbr 222.1.5.1 on TokenRing0 from FULL to

DOWN, Neighbor Down: Dead timer expired

01:08:28: OSPF: Neighbor change Event on interface TokenRing0

01:08:28: OSPF: DR/BDR election on TokenRing0

01:08:28: OSPF: Elect BDR 222.1.7.1

01:08:28: OSPF: Elect DR 222.1.8.1

01:08:28: DR: 222.1.8.1 (Id) BDR: 222.1.7.1 (Id)

The router that went down was neither DR nor BDR. Why was there a DR election reported? Does this always happen when there's a neighbor change event on a multiaccess interface? That doesn't jibe with my training, which says that an election won't take place unless the existing DR goes down.

Laurent Aubert · ‎02-20-2009

Hi,

From RFC 2328:

"

When a neighbor's state changes, it may be necessary to rerun

the Designated Router election algorithm. This is determined by

whether the interface NeighborChange event is generated (see

Section 9.2). Also, if the Interface is in DR state (the router

is itself Designated Router), changes in neighbor state may

cause a new network-LSA to be originated (see Section 12.4).

"

Losing a neighbor is a NeighborChange event so the election is expected.

HTH

Laurent.

marikakis · ‎02-21-2009

Yes, but as the RFC says "it may be necessary". In this case it is not necessary as far as I understand, since the DR and BDR are still there. This looks like a bug to me and I have responded in another thread:

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Career%20Certifications&topic=Training&topicID=.ee702b3&fromOutline=&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.2cd232b5

marikakis · ‎02-21-2009

Ok, I might have not been very precise in this. In your case, the same routers are being re-elected as DR and BDR, so there is really no change. If you change the RID of the one DROTHER to be the highest in the network and bring the other DROTHER down, is there a change in the DR/BDR? What is important here is to not change the DR and BDR while they are still there. If routers realize during the election process that they need to do nothing to change the existing DR/BDR, all is fine.

Harold Ritter · ‎02-21-2009

Seth,

This not an election per say, as per Maria statement that the DR and BDR are still alive and kicking. Even if the router that was taken off-line was brought back with a higher RID or priority than the current DR and BDR, the result would remain the same (ie. current DR/BDR would remain in place).

Regards

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

marikakis · ‎02-21-2009

Harold,

I got confused at the beginning, because I recalled about a bug case with the election process (some kind of preemption). It was back in 2002 or close to this and my memory fades with time. Still, I think there was a case where a DR/BDR would change even though it was not supposed to. That's why I suggested this test procedure. Also, such bugs in older implementations caused some books to say contradicting things about the election process. (I am not obsessed with bugs. I only say this to inform about the chances of various descriptions in the literature of the election behavior.)

Kind Regards,

Maria

p.s. I found a book published in 2004 that mentions this issue. Its a networking academy lab companion in advanced routing. It says: a known bug in some IOS versions allows a "new" router with higher election credentials to force an election and assume the role of DR.

Harold Ritter · ‎02-21-2009

Maria,

I agree that sometimes bugs make one scratch their head and wonder if this is normal behavior or not.

Regards

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México