cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
16972
Views
16
Helpful
16
Replies

OSPF neighbor priority

John Blakley
VIP Alumni
VIP Alumni

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

HTH, John *** Please rate all useful posts ***
2 Accepted Solutions

Accepted Solutions

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


View solution in original post

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

View solution in original post

16 Replies 16

johnspaulding
Level 1
Level 1

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.

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

HTH, John *** Please rate all useful posts ***

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

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


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

HTH, John *** Please rate all useful posts ***

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

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

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.

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

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

 

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.

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

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

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.

 

Getting Started

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:

Review Cisco Networking products for a $25 gift card