OSPF – How to withdraw an OSPF route

Todays post will cover how OSPF withdraws a route after a link failure or deconfiguration. 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’s 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 it’s 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 it’s 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 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 it’s 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 it’s 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 it’s 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.

 

(Visited 92 times, 10 visits today)
Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInShare on RedditBuffer this pageShare on StumbleUpon

4 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

    • 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

Leave a Reply

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