OSPF Router ID

Lessons Discussion
21

Hi everyone, I have a question on manually setting the RID. Is there a conflict if a RID Ip is being used somewhere else in the area? Or is it only locally significant to the neighbors?

22

Hello Mario

The Router ID of an OSPF router must be unique within an OSPF autonomous system, including all associated OSPF areas of that autonomous system (AS). This is described in RFC2328 as shown below:

Router ID
A 32-bit number assigned to each router running the OSPF
protocol. This number uniquely identifies the router within
an Autonomous System.

and

Router ID
A 32-bit number that uniquely identifies this router in the AS.
One possible implementation strategy would be to use the
smallest IP interface address belonging to the router. If a
router’s OSPF Router ID is changed, the router’s OSPF software
should be restarted before the new Router ID takes effect. In
this case the router should flush its self-originated LSAs from
the routing domain (see Section 14.1) before restarting, or they
will persist for up to MaxAge minutes.

Now, to your specific question. If you are manually configuring the RID, then that RID must be unique among the RIDs in the AS. You can actually configure an IP address of 192.168.1.5 on R1, and an OSPF RID on R2 of 192.168.1.5 as long as R1 doesn’t use that IP as an RID.

So RIDs must be unique among themselves, and IP addressing (obviously) must be unique among themselves. However, RIDs and IP addresses of interfaces do not have to be unique (unless you use those IP addresses as RIDs).

In any case, it’s always best practice to manually configure RIDs and use IP addresses that are completely different than those used for actual interfaces in order to avoid confusion, or misconfigurations.

I hope this has been helpful!

Laz

23

Hi Reene,

What happens when you a duplicate router id is detected in your OSPF network? let’s say one of my important DC router has router id - 1.1.1.1 & it has BGP running on the router? we setup a remote site in same area(area 0)? we saw an outage but I want to know whats the correct reason for outage?

24

Hello Sampath

The router ID in OSPF is used to identify routers in the OSPF database as well as to create OSPF neighbor adjacencies. If you have two routers with the same router ID in your OSPF domain, then this will result in unpredictable routing and almost certainly in intermittently unreachable networks.

Imagine you have a network where R1 and R2 are using the same router ID. When R3 receives OSPF packets from these two routers, it will interpret all the received information as coming from the same OSPF device. This can result in:

  1. R3 continually creating and tearing down neighbor adjacencies with R1 and R2 as it receives OSPF hello packets with the same router ID on two different interfaces.
  2. The routes learned by R3 from R1 and R2 are identified as routes coming from a single router, so the next hop IP will be incorrect for some of them.
  3. Router IDs are also used for virtual links, so having duplicate router IDs will cause this feature to fail.

I hope this has been helpful!

Laz

25

Hi…

You wrote the following

  • My question is where is the problem here because I didn’t get it?

  • I mean where is the problem of that the new highest Loopback IP address becoming the new Router-ID?

Thanks

26

Hello Ameen

The OSPF router ID is chosen based on the process described in this NetworkLessons note:
https://notes.networklessons.com/ospf-router-id

Now let’s say that you have configured your OSPF router with a loopback interface with an IPv4 address of 5.5.5.5, and that router has chosen the IP address of the loopback as the router ID.

Several months down the road, a new administrator was hired, and he decides to configure another feature on the router that requires the addition of a loopback interface. Let’s say he creates a new loopback with an IP address of 10.10.10.10. All of a sudden, OSPF will choose that as the new router ID. The OSPF topology will become unstable, and no one will know why. It’s not readily perceivable.

For this reason, it is best practice to use the router-id command in the OSPF router configuration mode to configure the router ID. That way, no changes to any loopback interfaces will cause disruptive changes.

I hope this has been helpful!

Laz

1 Like
27

Thank you so much for the explanation.

1 Like
28

What will happen if we configure the same Router IDs on an indirectly connected neighbor within an area? Do the link state ID and advertising Router IDs from LSAs not cause any issue? I tried this scenario by configuring R1 → R2 → R3 where the router IDs are same on R1 and R3. Initially, when the router IDs were different, I was able to ping the IP address of R3 from R1. From the debugs I could see the neighbors were in full adjacency. When the same router IDs were configured, R3 removed the route to R1. But after a while, the route randomly appeared again.

R3(config-router)#ri      
R3(config-router)#ro
R3(config-router)#router-id 1.1.1.1
R3(config-router)#netw
R3(config-router)#network 192.168.23.0 0.0.0.255 area 0
R3(config-router)#
*Aug 20 21:07:35.359: %OSPF-5-ADJCHG: Process 2, Nbr 192.168.23.2 on GigabitEthernet0/0 from LOADING to FULL, Loading Done

R3#sh ip route
Gateway of last resort is not set

      192.168.23.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.23.0/24 is directly connected, GigabitEthernet0/0
L        192.168.23.3/32 is directly connected, GigabitEthernet0/0

R3#sh ip os
 Routing Process "ospf 1" with ID 1.1.1.1
 Start time: 00:00:08.960, Time elapsed: 00:15:08.932

R3#sh ip route
Gateway of last resort is not set

O     192.168.12.0/24 [110/2] via 192.168.23.2, 00:13:44, GigabitEthernet0/0
      192.168.23.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.23.0/24 is directly connected, GigabitEthernet0/0
L        192.168.23.3/32 is directly connected, GigabitEthernet0/0
R3#ping 192.168.12.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.1, timeout is 2 seconds:
!!!!!

R1#ping 192.168.23.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.23.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/24 ms
R1#sh ip ospf
 Routing Process "ospf 1" with ID 1.1.1.1

I expected it get stuck in loading state when exchanging the LSAs as they might see same router IDs from different routers on the LSAs

29

Hello Gokul

If you have two routers with the same router ID that are directly connected, they will never become neighbors. However, as stated in the lesson, if you have two routers that are not directly connected in the same area, as in the example you described, then adjacencies will form. However, this situation is not ideal. You will see that the SPF algorithm will continually be run as OSPF will try to reconverge. This is because LSAs contain within their contents the router ID of the generating router. If that router ID appears in the OSPF database in multiple LSAs, this results in the SPF algorithm being run continuously which will in turn cause flapping OSPF routes.

Take a look at this Cisco documentation on troubleshooting duplicate OSPF router IDs in a topology for more information.

I hope this has been helpful!

Laz

1 Like
30

Hello Guys,

I have an OSPF lab in PacketTracer. I first configured my neighbors without any Loopback. Then i configured a loopback and restarted the OSPF process but the RID is not changing. The only way to change the RID is to statically configure. Is that a normal behavior or a PacketTracer issue?

Thanks,

31

Hello David

That sounds interesting. I tried labbing this up in Packet Tracer and found the same issue. I’m using Packet Tracer Version 8.0.0.0212.

I also found that once the router chooses the router ID, it cannot be changed even if you do a clear ip ospf process. Even when I manually configured the router ID, and then removed it, the manually configured router ID remained.

From my experimentation, I found that in order for OSPF to change the router ID, you must either reload the router, or delete the OSPF configuration and reinstate it.

At first I believed this was a bug, but for completeness, I tried the same thing on Cisco CML. It had the same behavior! :open_mouth:

What I have found is this:

  1. When the router ID has been chosen as the IP address of a physical interface, even if you create a loopback interface and clear the OSPF process, the router ID will not change. You must either reboot the machine or delete and recreate the OSPF config.
  2. When the router ID has been chosen as the IP address of a loopback, even if you create a new loopback with a higher IP address, clearing the OSPF process will not change the router ID. The only way it will change is if you delete the loopback interface or change its IP address to something else.
  3. When creating, changing, or deleting a manually configured router ID, the router ID will change after clearing the OSPF process.

Notice that it is only when you create, change or delete the router ID that you get the following message from the console:

% OSPF: Reload or use "clear ip ospf process" command, for this to take effect

So it seems that packet tracer is recreating the behavior of OSPF router IDs correctly. This has been interesting, thanks for pointing this out!

I hope this has been helpful!

Laz

1 Like
32

Thank you for the detailed information.

I have one question, even if he configures the new loopback IP to be higher than the existing one. All of a sudden, it won’t take the new LB IP as RID until he clears the IP ospf process, right?

33

Hello Sathish

Yes, you are correct, it won’t happen “all of a sudden.” Actually, such a change will not immediately affect the OSPF topology at all!! You can see the details of when an OSPF router ID actually changes and when this affects the OSPF topology in this NetworkLessons note.

However, at some point, the router will be rebooted, the OSPF process will be cleared, or some other event will take place that will obligate the router to update its router ID. When this happens it will cause the OSPF process to reconverge, resulting in an instability in the topology. And the point is that administrators will not know why, because the router ID was inadvertently and unknowingly changed simply because another loopback was added.

The underlying concept remains, that the best practice is to explicitly assign the OSPF router ID in order to avoid such situations. However, thank you for pointing out the details of how this process will actually play out when applied in a production environment.

I hope this has been helpful!

Laz