OSPF Router-ID

OSPF is a link-state routing protocol.  That makes it vastly superior to EIGRP (go ahead and comment!)  Each node requires a unique ID, which is just a 32-bit number.  It’s unfortunate that Cisco routers (and other vendors) represent it as a dotted decimal number so it looks just like an IP address.  That’s the start of the confusion.

Here’s an example of the problem.  The show ip ospf database router command is the starting point for inspecting the configuration of the network.  In this truncated output we have one router with one loopback address and one stub network of 10.40.1.0/24.

Router#show ip ospf database router
            OSPF Router with ID (10.40.0.1) (Process ID 1)
                Router Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 1798
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 10.40.0.1
  Advertising Router: 10.40.0.1
  LS Seq Number: 80009BCC
  Checksum: 0xA5A5
  Length: 60
  AS Boundary Router

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.40.0.1
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.40.1.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

Without manually specifying a router-id the router will just select the highest IP address assigned to an interface.  That’s not stable (interface addresses can change) so Cisco will select an available loopback address before selecting an address from other interfaces.  That makes the process a little more deterministic.

Problem 1:
The loopback address gets added to the database as a stub network (as you can see in the above output as 10.40.0.1/32.)  If you’re running a network with n number of routers that’s n additional stub networks in your database.  That’s not a big deal; we have lots of DRAM in modern day routers.  It’s bad in a sense that a good engineer likes things clean, concise and minimal.  It also makes it more difficult if you are searching through the database to confirm its proper operation (or searching for a problem.)

Yes, I know sometimes you need a loopback address anyway, e.g., BGP peering, GRE source addresses, etc.  Yes, I know you can selectively run the OSPF process on certain interfaces and not select the loopback.  That potentially means multiple network statements instead of one, which sometimes creates more complexity than necessary.

Problem 2:
The router-id looks like an IP address!  Furthermore, it matches one of our stub networks.  This was quite confusing for me when I first started working with the OSPF show commands.  It could have been displayed as 170,393,601 or 0x10400001, which would have been the same 32-bit number.  Instead, they decided to be confusing.

Solution:
We can specify the router-id manually.  Plenty of network nerds have found this command but let’s use it to do something creative.  We can’t configure an interface with the address 0.0.0.1/24 (RFC 5735) but we can use that 32-bit number as a router-id.  Now the output looks like the following.

Router#show ip ospf database router
            OSPF Router with ID (0.0.0.1) (Process ID 1)
                Router Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 1798
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 0.0.0.1
  Advertising Router: 0.0.0.1
  LS Seq Number: 80009BCC
  Checksum: 0xA5A5
  Length: 60
  AS Boundary Router
  Number of Links: 3

   Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.40.1.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

It pops.  You can visually pick out quickly what part of the output is the router-id and what part is referencing the networks.   We also lost that pesky loopback address from the database.  Clean.

Operational Surprise #1
Can we use 0.0.0.0 as a router-id?  It would be nice to start at the beginning.  Nope.  Invalid.

Operational Surprise #2
Some vendors are not as permissive as Cisco for router-id.  I just worked with a vendor who was using the HP A7500 switches.  This switch is from the 3Com acquisition.  I asked the vendor to use router-id 0.0.0.2, which the A7500 said was invalid.  We unfortunately had to use router-id 1.0.0.2 and it worked fine.

Summary
So far these “weird” looking router-ids work great.  I’ve used them on Cisco Layer-3 switches and the ASA5500 platforms without a hitch.  Does anyone else have any insights on their use?