Re: OSPF neighbor down, yet OSPF database is not

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

Hi Geert,

That is an arkward issue if you can't clear the ospf process, clear ip
ospf redistribution, or modify the redistribution rules to temporarily
deny the prefix from one of the two redistributing routers.

One ugly method which would work, but which I would not use (for obvious
reasons), would be to source an identical prefix from another ospf
router but using a different network type on an interface which is down.
 This causes unstability of the LSAs for that prefix, as each router
disagrees about the link state and sends its version of reality to the
world. If it is a transit link, and you have an alternate similar path,
then you could in theory do that if you don't mind spf recalculations
every 10 seconds; if the link has hosts, those hosts will loose
connectivity. In practice of course contacting the person who has
access to the router is by far the best course of action.

Paul.

Geert Nijs wrote:
> Thanks Paul. That explains a lot !
>
> So the LSA is not reflooded but only marked as "invalid", consequence: the route tag on the LSA is not updated also.
>
> My problem is that on router 19.16.139.114, i am redistributing from BGP into OSPF with matching communities (ie. community 1:100 gets OSPF tag 100, 1:200 gets OSPF tag 200).
> In BGP, i have changed my tags on some prefixes. However, the OSPF tags don't get updated !! On 19.16.139.114, i can see the BGP route with community 1:200, yet in OSPF
> the damned route is still in the OSPF database with tag 100. Apparently, Cisco doesn't consider a "community change" as a "BGP route change" and doesn't re-redistribute or refresh into OSPF.
> Additional problem is that i don't have "clear" permissions on this 19.16.139.114 router, so my only option was to bounce the OSPF interface on the other side. Yet, mysteriously, that didn't help also (the point of my posting). So now i am stuck: the only way to update my tags is to get "clear" access on the 19.16.139.114 router and clear the ospf process. I need the tags to update, because some downstream OSPF routers have matching route-maps on these tags.
>
> Unless there is maybe another advanced option that i am overlooking.......
>
> (i know, yes, i should not redistribute into OSPF and extend my BGP session to the downstream destination router. This way i transport the BGP routes (with up to date communities) to the downstream destination router. However - the destination router is also running BGP and i don't want to link both BGP domains (they are from different providers :-) so they can see each other's AS numbers.
>
> Interesting stuff that i am stuck with, no ;-)
>
> regards,
> Geert
> CCIE #13729
>
>
>
> ________________________________
> From: Fahad Khan [fahad.khan@gmail.com]
> Sent: 22 August 2008 08:44
> To: Paul Cosgrove
> Cc: Geert Nijs; ccielab@groupstudy.com
> Subject: Re: OSPF neighbor down, yet OSPF database is not updated/refreshed ?
>
> 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<mailto: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<http://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<http://19.16.139.113> and 19.16.139.114<http://19.16.139.114> to be
> tagged with 401? Perhaps clearing the process on 19.16.139.114<http://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<mailto:fahad.khan@gmail.com>]
>> Sent: 21 August 2008 13:30
>> To: Geert Nijs
>> Cc: ccielab@groupstudy.com<mailto: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><mailto: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><http://10.50.0.0> 19.16.139.113<http://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><http://10.50.0.0> 19.16.139.114<http://19.16.139.114><http://19.16.139.114> 1040 0x8000004D 0x001B2D 400
>> 10.50.32.0<http://10.50.32.0><http://10.50.32.0> 19.16.139.113<http://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><http://10.50.32.0> 19.16.139.114<http://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><http://19.16.139.113> 1 FULL/BDR 00:00:19 10.63.14.1<http://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><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><http://10.50.0.0> 19.16.139.113<http://19.16.139.113><http://19.16.139.113> 1725 0x800001EE 0x00E290 401 <<<-- STILL HERE ???
>> 10.50.0.0<http://10.50.0.0><http://10.50.0.0> 19.16.139.114<http://19.16.139.114><http://19.16.139.114> 1344 0x8000004D 0x001B2D 400
>> 10.50.32.0<http://10.50.32.0><http://10.50.32.0> 19.16.139.113<http://19.16.139.113><http://19.16.139.113> 1725 0x800001EE 0x0081D1 401 <<<-- STILL HERE ???
>> 10.50.32.0<http://10.50.32.0><http://10.50.32.0> 19.16.139.114<http://19.16.139.114><http://19.16.139.114> 1344 0x8000004D 0x00B96E 400
>>
>> ping 19.16.139.113<http://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><http://10.50.0.0>
>> OSPF Router with ID (192.168.1.1<http://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><http://10.50.0.0> (External Network Number )
>> Advertising Router: 19.16.139.113<http://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><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><http://10.50.0.0> (External Network Number )
>> Advertising Router: 19.16.139.114<http://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><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><http://10.50.0.0>
>> OSPF Router with ID (192.168.1.1<http://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><http://10.50.0.0> (External Network Number )
>> Advertising Router: 19.16.139.113<http://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><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><http://10.50.0.0> (External Network Number )
>> Advertising Router: 19.16.139.114<http://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><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.
>
>
>
> --
> 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
> 

-- 
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