Ospf nbma "neighbor x.x.x.x priority x"

EdTheLad

I don't see the use in this command, by setting the priority to 0, you can delay sending hello's to a neighbor, but the remote neighbor's interface priority will still take precedence and influence the election.
Anyone have any idea what this command can be used for?

tomtom1

Indeed, labbed this out and the remote link will override this. Interested to see the answer!

Dieg0M

Not sure what you mean. Priority 0 in a hub and spoke topology will prevent the spoke to become DR. Make sure you have it configured on both sides (Hub and spoke) or this command will be overwritten.

FloOz

Yeah but whats the point of putting it on both sides when the ospf priority 0 command is only needed on the spoke.

EdTheLad

Exactly, we all know about setting the priority to 0 on the spoke interface to stop it participating in the election. The question is in regards to the hub and using the priority on the neighbor statement. With NBMA, the neighbor statement is only required on one end of the connection, usually on the hub to maintain a tidy config.
Setting the neighbor priority to > 1 doesn't seem to do anything, the received hello will have a priority in its packet which will override the configured hello.

I noticed when i had 4 neighbors, 2 with 0 priority and 2 with > 1 , hello's were sent to the 2 with priority > 1 . The DR was elected database exchanged and once synchronization complete, the hub sent hello's to the 2 neighbors with 0 priority.

One of those delayed neighbors eventually became the DR due to spoke interface priority being the highest on the subnet. So delaying the hello exchange didn't change the end result.

It's funny playing with this as you can see the designated election isn't exactly non preemptive. Without the neighbor statements configured the spoke interface is up but no communicating with the hub, because it's interface is up, it becomes a DR for the network. So when you configure the neighbor statement you effectively have 2 DRs on the local subnet and one will takeover, hence preemptive. The preemptive behavior only works on ospf initialization.

To make it even clearer, in the lab your asked to manipulate the DR election without modifying any RIDs or spoke config. Straight away i'd be thinking priority on the hub neighbor statement.

Dieg0M

Ed the neighbor command is used in a NBMA network only. If you are using it in a broadcast network, the hub will send the priority of 0 to the spoke and the spoke will indeed overwrite it with its local priority.

Fl0oz, the ospf priority 0 only works in broadcast networks.

EdTheLad

I'm talking about NBMA, why don't you lab it up and you will see what i'm talking about.

EdTheLad

Dieg0M wrote: »

Fl0oz, the ospf priority 0 only works in broadcast networks.

That's not correct, it works with nbma too, with a hub and spoke you need to ensure the spokes don't become dr/bdr.

FloOz

Hmmm yeah I agree with Ed. I swear I labbed this last week and I used it on the spokes in an NBMA network

Dieg0M

If you use the ospf priority command in an NBMA network, it will only set the priority locally. So if you use this command on a spoke with the priority 0, it will indeed never be eligble for DR election. This is because multicast is not allowed unless you configure the broadcast command on frame-relay map. That is why you need to configure the neighbor command in a NBMA network, to allow it to use unicast to the neighbor instead. The OSPF priority command always overwrites the neighbor priority command locally but in a NBMA network the OSPF priority does not have any effect on its neighbors.

EdTheLad

You are talking about 2 different things here. Firstly NBMA means non-broadcast hence the broadcast ability is not present due to no broadcast keyword applied on FR dlci. So in this case no hello's can be sent until one side is configured with the neighbor command, as the neighbor command is used to modify the hello from multicast to unicast. This has nothing to do with my question as it's fundamental nbma behavior.

Now for the priority issue.

When you configure ospf priority on an interface that priority is written to the hello packet priority field of egress hello packets. If i have a hub and spoke topology it's desired to have the hub as the DR and the spokes as DRother. If a spoke became DR or BDR it would break the network as the spoke doesn't have full connectivity. To achieve this the most common way is to configure the interface ospf priority on the spokes to 0.

Now back to the original question: What does the "neighbor x.x.x.x priority x" command achieve? We'll i've seen that when you set the neighbor priority to 0 for a spoke in a multi spoke environment, the neighbor with 0 priority does not take part in the DR election, essentially the hub will not send out a unicast hello for that neighbor until the other neighbors with non 0 neighbor priorities have elected a DR.

If all the spokes have a neighbor priority greater than 0, all spokes participate in the DR election process i.e. the hub unicasts hello's to all spokes during the election process. The only reason i can see to set the priority greater than zero is for faster convergence, the hub doesn't have to wait for the WAIT timer to expire before unicasting hello's.

If all spokes are configured with the neighbor command without specifying priority they will default to priority 0. This means the hub will be elected DR which is desired. There is one catch here: the spokes must not become DRs before receiving the first unicast hello from the hub, this is where the WAIT time becomes important.The WAIT time interval is equal to the dead time interval which by default is 120 sec on a nbma. If the spokes become DR before receiving the initial hello from the hub, and the spoke has higher priority/RID it can preempt the hub and become the DR for the subnet.

Lets say you have 1 hub and 2 spokes, R1,R2 and R3, R3 is the hub. You have a non-broadcast environment but initially configure ospf without using the neighbor command. No hello's will be sent between hub and spokes, each router will have an isolated interface on the subnet and therefore after the WAIT timer expires each router will declare itself as DR on the subnet. Eventually you get around to adding the neighbor command which will cause the hub to unicast it's hello to the spokes and the spokes reply with unicast hello's. The hello from R1 will have R1 as DR, the hello from R2 will have R2 as DR and same for R3. The router with the highest priority or if equal, highest RID will become DR for the subnet. This explains how ospf DR can be preempted.

Now looking at the same topology again, lets say you configure ospf on the hub only, the hub interface becomes DR, you then add the neighbor commands to the hub and configured the spokes. Once the spoke is configured it's interface will start the WAIT timer, if a hello is received from the hub before the spoke WAIT timer expires the spoke will accept the hub as the DR and hence will not preempt the DR even if it has a higher priority.In the first case the spoke could preempt the hub as the WAIT timer had already expired.

So what i've seen is that using the "neighbor x.x.x.x priority x" command give's you the ability to select which routers participate in the DR election. The recommended config for hub and spoke would be setting all spokes with neighbor priority 0. But in order for this to work you need a large WAIT timer, if the WAIT timer is small the spoke can become DR before receiving the initial hello from the hub, if that happens the spoke can preempt the DR and setting the priority to 0 on the hub will have meant nothing. In my opinion using the neighbor priority command is too unpredictable as it's highly dependent on timing, it's much safer to use the interface priority.

I found this interesting even if you didn't lol.

Dieg0M

Yes, it is much safer to use the interface priority and that is why it is the recommended option to set up a hub and spoke topology. Still, you should know as a CCIE candidate that you will need different commands to accomplish different tasks. I'm sorry that you think I didn't find this interesting but I already went over this discussion with an engineer at work. We were trying to figure out how ospf priority overwrites neighbor priority and what it does exactly.