03-06-2012 06:25 AM - edited 03-07-2019 05:22 AM
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!
03-06-2012 07:54 AM
Physical interfaces also have a priority value configured - change R3 & R4 interfaces to "ip ospf priority 0"
03-06-2012 07:05 PM
As you can noticed the question is not in how to make R1 and R2 DR/BDR but in how neighbor command works
03-06-2012 10:57 PM
Hello Alexey,
Check out this thread - it may provide some answers.
https://supportforums.cisco.com/message/829782#829782
Best regards,
Peter
03-07-2012 03:20 AM
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
03-07-2012 09:54 AM
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
03-10-2012 08:41 AM
Good day, Peter.
Tnx for replying!
Check out this thread - it may provide some answers.
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.
03-10-2012 03:04 PM
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:
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
03-11-2012 05:33 AM
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.
03-11-2012 08:55 AM
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:
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
03-11-2012 09:33 AM
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
03-11-2012 03:34 PM
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: