08-19-2009
06:52 AM
- last edited on
01-29-2022
04:37 AM
by
Translator
All,
It's my understanding that priority of 0 keeps the router from becoming eligible to be elected as a DR/BDR, and the default is priority of 1.
What is the neighbor priority statement used for? Does is override what the neighbor is announcing in it's Hello?
neighbor x.x.x.x priority 1
If x.x.x.x is advertising 254, does the priority 1 override this if it's on the other end of the link?
Thanks,
John
Solved! Go to Solution.
08-19-2009
08:15 AM
- last edited on
01-29-2022
04:39 AM
by
Translator
John,
Good question.
I did a lab on it and found the neighbor will overwrite whatever priority you've entered locally.
router ospf 1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 192.168.1.1 0.0.0.0 area 0
neighbor 192.168.1.3 priority 1
neighbor 192.168.1.2 priority 20
!
R0#clear ip os proc
Reset ALL OSPF processes? [no]: yes
After the adjacency, I check the running config and it showed:
router ospf 1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 192.168.1.1 0.0.0.0 area 0
neighbor 192.168.1.3
neighbor 192.168.1.2 priority 1
Then I went to 192.168.1.2
R1(config)#int f0/0
R1(config-if)#ip os pri
R1(config-if)#ip os priority 20
R1(config-if)#end
R1#clear
00:17:54: %SYS-5-CONFIG_I: Configured from console by console ip os proc
Reset ALL OSPF processes? [no]: y
R1#
Went back to R0
router ospf 1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 192.168.1.1 0.0.0.0 area 0
neighbor 192.168.1.3 priority 1
neighbor 192.168.1.2 priority 20
08-19-2009
03:00 PM
- last edited on
01-29-2022
05:06 AM
by
Translator
John,
I am having somewhat different results.
I have two routers connected via s1/0 interfaces, the network type configured to NBMA by command. The relevant configuration:
R1:
interface Serial1/0
ip address 10.0.0.1 255.255.255.0
ip ospf network non-broadcast
ip ospf priority 5
ip ospf 1 area 0
router ospf 1
neighbor 10.0.0.2 priority 200
R2:
interface Serial1/0
ip address 10.0.0.2 255.255.255.0
ip ospf network non-broadcast
ip ospf 1 area 0
router ospf 1
neighbor 10.0.0.1 priority 150
According to the priorities set on interface, the R1 should be the DR while R2 should be the BDR. On the other hand, according to the priorities set in the
neighbor
commands, the R2 should be DR while R1 is the BDR.
When s1/0 interfaces on both routers are shut down, the
show ip ospf nei
gives this output:
R1(config-if)#do show ip ospf n
Neighbor ID Pri State Dead Time Address Interface
N/A 200 ATTEMPT/DROTHER - 10.0.0.2 Serial1/0
R2(config-if)#do show ip ospf n
Neighbor ID Pri State Dead Time Address Interface
N/A 150 ATTEMPT/DROTHER - 10.0.0.1 Serial1/0
The priorities displayed here are taken from the
neighbor
command. However, after the interfaces are brought up and the state is 2WAY, the priorities immediately change back to their values as set on the interfaces:
R1(config-if)#do show ip ospf n
Neighbor ID Pri State Dead Time Address Interface
10.0.0.2 1 2WAY/DROTHER 00:01:54 10.0.0.2 Serial1/0
R2(config-if)#do show ip ospf n
Neighbor ID Pri State Dead Time Address Interface
10.0.0.1 5 2WAY/DROTHER 00:01:50 10.0.0.1 Serial1/0
Note that as soon as the two routers hear and accept each other's Hello packets, the priorities revert to their real values as configured on the interfaces. After the wait period expires, the DR/BDR elections will go by the real priorities, resulting in R1 being the DR and R2 being the BDR, according to the priorities set up on interfaces:
R1(config-if)#do show ip ospf n
Neighbor ID Pri State Dead Time Address Interface
10.0.0.2 1 FULL/BDR 00:01:58 10.0.0.2 Serial1/0
R2(config-if)#do show ip ospf n
Neighbor ID Pri State Dead Time Address Interface
10.0.0.1 5 FULL/DR 00:01:46 10.0.0.1 Serial1/0
From this it follows for me that the priority configured in the
neighbor
command has an effect only until we receive a Hello packet from that neighbor. As soon as we receive and accept a neighbor's Hello packet, we will use its real priority instead of the one defined in the
neighbor
command.
There is an interesting issue: if more
neighbors
are defined, some having a non-zero priority and another having unspecified priority, the router seems to send Hello packets initially only to routers that are preconfigured with non-zero priority. Only after the DR and BDR are elected, the router starts to send Hellos to all neighbors including those with the priority preconfigured to 0:
R1(config-if)#do show run | sec router ospf 1
router ospf 1
log-adjacency-changes detail
neighbor 10.0.0.3 priority 255
neighbor 10.0.0.2
neighbor 10.0.0.4 priority 90
R1(config-if)#do show ip ospf n
Neighbor ID Pri State Dead Time Address Interface
N/A 255 DOWN/DROTHER - 10.0.0.3 Serial1/0
N/A 0 DOWN/DROTHER - 10.0.0.2 Serial1/0
N/A 90 DOWN/DROTHER - 10.0.0.4 Serial1/0
Continuation follows...
08-19-2009 06:57 AM
This is for non-broadcast OSPF type. Since you can have multiple VC on the same physical interface this is where this command comes into play.You can also set the cost per neighbor as well. The Higher the priority the more likely elected DR. 254 would be preferred over 1.
08-19-2009
07:51 AM
- last edited on
01-29-2022
04:38 AM
by
Translator
Thanks for the response John.
Let's assume that we have two routers on FR.
Hub: 192.168.1.1
Spoke: 192.168.1.2
On the hub, I have neighbor 192.168.1.2 priority 1
It's my understanding, and could be wrong, that when the routers announce their presence, they put their priority in the hello packet. If the default is 1, yet I'm telling the hub that the neighbor is 1, I'm not sure that it's doing any good unless I have another neighbor specified with a priority of 2. So, in the above configuration, would I be manipulating the DR election from the hub?
Thanks,
John
08-19-2009 08:12 AM
You are correct with the priority being included into the hello packet...along with who is the DR/BDR, dead interval things like that. Now with your example your telling the HUB router to use priority 2 while the spoke is 1, this will influence the election process to choose the HUB as the DR. One thing to remember is that with a non-broadcast network You want to set every spoke router with a priority of zero and have the HUB be the DR. If the hub goes down you do not want one of the spokes to take over being the BDR since it will not have full connectivity and thus breaking you LSA advertisements...and than the routing domain.... Let me know if you have any more questions
08-19-2009
08:15 AM
- last edited on
01-29-2022
04:39 AM
by
Translator
John,
Good question.
I did a lab on it and found the neighbor will overwrite whatever priority you've entered locally.
router ospf 1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 192.168.1.1 0.0.0.0 area 0
neighbor 192.168.1.3 priority 1
neighbor 192.168.1.2 priority 20
!
R0#clear ip os proc
Reset ALL OSPF processes? [no]: yes
After the adjacency, I check the running config and it showed:
router ospf 1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 192.168.1.1 0.0.0.0 area 0
neighbor 192.168.1.3
neighbor 192.168.1.2 priority 1
Then I went to 192.168.1.2
R1(config)#int f0/0
R1(config-if)#ip os pri
R1(config-if)#ip os priority 20
R1(config-if)#end
R1#clear
00:17:54: %SYS-5-CONFIG_I: Configured from console by console ip os proc
Reset ALL OSPF processes? [no]: y
R1#
Went back to R0
router ospf 1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 192.168.1.1 0.0.0.0 area 0
neighbor 192.168.1.3 priority 1
neighbor 192.168.1.2 priority 20
08-19-2009
08:37 AM
- last edited on
01-29-2022
05:02 AM
by
Translator
Edison,
Thank you for looking at this! After all of this, I set up a FR lab in gns and I noticed that the interface priority from a remote router will override a hub router
neighbor
statement (like you just showed).
Below is a hub router with a
neighbor
statement and priority of 20. The remote router is left at the default priority:
Toro#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
20.20.20.1 20 ATTEMPT/DROTHER 00:01:37 192.168.1.2 Serial0/0
I configured the remote routers serial interface with a priority of 5, but I left the priority of 20 on the neighbor statement on this router:
Toro#sh ip ospf neigh
Neighbor ID Pri State Dead Time Address Interface
20.20.20.1 5 2WAY/DROTHER 00:01:37 192.168.1.2 Serial0/0
So it does look like a remote router can override what the local router wants to set it at. Cool.
Thanks!
John
08-19-2009 08:46 AM
Awesome!! Im glad that you labbed it up..I tend to do this as well and run some debugs to fully understand whats happening...Reminds me of when I was studying for my CCIE :) good work!!
08-19-2009
09:38 AM
- last edited on
01-29-2022
05:04 AM
by
Translator
Hello everyone,
This all leads to a question: what is the priority setting in the
neighbor
command good for if it always gets updated dynamically according to that
neighbor's
real priority?
I have an idea but I have to test it. And I would love to hear your opinions.
Best regards,
Peter
08-19-2009
10:03 AM
- last edited on
01-29-2022
04:42 AM
by
Translator
What the command does is give the neighbor "that" priority upon the
neighbor-ship exchange
thus, Making the router the DR (if higher priority)..If you lab it up you can see during the 2-way the priority will show whats under the
neighbor
command...and than switch to the interface priority.
08-19-2009
03:00 PM
- last edited on
01-29-2022
05:06 AM
by
Translator
John,
I am having somewhat different results.
I have two routers connected via s1/0 interfaces, the network type configured to NBMA by command. The relevant configuration:
R1:
interface Serial1/0
ip address 10.0.0.1 255.255.255.0
ip ospf network non-broadcast
ip ospf priority 5
ip ospf 1 area 0
router ospf 1
neighbor 10.0.0.2 priority 200
R2:
interface Serial1/0
ip address 10.0.0.2 255.255.255.0
ip ospf network non-broadcast
ip ospf 1 area 0
router ospf 1
neighbor 10.0.0.1 priority 150
According to the priorities set on interface, the R1 should be the DR while R2 should be the BDR. On the other hand, according to the priorities set in the
neighbor
commands, the R2 should be DR while R1 is the BDR.
When s1/0 interfaces on both routers are shut down, the
show ip ospf nei
gives this output:
R1(config-if)#do show ip ospf n
Neighbor ID Pri State Dead Time Address Interface
N/A 200 ATTEMPT/DROTHER - 10.0.0.2 Serial1/0
R2(config-if)#do show ip ospf n
Neighbor ID Pri State Dead Time Address Interface
N/A 150 ATTEMPT/DROTHER - 10.0.0.1 Serial1/0
The priorities displayed here are taken from the
neighbor
command. However, after the interfaces are brought up and the state is 2WAY, the priorities immediately change back to their values as set on the interfaces:
R1(config-if)#do show ip ospf n
Neighbor ID Pri State Dead Time Address Interface
10.0.0.2 1 2WAY/DROTHER 00:01:54 10.0.0.2 Serial1/0
R2(config-if)#do show ip ospf n
Neighbor ID Pri State Dead Time Address Interface
10.0.0.1 5 2WAY/DROTHER 00:01:50 10.0.0.1 Serial1/0
Note that as soon as the two routers hear and accept each other's Hello packets, the priorities revert to their real values as configured on the interfaces. After the wait period expires, the DR/BDR elections will go by the real priorities, resulting in R1 being the DR and R2 being the BDR, according to the priorities set up on interfaces:
R1(config-if)#do show ip ospf n
Neighbor ID Pri State Dead Time Address Interface
10.0.0.2 1 FULL/BDR 00:01:58 10.0.0.2 Serial1/0
R2(config-if)#do show ip ospf n
Neighbor ID Pri State Dead Time Address Interface
10.0.0.1 5 FULL/DR 00:01:46 10.0.0.1 Serial1/0
From this it follows for me that the priority configured in the
neighbor
command has an effect only until we receive a Hello packet from that neighbor. As soon as we receive and accept a neighbor's Hello packet, we will use its real priority instead of the one defined in the
neighbor
command.
There is an interesting issue: if more
neighbors
are defined, some having a non-zero priority and another having unspecified priority, the router seems to send Hello packets initially only to routers that are preconfigured with non-zero priority. Only after the DR and BDR are elected, the router starts to send Hellos to all neighbors including those with the priority preconfigured to 0:
R1(config-if)#do show run | sec router ospf 1
router ospf 1
log-adjacency-changes detail
neighbor 10.0.0.3 priority 255
neighbor 10.0.0.2
neighbor 10.0.0.4 priority 90
R1(config-if)#do show ip ospf n
Neighbor ID Pri State Dead Time Address Interface
N/A 255 DOWN/DROTHER - 10.0.0.3 Serial1/0
N/A 0 DOWN/DROTHER - 10.0.0.2 Serial1/0
N/A 90 DOWN/DROTHER - 10.0.0.4 Serial1/0
Continuation follows...
08-19-2009
03:01 PM
- last edited on
01-29-2022
04:52 AM
by
Translator
Note the messages from the
debug ip packet
:
*Mar 1 00:01:59.999: IP: s=10.0.0.1 (local), d=10.0.0.3 (Serial1/0), len 76, sending
*Mar 1 00:02:00.003: IP: s=10.0.0.1 (local), d=10.0.0.4 (Serial1/0), len 76, sending
*Mar 1 00:02:00.011: IP: tableid=0, s=10.0.0.2 (Serial1/0), d=10.0.0.1 (Serial1/0), routed via RIB
*Mar 1 00:02:00.015: IP: s=10.0.0.2 (Serial1/0), d=10.0.0.1 (Serial1/0), len 56, rcvd 3
*Mar 1 00:02:00.019: IP: tableid=0, s=10.0.0.2 (Serial1/0), d=10.0.0.1 (Serial1/0), routed via RIB
*Mar 1 00:02:00.023: IP: s=10.0.0.2 (Serial1/0), d=10.0.0.1 (Serial1/0), len 56, rcvd 3
*Mar 1 00:02:29.999: IP: s=10.0.0.1 (local), d=10.0.0.3 (Serial1/0), len 76, sending
*Mar 1 00:02:30.003: IP: s=10.0.0.1 (local), d=10.0.0.4 (Serial1/0), len 76, sending
Note that the Hello packets are sent only to 10.0.0.3 and 10.0.0.4 that are currently configured with a non-zero priority. The router does not send Hellos to the 10.0.0.2 which is currently configured with the priority of 0. Only after the DR/BDR are elected, we start sending Hellos also to the 10.0.0.2. This rule does not apply if all
neighbors
are configured with unspecified (i.e. zero) priority as that would be a deadlock - we would not send Hello packets to anybody.
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. Obviously, this is also the reason why no
neighbors
appear in configuration of a spoke router whose interface priority has been set to 0 - to effectively prevent it from sending any Hellos first. Yet the priorities in the
neighbor
command do not really play a role in DR/BDR elections - they only define which
neighbors
should be initially contacted, but the outcome of the DR/BDR election will be always based upon the real priorities set up on interfaces.
Jee, this is a lengthy post... I'm shutting up.
Best regards,
Peter
08-19-2009
04:07 PM
- last edited on
01-29-2022
04:53 AM
by
Translator
Wow, Thanks peter...I stand corrected
neighbor
command on the spoke router..Just the hub since its not needed. When I labbed it up I came up with during
neighbor
initialization it would use the priority and than change back. I used the default priority on the HUB and set the priority for the
neighbor
. The result were as expected where the Spoke would always become DR....I played around with priorities on both sides for a little bit..changing interface priority and such....Looks like ill have to play around some more with it. This is a real interesting command and have never really used it to tell you the truth.
08-19-2009
04:15 PM
- last edited on
01-29-2022
04:56 AM
by
Translator
When in Doubt.....DOC-CD
To configure Open Shortest Path First (OSPF) routers interconnecting to nonbroadcast networks, use the
neighbor
command in router address family topology or router configuration mode. To remove a configuration, use the no form of this command.
neighbor ip-address [priority number] [poll-interval seconds] [cost number] [database-filter all]
no neighbor ip-address [priority number] [poll-interval seconds] [cost number] [database-filter all]
priority number
(Optional) A number that indicates the router priority value of the nonbroadcast neighbor associated with the IP address specified. The default is 0. This keyword does not apply to point-to-multipoint interfaces.
Peter what do you think? Sounds pretty straight forward to me but seems like we are getting mixed results...
08-20-2009 06:49 AM
Hi John,
You are saying we are getting mixed results. Can you please elaborate? I am slightly lost what your results were. Could you please summarize them up?
Best regards,
Peter
08-20-2009
06:54 AM
- last edited on
01-29-2022
04:58 AM
by
Translator
Sorry, I didn't capture them but this is what I saw,
With the priority statement on the
neighbor
command that device always became the DR, even with a loopback configured on the other device and the interface priorities the same. So from what I saw, The
priority
command does impact the DR/BDR election.
Nevermind after looking back at your results You never said it didn't help the DR/BDR election. You concluded it does, but for those that have the
neighbor
command. sorry for the confusion.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide