Ethan Banks On productivity.

OECG – Chapter 10


We’ve got 2 routers running OSPF. How to they go about getting to know each other and exchanging their link state databases?

  • Before an OSPF router can start acting as such, it must have a router-id, or RID. The RID is in the form of an IP address, although that address need not coincide with an IP assigned to the router itself. IOS routers use the following steps, in order, to choose their RID.
    • Use the RID defined by the router-id command in the router ospf paragraph.
    • Use the highest IP address on any up/up loopback interface.
    • Use the highest IP on any up/up non-loopback interface.
  • The RID does not have to be matched by an OSPF network command.
  • The RID doesn’t have to be reachable by the IP routing table.
  • If the router is choosing the RID himself, that choice is based on the status of interfaces at the time the router is deciding things.
  • The RID never changes, unless the OSPF process restarts, or the RID is manually changed by a human.
  • If a RID changes, everyone else in the same OSPF area will perform a new SPF calculation.
  • Some folks like to set their RID’s with an obvious numbering scheme that helps them easily identify the routers on their network.

So let’s talk a bit more about how the routers become neighbors.

  • OSPF encapsulates its messages inside of IP, using IP protocol 89 (not TCP port 89).
  • There are several OSPF message types to be aware of. These are NOT the LSA types, which we’ll cover later.
    • Hello – neighbor discovery and keep-alive.
    • Database Description (DD or DBD) – used to send LSA headers usually at the beginning of a topology exchange, so that one router knows what LSA’s the other has.
    • Link-State Request (LSR) – “Hey – I want to know about this (or these) LSA (or LSA’s)!”
    • Link-State Update (LSU) – “Hey – here’s a everything there is to know about this LSA!” (usually sent as an LSR response).
    • Link-State Acknowledgement (LSAck) – “Thanks! I got the LSU.”
  • LSA’s are a part of this picture in that they are exchanged via LSU’s, but LSA’s are not an OSPF message type – they are rather payload.
  • So then, to become neighbors, various OSPF messages of the types listed above are exchanged. Each of these message exchanges result in the neighbors being in states that the neighbor tracks. These states, along with the messages exchanged, follow below:
    • INIT – mutual hellos – “Hi! I’m OSPF router RID”
    • 2-WAY – “Yes, I saw your hello…hello yourself, I’m!”
    • EXSTART – “Hello again – we need to choose a DR” and/or “Hello, DR is x.x.x.x.”
    • EXCHANGE – “My database of LSA’s look like so.” (Mutual DD messages exchanged.)
    • LOADING – “Hey, I need to see everything for these LSA’s” “Okay, here’s everything I’ve got.” “Okay, thanks, I got the update.”
    • FULL – All LSA’s have been exchanged, and now these 2 OSPF routers are considered fully adjacent. They will keep in touch via hellos.
  • You can check on neighbor status with “show ip ospf neighbor”.
  • Some considerations regarding the hello process:
    • Hellos are sent as a multicast to, sourced from the router’s primary IP address on that interface. OSPF adjacencies will not form on secondary addresses.
    • Hellos are used for sanity checks of the following parameters:
      • Authentication
      • Matching subnets, including subnet mask (unlike EIGRP which will allow neighbors to form, as long as the IP they are talking to falls within the same local subnet, even if the remote subnet mask is different. Which can SCREW UP YOUR DAY. Ask a friend of mine in Dallas.)
      • Matching areas – OSPF adjacencies can’t form if the router interfaces are in different areas.
      • Same area type (stub, not-so-stubby, etc. which we’ll talk more about later)
      • Unique RID’s.
      • Equal hello and dead timers.
    • Any mismatches, then adjacencies don’t form…and by the way, your MTU’s must match as well, or the OSPF adjacency won’t form, although this isn’t a Hello process sanity check – it’s just a fact of life. That can screw up your day, too – been there.
    • And finally – hellos are sent periodically (the hello interval to be exact) so that neighbor stay in touch.
      • The default hello interval is 10 seconds by default on LAN interfaces.
      • The default hello interval is 30 seconds by default on T1 and slower WAN interfaces.
      • The dead interval (when an OSPF neighbor is included amongst the dearly departed and considered unreachable) defaults to 4x the hello interval.
  • Once the routers have completed their hellos, they exchange DD packets, essentially headers of the LSA’s in their database. DD’s are acknowledges one for one, not with an ACK packet, but rather with a copy of the received DD sent back to the originating router.
  • Now that the routers have exchanged DD’s, they now know what each other has to offer in the form of LSA’s. So now the router must determine what LSA’s his new OSPF neighbor has that he needs a copy of.
    • If the LSA is missing from his LSDB, he will form an LSR and request
      that LSA.
    • If the LSA his neighbor has is newer than the one he has, he will request that LSA via an LSR as well. This is determined via the LSA’s sequence number. New LSA’s start with 0x80000001, increment, and then wrap to 0x7FFFFFFF. If the LSA sequence number gets to 0x8000000, then the LSA is flooded back through the network.
    • LSR’s are responded to with LSU’s. LSU’s are acknowledged either by the same LSU getting sent back, or by and LSAck.
  • Once LSA’s have been exchanged, the new neighbors are in a “FULL” state and should have identical LSDB’s. At that point, the routers can run the SPF algorithm, and populate their routing tables appropriately.
By Ethan Banks
Ethan Banks On productivity.

You probably know Ethan Banks because he writes & podcasts about IT. For example, he co-authored "Computer Networks Problems & Solutions" with Russ White.

This site is Ethan on productivity--not tech so much.

Find out more on his about page.