OSPF RID Question

Scott Pickles · ‎03-01-2010

I configured a couple of routers in my lab on an ethernet broadcast segment. I didn't blow away one router config and it still had an interface configured for 192.168.1.1. I added a network between the two routers (R1 and R5) of 15.1.1.0 /24 and placed two interfaces into area 0. I also added some loops (R1 is 1.1.1.1 and R5 is 5.5.5.5) to area 0. So when the neighbor relationship formed, R1 indicated that its neighbor's RID was 192.168.1.1. This didn't make any sense to me at all since a loopback interface, part of the OSPF process or not, always takes precedence for RID over an active physical interface (again, part of OSPF or not). So I shut the interface down and cleared the process on both routers. The neighbor RID of 192.168.1.1 persisted. It wasn't until I went into R5 and REMOVED the ip address on the interface and reset the process on both routers that it finally showed the correct neighbor ID of 5.5.5.5 (according to the RID rules). Attached is output of the occurrance on my routers. Anyone care to take a guess as to what was going on? It's important to me because I thought for sure I had a solid understanding of the RID rules as follows:

DR/BDR Election

1. Highest priority wins - priority is '1' by default on all routers, so we need a tie breaker...highest RID

2. RID breaks down thusly:

A. Configuration of 'router-id' on the OSPF process has highest weight

B. Highest Loopback interface configured, active, and part of the OSPF process or not

C. If no active Loopbacks, highest active physical interface configured (again, part of the OSPF process or not)

So I could see how what I experienced would be correct if it were the fact that it didn't matter if the interface was up or not. But my understanding was always that if the interface was administratively shutdown that it wouldn't be considered.

Regards,

Scott

Ganesh Hariharan · ‎03-01-2010

I configured a couple of routers in my lab on an ethernet broadcast segment. I didn't blow away one router config and it still had an interface configured for 192.168.1.1. I added a network between the two routers (R1 and R5) of 15.1.1.0 /24 and placed two interfaces into area 0. I also added some loops (R1 is 1.1.1.1 and R5 is 5.5.5.5) to area 0. So when the neighbor relationship formed, R1 indicated that its neighbor's RID was 192.168.1.1. This didn't make any sense to me at all since a loopback interface, part of the OSPF process or not, always takes precedence for RID over an active physical interface (again, part of OSPF or not). So I shut the interface down and cleared the process on both routers. The neighbor RID of 192.168.1.1 persisted. It wasn't until I went into R5 and REMOVED the ip address on the interface and reset the process on both routers that it finally showed the correct neighbor ID of 5.5.5.5 (according to the RID rules). Attached is output of the occurrance on my routers. Anyone care to take a guess as to what was going on? It's important to me because I thought for sure I had a solid understanding of the RID rules as follows:

DR/BDR Election

1. Highest priority wins - priority is '1' by default on all routers, so we need a tie breaker...highest RID

2. RID breaks down thusly:

A. Configuration of 'router-id' on the OSPF process has highest weight

B. Highest Loopback interface configured, active, and part of the OSPF process or not

C. If no active Loopbacks, highest active physical interface configured (again, part of the OSPF process or not)

So I could see how what I experienced would be correct if it were the fact that it didn't matter if the interface was up or not. But my understanding was always that if the interface was administratively shutdown that it wouldn't be considered.

Regards,

Scott

Hi Scott,

Genrally OSPF router ID selection is based on the following steps:-

If the router-id is specified in the OSPF configuration, the specified IP address is used. If the IP address configured with the router-id command overlaps with the router ID of another already active OSPF process, the router-id command fails.

If OSPF router ID was not set with the router-id configuration command (no router-id command was used in the OSPF configuration or there was a router ID overlap with another OSPF process), OSPF uses an interface IP address as its router ID.

The following algorithm is used to select an interface IP address as the OSPF router ID:

* IP addresses of all applicable loopback interfaces are collected. Addresses already used as OSPF router ID of other OSPF processes are removed. If any addresses are left, the highest IP address is used as the OSPF router ID.

* If the OSPF router ID has not been selected in the first step, IP addresses of all other applicable interfaces are collected. OSPF router IDs of active OSPF processes are removed from the list and the highest IP address is used.
* If the router was still not able to select an OSPF router ID, an error message is logged and the OSPF process does not start.

An OSPF process that failed to select a router ID retries the selection process every time an IP address becomes available (an applicable interface changes its state to up or an IP address is configured on an applicable interface).

If you have an (enabled) loopback interface configured on the router, its IP address will always be used as the OSPF router ID,then answers will be actually saying each OSPF process running on the router needs a unique Router ID. If you have a single loopback interface and two OSPF processes, the second OSPF process is forced to select another interface address as its router ID.

Hope to Help !!

Ganesh.H

Jon Marshall · ‎03-01-2010

Scott

Some of the documentation is not right on this. If the interface is shutdown then the router will continue to use that IP address as the OSPF router-id. If you then configure a loopback interface with a higher IP the router will still use it's existing RID. The RID won't change until you restart the OSPF process on the router concerned.

That is why it is often a good idea to use the "router-id" command under the router ospf config.

Jon

Kevin Dorrell · ‎03-02-2010

One thing to remember about the OSPF rid, is that it is not actually an IP address at all, but an arbitrary 32-bit number, expressed as 4 dotted-decimals. OK, if there is no configured value, the Cisco implementation derives it from the IP addresses on the router. But it is not actually used as an IP address at all. In fact, if you configure it manually, you can use any arbitrary value you like.

One of the problems with the early Cisco implementation was that the way it chose this arbitrary value was too dependent on whether interfaces were up or down, and whether they were part of the IP process. So OSPF networks tended to be a bit unstable. Nowadays, once the router has decided on the rid, it does its best to stick to it, even if the corresponding interface goes down.

Personally, I prefer to nail down the rid manually to some value related to the function of the router: for example 1.1.1.1 for R1, 2.2.2.2 for R2, etc. In fact, I find it helps not to have the rid related to an IP address. That way I can immediately see in the show outputs which values are RIDs and which are IP addresses.

Kevin Dorrell

Luxembourg