From: Fahad Khan (fahad.khan@gmail.com)
Date: Fri Aug 22 2008 - 03:44:44 ART
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.
>
-- *FAHAD KHANBE 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.*
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