OSPF static neighbor question

[Alexey Stytsenko]

Good day.

I have a problem with implementing priority option on static neighbor comman. In CISCO OSPF Design Guide inAdjacencies on Non-Broadcast Multi-Access (NBMA) Networks paragraph states that

Also, because of the lack of broadcast  capabilities, the  DR and BDR

need to have a static list of all other  routers attached to  the cloud.

This is achieved using the

neighbor ip-address [priority number] [poll-interval seconds]

command, where the "ip-address" and "priority" are the IP address

and   the OSPF priority given to the neighbor. A neighbor with

priority 0 is   considered ineligible for DR election.

At practice when i configure topology like this (logical topology adduced below)

and plan to make R1 become DR and R2 BDR i tried to configure both of themwith static neighbors (network type NBMA) and set priority for R3 and R4 to 0 but priority for R1 set to100 and for R2 set to 1 respectively (on R3 and R4 i simply configure static neighbors with no additional options).

During WAIT time all go as planned, R1 form with R2 2WAY neighborship and ignore R3 and R4 holding them in attempt state. But when WAIT time gone R4 is elected as DR due to highest RID.

So seems that i completely missuderstand in how this option work! Can somebody clarify?

Higly appreciate your responses! Thnx!

[andrew.prince]

Physical interfaces also have a priority value configured - change R3 & R4 interfaces to "ip ospf priority 0"

[Alexey Stytsenko]

As you can noticed the question is not in how to make R1 and R2 DR/BDR but in how neighbor command works

[Peter Paluch]

Hello Alexey,

Check out this thread - it may provide some answers.

https://supportforums.cisco.com/message/829782#829782

Best regards,

Peter

[cadet alain]

Hi Peter,

so what are your conclusions about the priority configured in the neighbor command as it is always superseded by the priority received in the hello from the neighbors ?

Regards.

Alain

[Peter Paluch]

Hello Alain,

According to the experiments I've conducted in that thread, it seems that the priorities configured in the neighbor statement are purely a local parameter that decides which neighbors shall be initially contacted if DR/BDR elections are necessary - and that's about it. There does not seem to be absolutely any further meaning to that setting.

If the priorities in the neighbor command are configured to match the real priorities of these neighbors, the result is apparent: when DR/BDR elections need to take place, the router will initially send OSPF Hellos only to those routers whose priorities are non-zero, because for DR/BDR elections, these are the only routers worthy to compete with. If the priorities do not match - well, I will have to think about this a good deal. I can see some skewed elections taking place but I have to confirm that first. Expect an addition to this post later.

Best regards,

Peter

[Alexey Stytsenko]

Good day, Peter.

Tnx for replying!

Check out this thread - it may provide some answers.
https://supportforums.cisco.com/message/829782#829782

Already red it before post here, but in my lab (topology i adduced in initial message) things goes different.

I want to show you configuration i make and maybe you will find out any mistake.

So for R1 (IP 192.168.123.1 RID 10.10.10.10):

router ospf 1 log-adjacency-changes neighbor 192.168.123.3 neighbor 192.168.123.2 neighbor 192.168.123.4 priority 100

interface Serial0/0 ip address 192.168.123.1 255.255.255.0 encapsulation frame-relay ip ospf network non-broadcast ip ospf 1 area 0 clockrate 2000000 end

For R4 (IP 192.168.123.4 RID 40.40.40.40):

router ospf 1 log-adjacency-changes neighbor 192.168.123.1 priority 200 neighbor 192.168.123.3 neighbor 192.168.123.2

interface Serial0/0 ip address 192.168.123.4 255.255.255.0 encapsulation frame-relay ip ospf network non-broadcast ip ospf 1 area 0 clockrate 2000000 end

For R2 (IP 192.168.123.2 RID 20.20.20.20):

router ospf 1 log-adjacency-changes

interface Serial0/0 ip address 192.168.123.2 255.255.255.0 encapsulation frame-relay ip ospf network non-broadcast ip ospf priority 100 ip ospf 1 area 0 clockrate 2000000 frame-relay map ip 192.168.123.3 201 end

For R3 (IP 192.168.123.2 RID 20.20.20.20):

router ospf 1 log-adjacency-changes

interface Serial0/0 ip address 192.168.123.3 255.255.255.0 encapsulation frame-relay ip ospf network non-broadcast ip ospf priority 200 ip ospf 1 area 0 clockrate 2000000 frame-relay map ip 192.168.123.2 301 end

During WAIT TIME everything goes well:

R1#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

N/A               0   ATTEMPT/DROTHER 00:00:30    192.168.123.3   Serial0/0

N/A               0   ATTEMPT/DROTHER 00:00:30    192.168.123.2   Serial0/0

40.40.40.40       1   2WAY/DROTHER    00:01:35    192.168.123.4   Serial0/0

R4#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

10.10.10.10       1   2WAY/DROTHER    00:01:48    192.168.123.1   Serial0/0

N/A               0   ATTEMPT/DROTHER 00:00:23    192.168.123.3   Serial0/0

N/A               0   ATTEMPT/DROTHER 00:00:23    192.168.123.2   Serial0/0

But after everything collapsed - R1, R4, R3 agrees on that R3 is DR and R1 is BDR, R2 insist that he is DR and R1 BDR

R1#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

30.30.30.30     200   FULL/DR         00:01:51    192.168.123.3   Serial0/0

20.20.20.20     100   FULL/DROTHER    00:01:51    192.168.123.2   Serial0/0

40.40.40.40       1   FULL/DROTHER    00:01:51    192.168.123.4   Serial0/0

R2#sh ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

10.10.10.10       1   FULL/BDR        00:01:37    192.168.123.1   Serial0/0

40.40.40.40       1   EXSTART/DROTHER 00:01:42    192.168.123.4   Serial0/0

Cos of such inconsistiency neighborships periodically "flaps" and network can not be admit as stable.

[Peter Paluch]

Hi Alexey,

I do not see any contradiction to my older article.

First of all, for DR/BDR election, the priorities configured in the neighbor commands are irrelevant. Your configuration is problematic in the sense that the interface priorities on R2 and R3 are non-zero even though neither R2 nor R3 have a VC to all other routers in this topology. For any OSPF deployment, this is a principially incorrect configuration. This leads to both R2 and R3 comparing their interface priorities to priorities of R1 and R4 only, as R2 and R3 do not hear each other. This comparison will end in a series of disparate views on the network:

• R2 hears only R1 and R4 and declares from its viewpoint that R2 is DR and R4 is BDR because of its higher RID
• R3 hears only R1 and R4 and declares from its viewpoint that R3 is DR and R4 is BDR because of its higher RID
• R1 and R4 hear each other router in the topology. Because of the highest priority and RID, they agree that R3 is DR and R4 is BDR

Your network therefore ends up in two DRs and one BDR - an illegal situation for OSPF.

Correctly, both R2 and R3 should have been configured with the interface priority set to 0. Having them configured with a non-zero interface priority will never produce correct results in your network. Specifying priorities in the neighbor command will not help at all - as I suggested in my previous thread, these priorities only influence which neighbors are contacted first but they do not directly impact the DR/BDR elections.

Best regards,

Peter

[Alexey Stytsenko]

Good day, Peter.

Specifying priorities in the neighbor command will not  help at all - as I suggested in my previous thread, these priorities  only influence which neighbors are contacted first but they do not  directly impact the DR/BDR elections.

But it seems to be logical that in case of OSPF process is not preemptive, and cos during WAIT time on broadcast and non-broadcast network no election of DR/BDR occurs and only neighbors with non 0 priority considered as possible DR/BDR candidates than after WAIT timer finished  two of those became DR/BDR.

Besides if im not missuderstood  - you already wrote it in your article (you provide link previously):

Well, all this leads me to a conclusion that by configuring some  priorities in the "neighbor" commands, we are able to define which  routers in a NBMA network should compete for DR/BDR when starting up.  All other routers will be simply left off this election. Only after the  elections have taken place, the remaining routers will be contacted and  adjacencies established

And in my topology only R1 and R4 should compete for DR/BDR election. And i made configuration accordingly.

So i see big "contradiction " between my lab behaviour and yours conclusions in previous post.

[Peter Paluch]

Hi Alexey,

But it seems to be logical that in case of OSPF process is not  preemptive, and cos during WAIT time on broadcast and non-broadcast  network no election of DR/BDR occurs and only neighbors with non 0  priority considered as possible DR/BDR candidates than after WAIT timer  finished  two of those became DR/BDR.

I am not sure if I understand the point of this comment. But in OSPF, it is actually the entire WAIT time during which the elections are performed. Technically, during the WAIT time, Hello packets are collected from all neighbors along with their priorities and RIDs, and after the WAIT time elapses, these priorities and RIDs are evaluated and DR/BDR are chosen. The DR/BDR elections are not an instantaneous process.

And in my topology only R1 and R4 should compete for DR/BDR election. And i made configuration accordingly.

I respectfully disagree - your configuration is not correct. It would be correct if R2 and R3 were configured with the interface priority of 0. However, what your configuration does is the following:

• To clear the terminology, I will be using two different terms: interface priority is the OSPF priority as defined on an interface configured using the ip ospf priority command; neighbor priority is the OSPF priority as defined using the neighbor command
• R1 and R4 have interface priorities on their default value, i.e. 1. In addition, on both these routers, you have configured all remaining neighbors manually, and in each neighbor command, you have either omitted the priority (which is then implicitly taken as 1) or configured an explicit neighbor priority of 200. The entire and sole effect of these neighbor commands and neighbor priorities is that because they are all non-zero, R1 and R4 will start sending Hello packets to all neighbors. There is absolutely no further use of these neighbor priorities at all.
• R2 and R3 have interface priorities set to 100 and 200, respectively. They have no neighbors defined (or you have tried to enter the neighbor commands on R2 and R3 with priority set to 0 - this will cause the neighbor commands to be ignored and not even added to the configuration). Therefore, R2 and R3 have no idea who the neighbors may be and cannot engage into OSPF adjacencies by themselves. However, when other routers, in this case R1 and R4, start speaking to them, they will respond.

So this is the situation: R2 and R3 sit quiet and wait for other routers to contact them. R1 and R4 have neighbors statically defined and because all neighbor priorities on R1 and R4 are non-zero, R1 and R4 will start speaking to all statically defined neighbors. From this point on, neighbor priorities become absolutely irrelevant. R2 and R3 learn about R1 and R4 (note that R2 and R3 do not learn of each other as there is no PVC between them) and engage into DR/BDR elections according to interface priorities. The result and exact steps of these election were described in my previous post.

Does this make sense, Alexey? Please feel welcome to ask further!

Best regards,

Peter

[Alexey Stytsenko]

Hi, Peter!

Great tnx for continuing examine my question!

I am not sure if I understand the point of this comment. 

Sry, for that - previously i wrote a lot but than delete half cos "propelry formulated question contains half of answer" and forget to check sense. I mean that during WAIT time on broadcast and non-broadcast network no election made but preparation for election goes and participate in this pre-election can only neighbors wich configured with non 0 priority. After WAIT time finished election occurs based on data collected during WAIT time and in two of routers initialy configured with non 0 priorities become DR/BRD respectively, and in my case those two must be R1 and R4.

BTW

 you have configured all remaining neighbors manually, and in each neighbor command, you have either omitted the priority (which is then implicitly taken as 1) 

I configured R1 and R4 with neighbor command, but use priority 0 for R2 and R3 neighbors (and in case of that is default value it hasnt reflected in show run commands).

So during WAIT time no hellos sended to R2 and R3 and no hellos received (and i confirm it - checked mannualy on each router), but as i observed - after WAIT time gone, R1 and R4 immediately make R3 DR, i cant even catch moment other than ATTEMPT/DROTHER (during WAIT time) and FULL/DR.

Im start thinking that smth wrong with my GNS3 emulator

[Peter Paluch]

Hello Alexey,

I am starting to see your point. One correction already: you are correct, the default neighbor priority is 0, not 1 as I suggested, and even configuring the neighbor priority of 0, the command is nevertheless accepted into configuration. I have confused this with interface priority - if that is set to 0, no neighbor commands are retained for neighbors over that interface.

I will need some time to re-check my experiments again. I'll be back, hopefully in a day. Thank you for your patience!

Best regards,

Peter