Re: OSPF neighbor down, yet OSPF database is not

From: Paul Cosgrove (paul.cosgrove@heanet.ie)
Date: Fri Aug 22 2008 - 07:24:03 ART

Hi Fahad,

You are correct, MAXAGE is 1 hour and is defined that way in the RFC so
cannot be changed. If there was some way you would have to apply it to
every router as they expect to received an updated LSA from the
advertising router before it expires.

My understanding of "timer lsa-group-pacing <sec>" (or "timer pacing
lsa-group") is that it controls the delay between groups of LSAs which
are refreshed, checksummed or aged. So if you have 10 LSAs which need
to be refreshed in t seconds, and 20 which will need to be refreshed in
t+120 seconds, the second group of LSA refreshes will be delayed until
the lsa-group-pacing timer has expired. By delaying the sending of LSAs
this way, you can send them in batches and so receiving routers run
fewer SPFs. The similar "timers pacing flood" command introduces a
delay between individial LSAs which comprise one of the LSA groups,
which may help slower routers.

I'm glad you made sense out of my earlier email, as reading my own post
now I see it is more than a little confusing. I mentioned "Only the LSA
for the affected link is reflooded, as that will have changed state."
but had used 'affected' to mean all routes dependent on the failed link
just before that.

Just to clarify that - the two recently disconnected rouers will each
update their own router LSAs and flood those out. Although each router
learns (say 99) other routes from the other, they cannot flood MAXAGE
LSAs for those routes as they were only learned, not locally originated.
 So instead the LSAs are just marked locally as not routable. Depending
on the link type the routers may also send a network LSA. The flooded
LSAs alert other routers in the area to the change, so they can also
locally invalidate LSAs for links which are no longer reachable.

Paul.

Fahad Khan wrote:
> Thank you paul, Your got the scenario exactly.I got ur point. If I am not
> wrong this MAXAGE is 3600 sec. Because after this time interval, the LSA was
> no loger seen. can I modify this max age?can u elaborate the use of this
> command "timer lsa-group-pacing <sec>" (run in router mode)?
>
> Thanks alot.
>
>
> On 8/21/08, Paul Cosgrove <paul.cosgrove@heanet.ie> wrote:
>> Hi Geert,
>>
>> There is a difference in behaviour when a change in a transit link is
>> detected, from when a link is specifically invalidated by a
>> connected/advertising router.
>>
>> A router can only MAXAGE its own LSAs, not those it has learned. If you
>> had instead left the neighbor relationship in place, and shutdown
>> another interface (e.g. loopback) on the 19.16.139.114 router, the
>> advertising router would have sent out a new LSA with MAXAGE set. In
>> that case that route would quicky be removed from the ospf databases of
>> other routers.
>>
>> In your case I understand you have instead dropped the connections
>> between the two routers. They perform an spf recalculation and
>> determine that they can no longer reach each other. Lets say they
>> normally each learn 99 routes from each other.
>>
>> You can see from your output that when the neighbor relationship times
>> out, rather than clearing all the affected routes from their ospf
>> databases, they simply mark them as invalid (by removing the routing
>> bit) and leave them there until they hit maxage. Only the LSA for the
>> affected link is reflooded, as that will have changed state.
>>
>> If the neighbor relationship is re-established before the other 99
>> routes hit maxage, and before they need to be reflooded (next 30 min
>> interval), the two routers can just exchange database sequence numbers
>> to synchronise rather than performing a full databases exchange. Only
>> the recovered link changes state, so only that needs to be reflooded.
>> This flooded LSA will trigger other routers in the area to run an spf
>> recalculation, based on which they will determine that the 99 dependent
>> routes are also reachable again.
>>
>> I'm not sure I completely understand your scenario regarding the tags.
>> Do you want the route from both 19.16.139.113 and 19.16.139.114 to be
>> tagged with 401? Perhaps clearing the process on 19.16.139.114 may help?
>>
>> Paul.
>>
>> Geert Nijs wrote:
>>> If neighbor goes down, i would presume all LSA of that router become
>> invalid - instantly - and OSPF should remove them from the database and to a
>> recalculation.
>>> regards,
>>> Geert
>>> ________________________________
>>> From: Fahad Khan [fahad.khan@gmail.com]
>>> Sent: 21 August 2008 13:30
>>> To: Geert Nijs
>>> Cc: ccielab@groupstudy.com
>>> Subject: Re: OSPF neighbor down, yet OSPF database is not
>> updated/refreshed ?
>>> For how long you found this behaviour? I mean to say that, may be after a
>> certain period of time,you saw them out of database table. Database table
>> contains LSAs only, may be this has some thing to do with LSA aging time.
>>> On 8/21/08, Geert Nijs <Geert.Nijs@simac.be<mailto:Geert.Nijs@simac.be>>
>> wrote:
>>> Hi all,
>>>
>>> I have strange stuff going on in my network. Yesterday, i bounced an
>> interface (shut/no shut) to reset an OSPF neighborship.
>>> However, when the neighbor was down, it seemed OSPF didn't update its
>> database. The routes were still in the OSPF database. I don't understand:
>>> The routes concerned are external redistributed routes:
>>>
>>> show ip ospf database
>>>
>>> Type-5 AS External Link States
>>> Link ID ADV Router Age Seq# Checksum Tag
>>> 10.50.0.0<http://10.50.0.0> 19.16.139.113<http://19.16.139.113>
>> 1421 0x800001EE 0x00E290 401 <<<------------ look at these routes
>>> 10.50.0.0<http://10.50.0.0> 19.16.139.114<http://19.16.139.114>
>> 1040 0x8000004D 0x001B2D 400
>>> 10.50.32.0<http://10.50.32.0> 19.16.139.113<http://19.16.139.113>
>> 1421 0x800001EE 0x0081D1 401 <<<------------ look at thse routes
>>> 10.50.32.0<http://10.50.32.0> 19.16.139.114<http://19.16.139.114>
>> 1040 0x8000004D 0x00B96E 400
>>> sh ip ospf neighbor
>>> 19.16.139.113<http://19.16.139.113> 1 FULL/BDR 00:00:19
>> 10.63.14.1<http://10.63.14.1> Vlan997
>>> Then i disable the interface:
>>> %OSPF-5-ADJCHG: Process 1, Nbr 19.16.139.113<http://19.16.139.113> on
>> Vlan997 from FULL to DOWN, Neighbor Down: Dead timer expired
>>> sh ip ospf database
>>> 10.50.0.0<http://10.50.0.0> 19.16.139.113<http://19.16.139.113>
>> 1725 0x800001EE 0x00E290 401 <<<-- STILL HERE ???
>>> 10.50.0.0<http://10.50.0.0> 19.16.139.114<http://19.16.139.114>
>> 1344 0x8000004D 0x001B2D 400
>>> 10.50.32.0<http://10.50.32.0> 19.16.139.113<http://19.16.139.113>
>> 1725 0x800001EE 0x0081D1 401 <<<-- STILL HERE ???
>>> 10.50.32.0<http://10.50.32.0> 19.16.139.114<http://19.16.139.114>
>> 1344 0x8000004D 0x00B96E 400
>>> ping 19.16.139.113<http://19.16.139.113>
>>> ..... <<-- he is down for sure
>>>
>>> Why doesn't the database get updated ? I need the route to be removed and
>> re-inserted/refreshed with an up-to-date tag.
>>> regards,
>>> Geert
>>> CCIE #13729
>>>
>>>
>>>
>>> Details when neighbor is UP:
>>>
>>>
>>> # sh ip ospf database external 10.50.0.0<http://10.50.0.0>
>>> OSPF Router with ID (192.168.1.1<http://192.168.1.1>) (Process ID
>> 1)
>>> Type-5 AS External Link States
>>> LS age: 1897
>>> Options: (No TOS-capability, DC)
>>> LS Type: AS External Link
>>> Link State ID: 10.50.0.0<http://10.50.0.0> (External Network Number )
>>> Advertising Router: 19.16.139.113<http://19.16.139.113>
>> <---- this is it
>>> LS Seq Number: 800001EE
>>> Checksum: 0xE290
>>> Length: 36
>>> Network Mask: /19
>>> Metric Type: 2 (Larger than any link state path)
>>> TOS: 0
>>> Metric: 60
>>> Forward Address: 0.0.0.0<http://0.0.0.0>
>>> External Route Tag: 401
>>>
>>> Routing Bit Set on this LSA <--- what does this
>> mean ? this is the redundant path route and currently the preferred one. Is
>> there no refresh when "routing bit" not set ?
>>> LS age: 1516
>>> Options: (No TOS-capability, DC)
>>> LS Type: AS External Link
>>> Link State ID: 10.50.0.0<http://10.50.0.0> (External Network Number )
>>> Advertising Router: 19.16.139.114<http://19.16.139.114> <---redundant
>> path, currently selected (see cost)
>>> LS Seq Number: 8000004D
>>> Checksum: 0x1B2D
>>> Length: 36
>>> Network Mask: /19
>>> Metric Type: 2 (Larger than any link state path)
>>> TOS: 0
>>> Metric: 10
>>> Forward Address: 0.0.0.0<http://0.0.0.0>
>>> External Route Tag: 400 <<<--- i
>> want this tag to update !!
>>>
>>> Details when neighbor is DOWN:
>>>
>>> # sh ip ospf database external 10.50.0.0<http://10.50.0.0>
>>> OSPF Router with ID (192.168.1.1<http://192.168.1.1>) (Process ID
>> 1)
>>> Type-5 AS External Link States
>>> LS age: 1984
>>> Options: (No TOS-capability, DC)
>>> LS Type: AS External Link
>>> Link State ID: 10.50.0.0<http://10.50.0.0> (External Network Number )
>>> Advertising Router: 19.16.139.113<http://19.16.139.113>
>> <-------- STILL HERE !
>>> LS Seq Number: 800001EE
>>> Checksum: 0xE290
>>> Length: 36
>>> Network Mask: /19
>>> Metric Type: 2 (Larger than any link state path)
>>> TOS: 0
>>> Metric: 60
>>> Forward Address: 0.0.0.0<http://0.0.0.0>
>>> External Route Tag: 401
>>>
>>> Routing Bit Set on this LSA
>>> LS age: 1603
>>> Options: (No TOS-capability, DC)
>>> LS Type: AS External Link
>>> Link State ID: 10.50.0.0<http://10.50.0.0> (External Network Number )
>>> Advertising Router: 19.16.139.114<http://19.16.139.114>
>>> LS Seq Number: 8000004D
>>> Checksum: 0x1B2D
>>> Length: 36
>>> Network Mask: /19
>>> Metric Type: 2 (Larger than any link state path)
>>> TOS: 0
>>> Metric: 10
>>> Forward Address: 0.0.0.0<http://0.0.0.0>
>>> External Route Tag: 400
>>>
>>>
>>>
>>> ________________________________
>>> disclaimer : http://webservices.simac.be/disclaimer.htm
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> FAHAD KHAN
>>>
>>> BE Computer Systems NED,
>>>
>>> CCNA,CCDA,CCNP,FOUNDFE,CLSE,QOS,JNCIA,JNCIS,MCP,CCIE (Written)
>>>
>>> Systems Support Engineer, Premier Systems (Pvt) limited,
>>>
>>> Karachi, Pakistan
>>>
>>> 92-321-2370510.
>>>
>>> ________________________________
>>> disclaimer : http://webservices.simac.be/disclaimer.htm
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> HEAnet Limited
>> Ireland's Education & Research Network
>> 5 George's Dock, IFSC, Dublin 1, Ireland
>> Tel: +353.1.6609040
>> Web: http://www.heanet.ie
>> Company registered in Ireland: 275301
>>
>> Please consider the environment before printing this e-mail.
>>
>
>
> 

-- 
HEAnet Limited
Ireland's Education & Research Network
5 George's Dock, IFSC, Dublin 1, Ireland
Tel:  +353.1.6609040
Web:  http://www.heanet.ie
Company registered in Ireland: 275301

Please consider the environment before printing this e-mail.

Blogs and organic groups at http://www.ccie.net

This archive was generated by hypermail 2.1.4 : Mon Sep 01 2008 - 08:15:31 ART