OSPF neighbor priority

Answered Question
Aug 19th, 2009
User Badges:
  • Purple, 4500 points or more

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

Correct Answer by Peter Paluch about 7 years 10 months ago

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...

Correct Answer by Edison Ortiz about 7 years 10 months ago

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


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
johnspaulding Wed, 08/19/2009 - 06:57
User Badges:

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.

John Blakley Wed, 08/19/2009 - 07:51
User Badges:
  • Purple, 4500 points or more

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

johnspaulding Wed, 08/19/2009 - 08:12
User Badges:

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

Correct Answer
Edison Ortiz Wed, 08/19/2009 - 08:15
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

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


John Blakley Wed, 08/19/2009 - 08:37
User Badges:
  • Purple, 4500 points or more

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

johnspaulding Wed, 08/19/2009 - 08:46
User Badges:

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!!

Peter Paluch Wed, 08/19/2009 - 09:38
User Badges:
  • Cisco Employee,

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

johnspaulding Wed, 08/19/2009 - 10:03
User Badges:

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.

Correct Answer
Peter Paluch Wed, 08/19/2009 - 15:00
User Badges:
  • Cisco Employee,

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...

Peter Paluch Wed, 08/19/2009 - 15:01
User Badges:
  • Cisco Employee,

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


johnspaulding Wed, 08/19/2009 - 16:07
User Badges:

Wow, Thanks peter...I stand corrected :) The only difference is I did not specify a 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.

johnspaulding Wed, 08/19/2009 - 16:15
User Badges:

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...

Peter Paluch Thu, 08/20/2009 - 06:49
User Badges:
  • Cisco Employee,

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


johnspaulding Thu, 08/20/2009 - 06:54
User Badges:

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.


Peter Paluch Thu, 08/20/2009 - 07:02
User Badges:
  • Cisco Employee,

Hi John,


If possible, can you post here the configurations you've used? I'll try to reproduce the experiment. Let's see what happens.


Best regards,

Peter


johnspaulding Thu, 08/20/2009 - 07:03
User Badges:

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.

Actions

This Discussion