Weird OSPF election results

kpjungle

Hi,

I have a 3640 with Fast Ethernet, and a 2611 with Ethernet, they are each connected to a 2950 switch to provide connectivity.

The 3640 is configured like this:
Fastethernet0/0 192.168.1.2
Loopback0 1.1.1.1

The 2611 like this:
Ethernet0/0 192.168.1.10
Loopback0 2.2.2.2

They are running standard ospf priority (1) on the interfaces. But for some reason, contrary to my studying, the 1.1.1.1 router becomes DR. If I powercycle both routers, the same happens.. 1.1.1.1 is DR and 2.2.2.2 is BDR. Shouldnt it always be the other way around?

I can see that respectively, they are using their loopback addresses as the OSPF router ID, so I know that part is okay, but for some reason, its not working as expected, any ideas?

(Yes, i tried setting the ip ospf cost on the 2611 to 1 to match the 100mbps interface of the 3640, but with the same results).

Thanks!

gojericho0

Powercycle again, this time boot the 2.2.2.2 router first. Does this fix the problem?

kpjungle

Hi,

That seems to work. If i boot the router with ID 2.2.2.2 it becomes DR and after the other one is booted up 1.1.1.1 becomes BDR.. But if if i do it the other way around.. boots 1.1.1.1 first, and then 2.2.2.2, 1.1.1.1 becomes DR... Doesnt that just mean that the first one on the segment, becomes DR?

You would think that when you only have two routers, and you boot them up, they would actually see which one of them has the highest router ID, and choose that one as DR and the other one as BDR?


Bit confused

gojericho0

Here's the catch. Whatever router you boot up first the OSPF process will detect that its on an ethernet (broadcast) network. It will they try to negotiate the PDR, since no other router is powered on yet to negotiate with, it will assume the PDR role since it has the higher loopback by default.

Once OSPF picks a PDR or BDR it will not dynamically change if a higher IP address is later added to the network. The only way this will happen is if you restart the OSPF process on both routers


Does this make sense?

kpjungle

Hi again,

Yes, it makes alot of sense. Thanks. But there must be some sort of timing issue involved. I did try to issue the command: "clear ip ospf process" on both routers, but im having a hard time deciding if it works or not.. it seems to work sometimes, but not consistently like i would have liked.

But thanks alot, it makes more sense why im seing what i am, but in what scenario will it actually make a "real" election (if it will), deciding on a network that the highest router ID wins? is it only if both the DR and BDR bails out and any remaining routers need to make sure that there is at least a DR?

gojericho0

Even if both DR and BDR go down, you will have to restart the OSPF process to have an election, you could also shut down the interfaces, but then you have to wait until the hold timers expire

kpjungle

Thanks Gojericho0,

Just a little misguiding to call it an election then i guess Hope theres more after CCNA (CCNP maybe) on the election stuff, because I cant find much of those gold nuggets with my current study material.

Thanks for your time to help me out

Stovokor

kpjungle wrote:

Thanks Gojericho0,

Just a little misguiding to call it an election then i guess Hope theres more after CCNA (CCNP maybe) on the election stuff, because I cant find much of those gold nuggets with my current study material.

Thanks for your time to help me out

There is a whole heap of information on the election process in the BSCI self study guide.

gojericho0

kpjungle wrote:

Hi again,
I did try to issue the command: "clear ip ospf process" on both routers, but im having a hard time deciding if it works or not.. it seems to work sometimes, but not consistently like i would have liked.?

This normally only works for me if I assign the ospf process a priority instead of doing assigning an ID by interface or loopback. you can do a "no router ospf process id" then re-enter your networks to get it to take the new ID

gojericho0

here's some more info

http://www.cisco.com/warp/public/104/1.html#t21