Skip to content

OSPF Router-ID

2011/10/21

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?

Advertisements
6 Comments leave one →
  1. 2011/10/24 15:17

    It’s no different from the 32-bit area ID, which is displayed on any sane network OS in dotted-decimal notation also.

    Dumping the router ID into the RIB as a stub network is an idiotic idea – I’ll have to remember this if I’m ever stuck working on Cisco routers again.

    And unless your loopback addresses are very deterministic (eg. you can tell exactly what router you’re looking at, based on its loopback), you should *always* be setting your router ID manually. Hell, set it manually regardless.

    Thanks for the article.

    • 2011/10/25 12:30

      “Dumping the router ID into the RIB as a stub network is an idiotic idea”

      That’s the way I read this post too… Fortunately, it’s not what happens, and I don’t think it’s what Dan meant. The loopback interface (which the router ID could be based on) gets added to the router (type 1) LSA as a stub network *IF* that loopback interface has been added to the OSPF process. There’s nothing funny going on here. The behavior is required by RFC1583 12.4.1.

      “And unless your loopback addresses are very deterministic (eg. you can tell exactly what router you’re looking at, based on its loopback)”

      That’s a pretty common practice, isn’t it? I generally set things up this way: I know my routers by loopback interface, create DNS records referencing the loopback interface, ensure that management traffic is sent to / sourced from that interface, write firewall rules referencing the loopback interface, etc…

      The fact that the router ID is selected to match the Loopback interface *I*already*know* is a bonus at this point. The only exceptions are networks where I’m resource constrained to the point that loopback interfaces are a luxury I can’t afford.

  2. 2011/10/24 17:29

    I’d guess that 0.0.0.0 is bogus because of the DR election mechanism.

    Segments with DR or BDR of 0.0.0.0 need to hold a DR election. A real router numbered 0.0.0.0 would confuse things.

  3. 2011/10/24 18:24

    First, great post!

    Today, while copying some testing configuration on Cat6500 Sup2T (IOS 15.0(1)SY), I got
    some error message regarding the OSPF router-id. I was left with the impression that IOS refused to start the OSPF process when the router-id was not one of the IP interfaces in that VRF. (IOS 12.2(33)SXIsomething have not had any problems with it.)

    I was surprised but I had no time to check it further. I will have to test the configs again some other day, I’ll try to remember to get back with the results.

    • 2011/10/26 16:48

      Now after further checking looks like there was nothing wrong. IOS just complained because the VRF did not have any interfaces up BEFORE the router-id command was pasted in. The OSPF process then started normally after the router-id command was issued.

Trackbacks

  1. OSPF Router ID Confusion

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: