From: Paul Cosgrove (paul.cosgrove@heanet.ie)
Date: Thu Aug 21 2008 - 15:43:44 ART
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: 275301Please 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