OSPF – How to withdraw an OSPF route

OSPF – How to withdraw an OSPF route

Todays post will cover how OSPF withdraws a route after a link failure or de-configuration. There are some fantastic resources out there describing how to originate and advertise links and prefixes, but I haven’t found a good summary of OSPF link failure handling.

Router LSA

We’ll cover link-down events within an area first, because it is the easiest to explain.  As we discussed in my previous router LSA P2P post,  OSPF represents routes within an area by defining them as nodes and links with attached prefixes (stub networks).

When a link fails, the connected OSPF routers send an updated LSA which omits the now shutdown link from the list of connected links.  This new LSA has an incremented sequence number which replaces the old LSA in the LSDB of all routers in that area.

Thus the connected routers have now implicitly withdrawn that link and the associated prefix by overwriting the receiving routers LSDB with an updated router LSA.  OSPF will kick off a new SFP run, calculate a new topology and remove any routes associated with that withdrawn link.

Summary LSA

Remember that Summary LSAs are pure distance-vector advertisements. Summary LSAs don’t advertise link information, just prefix information (a.k.a. routes). Assuming no summarisation had been configured on the ABR, it will originate a single Type-3 Summary LSA for every Type-1 stub-network prefix it had installed in the ABRs routing table.

Now that the prefix associated with the failed link has been implicitly withdrawn, it has been removed from the routing table.  The ABR now needs to withdraw the summary LSA it had flooded into the backbone. The ABR informs all backbone routers that it can no longer reach the prefix from the failed link and asks the those routers to flush the Type-3 LSA for that prefix from their LSDBs.

The ABR does this by sending a new Summary LSA with and updated sequence number. The prefix is flagged as unreachable by setting the 24-bit metric field to all ones. This is called LSInfinity and has a decimal value of 16777215.

The LSA requests that it be flushed from the receiver’s LSDB by setting the LSAge to MaxAge (3600 seconds). If there are other ABRs in the network, they will cascade the prefix removal by re-originating these ‘poisoned’ Type-3s into their connected non-backbone areas.

External LSA

External LSAs behave almost identically to Summary LSAs.   As soon as the associated link goes down the ASBR will send an updated Type-5 LSA for the prefix with an updated sequence number. Again it will set the link cost to the 24-bit LSIninity and the LSAge to MaxAge.

In fact the type-5 prefix withdrawal is even simpler as Type-5 LSAs have domain-wide flooding scope.  As such, the poisoned LSA will immediately be flooded to all routers in the OSPF domain, regarded as unreachable and flushed from the receivers LSDB and routing tables.

9 thoughts on “OSPF – How to withdraw an OSPF route

  1. Just in case anybody drops by after this, the article is valid for P2P links only. For MA networks there is a SLA type 2 that needs to be withdrawn and that happens not by incrementing the Sqc# but by setting the LSA age to 3600sec…

  2. Just a question, why the poison LSA3 needs to set LSInfinity if at the same time is setting max age to 3600sec which will make receiver router to flush this LSA and consequently making the route unreachable?
    I wonder if this will have to do with the flushing of the LSA not happening at 3600 sec but at 3601 instead? See below output with just importan fields
    ## Before the withdrawal
    R2#show ip ospf database summary 1.1.1.1
    LS age: 163
    LS Seq Number: 80000001
    TOS: 0 Metric: 2
    ## After shutting down 1.1.1.1
    R2#show ip ospf database summary 1.1.1.1
    Delete flag is set for this LSA
    LS age: MAXAGE(3600)
    LS Seq Number: 80000002
    TOS: 0 Metric: 16777215
    R2#show ip ospf database summary 1.1.1.1
    Delete flag is set for this LSA
    LS age: MAXAGE(3601) >>> the LSA still last 1 sec after being poisoned
    LS Seq Number: 80000002
    TOS: 0 Metric: 16777215
    R2#show ip ospf database summary 1.1.1.1
    Here it disappeared from database

    1. Hi Saru,
      The quick answer is that I’m not 100% sure why both approaches are taken. My best guess is that this is a belt-and-braces approach, with the LSInfinity being processed as invalid, thus flushing the route from RIB and then FIB on the switch. The MaxAge then is a cleanup to ensure there’s no unnecessary LSA state left lying around the LSDB on the receiving router.
      Regards,
      John H

  3. The topic of the article is great and indeed is rarely explained., thank you! However I find a bit confusing the use of it’s for either the verb or the possessive adjective. It justs makes the reading more difficult for nothing…

    Thanks again, Rodrigo

    1. Hi Rodrigo,
      You make a fair point. I find that contraction/posessive difficult to remember. I’ve not removed all ‘it’s’ from the post and i hope that makes it more readable. Thanks for the feedback,
      John H

  4. I have a question here. Though, the originating switch sends LSA updates with in that area, how the database of the router which is directly connected to this withdrawn link. And if the neighbor connected to this withdrawn link is reachable via another route, will this route be relearnt after deleting the existing entry(both in the router which is directly connected to the withdrawn link as well in other routers in that area) or is there any waiting period ?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.